<< Back to previous view

[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File server.log    
Tags:
Participants: aaronjwhiteside, Sanjeeb Sahoo, Sivakumar Thyagarajan and tlcksnyder

 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 12:00 AM ]

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 12:03 AM ]

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

Comment by aaronjwhiteside [ 16/Mar/12 12:14 AM ]

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 12:18 AM ]

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 04:16 PM ]

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 06:58 PM ]

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 08:06 PM ]

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 01:23 AM ]

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 07:34 PM ]

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





[GLASSFISH-19215] Add support CDI in plain OSGi bundles Created: 23/Oct/12  Updated: 11/Dec/12

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

Type: Improvement Priority: Critical
Reporter: TangYong Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

File Attachments: Zip Archive GLASSFISH-19215-patch-20121211.zip     Zip Archive GLASSFISH-19215-patch.zip     Zip Archive GLASSFISH-19215-patch_20121029.zip     Zip Archive GLASSFISH-19215-patch_20121030.zip     Zip Archive GLASSFISH-19215-patch_20121109.zip     Zip Archive GLASSFISH-19215-patch_20121114.zip     Zip Archive GLASSFISH-19215_fighterfishtestcase_final_20121122.zip     Microsoft Excel reviewing_siva.xls     Microsoft Excel reviewing_siva_2012.12.10.xls     Microsoft Excel reviewing_siva_2012.12.11.xls     Zip Archive stockquote-cdi-osgi-sample.zip     Zip Archive stockquote_cdi_plainclient.zip    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19324 Instance.select(clazz).get() throw Il... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19325 moving the logics of publishing beans... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19326 invocating Weld-Integration bundle to... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19344 adding the handling logic of Weld Con... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19346 Adding fighterfish test cases Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19421 Adding java doc for OSGiServicePublis... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19422 refactoring OSGiCDIExtender.startWeld... Sub-task Open Sanjeeb Sahoo  
Tags:
Participants: Sanjeeb Sahoo, Sivakumar Thyagarajan and TangYong

 Description   

In order to implement RFC146(OSGi/CDI), there is prerequisite needed to be implemented.

If a plain vanilla osgi bundle included META-INF\beans.xml and wants to use @Publish and other OSGi/CDI annotation, on current glassfish, this is not supported.

The reason is that while deploying such a osgi bundle, because missing Weld Sniffer, OSGiServiceExtension can not be triggered by WELD Container.

So, this must be implemented.



 Comments   
Comment by TangYong [ 23/Oct/12 07:12 AM ]

My analyse result is that once deploying such a bundle using --type=osgi, while executing com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers method to get applicable sniffers, because archiveType is "osgi" , weld sniffer does not supports such a archiveType, weld sniffer was skipped.

I think that fixing way is that making weld sniffer can support such a case by checking beans.xml.

Comment by Sanjeeb Sahoo [ 23/Oct/12 07:20 AM ]

No sniffer should pick up an archive when --type osgi is used. The system is designed such that only OSGiContainer will be responsible for deploying such an archive. Once such a bundle is deployed as a vanilla OSGi bundle, it should be picked up by an appropriate extender. This is how OSGi/Web, OSGi/EJB features are implemented and it should be no different for OSGi/CDI as well.

Comment by TangYong [ 23/Oct/12 09:42 AM ]

Thanks sahoo's comment. Surely, for WAB and EJB bundle's deployment including beans.xml, real deployment is processed by OSGiWebDeployer and OSGiEJBDeployer respectively which are selected by OSGiContainer's OSGiDeployerTracker.

Then, while deploying process entered into ApplicationLifecycle, because of some magic handling(by setupClassLoader()?), getSniffers(handler, sniffers, context) can get WeldSniffer.

Backing to the problem, current deploying mode is a vanilla OSGi bundle which wants to be handled by WeldSniffer.

Just as sahoo said, it should be no different by creating a PlainOSGiDeployer. However, I have been not still clear for "some magic handling" and will continue to investigate.

Comment by TangYong [ 23/Oct/12 09:56 AM ]

Hi sahoo,

About the "some magic handling", I have found a place and for ejb bundle, OSGiEJBDeploymentContext has a method called getArchiveType() and returned the following:

return javax.enterprise.deploy.shared.ModuleType.EJB.toString();

Then, I have seen the WeldSniffer.supportsArchiveType method and found the following:

if (archiveType.toString().equals(ModuleType.WAR.toString()) ||
archiveType.toString().equals(ModuleType.EJB.toString()) ||
archiveType.toString().equals(ModuleType.RAR.toString())) { return true; }

So, for a vanilla OSGi bundle, it is not ejb and war and rar, so, if not modifying supportsArchiveType to add the supporting of a vanilla OSGi bundle, even if creating a PlainOSGiDeployer, WeldSniffer can be not still obtained.

Comment by TangYong [ 23/Oct/12 10:04 AM ]

For WAB, OSGiWebDeploymentContext returns the following:

@Override
public String getArchiveType() { // Since I am not able to reference GF 4.0 APIs as they are not yet staged in a maven repo, // I am accessing the value in a round about way. return javax.enterprise.deploy.shared.ModuleType.WAR.toString(); // WarType.ARCHIVE_TYPE; }

So, WAR is also supported by WeldSniffer.

Comment by TangYong [ 23/Oct/12 11:39 AM ]

In addition, there is a thing that I must say:

For a WAB or EJB Bundle, while deploying it using --type=osgi, ApplicationLifecycle.deploy method will be called twice and "sniffers = getSniffers(handler, sniffers, context)" will also be executed twice because on the second time, OSGiContainer's OSGiDeployerTracker will select right deployer to finish javaee related things.

Then, I have made a experiment by directly modifying WeldSniffer.supportsArchiveType(archiveType.toString().equals("osgi")) so that I want to see whether a plain osgi bundle with beans.xml can be scaned by OSGiServiceExtension.

The result is that, although beans.xml can be scaned by OSGiServiceExtension, the bean class with @Publish in the plain osgi bundle can not be recognized by weld container.

So, based this conclusion,

1) WeldSniffer still needs to be enhanced
2) maybe create a new module/container(for example, osgi-cdi-se-container) to do liking osgi-ejb-container under fighterfish sub-project.

Comment by Sanjeeb Sahoo [ 23/Oct/12 05:31 PM ]

Yes, I call it two-phase deployment. First phase involves osgi-container alone. It's the second phase where our Java EE specific extenders come into play their roles. I would expect new code to be part of osgi-cdi module itself.

Comment by TangYong [ 25/Oct/12 02:06 AM ]

Hi sahoo, siva,

The attachement is my fixing patch and I will explain sources in the patch in details:

1 osgi-cdi

1) Similar to osgi-ejb-container, the following java files are created to meet the second phrase deployment which will trigger Weld container's bootstrap

・OSGiCDIContainerActivator.java
used to register OSGiCDIExtender class

・OSGiCDIExtender.java
An extender that registers a OSGiCDIDeployer to deploy/undeploy a plain vanilla OSGi/CDI bundle

・OSGiCDIDeployer.java
On one hand, it is used to create OSGiCDIDeploymentRequest, on the other hand, it defined a method called isPlainOSGiCDIBundle used by handles method. The isPlainOSGiCDIBundle method is very important because by means of the method, OSGiContainer can select right OSGiCDIDeployer. Please see my comments on the method and in the future, I maybe will improve the method.

・OSGiCDIDeploymentRequest.java
A simple class extends OSGiDeploymentRequest and we must add the class in order to meet osgi-javaee-base design.

・OSGiCDIUndeploymentRequest.java
A simple class extends OSGiUndeploymentRequest and we must add the class in order to meet osgi-javaee-base design.

・Constants.java
A simple class used to define some constants to avoid magic string in sources

・OSGiCDIDeploymentContext.java
It is a very important class and specially returns a new ArchiveType(javax.enterprise.deploy.shared.ModuleType.PlainOSGiCDIBundle) used by WeldSniffer.

Defaultly, OSGiArchiveHandler's getArchiveType method returned "OSGiBundle", if directly making WeldSniffer to support "OSGiBundle" type and not adding the new type, for a plain osgi bundle without beans.xml, WeldSniffer will be also added, so, I created a new type to
differentiate a plain osgi bundle without beans.xml.

2)osgi.bundle.patch
Add Bundle-Activator: org.glassfish.osgicdi.impl.OSGiCDIContainerActivator

3)pom.xml.patch
Add the following dependency,
<dependency>
<groupId>org.glassfish.main</groupId>
<artifactId>javax.enterprise.deploy</artifactId>
<version>4.0-SNAPSHOT</version>
</dependency>

Pl. seeing my comments on the the file.

2 javax.enterprise.deploy
I added a new PlainOSGiCDIBundle Module Type used by WeldSniffer.

3 gf-weld-connector
WeldSniffer's supportsArchiveType method is modified to add the supporting of PlainOSGiCDIBundle Module Type.

4 osgi-container
PlainOSGiCDIArchiveType class needs to be created as a service of ArchiveType @Contract, if not creating the class, SnifferManagerImpl's getApplicableSniffers method can not add WeldSniffer successfully.

Please review these files.

Comment by Sanjeeb Sahoo [ 25/Oct/12 07:03 AM ]

From an initial look, they all look fine except the addition of a new module type and its use inside WeldSniffer. I think we should avoid using WeldSniffer. We should invoke Weld directly during deployment. I will let Siva comment on this.

Comment by TangYong [ 26/Oct/12 02:40 AM ]

>We should invoke Weld directly during deployment.
Indeed, invoking Weld directly is a good idea because I have found that using WeldSniffer is not a right solution because once using WeldSniffer, on the second phrase, deployment will trigger a org.glassfish.internal.deployment.Deployment.APPLICATION_LOADED event which will be listened by org.glassfish.weld.WeldDeployer, then WeldDeploy will start Weld Container. This looks very fine, but current gf weld integration only considers JavaEE related mode[1], rathen than pure OSGi or SE mode.

