[GLASSFISH-18514] CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled. Created: 15/Mar/12  Updated: 20/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: aaronjwhiteside Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log    

 Description   

CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled.

Please see attached server.log

You can see after the server has started I manually redeployed the WAB and CDI was enabled that time.

If I do not redeploy the WAB CDI is not enabled and I get NPE when trying to access a JAX-RS resource that @Inject's a @OSGiService(dynamic=true).



 Comments   
Comment by aaronjwhiteside [ 16/Mar/12 ]

So I think I tracked down the issue.

The org.glassfish.fighterfish.osgi-cdi bundle which provides the cdi support for WAB's has a run level of 2. However any bundle that is deployed under <domain>autodeploy/bundles always has a run level of 1.

So when you start glassfish that already has bundles under autodeploy/bundles and no osgi-cache (to tell it the deploy order, if you deployed something after the server was already started) it'll start the osgi-cdi bundle after the WAB bundle. And thus CDI support is never enabled for WAB's.

I tried adding

felix.fileinstall.start.level=4 

to glassfish3/glassfish/config/osgi.properties

But the bundles deployed from <domain>/autodeploy/bundles still seem to start in runlevel 1.

Comment by aaronjwhiteside [ 16/Mar/12 ]

For reference:
http://felix.apache.org/site/apache-felix-file-install.html

Comment by aaronjwhiteside [ 16/Mar/12 ]

OK so it turns out that all the felix.fileinstall* properties in osgi.properties are totally ignored and should probably be removed.

The real file doing the configuration is:

glassfish3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg

However if I add the line:

felix.fileinstall.start.level=4

to this file, it still does not set the run level for bundles under autodeploy/bundles, they still start at run level one.

However I do get a log message printed out:

