[GLASSFISH-15825] Allow user to specify additional metadata while declaratively publishing EJBs to Service Registry Created: 03/Feb/11  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1_b40
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred


Allow user to do the following:
#Exports EJBs with name com.acme.FooEJB and com.acme.BarEJB with additional service properties to the
Service Registry

Export-EJB: com.acme.FooEJB; Foo=Bar, com.acme.BarEJB; Foo1=Bar1; Foo2=Bar2

Comment by TangYong [ 13/Oct/12 ]

sahoo, previously, I have commented the following on osgi/cdi draft jira[1],

Thinking such a use case, if a user wants to use cdi to export a stateless ejb,
he/she maybe does the following:


public class UserAuthServiceEJB2 implements UserAuthService { ... }

Then, if using CDI to export a ejb in OSGi, CDI must support exporting or
registering ejb-related metadata in order to comply with RFP 152 using liking

Now, backing to the improvement, "Export-EJB: com.acme.FooEJB; Foo=Bar, com.acme.BarEJB; Foo1=Bar1; Foo2=Bar2" really can be implemented using osgi/cdi enhancement, pl. see GLASSFISH-18972 , maybe should be using the following declaretive way:


@Publish({ @property(name="Foo", value="Bar"))
public class com.acme.FooEJB implements com.acme.Foo

{ ... }

So, the first thing is to implement GLASSFISH-18972 .

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.

Generated at Mon Aug 31 16:14:42 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.