So, if invoking Weld directly on deploying, we should do the following-liking in order:

(1) WeldBootstrap bootstrap = new WeldBootstrap();
(2) DeploymentImpl deploymentImpl = new DeploymentImpl(archive, ejbs, deploymentContext);
(3) List<BeanDeploymentArchive> archives = deploymentImpl.getBeanDeploymentArchives();
(4) deploymentImpl.buildDeploymentGraph();
(5) bootstrap.startContainer(Environments.SE, deploymentImpl);
(6) bootstrap.startInitialization();
(7) fireProcessInjectionTargetEvents(bootstrap, deploymentImpl);
(8) bootstrap.deployBeans();

Let us see the above sequence:

1. about DeploymentImpl and BeanDeploymentArchive
I have not still made sure whether the two essential classes can be used in pure OSGi or SE mode because most of them are related to JavaEE.

2 about bootstrap.startContainer(Environments.SE, deploymentImpl);
Whether 1st Parameter is Environments.SE or others(including we create a implementation of Enviroment. Note: Weld-OSGi creates a implementation of Enviroment) or not needs to be investigated.

3 about fireProcessInjectionTargetEvents(bootstrap, deploymentImpl);
Whether needing the call or not needs to be investigated.

I will listen to Siva and Sahoo's comments.

[1]: I have found a exception on using WeldSniffer, and made sure that using WeldSniffer is not a good solution.

[#|2012-10-25T15:15:16.671+0900|WARNING|44.0|javax.enterprise.system.core.org.glassfish.kernel.event|_ThreadID=13;_ThreadName=pool-17-thread-1;_TimeMillis=1351145716671;_LevelValue=900;|Exception while dispatching an event
java.lang.RuntimeException: Error binding app-level env dependencies null
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.registerAppLevelDependencies(ManagedBeanManagerImpl.java:176)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.event(ManagedBeanManagerImpl.java:136)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:275)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:502)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:228)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.naming.NamingException: Null appName
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.getAppNamespace(GlassfishNamingManagerImpl.java:432)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.bindToAppNamespace(GlassfishNamingManagerImpl.java:595)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl.bindToComponentNamespace(ComponentEnvManagerImpl.java:208)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.registerAppLevelDependencies(ManagedBeanManagerImpl.java:174)
... 18 more

Comment by TangYong [ 26/Oct/12 02:58 AM ]

The improvement is very critical to implement the whole RFC146(OSGi/CDI) and I will postpone other OSGi/CDI features's implementation until the problem is resolved.

In addition, remembering siva's "Typesafe injection of dynamic OSGi services in hybrid Java EE applications"(https://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi) , the sample used a servlet consumer,

public class StockQuoteServlet extends HttpServlet { @Inject @OSGiService(/\* wait for 1 min \*/ waitTimeout=60\*1000) StockQuoteService sqs; ... }

Servlet consumer is one of of consumers of OSGi/CDI @OSGiService, and plain OSGi bundle should be also another use case, if the improvement can not be resolved, @OSGiService can not be used in plain OSGi bundle's use case,let alone say @Publish ...

Comment by Sivakumar Thyagarajan [ 26/Oct/12 11:36 AM ]

Hi Tang

I agree with Sahoo and you that we should not use WeldSniffer. It unnecessarily ties the osgi-cdi implementation to the weld-integration module in GlassFish. We should see the work you are doing in OSGi-CDI as only meant to support OSGi bundles as CDI bean archives, and leave the support for Java EE CDI bean archives to the Weld integration. Directly using the Weld SPI to do deployment of bean archives is the right approach.

> 1. about DeploymentImpl and BeanDeploymentArchive
> I have not still made sure whether the two essential classes can be used in pure OSGi or SE mode
> because most of them are related to JavaEE.

Yes, these SPI implementations in the weld-integration module is very EE specific and may not be useful as is to you. Could you please look at implementing light-weight implementations of these to just support the "OSGi bundles as bean archives" scenario.

> 2 about bootstrap.startContainer(Environments.SE, deploymentImpl);
> Whether 1st Parameter is Environments.SE or others(including we create a implementation of
> Enviroment. Note: Weld-OSGi creates a implementation of Enviroment) or not needs to be
> investigated.

For now let us assume that the support for "OSGi bundles as bean archives" is just an SE style environment as we don't need to support EE style resource injection, transactions, Servlet, EJB etc. So let us start with reusing Environments.SE.

Firing ProcessInjectionTarget events was done in DeploymentImpl for handling non-contextual EE components such as Services. In this case, this may not be needed.

Thanks.

Comment by TangYong [ 28/Oct/12 06:52 AM ]

Thanks siva's confirmation and sahoo's change on the improvement's title.

>Yes, these SPI implementations in the weld-integration module is very EE specific and may not be useful as is to
>you. Could you please look at implementing light-weight implementations of these to just support the "OSGi bundles >as bean archives" scenario.
I am investigating this.

>For now let us assume that the support for "OSGi bundles as bean archives" is just an SE style environment as we >don't need to support EE style resource injection, transactions, Servlet, EJB etc. So let us start with reusing >Environments.SE.
On Weld-OSGi project and ops4j.pax.cdi project, they all create a new environment used for OSGi/CDI rather than using Environments.SE, so, I must investigate the reason that they do not use Environments.SE directly.

>Firing ProcessInjectionTarget events was done in DeploymentImpl for handling non-contextual EE components such as >Services. In this case, this may not be needed.
OK, I see.

In addition, I will add a topic as following:

Needing to investigate that ,by overriding which method, directly using the Weld SPI is to do deployment of bean archives.

Comment by TangYong [ 29/Oct/12 10:17 AM ]

Hi siva, sahoo,

I have implemented the improvement and have made a @Publish test(based my current @Publish implementation). Please review the patch(20121029). I want to make a description about essential classes of the patch.

1) OSGiBeanDeploymentArchiveImpl
>Yes, these SPI implementations in the weld-integration module is very EE specific and may >not be useful as is to you. Could you please look at implementing light-weight >implementations of these to just support the "OSGi bundles as bean archives" scenario.

the class is a OSGi bundles bean archives's implementation

2) OSGiBeanDeploymentArchiveFactory
its role is scanning current bundle and finding beans.xml and bean classes used by weld

3) OSGiBeanDeployment
used by WeldBootstrap to start weld container

4) OSGiCDIDeploymentRequest
>Needing to investigate that ,by overriding which method, directly using the Weld SPI is >to do deployment of bean archives.

Overriding postDeploy() method to trigger Weld SPI directly.

5) OSGiServicePublisher and Publish and ServiceProperties and Property
handling @Publish and registering current Bean into OSGi, I will discuss @Publish in Glassfish-18938

6) about Environments.SE
Currently, using Environments.SE looks fine.

Thanks

Comment by TangYong [ 29/Oct/12 12:14 PM ]

Hi sahoo,siva

On testing the improvement based my patch, I found two problem on stopping domain:

1) osgi-ejb-container

After I deployed a plain bundle with beans.xml, while I was executing "asadmin stop-domain", the following exception happened on server.log,

[#|2012-10-29T18:57:24.843+0900|SEVERE|44.0|javax.enterprise.logging.stderr|_ThreadID=14;_ThreadName=Thread-16;_TimeMillis=1351504644843;_LevelValue=1000;|java.lang.NullPointerException
at org.glassfish.osgiejb.OSGiEJBDeployer$EJBTracker.removedService(OSGiEJBDeployer.java:236)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1006)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:906)
at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:949)
at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
at org.apache.felix.framework.Felix.access$000(Felix.java:74)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148)
at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
at org.glassfish.osgijavaeebase.OSGiContainer.undeploy(OSGiContainer.java:184)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.undeployAll(AbstractOSGiDeployer.java:168)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.unregister(AbstractOSGiDeployer.java:115)
at org.glassfish.osgicdi.impl.OSGiCDIExtender.stop(OSGiCDIExtender.java:72)
at org.glassfish.osgijavaeebase.ExtenderManager$ExtenderTracker.removedService(ExtenderManager.java:153)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1006)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:906)
at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:412)
at org.glassfish.osgijavaeebase.ExtenderManager.stopExtenders(ExtenderManager.java:122)
at org.glassfish.osgijavaeebase.ExtenderManager.access$400(ExtenderManager.java:67)
at org.glassfish.osgijavaeebase.ExtenderManager$GlassFishServerTracker$1$1.event(ExtenderManager.java:197)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:324)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:80)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:78)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:549)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:79)

#]

I analysed for a while and made a modification for EJBTracker.removedService method 236 line as following,

Application app = ai.getMetaData(Application.class);
if (app != null ){ Collection<DolAdapter.EjbDescriptor> ejbs = DolAdapter.convert(app.getEjbDescriptors()); ... }
super.removedService(reference, service);

I found that while deploying a plain bundle with beans.xml, ApplicationInfo of the bundle has no metadata, so, NullPointerException happened. However, I also doubted whether the exception was caused by my patch or not?

2)AbstractOSGiDeployer.getGlassFish

After I made the above modification, the 1) exception did not happen, however, another exception happened on the server.log,

[#|2012-10-29T18:57:24.843+0900|WARNING|44.0|org.glassfish.osgijavaeebase|_ThreadID=14;_ThreadName=Thread-16;_TimeMillis=1351504644843;_LevelValue=900;|Failed to undeploy bundle sample.osgicdi.stockquote_service_usingcdi [280]
java.lang.NullPointerException: Specified service reference cannot be null.
at org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:458)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.getGlassFish(AbstractOSGiDeployer.java:197)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.getReport(AbstractOSGiDeployer.java:149)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.undeploy(AbstractOSGiDeployer.java:137)
at org.glassfish.osgijavaeebase.OSGiContainer.undeploy(OSGiContainer.java:193)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.undeployAll(AbstractOSGiDeployer.java:168)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.unregister(AbstractOSGiDeployer.java:115)
at org.glassfish.osgicdi.impl.OSGiCDIExtender.stop(OSGiCDIExtender.java:72)
at org.glassfish.osgijavaeebase.ExtenderManager$ExtenderTracker.removedService(ExtenderManager.java:153)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1006)
at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:906)
at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:352)
at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:412)
at org.glassfish.osgijavaeebase.ExtenderManager.stopExtenders(ExtenderManager.java:122)
at org.glassfish.osgijavaeebase.ExtenderManager.access$400(ExtenderManager.java:67)
at org.glassfish.osgijavaeebase.ExtenderManager$GlassFishServerTracker$1$1.event(ExtenderManager.java:197)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:324)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:80)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:78)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:549)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:79)