[#|2012-03-15T20:08:20.322-0400|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName=Thread-2;|felix.fileinstall.start.level set, but not a int: 4 |#]

Which is interesting, apparently 4 really isn't an int.. I guess this is an ERROR even though it says INFO.. or maybe a WARN as it seems to have ignored the config.

Without this fixed OSGi is pretty much useless.

Comment by aaronjwhiteside [ 16/Mar/12 ]

Fixing this issue will probably fix another bug I reported too.

http://java.net/jira/browse/GLASSFISH-18508

And a bunch of other random weird stuff I was pulling my hair out over..

Comment by aaronjwhiteside [ 16/Mar/12 ]

OK so after more investigation it turns out you have to set:

felix.fileinstall.start.level=4

in osgi.properties AND org.apache.felix.fileinstall-autodeploy-bundles.cfg or less it does not get picked up. This is probably a bug too.

(and obviously, even through I omitted it you must set glassfish.osgi.start.level.final=4 in osgi.properties too).

So now I can see that the start level of my WAB bundle is really 4, however CDI still does NOT get enabled. I have to remove the war and redeploy it again, after the server has started for CDI to kicked in.

So my assumption that the start level's were the issue seems to be moot, however having a start level of 1 for the bundles under autodeploy/bundles and a start level of 2 for most of glassfish's osgi to jee integration bundles is still a bug. The bundles under autodeploy/bundles should start in start level 4.

So the question is now, if not start levels, what is causing CDI to not load and required a redeploy of the war to be enabled???

Comment by Sanjeeb Sahoo [ 16/Mar/12 ]

No, I don't understand some of your observations. This is how things are supposed to work:

no osgi-cache:
fileinstall is started at start level 2 and it is configured to start after modules/autostart/,
which means first time (same as no osgi cache) the server starts, fileinstall will come into effect
after all bundles in modules/autostart/. Once fileinstall is started, it will then go onto deploy
autodeploy/bundles/. Now, let's say one such bundle is a WAB that uses CDI.
Since osgi-cdi is already installed,when the WAB is processed, osgi-cdi will process the WAB as well.

Let's stop the server and restart. Upon restart, the WAB is started at start level 1 which means it is
started before osgi-web-container and osgi-cdi are started. But, the WAB processing is deferred until
osgi-web-container is started. When server reaches start level 2, osgi-web-container is started and it
processes the WAB. It does not matter whether osgi-cdi is active or not. It only has to be in INSTALLED
state for it to be useful. So, when the WAB is processed by osgi-web-container, osgi-cdi will be used
as well.

So, I don't see a case why osgi-cdi is not used in your case. Could you supply a test case with instructions?
I tried a WAB+CDI test case and could not reproduce.

A note about fileinstall start level:
The bundles in autodeploy/bundles/ are started at start level 1. This seems like
a bad configuration. They should have start level matching that of fileinstall, which is 2. I will
open a separate issue to do this. But, I can't see it affecting any functionality now.

To change the start level of bundles in autodeploy/bundles, edit osgi.properties file.
modules/autostart/o.a.f.fileinstall-autodeploy-bundles.cfg is not used any more.
If you set a start level higher than 2, then you must also configure the server to change the
start level to that value. Currently, server sets final start level to 2 using the property:
glassfish.osgi.start.level.final=2
Change it to the higher value, else your bundles in autodeploy/bundles will never get activated.

Comment by aaronjwhiteside [ 16/Mar/12 ]

After clearing the osgi-cache (I keep forgetting) CDI now works, so changing the start level fixed the issue.

Can this please be fixed in the next release?

Comment by Sanjeeb Sahoo [ 17/Mar/12 ]

What you want to be fixed? start level of bundles/autodeploy/? Sure it can be (could you file an issue under osgi category?), but, as I mentioned earlier, I don't understand why you had to change start level. Are you really sure things didn't work for you as is? I would love to understand it better. Do you have a reproducible test case?

Comment by tlcksnyder [ 20/Mar/13 ]

not attempting to fix without a reproducible test case, or better description of reproduction steps.





[GLASSFISH-15119] CDI Interceptor still not working in OSGi Created: 12/Dec/10  Updated: 25/Mar/13

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

Type: Bug Priority: Major
Reporter: chaoslayer Assignee: mtaube
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested with promoted b32


Attachments: GZip Archive interceptor-osgi-test-2-fixed.tar.gz     GZip Archive interceptor-osgi-test-2.tar.gz     File interceptor-osgi-test.tar.bz2    
Issue Links:
Dependency
depends on GLASSFISH-15249 Support vanilla OSGi bundles as bean ... Open
Tags: 3_1-exclude, 3_1-next, 3_1_1-scrubbed

 Description   

I just revisited GLASSFISH-13513 and GLASSFISH-14831 to see if it is possible to plug in interceptors the CDI way around EJBs.

Indeed when deploying a prepared package as non-OSGi the interceptor gets invoked but not when using OSGi deployment.

Therefore I made up another test case which should be sufficient for a confirmation of this issue:

  • maven reactor build with 4 modules
  • build.sh script for test:
  • "mvn clean install"
  • copy resulting artifacts into .../autodeploy/bundles/ folder of a running glassfish domain
  • wait for (re-)deployment
  • using "curl" to call the web service
  • search for a fault inside the returned XML

So basically for a test I issue a command like this:

$ GF_DOMAIN_DIR=/srv/servers/gf-3.1-b32/glassfish/domains/domain1/ ./build.sh

Well, I also can say that with the old @Interceptors(

{SecurityInterceptor.class}

) method the interceptor is being called so I suspect it is not injected at all.

This test throws a fault if the interceptor is being invoked. If no fault occurs and the response is valid there must be something wrong.



 Comments   
Comment by chaoslayer [ 12/Dec/10 ]

Thanks for reopening the issue, I was not allowed to.

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

Assigning this to cdi team after talking to Siva. It is a bug in their layer.

Comment by chaoslayer [ 14/Dec/10 ]

Fixed the project and enabled interceptor class in beans.xml for the user service [interceptor-osgi-test-2-fixed.tar.gz].

Just tested again with a completely clean b32:

INFO: Portable JNDI names for EJB UserServiceImpl : [java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl!org.glassfish.cditest.user.api.UserService, java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl]
INFO: WELD-000900 $

{parsedVersion (osgiVersion}

)
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
SEVERE: Exception while loading the app
INFO: Deleted /tmp/osgiapp5600363451663621402
SEVERE: Failed while deploying bundle org.glassfish.cditest.user.service [252]
WARNING: Failed to deploy bundle org.glassfish.cditest.user.service [252]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.service [252] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.service [252] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:132)
at org.glassfish.osgijavaeebase.JavaEEExtender.handleEvent(JavaEEExtender.java:117)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$000(JavaEEExtender.java:56)
at org.glassfish.osgijavaeebase.JavaEEExtender$1.run(JavaEEExtender.java:100)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 5 more
Caused by: org.glassfish.deployment.common.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.interceptor.SecurityInterceptor</class> in bundle://252.0:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:187)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:302)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
... 7 more
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.interceptor.SecurityInterceptor</class> in bundle://252.0:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:471)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:344)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184)
... 12 more

So I guess it has to do with class visibility here. Although all required classes are visible for the bundle it may once again be a deployment issue:

250|Active | 1|Apache Felix Bundle Repository (1.6.2)
251|Active | 1|OSGi/JTA implementation in GlassFish (3.1.0.b32)
252|Active | 1|User Service OSGi Bundle (2.0.0.SNAPSHOT)
253|Active | 1|User Web Service OSGi Web Service (2.0.0.SNAPSHOT)
254|Active | 1|security.impl OSGi Bundle (2.0.0.SNAPSHOT)
255|Active | 1|security.api OSGi Bundle (2.0.0.SNAPSHOT)
g! inspect p c 255
org.glassfish.cditest.security.api [255] exports packages:
----------------------------------------------------------
org.glassfish.cditest.security.api; version=0.0.0 imported by:
org.glassfish.cditest.user.service [252]
org.glassfish.cditest.security.impl [254]
g! inspect p c 254
org.glassfish.cditest.security.impl [254] exports packages:
-----------------------------------------------------------
org.glassfish.cditest.security.interceptor; version=0.0.0 imported by:
org.glassfish.cditest.user.service [252]
g! inspect p r 252
org.glassfish.cditest.user.service [252] imports packages:
----------------------------------------------------------
javax.ejb; version=3.1.0 -> org.glassfish.javax.ejb [171]
org.glassfish.cditest.security.interceptor; version=0.0.0 -> org.glassfish.cditest.security.impl [254]
org.glassfish.cditest.security.api; version=0.0.0 -> org.glassfish.cditest.security.api [255]

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

I discussed with our CDI engineer (sivakumar) and he thinks there is more to it than classloading. He thinks this can be reproduced without use of OSGi as well. He is looking into it.

Comment by chaoslayer [ 14/Dec/10 ]

OK, so do you need any additional data from my side?

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

No, not at this point. We have sufficient information to proceed. Thanks.

Comment by Sanjeeb Sahoo [ 15/Dec/10 ]

Needed for 3.1

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Modified testcase with the following changes:
1. brought the interceptor enablement to security.impl and 2. removed the interceptor enablement in user.impl

The interceptor class is defined in security.impl and must be enabled there.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

While debugging this issue, we noticed that the interceptor was enabled in the user.impl bundle. The interceptor is defined in the security.impl bundle and hence has to be enabled there. Attached the modified test-case that has these changes. With these changes, the 3 bundles deploy in GF3.1 latest trunk.

However there is an issue. GF3.1 considers the first two bundles (security.api and security.impl) as plain vanilla OSGi bundles (not EE archives) and hence are not considered as CDI archives. Furthermore, since there is no "explicit" relationship (apart from the usage of the CDI interceptor binding) between the user.impl and the other two bundles, when the user.impl WAB is deployed, the user.impl WAB "alone" is considered as a CDI archive. The CDI runtime does not have access to the Beans in security.api/security.impl and hence this usecase will not work. GF3.1 CDI-OSGi support should support scenarios where the Beans used by a bundle are in a different bundle and scenarios where Beans could exist in plain vanilla osgi bundles. I have raised a RFE, GLASSFISH-15249, for this and targetted this for 3.2 as it is more involved to be considered for 3.1.

Here are two possible workarounds:

  • One bundle: Bundling all the Beans together in user.impl (ie have one bundle and not 3 bundles) would work. I don't know if this works for you, though.
  • Fragment bundle approach: I had a discussion with Sahoo and he is investigating the use of security.api and security.impl as fragment bundles as a workaround, and he will update this thread with his finding.
Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Raised a RFE GLASSFISH-15249 to fix the underlying usecase.

Comment by chaoslayer [ 17/Dec/10 ]

Well, not quite covering our use case scenario. Let me explain what we "want":

  • we have one Security API bundle that contains the @Secure interface
  • we have one or more Security implementation bundles that contain the implementation for @Secure
  • we have around 20 EJB bundles that have to be "secured" via the CDI interceptor binding