#]

While I was debugging the exception, the exception happened on AbstractOSGiDeployer.getGlassFish() method 197,
"getBundleContext().getServiceReference(GlassFish.class.getName())" is null, however, I felt very curious,

・Whether on EJB Bundle case or WAB case the exception also happened or not?
・From exception, It seemed that it should be not related to my patch.

I want to listen your comments.
Thanks.

Comment by TangYong [ 29/Oct/12 12:18 PM ]

I attached my test application and I used stockquote_service_usingcdi as deploying sample.

Comment by Sanjeeb Sahoo [ 29/Oct/12 05:38 PM ]

Tang,

1. I agree with your assessment of first exception. We may have to adopt a different strategy for OSGi/CDI instead of implementing them like OSGi/EJB or OSGi/Web. Can you please explore if we can just have an extender which registers a BundleTracker that does what you are doing in OSGiCDIDeploymentRequest?

2. The second exception sounds like a bug to me. Since GlassFish service is getting removed, it is likely that getBundleContext().getServiceReference(GlassFish.class.getName()) is returning null. Can you please try to reproduce it for an EJB bundle or WAB and file a bug?

Very good work, BTW.

Thanks,
Sahoo

Comment by TangYong [ 30/Oct/12 01:38 AM ]

Hi sahoo,

For 1, I will investigate it and at the same time I will also listen to siva's comments for other sources of my patch.

For 2, I will try EJB bundle and WAB and see whether the exception will happen again or not?

Thanks your suggestion.
Tang

Comment by TangYong [ 30/Oct/12 11:03 AM ]

Hi sahoo,

>For 2, I will try EJB bundle and WAB and see whether the exception will happen again or not?
I have confirmed that 2 can be reproduced and please see GLASSFISH-19261 .

Comment by TangYong [ 30/Oct/12 01:04 PM ]

Hi sahoo, siva,

I have attached my new patch according to sahoo's comment and I can deploy stockquote_service_usingcdi.jar successfully, In the patch, modified class is OSGiCDIExtender, and I add BeanBundleTrackerCustomizer to track deployed bundle, once finding the bundle is a plain bundle with beans.xml, I trigger Weld SPI directly.

In addition, after executing stop-domain, previous 1 and 2 exceptions all disappeared in server.log. The following is server.log's contents in my env. Currently, it looks fine.