So workaround one effectively disables OSGi here completely and pulls in a lot of work todo for our setup, from building to integration testing to deployment.

Option two could be an option, although I think only the bundle that contains the interceptor should be made available as a fragment bundle attaching to all those EJB bundles.

But what happens if not all Fragement-Hosts are available for the interceptor fragment bundle? Is it still resolved for those that are available? The spec is somewhat unclear here. The use case here is of course modularity. As our developers are working in different areas of interest they only use the bundles that they need. Security is a very basic need but should support those scenarios without modification at build time.

Thanks for the RFE, btw.

Comment by Sanjeeb Sahoo [ 17/Dec/10 ]

Yes, I just tried by converting security.impl to be a fragment of user.impl and having the <interceptors> element defined in user.impl's beans.xml. With this, I am able to see the interceptors in action. I realize this is not an optimal solution, but looks like a work around to me.

Comment by Sanjeeb Sahoo [ 17/Dec/10 ]

A fragment can't be attached to more than one host, so there is a potential issue for your use case. Let us think more.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Marking as "3_1-exclude" and targetting for 3.2

Comment by Sivakumar Thyagarajan [ 06/Jul/11 ]

Marking as 3_1-next as this was targetted for 3.1+ releases

Comment by Sivakumar Thyagarajan [ 08/Jul/11 ]

Marked issue as "Major"

Comment by Sivakumar Thyagarajan [ 15/Oct/12 ]

Moving a fix for this to a "future release" as the dependent issue GLASSFISH-15249 is also moved.

There is a workaround for this issue as Sahoo points out above.

Comment by TangYong [ 15/Oct/12 ]

siva, sahoo,

Please add a osgi-javaee component for the issue.

Comment by TangYong [ 25/Mar/13 ]

Because the bug depends on GLASSFISH-15249 which will be implemented in future release, fix version is adjusted into future release.





[GLASSFISH-15249] Support vanilla OSGi bundles as bean archives and Bean dependencies between bundles Created: 17/Dec/10  Updated: 16/Oct/12

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15119 CDI Interceptor still not working in ... Open

 Description   

GF3.1 CDI-OSGi support should support scenarios where the Beans used by a bundle are in a different bundle, and scenarios where Beans could exist in plain vanilla osgi bundles.

See GLASSFISH-15119 for a discussion on this issue.



 Comments   
Comment by Sivakumar Thyagarajan [ 15/Oct/12 ]

Moving this to a future release. The immediate interest is to align with the OSGi/CDI RFC.

Comment by TangYong [ 15/Oct/12 ]

siva, sahoo

Pl. add osgi-javaee into Component/s.

Comment by Sivakumar Thyagarajan [ 16/Oct/12 ]

Adding osgi-javaee to the component list





[GLASSFISH-20413] automate jms resource creation for weld glassfish tck runner Created: 25/Apr/13  Updated: 11/Sep/14

Status: Open
Project: glassfish
Component/s: cdi
Affects Version/s: None
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See
https://github.com/weld/weld-glassfish-tck-runner/blob/master/src/test/java/org/jboss/weld/tck/glassfish/GlassFishResourceManager.java#L36

Wouldn't it be better to support this directly in the Managed/Remote containers in the same way it's done for Embedded, by exposing a configuration option in ContainerConfiguration. Then any user can install a global resources.xml file during the lifetime of the test execution. Installed in start(), removed in stop() ?

glassfish embedded configuration:
https://github.com/arquillian/arquillian-container-glassfish/blob/master/glassfish-embedded-3.1/src/main/java/org/jboss/arquillian/container/glassfish/embedded_3_1/GlassFishConfiguration.java#L156

glassfish embedded impl:
https://github.com/arquillian/arquillian-container-glassfish/blob/master/glassfish-embedded-3.1/src/main/java/org/jboss/arquillian/container/glassfish/embedded_3_1/GlassFishContainer.java#L186

glassfish-resources.xml example: https://github.com/ahhughes/glassfish3x.resources.xml.example/blob/master/glassfish3x-resources-xml-example-ear/src/main/application/META-INF/glassfish-resources.xml



 Comments   
Comment by jjsnyder83 [ 25/Apr/13 ]

The arquillian.xml property, in this case, allow for a , separated list of resource file references. Tho I'm pretty sure you could define two jms resources in one resource.xml file as well.





[GLASSFISH-21163] Include ../modules/cdi-api.jar in the Class-Path: section of META-INF/MANIFEST.MF in ${com.sun.aas.installRoot}/lib/javaee.jar Created: 12/Aug/14  Updated: 24/Mar/15

Status: Open
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: rgoldberg Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 5 minutes
Time Spent: Not Specified
Original Estimate: 5 minutes
Environment:

All


Tags: cdi, jar, javaee, manifest, modules

 Description   

The:

Class-Path:

section of the file:

META-INF/MANIFEST.MF

in the jar file:

$

{com.sun.aas.installRoot}

/lib/javaee.jar

should include:

../modules/cdi-api.jar

Other Java EE jars might be missing from that manifest, too, but I haven't checked.



 Comments   
Comment by rgoldberg [ 12/Aug/14 ]

In the Description, I forgot to escape the opening brace and closing brace, so .${com.sun.aas.installRoot}/lib/javaee.jar is formatted poorly.

I cannot seem to edit the Description.

Can someone escape the braces?

Comment by rgoldberg [ 25/Aug/14 ]

Will this be fixed anytime soon?

It should only take 30 seconds to add ../modules/cdi-api.jar to the Class-Path: section.

It might take a few minutes (around 2 - 5) to check if any other jars should also be included.





[GLASSFISH-19759] Support binding to OSGi services at deploy-time Created: 01/Mar/13  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: future-release, osgi-cdi, osgi-javaee

 Description   

Today the osgi-cdi portable extension supports the injection of OSGi Services into injection points marked with a custom OSGi Qualifier @OSGiService. Unfortunately this binds application components that reference these Services at deployment time to OSGi. There could be scenarios where the determination that a Service being injected is an OSGi Service, can be made at deployment-time based on the environment that the application component is part of. It would be good if we have the ability for a client of an OSGi Service to indicate that the Service is an OSGi Service at deploy-time.



 Comments   
Comment by Sivakumar Thyagarajan [ 01/Mar/13 ]

One approach to consider is providing a capability to a deployer (through a custom deployment-descriptor) to specify that a particular injection point is an OSGi Service injection point, and have the osgi-cdi portable extension read this descriptor and automatically add the @OSGiService qualifier at runtime.

Comment by TangYong [ 01/Mar/13 ]

Siva,

The capability is very important while combining PaaS model, and in PaaS, ServiceType can be extended into OSGi Service, then, an user can specify an OSGi Service as some PaaS Service in liking glassfish-services.xml.

Then, by discovering OSGi Service engine(to be implemented in the future), these OSGi Services meeting the user's requirements will be injected into client at runtime.

Tang

Comment by TangYong [ 25/Mar/13 ]

Seeing siva's said carefully, Siva's means should be following,

[Current OSGi/CDI portable extension]
Class A

{ @OSGiService B b ... }

The issue should wish to remove @OSGiService instead still using @Inject and adding some way to tell deployment to automatically determinate b is a OSGi Service.

Then, if using a custom deployment-descriptor, this is similar to Declarative Services, OK, let us to see this will bring what advantage?

Imaging a scene that some user has written a application which uses common cdi with well-designed interface, however, while he/she wants to switch another B's implementation and does not change any consumer's source, by this feature, he/she should implement.

Comment by Sivakumar Thyagarajan [ 25/Mar/13 ]

Yes, Tang.

The idea is to support the following:

  • Allow the development of POJOs and dependency injection not knowing during development time that a particular injection point would be satisfied through an OSGi Service. So in the above example, the application includes a POJO
    Class A { @Inject StockQuoteService b; }
  • At deployment time, we should allow the deployer to override the injection and indicate that the injection point A.b is an OSGi Service injection and provide the details through a custom deployment-descriptor. For instance here is a rough idea on how a deployer could state that the injectin point A.b is an OSGi Service.
    glassfish-osgi-cdi.xml:
    <osgi-service dynamic="true">
    <managed-bean name="A">
    <attribute name ="b"/>
    </managed-bean>
    </osgi-service>
  • The osgi-cdi portable extension must read this optional custom deployment-descriptor, and automatically at deployment time, make A.b have a qualified @OSGiService.

Does this help? All the above details are just ideas at this point in time. Let us evaluate how best to resolve this.





Generated at Tue Sep 01 16:33:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.