[#|2012-10-30T21:54:08.531+0900|INFO|44.0|null|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648531;_LevelValue=800;|Snifer org.glassfish.extras.osgicontainer.OSGiSniffer@343329 set up following modules: []|#]

[#|2012-10-30T21:54:08.921+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648921;_LevelValue=800;|Started sample.osgicdi.stockquote_service_usingcdi [280]|#]

[#|2012-10-30T21:54:08.937+0900|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648937;_LevelValue=800;_MessageID=loading.application.time;|CORE10010: Loading application stockquote_service_usingcdi done in 594 ms|#]

[#|2012-10-30T21:54:08.968+0900|INFO|44.0|org.glassfish.ha.store.spi.BackingStoreFactoryRegistry|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648968;_LevelValue=800;|Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry|#]

[#|2012-10-30T21:54:08.968+0900|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601648968;_LevelValue=800;|GlassFish Server Open Source Edition 4.0 (Administrator-private) startup time : Felix (2,641ms), startup services(1,859ms), total(4,500ms)|#]

[#|2012-10-30T21:54:09.031+0900|INFO|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.services.impl|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601649031;_LevelValue=800;|Grizzly Framework 2.3 started in: 16ms - bound to [/0.0.0.0:7,676]|#]

[#|2012-10-30T21:54:09.109+0900|INFO|44.0|javax.enterprise.system.jmx|_ThreadID=11;_ThreadName=Thread-7;_TimeMillis=1351601649109;_LevelValue=800;_MessageID=AS-JMX-00005;|JMXStartupService has started JMXConnector on JMXService URL service:jmx:rmi://10.167.157.133:8686/jndi/rmi://10.167.157.133:8686/jmxrmi|#]

[#|2012-10-30T21:54:09.171+0900|INFO|44.0|com.sun.enterprise.glassfish.bootstrap.osgi|_ThreadID=10;_ThreadName=main;_TimeMillis=1351601649171;_LevelValue=800;|Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@1869971 as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@432685|#]

[#|2012-10-30T21:54:09.531+0900|INFO|44.0|org.jboss.weld.Version|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649531;_LevelValue=800;|WELD-000900 1.1.4 (Final)|#]

[#|2012-10-30T21:54:09.781+0900|INFO|44.0|org.jboss.weld.Bootstrap|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649781;_LevelValue=800;|WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.|#]

[#|2012-10-30T21:54:09.921+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649921;_LevelValue=900;|Class 'javax.interceptor.AroundInvoke' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.921+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649921;_LevelValue=900;|Class 'javax.interceptor.AroundTimeout' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.921+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649921;_LevelValue=900;|Class 'javax.ejb.PostActivate' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.937+0900|WARNING|44.0|org.jboss.interceptor.util.InterceptionTypeRegistry|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=900;|Class 'javax.ejb.PrePassivate' not found, interception based on it is not enabled|#]

[#|2012-10-30T21:54:09.937+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=800;|SimpleStockQuoteServiceImplUsingCDI::Initializing quotes|#]

[#|2012-10-30T21:54:09.937+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=800;|SimpleStockQuoteServiceImplUsingCDI::getSymbols|#]

[#|2012-10-30T21:54:09.937+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=pool-6-thread-1;_TimeMillis=1351601649937;_LevelValue=800;|Registered:[IBM, Fujitsu, HPQ, ORCL]|#]

Please Sahoo and Siva review.

Comment by TangYong [ 30/Oct/12 01:34 PM ]

I made a improvement for BeanBundleTrackerCustomizer.addingBundle method,

public Object addingBundle(final Bundle bundle, BundleEvent event) {
if ( !isCDIBundle(bundle) ){ return null; }

final int state = bundle.getState();

if ( isReady(event, state) ) { ... }

Comment by TangYong [ 05/Nov/12 09:09 AM ]

There is a problem happened on my test app(Pl. seeing stockquote_cdi_plainclient.zip).

Test Case:

In activator of a plain osgi bundle, I add the following test logic,

public class OSGiPlainClientActivator implements BundleActivator{

@Inject
@OSGiService(/* dynamically bound */ dynamic = true,
/* wait for 1 min */ waitTimeout=1*1000)
StockQuoteService sqs;

public void start(BundleContext arg0) throws Exception { System.out.println("OSGiPlainClientActivator::start"); System.out.println("Obtained StockQuotes:" + sqs.getSymbols()); System.out.println("OSGiPlainClientActivator::getting Stock quote service successful"); }

On debugging, I found that sqs is NULL because before sqs is injected, Starting logic of the activator has ended.
So, here has a multi-thread problem and weld container's scanning must happen before the activator's start method.

I will investigate how to fix the problem and also listen to your comments.

The problem is very fatal.

Thanks
Tang

Comment by TangYong [ 05/Nov/12 09:25 AM ]

I forgot to say that while deploying the test bundle, when executing BeanBundleTrackerCustomizer.isReady method, current bundle's state is Starting, the method can not return true on this case, so, I modify the method as following,

private boolean isReady(BundleEvent event, int state) { return state == Bundle.ACTIVE || state == Bundle.STARTING; }

However,Modifying the method can not fix the problem, because main reason is multi-thread which I said in previous reply.

Comment by TangYong [ 05/Nov/12 09:38 AM ]

Hi siva, sahoo,

I made an experiment on WAB with beans.xml. I added a activator and @OSGiService on the activator's start method, the same problem happened. So, regardless of JAVAEE bundle or Plain OSGi bundle, the problem all happened.

Comment by TangYong [ 05/Nov/12 09:52 AM ]

I think that the problem is difficult to fix because if a user used OSGi Shell command to stop the test sample and start the sample again, then, on such a case, if using listener or tracker, because they are asynchronous, injection on activator's start method can be still null.

Comment by TangYong [ 05/Nov/12 10:07 AM ]

I have a fix way and use SynchronousBundleListener, I will try it.

Comment by TangYong [ 05/Nov/12 11:16 AM ]

In addition, because glassfish has updated Weld into 1.1.10.Final, I need to update some modified files.
Now, SynchronousBundleListener is a valid fixing solution, however, from testing, I have found another problem(Although abd.addBean(new OSGiServiceBean(svcInjectionPoint)) can be executed successfully, on injection point, sqs has been not injected a bean) and will resolve it, maybe my source has a problem related to classloader.

Comment by Sanjeeb Sahoo [ 05/Nov/12 05:50 PM ]

Tang,

It is perfectly understandable to get an NPE when a bundle activator tries to access an injected field. It happens for two reasons:
a) The bundle activator instance is likely to be not known to the injection manager,
b) The injection happens after a bundle is activated.

So, we should treat it as a user application error.

We should demonstrate the integration using some sort of service tracker as you have mentioned.

Thanks,
Sahoo

Comment by TangYong [ 06/Nov/12 07:00 AM ]

Hi sahoo,siva,

This problem is a litter complex and I want to make a detailed explanation.Firstly, let us see OSGi/CDI's using scene and injection process.

[OSGi/CDI's Using Scene and Injection process]
1 JavaEE Bundle's Injection
Taking a WAB as example, normally @OSGiService injection happens on a servlet as the following,

public class StockQuoteServlet extends HttpServlet { @Inject @OSGiService(dynamic = true, waitTimeout=1*1000) StockQuoteService sqs; ... }

in this case, while deploying the WAB, Weld SPI will be triggered and in "AfterBeanDiscovery" of Bean Deployment LifeCycle, a OSGiServiceBean for sqs injectionPoint will be created and added into Weld Bean Manager. Then, while a user accessed the StockQuoteServlet by browser, true injection started and the injection is triggered by WebContainer.

That is to say, in order to obtain a injected bean, there are two critical steps:
1) scanning injectionPoint and adding OSGiServiceBean
2) needing a medium or container to trigger injection

2 Plain Bundle's Injection
Taking my test sample(stockquote_cdi_plainclient.zip) as example, here I used the following test logic on a activator.

public class OSGiPlainClientActivator implements BundleActivator{

@Inject
@OSGiService(dynamic = false, waitTimeout=1*1000)
StockQuoteService sqs;

public void start(BundleContext arg0) throws Exception { System.out.println("Obtained StockQuotes:" + sqs.getSymbols()); }

Firstly, I want to express my comments on sahoo's saying "So, we should treat it as a user application error."
I think that BundleActivator is similar to "main" function in java se world, when a StockQuoteService has been available, a user is likely to use the StockQuoteService eagerly. However, just as sahoo's saying, putting @OSGiService into OSGiPlainClientActivator can not finish 2) of two critical steps because the activator has missing the chance of triggering true injection. The result is that you maybe only use OSGi related API to get StockQuoteService. This is true?

After I evaluated Weld-OSGi's a standalone example, I found that Weld-OSGi used a interesting using way to resolve the problem rather than using OSGi related API, please seeing the following.

public class StandaloneActivator implements BundleActivator {

private EmbeddedContainer embedded;
private EmbeddedCDIContainer container;
private MyService service;

@Override
public void start(BundleContext context) throws Exception { embedded = new EmbeddedContainer(context); container = embedded.initialize(); service = container.getInstance().select(MyService.class).get(); System.out.println(service.hello()); System.out.println(service.admin()); System.out.println(service.adminAvailable()); }
...
}

public class MyService { @Inject @OSGiService private PackageAdmin admin; ... }

In the StandaloneActivator's start method, MyService can be obtained by using Weld's Instance<Object> way. In order to make effect, you must use a medium(Weld-OSGi uses EmbeddedContainer) to trigger Weld SPI and save Bean Manager, then by this Bean Manager, you can obtain Instance<Object>.

However, for Glassfish, if we also offer such a medium, we must make a classification, and once a user uses the medium to trigger Weld SPI directly, because on gf's deploying phrase , Weld SPI will be also triggered, that is to say, there are two places which will trigger Weld SPI. For the problem, Weld-OSGi used a trick that if the bundle's meta-data includes "Embedded-CDIContainer: =true", Weld SPI will be only triggered in the bundle's activator, otherwise, Weld SPI will be triggered by Weld-OSGi related bundles.

I wish that I can express more clear, and maybe we will create another feature for stating the problem.

Thanks
Tang

Comment by TangYong [ 06/Nov/12 07:28 AM ]

>However, for Glassfish, if we also offer such a medium, we must make a classification, and once a user uses the >medium to trigger Weld SPI directly, because on gf's deploying phrase , Weld SPI will be also triggered, that is to
Maybe there is another way other than using a medium to resolve the problem, and we maybe use Event integration. For example, for OSGiPlainClientActivator, the user can write the following,

public class OSGiPlainClientActivator implements BundleActivator{

private StockQuoteService sqs;

public void start(BundleContext arg0) throws Exception {...}

public void bindService(@Observes @Contracts(StockQuoteService.class) ServiceEvents.ServiceArrival event) { System.out.println("bind : " + event.getServiceClassNames()); sqs = event.getService(ShapeProvider.class); System.out.println("Obtained StockQuotes:" + sqs.getSymbols()); }

by this way, while StockQuoteService is available, bindService as a Observer can be called back to inject StockQuoteService into sqs.

Comment by Sanjeeb Sahoo [ 06/Nov/12 08:24 AM ]

Even the event integration approach won't ensure that injection happens before BundleActivator.start().

As I said earlier, I would keep it simple as we have done for OSGi/EJB and OSGi/Web. Once a bundle is ready (either ACTIVE or STARTING if activation-policy is lazy), we should scan the bundle and add the beans to the underlying CDI bean archive.

I don't like the approach of bootstrapping a CDI runtime inside BundleActivator.start(). If someone does that, then they are not leveraging OSGi/CDI integration and we should not care about those bundles.

BTW, can you add a marker header which must be present in a bundle to tell us that we should introspect the bundle as a CDI enabled bundle? Something like Meta-CDI header whose semantics can be same as Meta-Persistence header of OSGi/JPA spec. Only bundles having this header should be considered by OSGi/CDI layer.

Comment by TangYong [ 06/Nov/12 08:47 AM ]

>Even the event integration approach won't ensure that injection happens before BundleActivator.start().
My means is that event integration should happen after BundleActivator.start() and similar to postConstruct function, and such a way, we recommend a user does not add logic related injection in BundleActivator.start().

>BTW, can you add a marker header which must be present in a bundle to tell us that we should introspect the bundle >as a CDI enabled bundle? Something like Meta-CDI header whose semantics can be same as Meta-Persistence header of >OSGi/JPA spec. Only bundles having this header should be considered by OSGi/CDI layer.
Hi sahoo, I think that this is not required because beans.xml has been a enabled flag that will be considered by OSGi/CDI layer.If the bundle does not contain beans.xml, it should be considered by OSGi/CDI layer and this also meets general rule of JSR 299.

>I don't like the approach of bootstrapping a CDI runtime inside BundleActivator.start(). If someone does that, then >they are not leveraging OSGi/CDI integration and we should not care about those bundles.
I want to say that you can not understand my means, when the user bootstrapps a CDI runtime inside BundleActivator.start(), in reality, he/she should use a medium to bootstrap and the medium is offered by OSGi/CDI layer. If he/she bootstrapps a CDI runtime using himself/herself medium, we should not care about these bundles.

>As I said earlier, I would keep it simple as we have done for OSGi/EJB and OSGi/Web. Once a bundle is ready >(either ACTIVE or STARTING if activation-policy is lazy), we should scan the bundle and add the beans to the >underlying CDI bean archive.
I can understand the point and activator's scene is a special use case, on such a use case, beans has been added, however, the use case cares about how to obtain these added beans. Of course, I maybe considered too much.

OK, let me leave the problem and do @publish related tests.

Comment by Sanjeeb Sahoo [ 06/Nov/12 09:24 AM ]

1. As long as user does not use the injected field in activator.start(), it's fine.

2. Scanning every bundle for existence of META-INF/beans.xml is not correct. OSGi/JPA could have done the same for META-INF/persistence.xml. The issue here is before we scan a bundle, we need an explicit approval from the bundle whether it wants to be scanned or not. The presence of the header is considered as an approval. There is another reason for having the header. Imagine a scenario where the bundle wants to bootstrap CDI runtime itself bypassing OSGi/CDI integration facility. We can't support it unless we have such a header.

3. No, we can't provide an API to bootstrap CDI runtime. If user bootstraps themselves, we don't come into picture.

Comment by TangYong [ 06/Nov/12 09:30 AM ]

OK, I will investigate and add such a head.
Thanks.

Tang

Comment by Sanjeeb Sahoo [ 06/Nov/12 09:33 AM ]

Here are some basic requirements:
a) A CDI bean that's published as OSGi service must be using Singleton scope to match with lifecycle of OSGi services. e.g.,

@Publish
@Singleton
public class FooBean {}

In other words, following example must be treated as an error:
@Publish
public class FooBean {}

a) A CDI bean that's published as OSGi service must always consumed as an OSGi Service. In other words, following sample should fail as BarBean is trying to reference FooBean as a regular bean:

@Publish
@Singleton
public class FooBean {}

public class BarBean { @Inject FooBean foo; }

For it to work, it should look like this:
public class BarBean { @Inject @OSGiService FooBean foo; }

or
public class BarBean {
public void somemethod() { BundleContext bundleContext = // somehow obtain BundleContext bundleContext.getServiceReference(FooBean.class.getname(),...); }
}

Thanks,
Sahoo

Comment by TangYong [ 06/Nov/12 09:42 AM ]

Thanks for clarifying test case's requirements.

Tang

Comment by Sivakumar Thyagarajan [ 09/Nov/12 04:22 AM ]

It appears that in the patch you are resetting the SingletonProvider after a plain cdi osgi bundle deployment is complete. What happens if:
1. a CDI-enabled EAR was first depoyed (which would have setup the SingletonProvider in Weld to ACLSingletonProvider
2. A plain cdi osgi bundle is deployed, which would have reset the SingletonProvider to null.
3. Another CDI-enabled EAR is deployed. Since the ACLSingletonProvider was set only on the WeldActivator, the SingletonProvider would not be set to ACLSingletonProvider and hence this CDI-enabled EAR would use the default TCCLSingletonProvider. Isn't this wrong? Shouldn't we reset in step #2 to the earlier used SingletonProvider?

Comment by TangYong [ 09/Nov/12 05:24 AM ]

Thanks siva's comments very much!

Yes, you are right, and I add a comment about SingletonProvider. When defaultly triggering bootstrap.startInitialization() using Weld SPI, SingletonProvider's instance is IsolatedStaticSingletonProvider. So, I made the following fix, and lately, I will attch my newest patch.

if (SingletonProvider.instance() instanceof IsolatedStaticSingletonProvider){ SingletonProvider.reset(); }

Thanks.
Tang

Comment by TangYong [ 09/Nov/12 05:44 AM ]

The attachment(GLASSFISH-19215-patch_20121109.zip) is my newest patch for this feature.

In addition, I added a GlassFish-CDIEnabled metadata handling logic according to sahoo's suggestion.

Comment by TangYong [ 09/Nov/12 04:44 PM ]

Combined with sahoo and siva's comments and some issues found in integration tests, the newest patch has the following problems:

1 About SingletonProvider's initialize

Needs to consider multi-thread scene. I tried to directly start Weld-Integration bundle before triggering Weld-SPI , anything seemed to be fine. However, when combining with Weld Bootstrap's shutdown(now, handling logic is my local patch rather than appearing on my patch), because Weld-Integration's activate has a stop method which will reset SingletonProvider, we must take care of the point while managing Weld Bootstrap's shutdown in osgi-cdi module.

2 About position of publishing the beans

Better design is to make OSGiServiceExtension to publish beans in order that publish feature can work in hybrid javaee bundle.

The reason that I put the logic of publishing beans in OSGiCDIExtender is that I need to use Instance<object> to get bean service instance object, so we must get WeldManager, however, OSGiServiceExtension can not help me get Instance<object>.

3 About a exception called "WELD-001408 Unsatisfied dependencies "
After I deployed CDI OSGi Bundles, if I stop domain, and again start domain, deployed bundles should work normally, however, a exception happened in server.log,

org.glassfish.deployment.common.DeploymentException: WELD-001408 Unsatisfied dependencies for type [StockQuoteService] with qualifiers [@OSGiService] at injection point [[field] @Inject @OSGiService org.acme.cdiwab.impl.StockQuoteServlet.sqs]

4 About Weld Bootstrap's shutdown related handling
Doing.

Please siva and sahoo review in depth.

Thanks
Tang

Comment by TangYong [ 12/Nov/12 06:24 AM ]

>2 About position of publishing the beans
>Better design is to make OSGiServiceExtension to publish beans in order that publish feature can work in hybrid >javaee bundle.
>The reason that I put the logic of publishing beans in OSGiCDIExtender is that I need to use Instance<object> to get >bean service instance object, so we must get WeldManager, however, OSGiServiceExtension can not help me get >Instance<object>.

I have confirmed that in OSGiServiceExtension.beforeBeanDiscovery method, adding the second parameter BeanManager manager can get SPI Manager(WeldManager), seeing following:

void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bdd, BeanManager manager){
debug("beforeBeanDiscovery" + bdd);
bdd.addQualifier(OSGiService.class); //XXX:needed?

if (manager instanceof WeldManager){ this.manager = (WeldManager)manager; }
}

Then, in afterBeanDiscovery method, executing publishOSGiService should be good and can work for hybrid javaee bundle.

However, once using the above way, in OSGiServiceExtension, we just put a cdi implementation's dependency called org.jboss.weld.manager.api, if not minding this, I think that the way should be good.

In addition, please seeing https://issues.jboss.org/browse/CDI-14, and maybe in the future, CDI Specification will add a portable method called "Instance<Object> instance()", so, I suggest that firstly we use the above way, then, once new api published, we can modify and use that new api.

Thanks.
-Tang

Comment by TangYong [ 12/Nov/12 06:25 AM ]

>3 About a exception called "WELD-001408 Unsatisfied dependencies "
>After I deployed CDI OSGi Bundles, if I stop domain, and again start domain, deployed bundles should work normally, >however, a exception happened in server.log,

>org.glassfish.deployment.common.DeploymentException: WELD-001408 Unsatisfied dependencies for type >[StockQuoteService] with qualifiers [@OSGiService] at injection point [[field] @Inject @OSGiService >org.acme.cdiwab.impl.StockQuoteServlet.sqs]

I have sent two problems to you and siva and hong related the issue.

Tang

Comment by TangYong [ 12/Nov/12 06:29 AM ]

>4 About Weld Bootstrap's shutdown related handling
>Doing.

I consider that the issue's priority should be lower than 1,2, and 3 and fighterfish related test cases.

I think that let me implement 1,2,3 and fighterfish test cases firstly.

Thanks.
Tang

Comment by TangYong [ 14/Nov/12 12:23 PM ]

The attachment(GLASSFISH-19215-patch_20121114.zip) is the newest patch which has resolved 4 subtasks and passed my local integration test case.

Please sahoo and siva review it, and I will write fighterfish test cases(the fifth subtask).

Thanks.
Tang

Comment by TangYong [ 22/Nov/12 02:27 PM ]

Combined with GLASSFISH-15365 and GLASSFISH-19359, I have added into fixing for them and made some adjustment of 19215.

Now, the attachment(GLASSFISH-19215_fighterfishtestcase_final_20121122.zip) has passed the fighterfish tests which I have uploaded in my local env.

Please sahoo and siva review and confirm the version.

Comment by TangYong [ 05/Dec/12 12:06 PM ]

Yesterday, Siva has spent a lot of time to review my patch(GLASSFISH-19215_fighterfishtestcase_final_20121122.zip) and I arranged review contents in excel form in order to see and discuss them better. Please seeing attachment(reviewing_siva.xls).

Comment by TangYong [ 10/Dec/12 12:36 PM ]

Current fixing state has been uploaded, please seeing reviewing_siva_2012.12.10.xls

Comment by TangYong [ 11/Dec/12 08:19 AM ]

Currently, all problems from review other than splitting patch and needing to discuss have been fixed, about status, please seeing reviewing_siva_2012.12.11.xls.

Tomorrow, I will finish the working of splitting patch.

Comment by TangYong [ 11/Dec/12 09:05 AM ]

Splited patch for Glassfish-19215 is uploaded, please seeing GLASSFISH-19215-patch-20121211.zip





[GLASSFISH-4320] [v3] Expose Grizzly's Resource Consomption Management API, support officialy RCM Created: 29/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: jfarcand Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4147 Request prioritization in application... Open
Issuezilla Id: 4,320
Status Whiteboard:

v3-prd-item gfv3-prelude-excluded

Tags:
Participants: jfarcand, kumara, Sivakumar Thyagarajan and Tom Mueller

 Description   

Resource Consomption Management is implemented since v2 but not officially
supported:

http://blogs.sun.com/sduv/entry/resource_management_in_enterprise_application
http://weblogs.java.net/blog/jfarcand/archive/2007/06/improving_ajax_1.html

Now that Grizzly is fronting every thing in v3, RCM can be extended to support
GIOP/Corba, JMS, etc.



 Comments   
Comment by jfarcand [ 29/Feb/08 11:19 AM ]

...

Comment by jfarcand [ 05/Mar/08 07:43 AM ]
      • Issue 4384 has been marked as a duplicate of this issue. ***
Comment by Sivakumar Thyagarajan [ 07/Mar/08 12:07 AM ]

Grizzly's RCM can be viewed as just another instance of the request
prioritization planned in the container ( issue 4147 ) and so I think exposing
Grizzly' RCM separately in the admin GUI wouldn't be right.

This would essentially mean a user would need to use Grizzly RCM for Grizzly and
a "unified" resource prioritization model for all the other resources/containers
in v3, which doesn't seem right.

Comment by jfarcand [ 07/Mar/08 07:09 AM ]

Siva, since we are planning to use port unification, every connection will be
analyzed inside Grizzly via its tcp listener. So RCM should happens there since
the thread pool is handled by Grizzly. So I'm not sure I see that as 'just an
instance'. I agree with you if the case of not using port unification.

For sure we need to continue supporting what we have in v2 and add configuration
support under the new grizzly-config element.

Let's try to have a meeting with Jerome/Ken on that (just reply on the email
I've sent you internally )

Comment by jfarcand [ 07/Apr/08 03:06 PM ]

Currently available by adding, in domain.xml:

<property name="enableRCM" value="true"/>

Comment by kumara [ 19/Aug/08 10:31 PM ]

Add gfv3-prelude-include to status whiteboard

Comment by kumara [ 03/Sep/08 12:59 AM ]

v3 defect tracking

Comment by kumara [ 25/Sep/08 06:21 PM ]

The initial implementation is done. We need to go through formal
specification/documentation process and then adapt to that for final release.

Comment by jfarcand [ 09/Oct/08 06:04 PM ]

Re-assign to Siva and Sahoo will drive the effort for the overall GlassFish, not
only web container.

Comment by kumara [ 24/Oct/08 08:06 PM ]

Defect->Feature

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-7970] clean up application library classloaders during undeployment of the application Created: 22/Apr/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: v2.1
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: obdulin Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 7,970
Tags:
Participants: kumara, obdulin, Sivakumar Thyagarajan and Tom Mueller

 Description   

When you deploy an application with the --libraries option the server creates
individual classloaders for each of the jar files included. Those classloaders
are never cleaned up so when all the applications that use those libraries are
stopped the classloaders are still there and they may be holding references to
instances loaded by the application or web module classloader. That may
represent an important memory leak is you start and stop application quite often.

This is a summary from a chat with Sivakumar Thyagarajan:

I wrote: "However, I'm concern about the disposal of those classloaders. As far
as I understand the code, those classloaders are stored in a registry (static
HashMap) and they are never remove (until the JVM exits). If you see the library
as an extension of the application (that's my case) that could be a problem
since the classloader never gets gc and neither does the library's static
members object graph."

Sivakumar wrote: "Yes, you are right that we do not clean up application library
classloaders during undeployment of the application. If you could raise
a request for enhancement ticket we could fix it as soon as we can. We
can have a reference counting like mechanism and remove all library
classloaders that are not references by any deployed applications
and solve this issue."



 Comments   
Comment by kumara [ 01/Sep/09 01:09 AM ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-9570] Need Probes for WELD Created: 17/Sep/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: Nazrul Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 9,570
Status Whiteboard:

v3_excluded

Tags: 3_1-exclude
Participants: kumara, Nazrul, Sivakumar Thyagarajan and Tom Mueller

 Description   

Tracking bug.

Need probes for JCDI (web beans) functionality in GlassFish (glassfish:jcdi::).

References:
----------
Dashboard - http://appserver.sfbay.sun.com/Wiki.jsp?page=GFv3ProbesDashboard



 Comments   
Comment by Nazrul [ 17/Sep/09 03:49 PM ]

Adding Prashanth to the CC list and excluding from the GFv3 count.

Comment by Nazrul [ 16/Oct/09 05:56 PM ]

The official name for this feature is WELD.
JCDI -> WELD
glassfish:jcdi:: -> glassfish:weld::

Comment by kumara [ 07/Dec/09 02:34 AM ]

Setting target release for unresolved issues submitted on v3 release to the next release. Not changing
issues submitted on v2.x release because they might not apply to v3.next release.

Comment by Sivakumar Thyagarajan [ 19/Nov/10 08:44 AM ]

Marking it as a feature

Comment by Tom Mueller [ 06/Mar/12 09:59 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[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
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
Tags:
Participants: Sivakumar Thyagarajan and TangYong

 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 01:22 PM ]

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

Comment by TangYong [ 15/Oct/12 11:09 PM ]

siva, sahoo

Pl. add osgi-javaee into Component/s.

Comment by Sivakumar Thyagarajan [ 16/Oct/12 05:10 AM ]

Adding osgi-javaee to the component list





[GLASSFISH-15265] Allow callbacks on service lifecycle events in @OSGiService Created: 18/Dec/10  Updated: 15/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: not determined
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-exclude
Participants: Sanjeeb Sahoo and Sivakumar Thyagarajan

 Description   

Should @OSGiService optinally take a callback object for service lifecycle events?



 Comments   
Comment by Sivakumar Thyagarajan [ 22/Dec/10 03:45 AM ]

This new feature request may need an OSGiService annotation enhancement and require more analysis/thought for the design. So moving this to 3.2.

Comment by Sivakumar Thyagarajan [ 15/Oct/12 01:25 PM ]

Marking fix version as "not determined".





[GLASSFISH-16805] [osgi-cdi] support @Inject @OSGiService Instance<T> Created: 06/Jun/11  Updated: 22/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1
Fix Version/s: not determined

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18978 select OSGi services used in CDI bean... Sub-task Open Sanjeeb Sahoo  
Tags: 3_1-next
Participants: Sanjeeb Sahoo, Sivakumar Thyagarajan, TangYong and Tom Mueller

 Description   

Currently having something like
@Inject @OSGiService(dynamic=true)
private Instance<AdminService> adminService;

cause following exception:

java.lang.UnsupportedOperationException: Injection target type javax.enterprise.inject.Instance<org.glassfish.fighterfish.test.app18.AdminService>not supported
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterBeanDiscovery(OSGiServiceExtension.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:52)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:43)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:372)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:270)
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)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:55)
at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:43)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:372)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:170)
... 17 more

#]


 Comments   
Comment by Sanjeeb Sahoo [ 06/Jun/11 10:19 PM ]

assigning to Siva for evaluation.

Comment by Sivakumar Thyagarajan [ 07/Jun/11 04:17 AM ]

Tagging this as 3_1-next, as this is not critical for the 3.1.1 release.

Comment by Sanjeeb Sahoo [ 07/Jun/11 04:26 AM ]

Do you know why it is not working? Can you at least mention the reason?

Comment by Sivakumar Thyagarajan [ 13/Jun/11 05:52 AM ]

Marked it as an improvement(RFE)

Comment by Tom Mueller [ 06/Mar/12 09:57 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by TangYong [ 06/Aug/12 06:59 AM ]

Now, the feature has been supported combined with subTask(GLASSFISH-18978). Please see.

https://github.com/tangyong/gf-cdi-osgi-integration

DEMO1: https://github.com/tangyong/gf-cdi-osgi-integration/tree/master/samples/[RFP146]CDI018
DEMO2: https://github.com/tangyong/gf-cdi-osgi-integration/tree/master/samples/[RFP146]CDI004

Using Way:

1 get all osgi services
@Inject Service<StockQuoteService> sqses;
....

2 get osgi services qualified @ServiceFilter
@Inject @ServiceFilter("(country=CN)") Service<StockQuoteService> sqses;
...

Comment by TangYong [ 22/Nov/12 02:38 PM ]

After event integration was finished, the feature will start because compared with other features, it has been turned more important.





[GLASSFISH-18748] [osgi/cdi] An OSGi Service cannot be injected into a Stateful EJB Created: 21/May/12  Updated: 25/May/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: None

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

Tags:
Participants: aaronjwhiteside, marina vatkina and Sivakumar Thyagarajan

 Description   

An OSGi Service cannot be injected into a Stateful EJB

org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001413 The bean Session bean [class com.mm.keygenerator.Home with qualifiers [@Any @Default @Named]; local interfaces are [Home] declares passivating scope but has non-serializable dependency org.glassfish.osgicdi.impl.OSGiServiceExtension$OSGiServiceBean@3c1597f8
        at org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:323)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:294)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:243)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:126)
        at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:345)
        at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:330)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:199)
        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
        at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:313)
        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)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
        at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
        at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
        at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)

        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:202)
        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
        at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:313)
        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)
        ... 12 more
Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 2 exceptions:
Exception 0 :
org.jboss.weld.exceptions.UnserializableDependencyException: WELD-001413 The bean @New Session bean [class com.mm.keygenerator.Home with qualifiers [@New]; local interfaces are [Home] declares passivating scope but has non-serializable dependency org.glassfish.osgicdi.impl.OSGiServiceExtension$OSGiServiceBean@3c1597f8
        at org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:323)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:294)
        at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:243)
        at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106)
        at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:126)
        at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:345)
        at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:330)
        at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:366)
        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:199)
        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
        at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:313)
        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)
        at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
        at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
        at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
        at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
        at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
        at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)


 Comments   
Comment by marina vatkina [ 22/May/12 04:15 PM ]

Siva, Sahoo said it's your code...





[GLASSFISH-531] java.class.path is set to the shared chain list Created: 03/Apr/06  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 531
Tags:
Participants: gfbugbridge, Sivakumar Thyagarajan and Tom Mueller

 Description   

Issues raised by Kedar/Cheng Fang in a mail to dev@glassfish
Details at https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=996

Issues:

  • Though the actual VM classpath contains only appserv-launch.jar,
    java.class.path is now set to the entire shared chain list. This is confusing to
    users seeing JConsole/jinfo/GlassFish jvm reports.
  • References to internal jars that have been removed in GlassFish lie
    appserv-env.jar, jsf-api.jar etc has to be cleaned.


 Comments   
Comment by Sivakumar Thyagarajan [ 03/Apr/06 02:17 AM ]

Updated URL

Comment by gfbugbridge [ 26/Jun/06 09:26 AM ]

<BT6443390>

Comment by gfbugbridge [ 05/Apr/07 05:41 PM ]

<BT6543327>

Comment by Sivakumar Thyagarajan [ 11/May/07 06:33 AM ]

Accepting issue. Working on fix.

Comment by Sivakumar Thyagarajan [ 23/May/07 02:49 AM ]

"* References to internal jars that have been removed in GlassFish lie
appserv-env.jar, jsf-api.jar etc has to be cleaned."

The above part of the issue has been fixed as part of this putback
http://fisheye5.cenqua.com/changelog/glassfish?cs=MAIN:sivakumart:20070523051647

I am working on modifying java.class.path to not have the entire shared chain list.

Comment by Sivakumar Thyagarajan [ 15/Jul/07 11:05 PM ]

downgrading to P4.

As indicated in the bug report, I have already fixed a part of the bug
"* References to internal jars that have been removed in GlassFish lie
appserv-env.jar, jsf-api.jar etc has to be cleaned." and java.class.path alone
now points to the entire AS classpath.

I found out that a lot of appserver components still depend on "java.class.path"
[1] having the entire application server classpath. We had tried to move the
components we knew like verifier/JSP compilation away from dependence on
java.class.path and use other APIs, but this hasn't happened fully yet. Making
all the components move would be risky at this point and so I am downgrading
this issue to P4 and would consider it as a candidate for a future release (or
UR1 even).

Without fixing this, the only problem I see is java.class.path, when someone
views System.getProperties or in jconsole, would indicate a long classpath
containing all AS jars. Otherwise I think there are no visible issues.

[1]

> [16:21:04] [siva@saxaphone ../gfv2-ws/glassfish]$ find . -name "*.java"|xargs
grep "java.class.path"| grep getProper
> ./appserv-commons/src/java/com/sun/enterprise/util/FileUtil.java:
String classPath = System.getProperty("java.class.path");
> ./appserv-commons/src/java/com/sun/enterprise/util/diagnostics/Classpath.java:
return System.getProperty("java.class.path");
> ./appserv-commons/src/java/com/sun/enterprise/util/diagnostics/JWhich.java:
cp = System.getProperty("java.class.path");//NOI18N
> ./appserv-webtier/src/java/org/apache/catalina/util/ExtensionValidator.java:
String systemClasspath = System.getProperty("java.class.path");
> ./appserv-webtier/src/java/org/apache/jasper/JspC.java: return
System.getProperty("java.class.path");
> ./appserv-webtier/src/java/org/apache/jasper/JspC.java: return
System.getProperty("java.class.path");
> ./appserv-webtier/src/java/org/apache/tomcat/util/IntrospectionUtils.java:
String cpath=System.getProperty( "java.class.path");
> ./appserv-core/src/java/com/sun/appserv/server/util/ASClassLoaderUtil.java:
classpath.append(System.getProperty("java.class.path"));
> ./appserv-core/src/java/com/sun/ejb/codegen/IASEJBC.java: String
bigClasspath = System.getProperty("java.class.path")
> ./appserv-core/src/java/com/sun/ejb/codegen/IASEJBC.java:
options.add(System.getProperty("java.class.path")
> ./appserv-core/src/java/com/sun/enterprise/admin/verifier/ServerMgr.java:
String classPath = System.getProperty("java.class.path");
> ./appserv-core/src/java/com/sun/enterprise/server/PELaunch.java:
StringBuilder classpath = new StringBuilder(System.getProperty("java.class.path"));
>
./admin-cli/commands/src/java/com/sun/enterprise/cli/commands/DatabaseCommand.java:
// sClasspath = System.getProperty("java.class.path");
> ./cmp/enhancer/libsrc/com/sun/jdo/api/persistence/enhancer/Main.java:
String classpath = System.getProperty("java.class.path");
>
./cmp/enhancer/libsrc/com/sun/jdo/api/persistence/enhancer/PersistenceLauncher.java:
final String classpath = System.getProperty("java.class.path");
> ./tools/src/java/com/sun/enterprise/tools/common/util/JWhich.java:
cp = System.getProperty("java.class.path");//NOI18N
> ./tools/src/java/com/sun/enterprise/tools/common/util/mclasspath.java:
String cp = System.getProperty("java.class.path");//NOI18N

Comment by Tom Mueller [ 06/Mar/12 09:57 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2073] WinNTFileSystem throws IOException when asked to canonicalize classpath suffix. Created: 16/Jan/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 9.0peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: gugrim Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 2000
Platform: PC


File Attachments: Text File gf-issue-2073.txt    
Issuezilla Id: 2,073
Tags:
Participants: gugrim, Hong Zhang, Sivakumar Thyagarajan, sridatta and Tom Mueller

 Description   

During deployment a lot of exceptions are logged, thrown by WinNTFileSystem when
it is asked to canonicalize the entire classpath suffix from JVM settings, with
unexpanded ${path.separator} "macros".

These exceptions doesn't seem to prevent the deployment from successing but they
are still a bit worrying IMO.



 Comments   
Comment by gugrim [ 16/Jan/07 04:27 AM ]

Created an attachment (id=690)
Log entry and argument to canonicalize

Comment by Hong Zhang [ 16/Jan/07 06:20 AM ]

assign to siva to look at the classpath tokens.

Comment by sridatta [ 15/May/07 02:05 PM ]

Not a release stopper. P4.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-2328] PWC1406: Servlet.service() for servlet jsp threw exception Created: 05/Feb/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 9.1pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: elmooney Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


File Attachments: File bp-auto-complete.war     Text File server-jsp.log     File Transactional_Service_Sun_client.war    
Issuezilla Id: 2,328
Tags:
Participants: Dhiru Pandey, elmooney, jluehe, kchung, km, Sivakumar Thyagarajan, sridatta and Tom Mueller

 Description   

This is with
http://javaweb.sfbay/java/re/glassfish/9.1/promoted/beta/b34/images/solaris/glassfish-image-SNAPSHOT.jar
overloaded with
http://javaweb.sfbay/java/re/wsit/1.0/promoted/fcs/b06/bundles/wsit-1_0.zip.
Clicking on http://zephyr.east.sun.com:3001/applications/webApplications.jsf#
(launch) from Web Applications panel throws

javax.servlet.ServletException: java.lang.NoClassDefFoundError:
org/apache/tools/ant/BuildListener

Log attached.



 Comments   
Comment by elmooney [ 05/Feb/07 01:05 PM ]

Created an attachment (id=719)
server.log with exception near bottom

Comment by elmooney [ 05/Feb/07 01:08 PM ]

Created an attachment (id=720)
web app attempting to launch

Comment by Dhiru Pandey [ 05/Feb/07 01:33 PM ]

looks like this may be an issue with asadmin script since it is not including
the imqbroker.jar in the classpath. please try adding the following in asadmin
script's classpath

AS_IMQ_LIB/imqbroker.jar

Comment by Dhiru Pandey [ 05/Feb/07 01:35 PM ]

Ignore my previous comment. It was mean't for issue 2317. Sorry

Comment by elmooney [ 06/Feb/07 10:08 AM ]

I had installed GF into a directory with a "," in it's name. This doesn't happen
when I install GF into a directory without a "," in it's name.

Comment by sridatta [ 09/Apr/07 01:47 PM ]

assigning to Jan for investigation

Comment by jluehe [ 11/Apr/07 12:00 PM ]

Asking Kin-Man to take a look.

Comment by kchung [ 11/Apr/07 05:12 PM ]

Please include the exact steps for reproducing the problem, starting with
glassfish download. Thanks.

Comment by elmooney [ 19/Apr/07 11:01 AM ]

Created an attachment (id=882)
web tier example from blue prints

Comment by elmooney [ 19/Apr/07 11:02 AM ]

On Solaris:

% # Save attachment bp-auto-complete.war
% mkdir com,ma # The most important step
% cd com,ma
% wget
http://javaweb.sfbay/java/re/glassfish/9.1/promoted/beta2_branch/latest/images/solaris/glassfish-image-SNAPSHOT.jar
% jar xvf glassfish-image-SNAPSHOT.jar
% ant -f setup.xml
% bin/asadmin start-domain
% bin/asadmin deploy bp-auto-complete.war
% # Open http://localhost:4848/
% # Click on "Web Applications"
% # Click "Launch" to the right of bp-auto-complete.
% # Application fails top launch. Check server log for stack trace.

Comment by kchung [ 30/Apr/07 04:33 PM ]

The root of this problem seems to be related to the classpath for jasper loader.
In ASLauncher (in admin-core), ant.jar is included in properties
com.sun.aas.classloader.serverClassPath and
com.sun.aas.classloader.sharedChainJars. However, these lists assume that jars
are separated by a comma (','). The same assumption is again made in PELaunch
(in appserv-core). Hence, if the path to ant.jar contains a comma, bad things
happen.

Reassigned to Kedar.

Comment by km [ 15/May/07 07:37 PM ]

Apparently, we don't support directory names with ',' in their names
for this particular case. The classloader hierarchy is based on comma-separated
list. So, Launcher is doing the right thing. Looks like the right way is
to use some other delimiter, or not use any delimiter at all. Assigning to Siva
for advice.

IMO, this can be downgraded to P4. elmooney – do you agree?

Comment by elmooney [ 16/May/07 04:57 AM ]

I agree.

Comment by Sivakumar Thyagarajan [ 17/May/07 07:33 AM ]
      • Issue 2317 has been marked as a duplicate of this issue. ***
Comment by Sivakumar Thyagarajan [ 17/May/07 07:41 AM ]

There was also a similar issue already logged as 2317. I have closed that as a
duplicate of this as this issue had more information on reproducing the issue
and comments. I have also been able to reproduce this issue with the
instructions listed below. The analysis listed below is correct and the reason
there is a failure to load the Ant class is because of the comma in the
directory name that conflicts with the use of "comma" as a delimiter while
computing the classpath.

As of now the workaround is to not install the application server in a
directory with a "comma" in its name. I assume manually modifying
processLauncher.xml and domain.xml to escape all references to the comma might
also help.

One of the potential fixes is to not use "comma" as a delimiter, but any other
ascii character choice would have the same issue [?]. So we need to figure out
if we could "escape" the directory name during installation/domain-creation so
that this issue would not happen while creating the classpath. Please let me
know if there are any other alternatives.

I will discuss this with others and think this through before we make a fix for
this issue. Thanks.

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-3915] LinkageError in EJB Created: 13/Dec/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: eduardp Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Linux


File Attachments: GZip Archive testcase.tar.gz    
Issuezilla Id: 3,915
Status Whiteboard:

as911-na

Tags:
Participants: eduardp, harpreet, sanandal, Sivakumar Thyagarajan and Tom Mueller

 Description   

I have the following setup :
I'm usings sjsas 9.1 update 3 (glassfish v2)
I have a class library that I wrote to do logging for my connectors / ejb's.
This library has a Logger interface with debug, info etc. methods.
I have 2 connectors. Both connectors use the library. The first connector uses
it to do logging while connecting to our AS400 mainframe, the second connector,
let's call it the logging connector, uses it to create and pass logger instances
to other ejb's packaged in an ear file.

The as400 connector works fine and logs without problems.
The ejb that fails injects both connectors using setter injection. When it asks
the logging connector for a Logger, the logger is created and returned
successfully, but the moment I call a method on the Logger interface I get this
error :

java.lang.LinkageError: Class libraries/ejbLogging/Logger violates loader
constraints

If I remove all references to this class from the AS400 connector, then the
logging connector works fine. Also copying the library jar file to the
domain/lib directory, and removing it from both rar and ear files works. But
according to me I should not have to do this.

I've also noticed that the documentation says that the "connector class loader"
is a single class loader instance. In my debugging efforts, I noted that each
connector seems to have it's own class loader.



 Comments   
Comment by Sivakumar Thyagarajan [ 13/Dec/07 07:14 PM ]

Could you provide more information to help us debug this issue better?

  • How have you bundled the two RARs? Could you provide the directory structure
    of the two RARs? Where are the logging interfaces bundled?
  • If there is a stacktrace with the LinkageError could you share it please?
  • I am assuming you are deploying both the RARs as standalone?
  • Would you be able to share a simple testcase that helps us reproduce the issue
    locally?

"I've also noticed that the documentation says that the "connector class loader"
is a single class loader instance. In my debugging efforts, I noted that each
connector seems to have it's own class loader."

Yes, as you have correctly noticed, though the connector classloader, as shown
in the documentation, logically is a single classloader, it in turn contains a
classloader per standalone RAR deployment. This is to aid dynamic/hot
redeployment of standalone connector modules.

Comment by eduardp [ 14/Dec/07 04:21 AM ]

1. The rar's are deployed as standalone and look like this :

configuration:

– META-INF
  – MANIFEST.MF
`-- ra.xml
– javaee.jar
– libraries.configuration-configuration.jar
– libraries.ejbUtils-ejbUtils.jar
– log4j.jar
– services.configurationConnector.client-client.jar
`-- services.configurationConnector.server-server.jar

as400:

– META-INF
  – MANIFEST.MF
`-- ra.xml
– javaee.jar
– jt400.jar
– libraries.ejbUtils-ejbUtils.jar
– log4j.jar
– services.as400Connector.client-client.jar
`-- services.as400Connector.server-server.jar

The manifest files are essentially empty. The common logging code is in
libraries.ejbUtils-ejbUtils.jar. This is the same jar that the ear file (the
one that breaks) includes.

2. Here is the stack trace I get from my junit test case
(services.orbit.client.FISCHRHRemote is the remote iterface in my ear) :

java.lang.LinkageError: Class libraries/ejbUtils/logging/Logger violates loader
constraints
at services.orbit.client._FISCHRHRemote_Wrapper.GETUNIQUESCHEME
(services/orbit/client/_FISCHRHRemote_Wrapper.java)
at TestCorbaClient.testOrbitServer(TestCorbaClient.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run
(OldTestClassRunner.java:35)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run
(JUnit4TestReference.java:38)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run
(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
(RemoteTestRunner.java:196)

3. I'll try to produce a test case, but this might be a bit difficult, I'll
post it when I have something

Comment by Sivakumar Thyagarajan [ 11/Feb/08 02:20 AM ]

Sorry for the delay in the response.

Could you try providing a testcase? I was not able to reproduce this locally.
May be I am missing some of your steps while trying to reproduce this.

Could you also provide some clarifications?
1. Is libraries.ejbUtils-ejbUtils.jar is also included in the EAR?

"java.lang.LinkageError: Class libraries/ejbUtils/logging/Logger violates loader
constraints at services.orbit.client._FISCHRHRemote_Wrapper.GETUNIQUESCHEME
(services/orbit/client/_FISCHRHRemote_Wrapper.java)"
I am assuming libraries/ejbUtils/logging/Logger is bundled in
libraries.ejbUtils-ejbUtils.jar.

2. How do you inject the Logger instance from the Logging RA into the EJB? Could
you provide some sample code? It appears that the Logger class loaded in the EJB
classloader does not appear to be the same Logger class the connector
classloader has loaded, inspite of delegation. How do you run this test in
junit? I don't see any glassfish classes being in the stack trace. Are you just
making a remote EJB call?

Sorry again for the delay in the response, but if you could help us by providing
more details, we could investigate this further and consider a fix in 9.1.1. Thanks.

Comment by harpreet [ 12/Mar/08 02:01 PM ]

Marking as not applicable for as9.1.1 as there is no test case provided yet. Once provided I can look into
approving it for FCS for v.2.1

Comment by eduardp [ 13/Mar/08 02:40 AM ]

Hi

Sorry for the slow response, I had to hack the code to not be dependant on any
of our infrastructure.

I've included both the rar and ear files as well as the source code.

You will need to deploy all 3 of then call the sayHello method on the
HelloWorld ejb. The 2 connectors need to be registered as as400/as400Connector
and configuration/configurationConnector in the jndi.

Let me know if you need more information

Regards
Eduard

Comment by eduardp [ 13/Mar/08 02:55 AM ]

Created an attachment (id=1379)
testcase to reproduce the error

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 09:58 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4961] Glassfish install directory being added to the JRE classpath Created: 30/Apr/08  Updated: 25/Jan/11

Status: Open
Project: glassfish
Component/s: configuration
Affects Version/s: v2.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: cjmal Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,961
Tags:
Participants: cjmal, km, kumara, sanandal, Sivakumar Thyagarajan and Tom Mueller

 Description   

We have noticed that the Glassfish install directory is being placed onto the
end of the JRE Classpath for the running server.

The causes problems for any code which uses wildcarding to find resources on
the classpath. It can find resources from any of the web applications deployed
in the default domain1.

For example spring loading of resources from the classpath using wildcarding
will find files acrosss multiple wars deployed to the same domain. (eg using
"classpath*:*/-applicationContext.xml")

Steps to see the problem:

  • It does not matter where glassfish is installed, but for the sake of
    this example assume glassfish is installed in "/usr/local/glassfish".
  • Via the Administration web interface examine the JVM Report
    (Application Server --> General --> JVM Report)
  • The report displays the current value of the JRE Classpath:

"JRE Classpath: ........
:/usr/local/glassfish/lib/appserv-ext.jar:/usr/local/glassfish"

The install directory is always included as the last part of the JRE classpath.

Our environment is:

  • glassfish server version is 9.1_01.
  • using jre 1.5.0.11
  • problem appears on Ubuntu 7.03, Mac, and Windows Vista.
  • using the default "domain1".
  • we have not modified any of the server classpath configuration values
    (eg classpath prefix/suffix, system classpath)
  • we do not have any CLASSPATH environment variable defined


 Comments   
Comment by km [ 02/Jun/08 05:23 PM ]

I agree, I can't think of any reason why this would be needed.

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by kumara [ 01/Sep/09 01:09 AM ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Tom Mueller [ 25/Jan/11 11:48 AM ]

Cleared the Fix version field since this issue isn't going to be fixed in V3.





[GLASSFISH-5222] EJBClassLoader.InternalJarURLConnection reports incorrect content-type Created: 26/Jun/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 9.1peur1
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,222
Tags:
Participants: sanandal, Sivakumar Thyagarajan, Tim Quinn and Tom Mueller

 Description   

The EJBClassLoader.InternalJarURLConnection class should override getContentType
rather than deferring to the implementation at java.net.URLConnection. It could
probably just invoke the public static
java.net.URLConnection.guessContentTypeFromName or guessContentTypeFromStream
method.

This problem appeared when a user built an app client that uses JavaHelp. The
help text is displayed in raw HTML form rather than formatted as it should be -
and as it is when run in a plain Java app. Here's why.

JavaHelp uses a JEditorPane, which accepts a URL pointing to the content to be
displayed. JEditorPane opens a connection to the URL in order to invoke the
connection's getContentType method and then uses this content type in setting
the content type on the JEditorPane. This allows the GUI to format the content
appropriately.

A URL returned by the typical URLClassLoader creates an instance of
sun.net.www.protocol.jar.JarURLConnection for use as its connection, and the
getContent method in that class examines the first few bytes of the stream to
"guess" what the content type is. This works fine with JavaHelp.

Many places in GlassFish - including the app client container - use the
EJBClassLoader class. To avoid some side-effects of URLClassLoader (locked JAR
files on Windows, for example) the EJBClassLoader uses its own connection class
which extends the public and supported java.net.JarURLConnection (not the
private unsupported sun.net.www.protocol.jar.JarURLConnection). Neither
EJBClassLoader's connection class nor java.net.JarURLConnection overrides
getContentType, so the implementation from the URLConnection is used. This
method simply looks at the content-type header in the URL, which for a
JarURLConnection does not exist.

JavaHelp running in the app client - and therefore under the influence of the
EJBClassLoader.InternalJarURLConnection - retrieves the null content type from
the connection and uses that to set the content type for the JEditorPane,
causing the plain-text display the user noticed instead of the formatted display
expected.



 Comments   
Comment by Tim Quinn [ 27/Jun/08 03:29 PM ]

By the way, I've tested a simple fix in my local workspace that is working.
I've sent it to Siva.

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-5396] Custom connector api classes not visible to war inside ear when deploying resource adapter as module in ear Created: 29/Jul/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 9.1peur2
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: obergner Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 5,396
Tags:
Participants: Jagadish, obergner, sanandal, Sanjeeb Sahoo, Sivakumar Thyagarajan and Tom Mueller

 Description   

When deploying an ear containing

  • a custom resource adapter exposing customer connection and connection factory
    classes, and
  • a war using this custom resource adapter

the embedded rar module deploys successfully, yet the embedded web module fails
to deploy with

[#|2008-07-25T00:59:16.088+0200|SEVERE|sun-appserver9.1|
javax.enterprise.system.container.web|
_ThreadID=16;_ThreadName=Thread-76;_RequestID=e7a1650b-7a69-4457-
a4c6-0daeef4258d5;|WEB0123: WebModule [/ws] failed to deploy and has been
disabled
java.lang.IllegalArgumentException:
[de.saxsys.osgira.shared.connectorapi.factory.JeeServiceLookupConnectionFactory]
is not an allowed property value type
at com.sun.enterprise.deployment.ResourceReferenceDescriptor.checkType
(ResourceReferenceDescriptor.java:492)
at com.sun.enterprise.naming.NamingManagerImpl.bindObjects
(NamingManagerImpl.java:530)
at com.sun.enterprise.web.WebModuleContextConfig.configureResource
(WebModuleContextConfig.java:220)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent
(WebModuleContextConfig.java:161)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:143)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:6350)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4848)
at com.sun.enterprise.web.WebModule.start(WebModule.java:326)

where
de.saxsys.osgira.shared.connectorapi.factory.JeeServiceLookupConnectionFactory
is a custom JCA connection factory.

The jar containing
de.saxsys.osgira.shared.connectorapi.factory.JeeServiceLookupConnectionFactory
lives inside the ear's lib directory. See http://forums.java.net/jive/
thread.jspa?threadID=44527&tstart=45 for a more through description.

Conclusion: The classloader which resolves the embedded war's resource
references has no visibility into classes deployed inside the ear's lib
directory.



 Comments   
Comment by Jagadish [ 30/Jul/08 02:01 AM ]

Requesting Siva to investigate the class-loader issue.

Comment by Sanjeeb Sahoo [ 30/Jul/08 03:38 PM ]

added cc

Comment by sanandal [ 11/Jan/09 07:01 AM ]

"Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
release whose primary release driver is SailFin.
This issue will be scrubbed after this release and will be given the right
priority for the next release."

Comment by Tom Mueller [ 06/Mar/12 09:56 PM ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[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
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: osgi-cdi osgi-javaee future-release
Participants: Sivakumar Thyagarajan and TangYong

 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 09:15 AM ]

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 10:02 AM ]

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 01:56 PM ]

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 04:19 PM ]

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 Sat Apr 19 04:52:21 UTC 2014 using JIRA 4.0.2#472.