[GLASSFISH-3625] Report non-portable annotation use in code Created: 19/Sep/07  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Attachments: Text File Bug3625.zip     Text File Bug3625.zip    
Issuezilla Id: 3,625

 Description   

Verifier currently does not report about non-portable annotation usage in the
code. The API scanning facility needs to be improved to scan class data section
that contains annotations. An example of where current verifier does not report
a failure is given below:

@WebService
public class MyServletEndpoint {
@javax.ejb.TransactionAttribute(REQUIRES_NEW) // incorrect use
public void registerUser(String username, String encodedPW)

{ // ... }


}

I think, we need to switch to ASM based API scanning implementation to address
this issue.

Sahoo



 Comments   
Comment by Sanjeeb Sahoo [ 26/May/08 ]

Confirming the issue.

Comment by seemarich [ 05/Jun/08 ]

Created an attachment (id=1537)
New files, old files, patch and a readme

Comment by seemarich [ 14/Jun/08 ]

Created an attachment (id=1558)
Updated patch is attached

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4148] Verifier should be aware of Java EE 6 specification Created: 10/Feb/08  Updated: 06/Mar/12

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

Type: New Feature Priority: Blocker
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,148
Status Whiteboard:

v3-prd-item


 Description   

This is an umbrella RFE. When we write the one-pager, we need to break this down
into multiple manegable RFEs. In a nutshell, verifier needs to be aware of Java
EE 6 rules. At a minimum, it must not flag valid Java EE 6 archive as failures.



 Comments   
Comment by Sanjeeb Sahoo [ 10/Feb/08 ]

Tagged as v3 prd item.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-11833] Fixes to OSGi EJB Container Created: 29/Apr/10  Updated: 06/Mar/12

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

Type: Task Priority: Critical
Reporter: jplatts Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows Vista
Platform: All


Attachments: Text File osgi-ejb-container-fix.diff    
Issuezilla Id: 11,833

 Description   

I have made some fixes to the OSGi EJB Container. Here are the fixes that I have
made to the OSGi EJB Container:

  • In the EJBTracker.addingService method, ensured that the service object was
    always returned. Exceptions thrown after the service object were returned are
    handled and logged within the addingService method before returning the service
    object. The service object is always returned here to ensure that cleanup can
    occur in the EJBTracker.
  • In the EJBTracker.removedService method, the getService call should not be
    used to grab the service object. The service parameter should be used instead of
    the getService call. EJBTracker.removedService method is also supposed to unget
    the service. The default implementation in ServiceTracker.removedService does
    unget the service.
  • A map mapping ServiceReferences to ConcurrentLinkedQueues containing EJB
    Service Registrations is added to EJBTracker. This ensures that all EJBs
    registered by EJBTracker.addingService are unregistered when
    EJBTracker.removedService is called.
  • The EJBTracker.removedService method will ensure that any services registered
    by the EJBTracker.addingService method for the given ServiceReference are
    unregistered. This is accomplished by obtaining the ConcurrentLinkedQueue for
    the ServiceReference passed into the EJBTracker.removedService, and then polling
    the ConcurrentLinkedQueue for any ServiceRegistration objects in the queue. For
    any ServiceRegistration objects that have been removed from the
    ConcurrentLinkedQueue, the unregister() method is called on these
    ServiceRegistration objects to ensure that the services registered by the
    EJBTracker.addingService method are unregistered.
  • The EJBTracker.removedService method will remove the ConcurrentLinkedQueue
    that the ServiceReference is mapped to from the map if the queue is empty.
  • I added a method to OSGiEJBContainer to close the EJB tracker. This is added
    to ensure that the EJBTracker is stopped whenever the EJBExtender is stopped.

The fixes that I made address the following issues with the OSGi EJB container:

  • The ServiceTracker might still continue tracking services when the EJBExtender
    is stopped. I added a method to OSGiEJBContainer to close the EJB tracker to
    ensure that the EJBTracker does not perform any tracking whenever the
    EJBExtender is stopped.
  • The EJBTracker did not properly unget the service in the
    EJBTracker.removedService. In addition, the service object was obtained using
    the BundleContext.getService call instead of using the service object passed
    into the EJBTracker.removedService method. The correct behavior is to use the
    service object parameter in EJBTracker.removedService and to unget the service here.
  • The EJBTracker.addingService always returns the service object, even if an
    exception gets thrown after the service object is obtained by the getService
    call. This ensures that the cleanup in EJBTracker.removedService is performed
    and ungetting the service occurs in EJBTracker.removedService.
  • The EJBTracker did not unregister the services registered by addingService in
    removingService. A map mapping ServiceReferences to ConcurrentLinkedQueues
    containing ServiceRegistrations is used to ensure that the EJBTracker
    unregisters services in the EJBTracker.removedService method.

Attached is the patch that incorporates the changes described here.



 Comments   
Comment by jplatts [ 29/Apr/10 ]

Created an attachment (id=4320)
Patch to OSGi EJB Container

Comment by Sanjeeb Sahoo [ 29/Apr/10 ]

First and foremost, thank you for taking time to analyse the code and not only
find bugs but also coming up with patch. Can you explain what problem you
foresee if the registered EJB services are not unregistered? Since they are
registered using the bundle context of the EJB JAR Bundle, won't they
automatically unregistered by the framework when EJB JAR Bundle is stopped? The
only way to undeploy the EJBs is to stop the EJB JAR Bundle. SO, I really don't
see any issue on this count.

I agree about EJBTracker left open.

I tend to agree about the missing exception handling logic as well.

Thanks much,
Sahoo

p.s. I tried to find out if we have ever interacted before. I could not find any
such instance. So, I am a bit surprised to see your involvement in this code. I
tried to look for your real name and the closest I got is John Platts as
mentioned in our SCA page.

Comment by jplatts [ 29/Apr/10 ]

I included the service unregistration logic to ensure that service references
are not leaked out whenever the EJB JAR gets undeployed, but I believe that this
code might be unnecessary.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-11780] Specify bundle metadata corretcly. Created: 11/Apr/10  Updated: 11/Mar/13

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

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: XML File bundles.xml    
Issue Links:
Dependency
depends on GLASSFISH-13236 [jersey] Jersey bundles optionally de... Resolved
depends on GLASSFISH-13165 Jersey uses DynamicImport-Package: * Open
blocks GLASSFISH-11782 Make GlassFish embeddable in OSGi env... Open
Issuezilla Id: 11,780
Tags: 3_1-exclude

 Description   

Two issues:
a) lack of correct package constraints in their Import-Package header:
Depending on they are consumers or providers, they should have appropriate upper
bound. Most of them import infinite as upper bound. This won't work for
providers, because a provider can only implement a certain package version range.
Similarly the issue of lower bound. some bundles don't specify lower bounds
while in practice they require a specific lower bound.

b) too many packages exported: Packages like metro export everything and in the
process they also leak implementation details.

This is an umbrella issue. We will require each module owner to fix their
modules and update this issue.



 Comments   
Comment by Richard S. Hall [ 14/Apr/10 ]

cc heavy

Comment by Sanjeeb Sahoo [ 01/Jul/10 ]

Now that we have made JAXB and JAX-WS packages part of system bundle even for
Equinox (see svn revision #38298 and issue #11781), when I run QL on Equinox
platform [1], I see quite a few failures. They are all related to following
exceptions found in server.log:
[#|2010-07-02T10:08:15.438+0530|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=40;_ThreadName=Thread-1;|Exception
while loading the app
org.glassfish.deployment.common.DeploymentException: Interceptor Class class
numberguess.InterceptorA has no method annotated with interface
javax.annotation.PostConstruct
Caused by: java.lang.IllegalStateException: Interceptor Class class
numberguess.InterceptorA has no method annotated with interface
javax.annotation.PostConstruct
[#|2010-07-02T10:09:06.867+0530|SEVERE|glassfish3.1|com.sun.xml.ws.server.http|_ThreadID=26;_ThreadName=Thread-1;|WSSERVLET11:
failed to parse runtime descriptor: java.lang.IllegalArgumentException: class
jaxwsfromwsdl.server.AddNumbersImpl has neither @WebService nor
@WebServiceProvider annotation
java.lang.IllegalArgumentException: class jaxwsfromwsdl.server.AddNumbersImpl
has neither @WebService nor @WebServiceProvider annotation

This indicates that some bundles are getting wired to JRE and some bundles are
getting wired to some other OSGi bundles for the same class. When I look at the
import package definitions, I see that quite a few bundles imprt packages with
no version range. Given below is such a list generated from a workspace which is
built in 1 July 2010:

grep javax /home/ss141213/WS/hk2/trunk/dependency-verifier/bundles.xml | grep
"[0.0.0" | grep -v javax.net | grep -v javax.management | grep -v javax.rmi |
grep -v javax.xml.stream | grep -v javax.sql | grep -v javax.naming | grep -v
javax.xml.transform | sort -u
javax.annotation.security; version="[0.0.0, infinity)",\
javax.annotation; version="[0.0.0, infinity)",\
javax.ejb; version="[0.0.0, infinity)",\
javax.el; version="[0.0.0, infinity)",\
javax.enterprise.context.spi; version="[0.0.0, infinity)",\
javax.enterprise.context; version="[0.0.0, infinity)",\
javax.enterprise.event; version="[0.0.0, infinity)",\
javax.enterprise.inject.spi; version="[0.0.0, infinity)",\
javax.enterprise.inject; version="[0.0.0, infinity)",\
javax.faces.application; version="[0.0.0, infinity)",\
javax.faces.bean; version="[0.0.0, infinity)",\
javax.faces.component.behavior; version="[0.0.0, infinity)",\
javax.faces.component.html; version="[0.0.0, infinity)",\
javax.faces.component; version="[0.0.0, infinity)",\
javax.faces.component.visit; version="[0.0.0, infinity)",\
javax.faces.context; version="[0.0.0, infinity)",\
javax.faces.convert; version="[0.0.0, infinity)",\
javax.faces.el; version="[0.0.0, infinity)",\
javax.faces.event; version="[0.0.0, infinity)",\
javax.faces.lifecycle; version="[0.0.0, infinity)",\
javax.faces.model; version="[0.0.0, infinity)",\
javax.faces.render; version="[0.0.0, infinity)",\
javax.faces.validator; version="[0.0.0, infinity)",\
javax.faces; version="[0.0.0, infinity)",\
javax.faces.view.facelets; version="[0.0.0, infinity)",\
javax.faces.view; version="[0.0.0, infinity)",\
javax.faces.webapp; version="[0.0.0, infinity)",\
javax.interceptor; version="[0.0.0, infinity)",\
javax.jws.soap; version="[0.0.0, infinity)",\
javax.jws; version="[0.0.0, infinity)",\
javax.mail.internet; version="[0.0.0, infinity)",\
javax.mail.util; version="[0.0.0, infinity)",\
javax.mail; version="[0.0.0, infinity)",\
javax.persistence; version="[0.0.0, infinity)",\
javax.resource.spi; version="[0.0.0, infinity)",\
javax.servlet.annotation; version="[0.0.0, infinity)",\
javax.servlet.descriptor; version="[0.0.0, infinity)",\
javax.servlet.http; version="[0.0.0, infinity)"
javax.servlet.http; version="[0.0.0, infinity)",\
javax.servlet.jsp.el; version="[0.0.0, infinity)",\
javax.servlet.jsp.jstl.core; version="[0.0.0, infinity)",\
javax.servlet.jsp.jstl.fmt; version="[0.0.0, infinity)",\
javax.servlet.jsp.jstl.sql; version="[0.0.0, infinity)",\
javax.servlet.jsp.tagext; version="[0.0.0, infinity)",\
javax.servlet.jsp; version="[0.0.0, infinity)",\
javax.servlet; version="[0.0.0, infinity)",\
javax.validation.bootstrap; version="[0.0.0, infinity)",\
javax.validation.constraints; version="[0.0.0, infinity)",\
javax.validation.groups; version="[0.0.0, infinity)"
javax.validation.groups; version="[0.0.0, infinity)",\
javax.validation.metadata; version="[0.0.0, infinity)",\
javax.validation; version="[0.0.0, infinity)",\
javax.xml.bind.annotation.adapters; version="[0.0.0, infinity)",\
javax.xml.bind.annotation; version="[0.0.0, infinity)",\
javax.xml.bind.attachment; version="[0.0.0, infinity)",\
javax.xml.bind; version="[0.0.0, infinity)",\
javax.xml.soap; version="[0.0.0, infinity)",\
javax.xml.ws; version="[0.0.0, infinity)",\

The file containing bundle metadata is attached here with. See bundles.xml. Open
that file, look at your bundle and see what Java EE packages without version
constraint. Fix it please. To generate the file yourself, refer to the email
that was sent to dev forum earlier.

Chris,

I have reassigned the issue to you, because this issue needs to be addressed by
respective module owners and you are in a better position to coordinate that
than me.

[1] To run QL on Equinox, do the following:
cd glassfish/osgi/equinox/
wget
http://download.eclipse.org/equinox/drops/R-3.5.1-200909170800/download.php?dropFile=org.eclipse.osgi_3.5.1.R35x_v20090827.jar
export GlassFish_Platform=Equinox
Now run QL. Please ensure you see this message in server.log:
"startup time : Equinox"

Comment by Sanjeeb Sahoo [ 02/Jul/10 ]

Created an attachment (id=4535)
Bundle metadata

Comment by Sanjeeb Sahoo [ 27/Aug/10 ]

Updated dependency

Comment by Chris Kasso [ 13/Dec/10 ]

No additional work will be done on this issue for 3.1. For 3.2 Rajiv (3.2 lead) should work with Sahoo to determine which modules need additional work.





[GLASSFISH-11745] add option to clear the verifier-cache Created: 01/Apr/10  Updated: 06/Mar/12

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

Type: Improvement Priority: Critical
Reporter: vince kraemer Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Solaris
Platform: Sun


Issuezilla Id: 11,745

 Description   

I have run into this a couple times.

I have a couple different v3 installs that I have updated to include the verifier.

If I run the verifier from install A, then run the verifier from install B, I
end up with some really interesting stack traces... including traces that
indicate that the verifier from install B is looking for jars from install A.

Once I clear the /tmp/verifier-cache, the stack traces go away.

maybe we should add an option to clear this cache... or detect that cache is
invalid and clear it automagically.

I think https://netbeans.org/bugzilla/show_bug.cgi?id=183000 is related to this
invalid cache issue.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-14620] Enable cluster support for hybrid apps Created: 11/Nov/10  Updated: 20/Oct/13

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

Type: Task Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,620

 Description   

We need to add entries in domain.xml for hybrid apps for hybrid apps to take
advantage of glassfish cluster.



 Comments   
Comment by ancoron [ 10/Sep/11 ]

Hi,

I'm really looking forward for the OSGi/Cluster support. However, I assumed that (at least) OSGi/EJB bundles deployed into a cluster should automatically benefit from the EJB-clustering.

I really should test that, but didn't manage to get some spare time in this area.

So exactly what does this issue mean?

Comment by TangYong [ 06/Sep/12 ]

I agree with Ancoron and firstly need to know what is the mean of deploying a osgi app into Cluster.

Wish sahoo can explain in details.

Comment by TangYong [ 13/Oct/12 ]

Sahoo, I forgot a point about the task, I want to ask the relation between the task and GLASSFISH-11700.
If GLASSFISH-11700 has not been implemented, I think that the task can not be implemented, in addition, what ancoron said ejb-clustering is not considered until implemeting GLASSFISH-11700 (that is to say, implementing osgi cluster deployment).

In addition, about osgi ejb-clustering self, on current osgi alliance ejb/osgi draft, it is not stated because the feature is not standardard and belongs to vendor behavior, (ejb3.x is not also stating the point), if needing to implement it, I think that we must consider current ejb container's implementing, then properly define osgi ejb clustering's behavior.

Comment by zhsc [ 20/Oct/13 ]

Any thoughts on feasibility / progress / likelihood of this functionality.

It seems the hold up is the behavior of these hybrid apps in a cluster environment is undefined in both osgi and javaee specs?

Is it possible today to deploy bundles to multiple managed servers in a domain (i.e. from autodeploy/bundles) at all? i.e. at least be managed together even if not fully "clustered"?





[GLASSFISH-15585] GF fails to start with java.security.debug property set Created: 14/Jan/11  Updated: 07/May/14

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b01
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: Martin Grebac Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File error.log     Text File mutual-recursion-problem.txt    
Tags: 3_1-exclude, 3_1-next, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

Switch security manager on. Set java.security.debug logging property to 'all' or 'access:stack'. GF fails to start or behaves indeterministicaly. This makes it very hard to obtain debugging information for security issues.



 Comments   
Comment by naman_mehta [ 16/Jan/11 ]

hi,

I tried the same to reproduce but not get any error on my machine. I run quicklook also.

1. Setup GF latest
2. Start GF
3. Run command: ./asadmin set-log-levels java.security.debug=ALL
4. Stop GF
5. Run QL on above setup.

It went fine no exception is server.log also. Is this the correct way to reproduce?

Comment by Martin Grebac [ 17/Jan/11 ]

Make sure you switch security manager on. See e.g. 15536 how to switch it on. Did you get long full log with security debugging statements? If not, you did not reproduce correctly.

Comment by naman_mehta [ 17/Jan/11 ]

As per your comment, server is failing to start after java.security.debug logging property set to 'all'.

I tried as per mention in bug 15536.

1. Setup GF latest
2. Start GF
3. Run command: ./asadmin set-log-levels java.security.debug=ALL
4. Stop GF
5. Start GF again
6. cd quicklook;
7. ant -Dglassfish.home=$

{GF_HOME} add-quicklook-policy-grants enable-security-manager
8. ant -Dglassfish.home=${GF_HOME}

stop-server start-server-felix

So here server is starting without any exception. It shows log like

[#|2011-01-17T15:13:56.615+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=75;_ThreadName=Thread-1;|SEC1001: Security Manager is ON.|#]

[#|2011-01-17T15:13:58.048+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=75;_ThreadName=Thread-1;|SEC1010: Entering Security Startup Service|#]

[#|2011-01-17T15:13:58.061+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=75;_ThreadName=Thread-1;|SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.|#]

[#|2011-01-17T15:13:58.114+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=75;_ThreadName=Thread-1;|SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

[#|2011-01-17T15:13:58.115+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=75;_ThreadName=Thread-1;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

[#|2011-01-17T15:13:58.121+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=75;_ThreadName=Thread-1;|SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.|#]

[#|2011-01-17T15:13:58.132+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security|_ThreadID=75;_ThreadName=Thread-1;|SEC1011: Security Service(s) Started Successfully|#]

After starting server I tried following QL as mention in bug 15536 but it's failing. And looks like it's not due to logging.
9. cd wsit/JaxwsFromWsdl; ant -Dglassfish.home=$

{GF_HOME}

all

Please confirm me on the same so I can close this issue.

Comment by Martin Grebac [ 17/Jan/11 ]

Hmm, one difference in the steps I see is that I do set the property in domain.xml by adding:
<jvm-options>-Djava.security.debug=all</jvm-options> or <jvm-options>-Djava.security.debug=access:stack</jvm-options>
Would you please try this and attach the full server log after GF start so that I can confirm it's properly set? Thanks for looking at this.

Comment by naman_mehta [ 17/Jan/11 ]

After adding JVM options as you suggested, server is failing to start. Please check attached error.log file. How can I avoid that error.

Comment by Martin Grebac [ 17/Jan/11 ]

I think you might have already reproduced the issue ;O).

Comment by naman_mehta [ 17/Jan/11 ]

I debug the code and found that exception is coming before the log manager service starts so all the logging/exception output goes to console handler. Still the file handler for logging is not initialized. So you can get all logging/exception data on the console only. So best way to debug this is to use --verbose option on starting of server.

Comment by naman_mehta [ 18/Jan/11 ]

Martin, this one is not a logging issue so I am assigning same to you. Please assign same to appropriate module owner.

Comment by Nazrul [ 18/Jan/11 ]

Requesting Nithya to take a look

Comment by kumarjayanti [ 19/Jan/11 ]

Nithya was experimenting this today. When we set java.security.debug=all or access:stack and the security-manager is ON, then it is not as-if glassfish does not start, but it seems to take a long long time since it is dumping the stack for every permission evaluation.

Nithya has run it for 15-20 mins and still seems to have not completed. The main reason is that when felix is trying to load classes, the getClassLoader() call will result in a RuntimePermission check ("getClassLoader"). And since the Active CodeSource for the PolicyDomain is felix.jar, it tries to evaluate the set of Permissions for the PD by matching the codesource against the codesources in all the grant statements in server.policy, java.policy, .java.policy. As part of that we will see stack dumps of the following form :

--------
policy: evaluation (codesource) failed
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1223)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:291)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.Class.getClassLoader(Class.java:611)
at org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:605)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:572)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:472)
at java.net.URL.toExternalForm(URL.java:919)
at java.net.URL.toString(URL.java:905)
at java.lang.String.valueOf(String.java:2838)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at java.security.CodeSource.toString(CodeSource.java:461)
at java.lang.String.valueOf(String.java:2838)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at sun.security.provider.PolicyFile.addPermissions(PolicyFile.java:1318)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1281)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1247)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1188)
at java.security.ProtectionDomain$1.run(ProtectionDomain.java:331)
at java.security.ProtectionDomain$1.run(ProtectionDomain.java:328)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain.mergePermissions(ProtectionDomain.java:326)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:271)
at java.lang.String.valueOf(String.java:2838)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:299)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.Class.getClassLoader(Class.java:611)
at org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:607)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:572)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:472)
at java.net.URL.toExternalForm(URL.java:919)
at java.net.URL.toString(URL.java:905)
at java.lang.String.valueOf(String.java:2838)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at java.security.CodeSource.toString(CodeSource.java:461)
at java.lang.String.valueOf(String.java:2838)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at sun.security.provider.PolicyFile.addPermissions(PolicyFile.java:1318)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1281)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1247)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1188)
at java.security.ProtectionDomain$1.run(ProtectionDomain.java:331)
at java.security.ProtectionDomain$1.run(ProtectionDomain.java:328)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain.mergePermissions(ProtectionDomain.java:326)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:271)
at java.lang.String.valueOf(String.java:2838)
at java.lang.StringBuilder.append(StringBuilder.java:132)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:299)
at java.security.AccessController.checkPermission(AccessController.java:553)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.Class.getClassLoader(Class.java:611)
at org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:607)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:572)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:472)
at java.net.URL.toExternalForm(URL.java:919)
at java.net.URL.toString(URL.java:905)
-----------------------
Wherein the stacktrace is very-very long due to mutual recursion between Felix and
java.lang.Class.getClassLoader(Class.java:611) . The debug mechanism seems to truncate the stack after some number of iterations and print it. This particular thing needs to be looked into by Felix Dev Team. However the policy evaluation failure for this case is not a problem as such and is not stalling the starting of glassfish.

I would suggest that someone try this scenario and keep it running for a long time to see if it finally starts or not.

Comment by kumarjayanti [ 19/Jan/11 ]

attaching the mutual-recursion stack dump between java.lang.Class.getClassLoader(Class.java:611) and org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:605)

And you can see that the stacktrace is really long. It appears the JDK truncates the recursion after some 30-40 recursive calls (atleast in the dump that we see).

Comment by Nithya Ramakrishnan [ 19/Jan/11 ]

One way to workaround this issue is to set java.security.debug=access:failure to check the cases of permission failures alone. That way, the stack dumps get reduced and GlassFish starts with SM on.

Also, in case java.security.debug is set to all, to make sure that these repeated permission checks and stack dumps are harmless, one could correlate it with a felix shell by checking the classes that felix.jar tries to load and make sure there is no infinite loop.

Comment by Nithya Ramakrishnan [ 19/Jan/11 ]

We believe that if the mutual recursive call problem in Felix (that appears repeatedly in the stack trace (mentioned by Kumar)) is fixed, it could improve the Glassfish startup performance with Security Manager on. Since it appears that these calls are made even when java.security.debug is not set, but are not dumped in the console.

Comment by Nazrul [ 19/Jan/11 ]

Not a show stopper. We have a work around for this. Excluding from 3.1 count.

Comment by Nithya Ramakrishnan [ 07/May/14 ]

In the latest built GF (v4) tried adding the jvm-option -Djava.security.debug=policy,access:domain to the server config to retry the test case .
It seems like the server does not start with the access:domain option . It looks like there is an issue in the OSGi libraries when the codesource is being printed ?

With access:failure Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.apache.felix.framework.URLHandlersStreamHandlerProxy
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:492)
at org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
at java.net.URL.toExternalForm(URL.java:922)
at java.net.URL.toString(URL.java:908)
at java.lang.String.valueOf(String.java:2979)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at java.security.CodeSource.toString(CodeSource.java:467)
at java.lang.String.valueOf(String.java:2979)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at sun.security.provider.PolicyFile.addPermissions(PolicyFile.java:1266)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1228)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1191)
at sun.security.provider.PolicyFile.getPermissions(PolicyFile.java:1132)
at java.security.ProtectionDomain$2.run(ProtectionDomain.java:367)
at java.security.ProtectionDomain$2.run(ProtectionDomain.java:364)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain.mergePermissions(ProtectionDomain.java:364)
at java.security.ProtectionDomain.toString(ProtectionDomain.java:308)
at java.lang.String.valueOf(String.java:2979)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:412)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at org.apache.felix.framework.BundleImpl.getBundleContext(BundleImpl.java:225)
at org.apache.felix.framework.Felix.getBundleContext(Felix.java:74)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.newFramework(OSGiGlassFishRuntimeBuilder.java:241)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:135)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)which seemed to work.

Comment by Nithya Ramakrishnan [ 07/May/14 ]

Changing the priority since this is blocking the debugging of https://java.net/jira/browse/GLASSFISH-21012.
Assigning to OSGi, since it appears to be an issue in the OSGi libraries





[GLASSFISH-4147] Request prioritization in application server Created: 10/Feb/08  Updated: 06/Mar/12

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

Type: New Feature Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-4128 ability to plugin custom implementati... Open
depends on GLASSFISH-4320 [v3] Expose Grizzly's Resource Consom... Open
depends on GLASSFISH-4386 Request prioritization in application... Open
depends on GLASSFISH-4160 Support request prioritization in ORB Open
depends on GLASSFISH-4385 Support request prioritization in app... Open
depends on GLASSFISH-4384 Support request prioritization in web... Resolved
depends on GLASSFISH-3205 Need "application aware" pools Open
Issuezilla Id: 4,147
Status Whiteboard:

v3-prd-item

Tags: 3_1_x-exclude

 Description   

In a typical application server deployment, there is a need to discriminate
user requests to an application in order to provide differentiated quality
of service.

However, our current application server implementation does not provide
sufficient resource consumption management policies/aids to enable
such a service.



 Comments   
Comment by Sanjeeb Sahoo [ 10/Feb/08 ]

This RFE will be used to provide infrastructure for the following conection pool
RFEs as well:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3205
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4128

Comment by Sanjeeb Sahoo [ 10/Feb/08 ]

Changed target milestone and prority

Comment by jfarcand [ 11/Feb/08 ]

Adding the link that explain how Grizzly implements it in GlassFish v2/v3

http://weblogs.java.net/blog/jfarcand/archive/2007/06/improving_ajax_1.html

Comment by Sanjeeb Sahoo [ 05/Mar/08 ]

adding dependency on 4160, which is the ORB part of this feature.

Comment by Sanjeeb Sahoo [ 05/Mar/08 ]

Set dependency on 4384

Comment by Jagadish [ 05/Mar/08 ]

adding dependencies

Comment by jfarcand [ 05/Mar/08 ]

Adding myself to the cc-list as we need to synchronize the work, because the
WebTier also have a similar task already in progress.

Comment by jfarcand [ 05/Mar/08 ]

Add dependencies....

Comment by seanespn [ 28/Oct/11 ]

ESPN.com would love to see this feature.

One thing we did lose by moving off our home grown servlet container was the concept of "swim lanes".

Basically we could tell our previous container to ONLY use a max of X threads to handle requests for a certain URI or set of URIs. This prevented one page that is for some reason running very slowly from exhausting the HTTP thread pool and starving other pages that are working fine.

Comment by scatari [ 28/Oct/11 ]

Marking appropriately to be considered for 3.1.2. We will re-evaluate this request.

Comment by Sanjeeb Sahoo [ 22/Dec/11 ]

Sorry, I don't see getting addressed anytime soon.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-20937] loadClass from org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor needs to be improved Created: 19/Dec/13  Updated: 19/Dec/13

Status: Open
Project: glassfish
Component/s: hk2, OSGi
Affects Version/s: 3.1.2, 3.1.2.2, 4.0
Fix Version/s: None

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


 Description   

Currently, loading class way from org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor is directly starting OSGi bundle, then loading class.

OsgiPopulatorPostProcessor(OSGiModuleImpl paramOsgiModule) {
this.osgiModule = paramOsgiModule;

loader = new HK2Loader() {

@SuppressWarnings(

{ "unchecked", "rawtypes" }

)
@Override
public Class<?> loadClass(final String className)
throws MultiException {
osgiModule.start();
return (Class<?>) AccessController.doPrivileged(new PrivilegedAction() {
public java.lang.Object run() {
try

{ return osgiModule.getBundle().loadClass(className); }

catch (Throwable e) {
...

A question is as following,

Why not directly calling Bundle.loadClass?

According to API Doc,

If this bundle's state is INSTALLED, this method must attempt to resolve this bundle before attempting to load the class.

So, we only wish the bundle state is changed into Resolved rather than Active, right?



 Comments   
Comment by TangYong [ 19/Dec/13 ]

The same improvement also happened in the following method,

[Class] org.jvnet.hk2.osgiadapter.OSGiModuleImpl

public synchronized void resolve() throws ResolveError

{ // Since OSGi bundle does not have a separate resolve method, // we use the same implementation as start(); start(); }
Comment by TangYong [ 19/Dec/13 ]

I am sorry that things is not really simple,

I have known why you firstly start the bundle. For some cases, eg. While kernel is starting, it will proceed to some higher hk2 start level, and attempt to start these bundles, if removing osgiModule.start(), these bundles will stay in Resolved state rather than active state.

However, for general case(using @Service or getService), this will be Brute Force because we only want to load classes rather than starting the bundle.

Right?





[GLASSFISH-20782] [Fighterfish Test]test_GLASSFISH_12975() has some regression Created: 27/Aug/13  Updated: 19/Sep/14

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

Type: Bug Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows
4.0.1/nightly/ 26-Aug-2013 07:25



 Description   

test_GLASSFISH_12975() causes Fighterfish Test failed as following,

[#|2013-08-27T15:16:29.922+0900|SEVERE|glassfish 4.0|org.ops4j.pax.exam.junit.JUnit4TestRunner|_ThreadID=1;_ThreadName=main;_TimeMillis=1377584189922;_LevelValue=1000;ClassName=org.ops4j.pax.exam.junit.JUnit4TestRunner$3;MethodName=evaluate;|
Exception
org.ops4j.pax.exam.TestContainerException: [test_GLASSFISH_12975(org.glassfish.fighterfish.test.it.T2_Test): Aether Error.]
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:112)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:89)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
at org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:86)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:85)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$3.evaluate(JUnit4TestRunner.java:289)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:87)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.io.IOException: Aether Error.
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:234)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:221)
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:120)
at java.net.URL.openStream(URL.java:1037)
at org.glassfish.fighterfish.test.it.T2_Test.test_GLASSFISH_12975(T2_Test.java:742)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108)
... 26 more
Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-SNAPSHOT from/to maven-central (http://repo1.maven.org/maven2/): Error transferring file: repo1.maven.org
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:323)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:232)
... 51 more
Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could not transfer artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-SNAPSHOT from/to maven-central (http://repo1.maven.org/maven2/): Error transferring file: repo1.maven.org
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:949)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:940)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:695)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:689)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.get(WagonRepositoryConnector.java:445)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:460)
... 55 more
Caused by: org.apache.maven.wagon.TransferFailedException: Error transferring file: repo1.maven.org
at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:143)
at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.run(WagonRepositoryConnector.java:608)
at org.sonatype.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:64)
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)
Caused by: java.net.UnknownHostException: repo1.maven.org
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:178)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:157)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:378)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:473)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:203)
at sun.net.www.http.HttpClient.New(HttpClient.java:290)
at sun.net.www.http.HttpClient.New(HttpClient.java:306)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:995)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:931)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:849)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1299)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:115)
... 8 more

#]


 Comments   
Comment by TangYong [ 27/Aug/13 ]

Noting that in test_GLASSFISH_12975() , the following,

String location2 = "mvn:org.glassfish.main.osgi-platforms/felix-webconsole-extension/4.0.1-SNAPSHOT/jar";

I used 4.0.1/nightly/ 26-Aug-2013 07:25 rather than SNAPSHOT from trunk, and, my local maven repo can not have such bundle, and repo1 or other maven repos have not such bundle too. So, pl. Sahoo explains the reason using 4.0.1-SNAPSHOT here. I think that the test failure is caused by the issue.

Thanks
Tang

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

We should change the URL in test to use 4.0.1-b01 which is available in maven central.

Comment by TangYong [ 27/Aug/13 ]

Will change it and also noticing that 4.0.1-b01 is in https://maven.java.net/content/groups/promoted rather than other repos including repo1, so, whether glassfish osgi fighterfish wiki will be updated to add a description?

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

See if we can use 4.0 instead of 4.0.1?

Comment by TangYong [ 27/Aug/13 ]

Let us to see the result of using 4.0.1-b01,

[#|2013-08-27T15:55:13.871+0900|SEVERE|glassfish 4.0|org.ops4j.pax.exam.junit.JUnit4TestRunner|_ThreadID=1;_ThreadName=main;_TimeMillis=1377586513871;_LevelValue=1000;ClassName=org.ops4j.pax.exam.junit.JUnit4TestRunner$3;MethodName=evaluate;|
Exception
org.ops4j.pax.exam.TestContainerException: [test_GLASSFISH_12975(org.glassfish.fighterfish.test.it.T2_Test): Admin Console Not Available expected:<200> but was:<401>]
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:112)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:89)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
at org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:86)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:85)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$3.evaluate(JUnit4TestRunner.java:289)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:87)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.lang.AssertionError: Admin Console Not Available expected:<200> but was:<401>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.glassfish.fighterfish.test.it.T2_Test.test_GLASSFISH_12975(T2_Test.java:780)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108)
... 26 more

#]

The above means that accessing "http://localhost:8080/osgi/system/console/bundles" failed.

Comment by TangYong [ 27/Aug/13 ]

4.0 is the same as 4.0.1, and noticing that in console, the following,

[#|2013-08-27T16:06:31.647+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=301;_ThreadName=http-listener-1(2);_TimeMillis=1377587191647;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=300;_ThreadName=http-listener-1(1);_TimeMillis=1377587191662;_LevelValue=800;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper$2;MethodName=run;|
JACC Policy Provider: Failed Permission Check, context(null)- permission(("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication"))|#]

[#|2013-08-27T16:06:31.662+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=300;_ThreadName=http-listener-1(1);_TimeMillis=1377587191662;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=302;_ThreadName=http-listener-1(3);_TimeMillis=1377587191662;_LevelValue=800;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper$2;MethodName=run;|
JACC Policy Provider: Failed Permission Check, context(null)- permission(("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication"))|#]

[#|2013-08-27T16:06:31.662+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=302;_ThreadName=http-listener-1(3);_TimeMillis=1377587191662;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=304;_ThreadName=http-listener-1(5);_TimeMillis=1377587191662;_LevelValue=800;ClassName=com.sun.enterprise.security.provider.BasePolicyWrapper$2;MethodName=run;|
JACC Policy Provider: Failed Permission Check, context(null)- permission(("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication"))|#]

[#|2013-08-27T16:06:31.662+0900|WARNING|glassfish 4.0|org.glassfish.security.services|_ThreadID=304;_ThreadName=http-listener-1(5);_TimeMillis=1377587191662;_LevelValue=900;ClassName=org.glassfish.security.services.common.SecurityAccessValidator;MethodName=checkPerm;|
Check Permission failed in lookup for permission = ("org.glassfish.security.services.common.SecureServiceAccessPermission" "security/service/authentication")|#]

[#|2013-08-27T16:06:31.662+0900|INFO|glassfish 4.0|org.glassfish.fighterfish.test.it|_ThreadID=1;_ThreadName=main;_TimeMillis=1377587191662;_LevelValue=800;ClassName=T2_Test;MethodName=test_GLASSFISH_12975;|
Sleeping for 5 Seconds on testurl = http://localhost:8080/osgi/system/console/bundles|#]

...

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

I know why you see that error. It's explained in GLASSFISH-20646. So, we can't use version 4.0. We need a build of webconsole which is later than svn #svn #62246. 4.0.1-b01 won't help as far as I see.

Comment by Sanjeeb Sahoo [ 27/Aug/13 ]

The problem is like this:

FighterFish test suite includes a test for felix-webconsole-extension which is built as part of glassfish, but not installed by default. So, the test is relying on 4.0.1-SNAPSHOT. If we move all our OSGi modules to fighterfish project, we can easily solve this issue via binary integration. Could you own the migration of such modules from glassfish to fighterfish?

Thanks,
Sahoo

Comment by TangYong [ 27/Aug/13 ]

>Could you own the migration of such modules from glassfish to fighterfish?

Apart from felix-webconsole-extension, pl. exactly telling me other modules belonging to us.

About here's "migration", could you please tell me how do you operate, then, I will confirm whether I have the same operation permission。

Thanks
Tang

Comment by TangYong [ 27/Aug/13 ]

Having another temp way:

Making the test case is @Ignore, and letting the jira open, then, once releasing a version later than #svn #62246, I will re-confirm the jira and remove @Ignore.

Agree with me?

Comment by TangYong [ 28/Aug/13 ]

fixing has been checked in.

Revisions:
----------
62668

Comment by Sanjeeb Sahoo [ 29/Aug/13 ]

After this checkin, I noticed a failure while running tests in an environment with clean local maven repository:

[#|2013-08-28T12:44:21.385-0700|SEVERE|glassfish 4.0|org.ops4j.pax.exam.junit.JUnit4TestRunner|_ThreadID=1;_ThreadName=main;_TimeMillis=1377719061385;_LevelValue=1000;ClassName=org.ops4j.pax.exam.junit.JUnit4TestRunner$3;MethodName=evaluate;|
Exception
org.ops4j.pax.exam.TestContainerException: [test_GLASSFISH_12975(org.glassfish.fighterfish.test.it.T2_Test): Aether Error.]
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:112)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:89)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
at org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:86)
at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:85)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$3.evaluate(JUnit4TestRunner.java:289)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.ops4j.pax.exam.junit.JUnit4TestRunner.run(JUnit4TestRunner.java:87)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.io.IOException: Aether Error.
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:234)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:221)
at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:120)
at java.net.URL.openStream(URL.java:1037)
at org.glassfish.fighterfish.test.it.T2_Test.test_GLASSFISH_12975(T2_Test.java:742)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:58)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:32)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:108)
... 26 more
Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-b02 in local (file:/scratch/java_re/BUILD_AREA/workspace/gf-trunk-fighterfish-it/.m2/repository/)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:323)
at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:232)
... 51 more
Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact org.glassfish.main.osgi-platforms:felix-webconsole-extension:jar:4.0.1-b02 in local (file:/scratch/java_re/BUILD_AREA/workspace/gf-trunk-fighterfish-it/.m2/repository/)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:945)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:940)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:695)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:689)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.get(WagonRepositoryConnector.java:445)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:460)
... 55 more

This is a known issue in the version of pax-url used by our tests. pax-url only searches in default maven repository (ie central repo), but this artifact is available in promoted jvnet repo, hence it is unable to find.

I made the following checkin to fix the issue:

Log Message:
------------
Clean up test classpath. Add felix-webconsole-extension
as a dependency so that test can provision it. Currently test is not able to download it from
remote repo because pax-url only searches in central repo and it's not available there.

Revisions:
----------
62676

After this checkin, our hudson job has run fine.

Comment by TangYong [ 30/Aug/13 ]

I think that while I was checking in previous patch, I made a mistake that I have not cleaned my local repo which still contained 4.0.1-b02 ever being downloaded in some way, after I looked at the new checking in, I see.

Thanks Sahoo's deep confirmation!





[GLASSFISH-21050] Problem with classloader and casting using osgi gf-client-module to access remote EJB (RMI) from GF4. Created: 23/Apr/14  Updated: 23/Apr/14

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: PashaTurok Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server:centos 6.4, 64, openjdk 7
Client:centos 6.4, 64, openjdk 7


Tags: ejb31, glassfish4, javaee, osgi, osgi-javaee

 Description   

I have server-client architecture. Server and client different machines in one local network. Both server and client are on osgi framework. For server it's hybrid EJB. There are three osgi bundles:for server,for client and shared. The copy of shared is both on server and on clients and contains LanguageDirBeanRemote and LanguageDirEntity. To get my bean I use the following code on osgi-client:

ClassLoader thatLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
try {
Properties jndiProps = new Properties();
jndiProps.put("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
jndiProps.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
jndiProps.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
jndiProps.setProperty("org.omg.CORBA.ORBInitialHost", "x.x.x.x");
jndiProps.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
InitialContext ctx = new InitialContext(jndiProps);
LanguageDirBeanRemote bean=(LanguageDirBeanRemote)ctx.lookup("java:global/...");
ArrayList<LanguageDirEntity> elements=bean.readDirectory();
System.out.println("HERE I GET THE ERROR:"+elements.get(0).getContent());
} finally {
Thread.currentThread().setContextClassLoader(thatLoader);
}

Here is the log:
java.lang.ClassCastException: com.test.cmn.shd.base.dir.language.LanguageDirEntity cannot be cast to com.test.cmn.shd.base.dir.language.LanguageDirEntity at com.test.cmn.dt.base.Activator.start(Activator.java:83) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977) at org.apache.felix.framework.Felix.startBundle(Felix.java:1895) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931) at com.test.cmn.dt.loader.LoaderModel.startCoreModule(LoaderModel.java:149) at com.test.cmn.dt.loader.LoaderModel.access$100(LoaderModel.java:39) at com.test.cmn.dt.loader.LoaderModel$InstallAndStartModuleWorker.doInBackground(LoaderModel.java:79) at com.test.cmn.dt.loader.LoaderModel$InstallAndStartModuleWorker.doInBackground(LoaderModel.java:73) at javax.swing.SwingWorker$1.call(SwingWorker.java:296) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at javax.swing.SwingWorker.run(SwingWorker.java:335) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744)

The reason that I think it's the bug is that the following code works without any problems:
LanguageDirEntity[] elements=bean.readDirectoryAsArray();
We see, that using simple array, without ArrayList we get no errors. But when I try to use ArrayList or ArrayList<LanguageDirEntity> I get ClassCastException. I think the problem is somewhere in RMI when it loads classes.
This prblem I also described on stackoverflow. http://stackoverflow.com/questions/23174582/arraylist-classloader-issue-in-osgi-client-javaeeejb-server






[GLASSFISH-20382] Needing to update Felix.system.packages in osgi.properties while integrating aries subsystem which importing org.osgi.framework;version="1.7" Created: 23/Apr/13  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b85
Fix Version/s: 4.1

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


 Description   

While integrating aries subsystem 1.0.0 which importing org.osgi.framework;version="1.7", once starting glassfish domain,
the following exception will happen in the server.log

...
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.apache.felix.resolver [296]: Unable to resolve 296.0: missing
requirement [296.0] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.framework)(version>=1.7.0)(!(version>=2.0.0)))
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:722)]]
...



 Comments   
Comment by TangYong [ 23/Apr/13 ]

[Analyze]

Glassfish v4 uses felix 4.2.1 which has exporting Core R5 API in its default.properties,

org.osgi.framework.system.packages=org.osgi.framework; version=1.7.0, \
org.osgi.framework.hooks.bundle; version=1.1.0, \
org.osgi.framework.hooks.resolver; version=1.0.0, \
org.osgi.framework.hooks.service; version=1.1.0, \
org.osgi.framework.hooks.weaving; version=1.0.0, \
org.osgi.framework.launch; version=1.1.0, \
org.osgi.framework.namespace; version=1.0.0, \
org.osgi.framework.startlevel; version=1.0.0, \
org.osgi.framework.wiring; version=1.1.0, \
org.osgi.resource; version=1.0.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.5.1 \
${jre-${java.specification.version}}

However, in osgi.properties, we have a Felix.system.packages definition,

Felix.system.packages=\
org.osgi.framework; version=1.6.0, \
org.osgi.framework.launch; version=1.0.0, \
org.osgi.framework.wiring; version=1.0.0, \
org.osgi.framework.startlevel; version=1.0.0, \
org.osgi.framework.hooks.bundle; version=1.0.0, \
org.osgi.framework.hooks.resolver; version=1.0.0, \
org.osgi.framework.hooks.service; version=1.1.0, \
org.osgi.framework.hooks.weaving; version=1.0.0, \
org.osgi.service.packageadmin; version=1.2.0, \
org.osgi.service.startlevel; version=1.1.0, \
org.osgi.service.url; version=1.0.0, \
org.osgi.util.tracker; version=1.5.0, \
$

{extra-system-packages}

Compared with felix 4.2.1 default.properties, we can find that our Felix.system.packages has been outdated, maybe you can ask whether glassfish needs to maintain system packages from felix?

Not simply saying "no", because we have some additional packages which are not defined in felix default.properties.

Please Sahoo comments the issue. My suggestion is to update our Felix.system.packages and keep it here.

Thanks
--Tang

Comment by TangYong [ 23/Apr/13 ]

This issue can be reproduced by deploying org.apache.felix.resolver_1.0.0.

Comment by Sanjeeb Sahoo [ 26/Apr/13 ]

Current Felix version does not provide 1.7 APIs, so we don't export them.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19346] Adding fighterfish test cases Created: 14/Nov/12  Updated: 10/Dec/12

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

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Zip Archive GLASSFISH-19215_fighterfishtestcase_20121114.zip     Zip Archive GLASSFISH-19215_fighterfishtestcase_final.zip     Zip Archive GLASSFISH-19215_fighterfishtestcase_multi-interfaces.zip    

 Description   

According to sahoo's test requirements , adding fighterfish test cases. In addition,

1) also needing to add negative test like failing to inject myservice as a regular cdi bean.
2) test cases must separate from stock quote sample, using common test cases liking foo/bar...



 Comments   
Comment by TangYong [ 14/Nov/12 ]

Hi sahoo, siva,

I have created a fighterfish test case for GLASSFISH-19215 and passed on my env successfully.
Please use my 20121114's patch and run the attachment(GLASSFISH-19215_fighterfishtestcase_20121114.zip).

Thanks.
--Tang

Comment by TangYong [ 15/Nov/12 ]

The attachment(GLASSFISH-19215_fighterfishtestcase_final.zip) is the final fighterfish test cases(Totoally two test cases) , and I have added a negative test case for GLASSFISH-19215.

Please try the attachment.

Thanks
--Tang

Comment by Sivakumar Thyagarajan [ 23/Nov/12 ]

The test cases looks good. I will try it out once I have your patch integrated locally into my workspace. The only enhancement I would like to see is that both the tests uses the "contracts" annotations attribute in @OSGiService, but do not use to add any new meaning, and just set the only interface that the Bean is implementing as the "contracts" value. It would be nice if we have another test or just reuse the 2 new test you have added, where the test tries to choose from one interface from a set of interfaces a Bean implements, and then testing to make sure that BarBean is available as an OSGiService only through Bar.class and not through Baz.class

@Publish(contracts =

{Bar.class}

)
public class BarBean implements Bar, Baz{}

In the test Servlet:
@Inject @OSGiService Bar bar; //must succeed
and
@Inject @OSGiService Baz baz; //must fail

Comment by TangYong [ 24/Nov/12 ]

Hi siva,

Thanks your suggestion very much. I have understood your means and I will add test for multi-interface scene.

Tang

Comment by TangYong [ 27/Nov/12 ]

Hi siva,

I have attached a new test case(GLASSFISH-19215_fighterfishtestcase_multi-interfaces.zip) for testing multi interfaces, and please seeing it.

Thanks.
--Tang

Comment by TangYong [ 10/Dec/12 ]

Because osgi-cdi-api will have some changes which are from Siva's suggestions, fighterfish tests will also make some changes. Waiting for final API Release.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19325] moving the logics of publishing beans into OSGiServiceExtension class Created: 13/Nov/12  Updated: 14/Nov/12

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

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Needing to move the logics of publishing beans into OSGiServiceExtension class in order to make @Publish to work in hybrid javaee bundle.



 Comments   
Comment by TangYong [ 14/Nov/12 ]

Currently, this moving has been finished, and triggering publish services has been put into AfterDeploymentValidation Observer method as following:

void afterDeploymentValidation(@Observes AfterDeploymentValidation adv)

{ //Publish @Publish Classes into OSGi Registry Instance<Object> instance = this.manager.instance(); publishOSGiService(instance); }

And, beforeBeanDiscovery method adds the second parameter as 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; }

}

In the future, once CDI Specification adds a portable method called "Instance<Object> instance()", the strong type cast(WeldManager) will be deleted and make a improvement. Now, the above is enough.





Add support CDI in plain OSGi bundles (GLASSFISH-19215)

[GLASSFISH-19326] invocating Weld-Integration bundle to use ACLSingletonProvider Created: 13/Nov/12  Updated: 14/Nov/12

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

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Needing to invocating Weld-Integration bundle in OSGiCDIExtender class to use ACLSingletonProvider



 Comments   
Comment by TangYong [ 13/Nov/12 ]

Adding the following logic into OSGiCDIExtender class,

if ( isPlainOSGiBundle(bundle) ){
if ( isGlassfishCDIEnabled(bundle) && isCDIBundle(bundle) ){
final int state = bundle.getState();
if ( isReady(event, state) ) {
startWeldIntegration();
currentBootstrap = new WeldBootstrap();
...

startWeldIntegration()'s definition is as following,

private void startWeldIntegration(){
Bundle[] installedBundles = context.getBundles();

for(Bundle bundle : installedBundles){
if (Constants.WEDINTEGRATION_SYMNAME.equals(bundle.getSymbolicName())){
if (bundle.getState() != Bundle.ACTIVE){
try

{ bundle.start(Bundle.START_TRANSIENT); }

catch (BundleException e)

{ throw new RuntimeException(e); }

However, sometimes, the following exception happened and weld-integration bundle was not started,

[#|2012-11-13T21:26:31.890+0900|SEVERE|44.0|javax.enterprise.logging.stderr|_ThreadID=14;_ThreadName=Thread-13;_TimeMillis=1352809591890;_LevelValue=1000;|com.sun.enterprise.module.ResolveError:
Failed to start OSGiModuleImpl:: Bundle =
[org.glassfish.main.web.weld-integration [260]], State = [RESOLVED]
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:227)
at
org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:78)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1355)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:346)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.narrow(ServiceLocatorImpl.java:1382)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetDescriptor(ServiceLocatorImpl.java:709)
at
org.jvnet.hk2.internal.ServiceLocatorImpl.getInjecteeDescriptor(ServiceLocatorImpl.java:397)
at
org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:148)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:153)
at
org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:176)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:280)
at
org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:420)
at
org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:87)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:1894)
at
org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:90)
at org.glassfish.internal.data.EngineInfo.getContainer(EngineInfo.java:86)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.startContainers(ApplicationLifecycle.java:1018)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:724)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:384)
at
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
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.OSGiContainer.redeploy(OSGiContainer.java:113)
at
org.glassfish.osgijavaeebase.OSGiContainer.access$500(OSGiContainer.java:61)
at
org.glassfish.osgijavaeebase.OSGiContainer$DeployerAddedThread.run(OSGiContainer.java:305)
Caused by: org.osgi.framework.BundleException: Activator start error in
bundle org.glassfish.main.web.weld-integration [260].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2027)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:219)
... 26 more
Caused by: java.lang.RuntimeException: SingletonProvider is already
initialized with
org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider@dd4f00
at
org.jboss.weld.bootstrap.api.SingletonProvider.initialize(SingletonProvider.java:113)
at org.glassfish.weld.WeldActivator.start(WeldActivator.java:79)
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:641)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
... 29 more

#]
Comment by TangYong [ 14/Nov/12 ]

The steps will trigger the above problem,

1) deploy a plain cdi bundle
2) asadmin stop-domain
3) asadmin start-domain

On 3) step, the problem will be triggered. After debugging, I can confirm that the problem is related to https://issues.apache.org/jira/browse/FELIX-3713 again.

That is to say, while trying to execute bundle.start(Bundle.START_TRANSIENT), because at the time point, there is a StartLevel thread in gf starting, so bundle.start returned immediately rather than executing Activate.start method.

Comment by TangYong [ 14/Nov/12 ]

I have a temp fixing way, and used bundle.start() rather than bundle.start(Bundle.START_TRANSIENT). After several tests, the problem did not happen. However, the fixing way has a shortcoming as following,

because not using Bundle.START_TRANSIENT, if I uninstall deployed plain cdi bundles, after I restarted domain, Weld-Integration Bundle's state will be active rather than installed, so Weld-Integration Bundle will be not ondemand starting any more.





[GLASSFISH-18975] Regression: GlassFish broken on Equinox, CNF occurs for javax.transaction classes Created: 05/Aug/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b45
Fix Version/s: 4.1

Type: Bug Priority: Critical
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File cnf.txt    

 Description   

QuickLook tests have started to fail on Equinox platform starting with svn rev # 55306 where Jersey 2.0-m05-2 was integrated. See the following job for details:
http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-continuous-ql-equinox/4449/
This job was triggered by http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/11710/ and as per this triggering job, only jersey component was upgraded.

To run QuickLook on Equinox, the steps are:
mkdir glassfish3/glassfish/osgi/equinox/
download equinox jar,
copy the downloaded jar to above equinox dir.
Set an environment variable GlassFish_Platform=Equinox
Run QuickLook.



 Comments   
Comment by Pavel Bucek [ 07/Aug/12 ]

mentioned job is not failing.

I've tried to run quicklook tests on my machine, but glassfish (trunk) did not even start.

My steps:

  • checkout fresh GF sources
  • build
  • unzip appserver/distributions/glassfish/glassfish.jar
  • mkdir -p glassfish3/glassfish/osgi/equinox/
  • cp org.eclipse.osgi_3.8.0.v20120529-1548.jar glassfish3/glassfish/osgi/equinox/
  • export GlassFish_Platform=Equinox
  • cd tests/quicklook; mvn -Dglassfish.home=/.../target/glassfish3/glassfish/ test | tee run.log

console output:

...
start-derby-unix:

start-derby-windows:

setOSConditions:

start-server-felix:
     [echo] +-----------------------------+
     [echo] |                             |
     [echo] | S T A R T I N G   GLASSFISH |
     [echo] |       in Felix mode         |
     [echo] |                             |
     [echo] +-----------------------------+

start-server-felix-unix:

execution get stuck after last line. And it still says that I'm using felix, not equinox.

Can you please provide more details about how to reproduce reported issue?

thanks,
Pavel

(I'm running Mac OS X - 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 and Java "1.6.0_33")

Comment by Lukas Jungmann [ 07/Aug/12 ]

Pavle, try to update, the failure you're seeing could be related to GLASSFISH-18976 which I fixed yesterday. Thanks.

Comment by Sanjeeb Sahoo [ 07/Aug/12 ]

Pavel,

I now see why you say that job is not failing. I had mentioned the continuous build job URL that triggered the failing job. Now I have updated the description with correct job URL. Sorry for the confusion. The job has been UNSTABLE since last jersey integration. See it's status is yellow and the last line in console output is UNSTABLE. The job runs QL against full and web profile. If you see the entire log, you shall see full profile QL failing the same way it failed for you. Basically, server does not start on Equinox and our pathetic QuickLook test framework continues to run tests instead of aborting early.

That report saying "starting Felix mode" should be changed to "OSGi mode."

You have already reproduced the issue. You don't have to run QL. Just start server and you shall see it failing to start. The behavior has not changed even after Lukas fixed the JAXB issue as part of his bug fix.

Thanks,
Sahoo

Comment by Pavel Bucek [ 14/Aug/12 ]

Sahoo,

thanks for input and direction (you've mentioned that problem might be in jersey-media-json-jettison module. Unfortunately I wasn't able to figure out the cause of this :/ Jakub is on vacation and he should be back next week and he should be able to handle this.

Or if you have some spare cycles and want to investigate further.. I should be able at least test proposed solution (I have my workspace ready for that, I've tested lots of Import/Export manifest headers combinations lately). Sorry for inconvenience :-/

Pavel

Comment by Sanjeeb Sahoo [ 14/Aug/12 ]

Thanks Pavel for the update. I don't have any cycles to work on this. I have already spent much time debugging this. Can we revert the integration until we have fixed it?

Comment by Pavel Bucek [ 15/Aug/12 ]

well, that is not for me to decide :-/ that commit fixes several other issues; mainly introduces Jersey EJB integration, which is required by other teams.

Personally - I would wait till start of next week (when Martin and Jakub will be back from vacation) with final decision.

Comment by Sanjeeb Sahoo [ 15/Aug/12 ]

Since we have waited so long, I think it makes sense to wait for them to come back and have a look.

Comment by Jakub Podlesak [ 23/Aug/12 ]

To me, this seems to remind an issue discussed some time ago here: http://www.eclipse.org/forums/index.php/m/901649/
Concrete fragment not being properly resolved in this case is javax.transaction.jar. This bundle exports packages,
which are already included in the osgi.properties:extra-system-packages. Felix console shows this conflict e.g. here (running in Felix):

g! inspect package requirement 244
org.glassfish.main.transaction.internal-api [244] imports packages:
-------------------------------------------------------------------
...
javax.transaction; version=0.0.0 -> org.apache.felix.framework [0]
javax.transaction.xa; version=0.0.0 -> org.apache.felix.framework [0]
javax.transaction; version=1.1.0 -> org.apache.felix.framework [0]
javax.transaction.xa; version=1.1.0 -> org.apache.felix.framework [0]
...

looking from the other end does not help neither:

g! inspect package capability 0 
org.apache.felix.framework [0] exports packages:
------------------------------------------------
javax.transaction; version=0.0.0 imported by:
   org.jboss.weld.osgi-bundle [263]
   org.glassfish.corba.glassfish-corba-orb [99]
   org.glassfish.main.connectors.runtime [40]
   org.glassfish.main.connectors.inbound-runtime [38]
   org.glassfish.main.javax.ejb [134]
   org.glassfish.main.ejb.ejb-container [77]
   org.glassfish.main.transaction.internal-api [244]
   org.glassfish.main.orb.iiop [198]
   org.eclipse.persistence.jpa [209]
   org.glassfish.main.transaction.jta [183]
   org.glassfish.fighterfish.osgi-jta [274]
   org.glassfish.metro.webservices-osgi [258]
   org.glassfish.main.web.weld-integration [262]
   org.glassfish.main.web.glue [250]
   org.eclipse.persistence.core [208]
   org.glassfish.main.transaction.jts [184]
   org.glassfish.main.common.container-common [66]
   org.glassfish.main.ejb.ejb-full-container [78]
   org.glassfish.main.javax.resource [144]
   org.glassfish.main.connectors.internal-api [39]
javax.transaction.xa; version=0.0.0 imported by:
   org.glassfish.main.connectors.runtime [40]
   org.glassfish.main.jms.core [175]
   org.glassfish.main.connectors.inbound-runtime [38]
   org.glassfish.main.transaction.jts [184]
   org.glassfish.main.javax.jms [140]
   org.glassfish.main.jdbc.runtime [160]
   org.glassfish.main.transaction.internal-api [244]
   org.eclipse.persistence.jpa [209]
   org.glassfish.main.transaction.jta [183]
   org.glassfish.metro.webservices-osgi [258]
   org.glassfish.main.connectors.internal-api [39]
   org.glassfish.main.javax.resource [144]
...
javax.transaction; version=1.1.0 imported by:
   org.jboss.weld.osgi-bundle [263]
   org.glassfish.corba.glassfish-corba-orb [99]
   org.glassfish.main.connectors.runtime [40]
   org.glassfish.main.connectors.inbound-runtime [38]
   org.glassfish.main.javax.ejb [134]
   org.glassfish.main.ejb.ejb-container [77]
   org.glassfish.main.transaction.internal-api [244]
   org.glassfish.main.orb.iiop [198]
   org.eclipse.persistence.jpa [209]
   org.glassfish.main.transaction.jta [183]
   org.glassfish.fighterfish.osgi-jta [274]
   org.glassfish.metro.webservices-osgi [258]
   org.glassfish.main.web.weld-integration [262]
   org.glassfish.main.web.glue [250]
   org.eclipse.persistence.core [208]
   org.glassfish.main.transaction.jts [184]
   org.glassfish.main.common.container-common [66]
   org.glassfish.main.ejb.ejb-full-container [78]
   org.glassfish.main.javax.resource [144]
   org.glassfish.main.connectors.internal-api [39]
javax.transaction.xa; version=1.1.0 imported by:
   org.glassfish.main.connectors.runtime [40]
   org.glassfish.main.jms.core [175]
   org.glassfish.main.connectors.inbound-runtime [38]
   org.glassfish.main.transaction.jts [184]
   org.glassfish.main.javax.jms [140]
   org.glassfish.main.jdbc.runtime [160]
   org.glassfish.main.transaction.internal-api [244]
   org.eclipse.persistence.jpa [209]
   org.glassfish.main.transaction.jta [183]
   org.glassfish.metro.webservices-osgi [258]
   org.glassfish.main.connectors.internal-api [39]
   org.glassfish.main.javax.resource [144]
...

Since Jersey does not deal with the javax.transaction packages in any regard, the failure
is IMHO caused by Jersey newly introduced bundles tweaked Equinox bundle ordering,
which lead to the above described fragile setup manifested itself by failing.

I tried to remove javax.transaction and javax.transaction.xa packages from the extra package list,
but it did not help, and instead of versioned javax.transaction* packages, the system bundle
kept showing the unversioned export only.

Comment by Jakub Podlesak [ 23/Aug/12 ]

CNF exception log, when starting osgi http service bundle in equinox

Comment by Jakub Podlesak [ 24/Aug/12 ]

updated summary and category

Comment by TangYong [ 03/Feb/13 ]

Hi Sahoo,

I have used the recent v4 trunk snapshot(2013/01/25) and put org.eclipse.osgi_3.9.0.v20130128-202223.jar(Equinox Stable Build: KeplerM5) into glassfish/osgi/equinox, then after setting "GlassFish_Platform=Equinox" and executing "asadmin start-domain", anything is OK basiclly and glassfish/domains/domain1/osgi-cache/equinox/org.eclipse.osgi and sub-directories and related files are all generated normally. However, also noticing that in glassfish/domains/domain1/osgi-cache/equinox/, a log file is generated and its content is as following:

!SESSION 2013-02-03 17:08:52.921 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.7.0_09
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=ja_JP

!ENTRY javax.annotation-api 4 0 2013-02-03 17:08:52.921
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: State change in progress for bundle "file:/D:/20130125/glassfish3/glassfish/modules/endorsed/javax.annotation-api.jar" by thread "main".
at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
... 6 more
Root exception:
org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.suspendBundle(PackageAdminImpl.java:330)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:467)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
at java.lang.Thread.run(Thread.java:722)

!ENTRY javax.annotation-api 4 0 2013-02-03 17:08:58.453
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: State change in progress for bundle "file:/D:/20130125/glassfish3/glassfish/modules/endorsed/javax.annotation-api.jar" by thread "main".
at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:387)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.resumeBundles(PackageAdminImpl.java:317)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:556)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
... 8 more
Root exception:
org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException
at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1088)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:387)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.resumeBundles(PackageAdminImpl.java:317)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.processDelta(PackageAdminImpl.java:556)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl.doResolveBundles(PackageAdminImpl.java:251)
at org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1.run(PackageAdminImpl.java:174)
at java.lang.Thread.run(Thread.java:722)

Then, I used "asadmin osgi lb" and found that javax.annotation API (1.1.99.b01)'s status is Active, so I can not confirm whether we can ignore the above exception.

Thanks

Comment by TangYong [ 03/Feb/13 ]

There is a point that I forgot to say: in server.log, I have found any exception or unnormal info.

Comment by Sanjeeb Sahoo [ 03/Feb/13 ]

Tang,

Have you run QuickLook tests against Equinox? You can find the instructions to run QL using Equinox in this bug's description field.

Sahoo

Comment by TangYong [ 04/Feb/13 ]

Sahoo

>Have you run QuickLook tests against Equinox? You can find the instructions to run QL using Equinox in this bug's
>description field.

I Have not still ran QuickLook tests against Equinox and today(maybe tomorrow) I will give you the result of QuickLook tests.

Tang

Comment by TangYong [ 04/Feb/13 ]

BTW: needing to modify <antcall target="start-server-felix"/> and based on GlassFish_Platform condition to judge outputting "in Felix mode" or "in Equinox mode" or "Knopflerfish mode", currently this is hard-coded.

Comment by TangYong [ 05/Feb/13 ]

Hi sahoo,

Please ignore my yesterday's comments because today, I made QL tests many times in my env and another machine again.

The result is that except <antcall target="start-server-felix"/> is hard-coded, QL tests did not hang,
....
testng-summary:
[echo] [testng]
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 112, Failures: 1, Skips: 0
[echo] [testng] ===============================================
[echo] [testng]
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
...

Failured test is as following and I will create a jira:

<class name="test.admincli.RestartDomainTests">
<test-method status="FAIL" signature="restartDomainTest()" name="restartDomainTest" duration-ms="0" started-at="2013-02-05T14:55:49Z" finished-at="2013-02-05T14:55:49Z">
<exception class="java.lang.AssertionError">
<message>
<![CDATA[Restart domain failed. expected:<true> but was:<false>]]>
</message>
<full-stacktrace>
<![CDATA[java.lang.AssertionError: Restart domain failed. expected:<true> but was:<false>
at org.testng.Assert.fail(Assert.java:84)
at org.testng.Assert.failNotEquals(Assert.java:438)
at org.testng.Assert.assertEquals(Assert.java:108)
at org.testng.Assert.assertEquals(Assert.java:239)
at test.admincli.RestartDomainTests.parseTestResults(RestartDomainTests.java:90)
at test.admincli.RestartDomainTests.restartDomainTest(RestartDomainTests.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:470)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:564)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:830)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
at org.testng.TestRunner.runWorkers(TestRunner.java:678)
at org.testng.TestRunner.privateRun(TestRunner.java:624)
at org.testng.TestRunner.run(TestRunner.java:495)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:300)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275)
at org.testng.SuiteRunner.run(SuiteRunner.java:190)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792)
at org.testng.TestNG.runSuitesLocally(TestNG.java:765)
at org.testng.TestNG.run(TestNG.java:699)
at org.testng.TestNG.privateMain(TestNG.java:824)
at org.testng.TestNG.main(TestNG.java:802)
]]>

So, could you please run that hudson job to see whether the issue happens again or not because I have no way to run that hudson job.

Thanks
--Tang

Comment by Sanjeeb Sahoo [ 01/Apr/13 ]

Deferring to 4.0.1 due to lack of time and priority.

Comment by tuomas_kiviaho [ 19/Dec/13 ]

@Jakub I started to have similar problems with JTA packages on another project when I switched from
org.glassfish.main.transaction:javax.transaction:3.1.2.2 over to javax.transaction:javax.transaction-api:1.2

http://wiki.osgi.org/wiki/System_Bundle has a compact explanation of the differentiating manifest headers (Require-Bundle and Fragment-Host) pointing to system.bundle





[GLASSFISH-18938] [osgi-cdi]OSGi service automatic publishing with @Publish-liking annotation Created: 25/Jul/12  Updated: 11/Dec/12

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

Type: New Feature Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: Zip Archive GLASSFISH-18938-patch-20121211.zip    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-18972 making @Publish to support filter pro... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19210 make @Publish support Service type re... Sub-task Open Sanjeeb Sahoo  
GLASSFISH-19440 getting out of the weld-integration l... Sub-task Open Sanjeeb Sahoo  

 Description   

Liking Weld-OSGi:

allows developers to automatically publish service implementation.There is nothing to do, just put the
annotation. OSGi framework is completely hidden. Then the service is accessible through CDI-OSGi service injection
and OSGi classic mechanisms.

In addition, on OSGi RFP-0146 Draft,

CDI002 - The specification MUST make it possible to publish CDI beans in the OSGi Service Registry.

So, this is a critical Requirement on CDI/OSGi Integration just as @OSGiService.



 Comments   
Comment by TangYong [ 01/Aug/12 ]

currently, a basic prototype has been implemented on https://github.com/tangyong/gf-cdi-osgi-integration.

Comment by TangYong [ 10/Aug/12 ]

Sahoo Said:

1. I think you should explore EJBTracker in osgi-ejb-container to see
how it registers EJBs as OSGi services.

2. The service properties look good to me to start with.

Comment by TangYong [ 23/Oct/12 ]

now, implementation is blocked by GLASSFISH-19215, and am fixing GLASSFISH-19215.

Comment by TangYong [ 11/Dec/12 ]

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

Note: I have not updated BeanDeploymentArchiveImpl.java from weld-integration module(JJ fixed GLASSFISH-19406), and once having no problem on this patch, I will update BeanDeploymentArchiveImpl.java with trunk.





[GLASSFISH-18928] Move osgi-adapter out of hk2 Created: 23/Jul/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0_b45
Fix Version/s: 4.1

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


 Comments   
Comment by Sanjeeb Sahoo [ 26/Jul/12 ]

We should also consider separating the module system layer from service layer.

Comment by TangYong [ 08/Oct/12 ]

Sahoo, I also think that osgi-adapter should be moved out of HK2 layer,after all, HK2 is mainly a implementation of JSR-330 standard. The responsibilities of HK2 and osgi-adapter are not same.

Whether the moving working has started or not? If not, I want to start to investigate it.

Comment by Sanjeeb Sahoo [ 09/Oct/12 ]

Although I agree with you, this is not a very high priority issue for us now. Ideally we should separate module layer from service layer in HK2 and keep only the service layer in HK2 project. Then, we can move module layer and the module layer adapters out to some other home. That's a big change with not much return at this point for me. So, I recommend deferring this for now.





[GLASSFISH-18501] EAR deployment fails when OSGi bundle is deployed Created: 13/Mar/12  Updated: 12/Oct/12

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

Type: Bug Priority: Critical
Reporter: jthoennes Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We have a JEE application packaged and deployed as EAR. Now we started to develop some OSGi EJB Application Bundles. Both will be deployed in the same Glassfish instance.

The OSGi EJB bundle includes some classes which are packaged in the EAR too. For example the package com.macd.foo is included in the bundle. The package com.macd.bar is not included in the bundle but added to the the Ignore-Package entry of bundles manifest.

Deploying the EAR fails saying that classes from com.macd.bar package could not be found. But the package com.macd.bar is packaged in the EAR file. If the OSGi bundle is removed deployment of EAR works.

So my questions are:

  • Why does the OSGi bundle affects deployment of EAR file?
  • How can I deploy OSGi bundles containing classes which are available in the EAR file too?


 Comments   
Comment by Sanjeeb Sahoo [ 13/Mar/12 ]

All packages exported by osgi bundles are visible to non-osgi javaee applications, so they can interfere.

Without knowing how the manifest of the bundle looks like and without knowing what the bundle actually contains, it is difficult to say what's going wrong. My guess is that the ear is trying to load some classes from the ejb bundle, but since the bundle is not getting resolved, it is failing.

Comment by cplaetzinger [ 13/Mar/12 ]

Thanks for first response, Sahoo. If I want to use a package within the EAR file and from other OSGi bundles it should be deployed as OSGi bundle?

E.g. package com.macd.foo is used by the EAR file and some other OSGi bundles. Thus package com.macd.foo has to be deployed as separate OSGi bundle to be available for the EAR and the other bundles. Is this assumption correct?

Comment by jthoennes [ 13/Mar/12 ]

Actually, the order of deployment matters:

  • If the EAR is deployed first, all is fine.
  • But if the OSGi bundle is deployed first deploying the EAR fails.

Sahoo, please could you suggest some tracing options besides class-loader tracing using -verbose:class?

Comment by Sanjeeb Sahoo [ 13/Mar/12 ]

jthonennes,

I hope you know how to connect to the osgi shell. Just in case, you don't know, please look at section #10.4.1 of [1]. You need to set glassfish.osgi.start.level.final=3 in osgi.properties file or domain.xml and then telnet localhost 6666. Check to make sure your osgi bundle is getting resolved. If you are finding it difficult to analyse, then attach the server.log. If you can attach the test applications, even better, but I will let you know if I need them or not only after looking at server.log. But, do mention the manifest.mf of the bundle and jar tf of the ear file contents.

cplaetzinger:
OSGi bundles are one level above in the classloader hierarchy, so if com.macd.foo is exported by a bundle then the ear file will always use the package from the bundle. If com.macd.foo is a private package of a bundle then the ear file will use its own version.

[1] http://glassfish.java.net/public/GF-OSGi-Features.pdf

Comment by jthoennes [ 13/Mar/12 ]

Hello Sahoo,

thanks for your answers. I will check my colleage tomorrow.

Cheers, Jörg

Comment by TangYong [ 12/Oct/12 ]

If having not test bundles(including Manifest.MF,etc), I think that the issue is not determined, and suggest that sahoo closed the issue as not reproduced. In addition, once jthoennes uploads more info and finds the issue can be reproduced, the issue will be reopened.





[osgi-cdi]OSGi service automatic publishing with @Publish-liking annotation (GLASSFISH-18938)

[GLASSFISH-19440] getting out of the weld-integration logic knowing about hybrid bundles and OSGi Created: 14/Dec/12  Updated: 14/Dec/12

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

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In current patch, weld-integration logic knows about hybrid bundles and OSGi because in order to get right Bean Manager and current bundle Id, I register Bean Manager as an OSGi Service and make bundle Id as service property.

For example,

BeanManager manager = bootstrap.getManager(archive);
Properties properties = new Properties();
properties.put("BundleID", bundleId);
ServiceRegistration sr = bundleContext.registerService(BeanManager.class.getName(), manager, properties);

However, from Siva's comment,

"However I would still like to try to see how we can get out of the weld-integration logic knowing about hybrid bundles and OSGi."

There is an import issue needing to investigate firstly:

"So, I understand this is the issue for which you bind the appropriate WeldBeanManager in the ServiceRegistry and use it later to get the @Public annotated classes. Can this be fixed? Why is only the BDA for OSGiServiceExtension and not osgiappXXXXX available in the extension? Is this a Weld issue? "






[GLASSFISH-19423] Using custom Qualifier on a @Publish class failed Created: 10/Dec/12  Updated: 11/Dec/12

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

Type: Bug Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[Problem Description]
While using the following custom Qualifier(@Blue) on a @Publish class to register OSGi service,

@Publish(contracts =

{MyServiceInf.class}

)
@Blue
public class MyService implements MyServiceInf{
...
}

The following exception will happen,

[#|2012-12-10T19:32:50.421+0900|SEVERE|44.0|javax.enterprise.logging.stderr|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1355135570421;_LevelValue=1000;|org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable to resolve any beans for Types: [class org.acme.myservice.MyService]; Bindings: [QualifierInstance{annotationClass=interface javax.enterprise.inject.Default, values={}, hashCode=477945538}, QualifierInstance{annotationClass=interface javax.enterprise.inject.Any, values={}, hashCode=249261545}, QualifierInstance{annotationClass=interface org.acme.myservice.api.Blue, values={}, hashCode=668150471}]
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:699)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:102)
at org.glassfish.osgicdi.impl.OSGiServicePublisher.registerOSGiService(OSGiServicePublisher.java:86)
at org.glassfish.osgicdi.impl.OSGiServiceExtension.publishOSGiService(OSGiServiceExtension.java:332)
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterDeploymentValidation(OSGiServiceExtension.java:264)
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:267)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:31)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:382)
at org.glassfish.osgicdi.impl.OSGiCDIExtender$BeanBundleTrackerCustomizer.addingBundle(OSGiCDIExtender.java:235)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:482)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:424)
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:262)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:234)
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:457)
at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.startBundle(OSGiDeployedBundle.java:107)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.resume(OSGiDeployedBundle.java:83)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.start(OSGiDeployedBundle.java:67)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:278)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:299)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:507)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:489)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1449)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1709)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:487)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:255)
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.glassfish.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:107)
at org.glassfish.jersey.server.model.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:146)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:80)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:354)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:349)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:97)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:204)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:180)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:796)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:306)
at org.glassfish.admin.rest.adapter.RestAdapter$1.service(RestAdapter.java:327)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNI|#]



 Comments   
Comment by TangYong [ 10/Dec/12 ]

The feature is very important and once implementing the feature, an user can use custom qualifier to register a OSGi Service, and the qualifier plays a role of Service Property.

Currently, because of some problem, the custom qualifier can not be resolved by cdi container.

Needing to investigate the reason in depth.

In addition, the feature is related to OSGiServicePublisher.getServiceProperties().

Comment by TangYong [ 11/Dec/12 ]

While testing in hybrid javaee bundle scene, the same problem happened.

[Direct Reason]
TypeSafeBeanResolver's resolved field is empty and this caused that while calling "resolve(R resolvable, boolean cache)" method, "resolved.get(wrappedResolvable)" returned null.

[Initial Analyze]
While registering a @Publish class, I used Instance<Object> to select bean instance with qualify and try to get the object. However, The WeldContainer.instance() method returns an instance with the @Default and @Any qualifiers[1], and maybe can not get @Blue bean instance.

So, according to [2], I need to confirm the point.
[1]:https://community.jboss.org/thread/179988
[2]:https://github.com/seam/persistence/blob/master/impl/src/main/java/org/jboss/seam/persistence/util/InstanceResolver.java

Comment by TangYong [ 11/Dec/12 ]

This problem has been fixed and fixing way is to use the following way to resolve bean and get bean instance object,

private <T> T getContextualInstance(BeanManager manager, Class<T> type, Annotation... qualifiers) {
T result = null;
Bean<T> bean = null;
if (qualifiers.length == 0)

{ bean = (Bean<T>) manager.resolve(manager.getBeans(type)); }

else

{ bean = (Bean<T>) manager.resolve(manager.getBeans(type, qualifiers)); }

if (bean != null) {
CreationalContext<T> context = manager.createCreationalContext(bean);
if (context != null)

{ result = (T) manager.getReference(bean, type, context); }

}
return result;
}

1 the above method applies in OSGiServicePublisher class
2 in order to use the above method, needing to use Bean Manager rather than Instance<Object>, So,current patch needing to be modified. Fixed patch will be placed in Glassfish-19215.
3 using the above way rather than Instance<Object> will bring a big advantage for patch: not using Weld Implementation related features, and only using CDI SPI Spec.





[GLASSFISH-19249] @OSGi causes ClassCastException when used from EJB deployed as EAR Created: 26/Oct/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.2.2
Fix Version/s: 4.1

Type: New Feature Priority: Critical
Reporter: cplaetzinger Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have a stateless session bean packaged and deployed as OSGi hybrid bundle. I want to access this EJB from another EJB packaged in an EAR file. So I used the following annotations:

@Inject
@OSGiService( dynamic = true )
private QueueRegistryInterface queueRegistry;

Deployment works fine but on runtime I got the following exception:

[2012-10-26 11:30:13,695] [ERROR] [org.glassfish.osgicdi.impl] [p: thread-pool-1; w: 7] [#1] Expected annotated element java.lang.ClassCastException to be within an OSGi Bundle.
[2012-10-26 11:30:13,695] [ERROR] [com.macd.xconnect.messageprocessor.base.MessageProcessor-OmsReceiver] [p: thread-pool-1; w: 7] failed to return failure message back: routeMessage: Error routing message: null
com.macd.xconnect.messageprocessor.base.MessageRouterBeanException: routeMessage: Error routing message: null
        at com.macd.xconnect.ejbeans.implementation.messagerouter.MessageRouterBean.routeMessage(MessageRouterBean.java:132)
        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.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:49)
        at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
        at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:89)
        at $Proxy207.routeMessage(Unknown Source)
        at com.macd.xconnect.messageprocessor.base.MessageProcessor.processAndRouteMessage(MessageProcessor.java:201)
        at com.macd.xconnect.messageprocessor.base.MessageProcessor.onMessage(MessageProcessor.java:126)
        at com.macd.xconnect.ejbeans.messageprocessor.MessageProcessorBean.onMessage(MessageProcessorBean.java:155)
        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.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
        at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4180)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5368)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
        at com.sun.ejb.containers.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1099)
        at com.sun.ejb.containers.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
        at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
        at $Proxy314.onMessage(Unknown Source)
        at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:260)
        at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:114)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
        at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.ClassCastException
        at java.lang.Class.cast(Class.java:2990)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.getBundleContext(OSGiServiceFactory.java:191)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.lookupService(OSGiServiceFactory.java:127)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory.access$100(OSGiServiceFactory.java:72)
        at org.glassfish.osgicdi.impl.OSGiServiceFactory$DynamicInvocationHandler.invoke(OSGiServiceFactory.java:232)
        at $Proxy315.find(Unknown Source)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.sendMessage(MessageRouter.java:113)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.sendMessage(MessageRouter.java:178)
        at com.macd.xconnect.messageprocessor.base.MessageRouter.routeMessage(MessageRouter.java:96)
        at com.macd.xconnect.ejbeans.implementation.messagerouter.MessageRouterBean.routeMessage(MessageRouterBean.java:130)
        ... 50 more

Please let me know if any further information or examples are required.



 Comments   
Comment by TangYong [ 06/Mar/13 ]

The exception is right because in this case, the EJB packaged in an EAR file can not obtain osgi related classloader and casues

BundleReference.class.cast(annotatedElt.getClassLoader()) will throw ClassCastException.

About how to fix the problem has the following considerations

1. Considering Hybrid EAR deploying

AFAIA, Hybrid EAR deploying is not still supported. Please paying attention to GLASSFISH-6741

2. Considering not using @OSGiService in the EAR

Whether can using JNDI or @EJB although I have not tried, if you can offer further information?

3. Spliting the EAR into WAB and another EJB Bundle in order to use @OSGiService

Thanks
--Tang

Comment by cplaetzinger [ 06/Mar/13 ]

I would like to see hybrid EAR deploying too. We have a huge JEE application packaged and deployed as EAR. So we tried to split it up into several modules using the Glassfish hybrid bundle approach. Since we can not refactor the whole application at once it is necessary to access the beans deployed within a hybrid bundle from the beans deployed in the EAR.

I also tried to access the EJB via JNDI lookup and @EJB annotation but it ends up with other exceptions.

Comment by TangYong [ 06/Mar/13 ]

>I also tried to access the EJB via JNDI lookup and @EJB annotation but it ends up with other exceptions.
I suggest that you can create a more litter case to mock your real JEE application and thus, you can narrow the problems domain into more litter domain. Then, giving me your mocked sample and exception, I will help you analyse and debug it and see how to fix it. Then, once OK, you can apply it into your real case.

If you have more time, please do it and send sample to me(www.tangyong.gf@gmail.com).

Thanks
--Tang

Comment by cplaetzinger [ 06/Mar/13 ]

Hi Tang,

thanks for your help and effort so far. I will try to get an example running next week.

regards,
Christian

Comment by TangYong [ 11/Apr/13 ]

Christian,

Pl. whether can send me an example about the issue.
My email: tangyong@cn.fujitsu.com

Comment by Sanjeeb Sahoo [ 12/Apr/13 ]

I have made it a new feature, because we don't support osgi bundles as part of ear files.

Comment by jthoennes [ 12/Apr/13 ]

Thanks, Sanjeeb. Do you have any plans when you could implement this feature?

Comment by cplaetzinger [ 12/Apr/13 ]

@Sanjeeb: Do you require any input from me?

Comment by Sanjeeb Sahoo [ 12/Apr/13 ]

No, I don't need any further input now. I will get back when we try to implement this.

Comment by jthoennes [ 12/Apr/13 ]

@Sanjeeb: Is there any chance to expedite this implementation by filing a service request in order to increase the priority for your management?

Comment by TangYong [ 16/Apr/13 ]

Sahoo,

I am confirming whether or how to integrate only Apache Aries Application(EBA) into Glassfish?
About supporting for ear in OSGi, I have evaluated many vendors's solution as following,

1 JBOSS 7
Having such a support.
1)
After the discussion with JBOSS OSGi's leader, he gives a test sample[1](However, I have not still tried the sample).
[1]https://github.com/jbossas/jboss-as/blob/7.2.0.Final/testsuite/integration/osgi/src/test/java/org/jboss/as/test/integration/osgi/ear/EnterpriseArchiveTestCase.java

2)integrating Apache Aries Application(EBA) into JBOSS OSGi[2]
Having been available.
[2]: https://issues.jboss.org/browse/JBOSGI-529

3) integrating Apache Aries Subsystem into JBOSS[3]
Will be done on 8.0.0.Beta1
[3]: https://issues.jboss.org/browse/AS7-5921

2 Apache Geronimo 3
Having such a support.
Using Apache Aries Application(EBA).

3 Apache Aries
Having such a support.
1) Apache Aries Application(EBA)
Having been in available status.

2) Apache Aries Subsystem(ESA)
Being in develop status. However, this will become RI of OSGi R5 Subsystem in the future.

4 Spring Source
Having such a support.
1) using PAR file
2) Spring Plan
However, I have not tried Spring related supports.

5 Apache Karaf
Having such a support
1) using Karaf feature
2) integrating Apache Aries into karaf[4]
[4]: http://repo2.maven.org/maven2/org/apache/karaf/assemblies/features/enterprise/2.3.1/enterprise-2.3.1-features.xml

So, based on the above results, we should have three implementation ways:

  • Considering a private solution
    eg. asadmin deploy --type=osgi xxx.ear

ear's structure:
--EAR
├ application.xml
├ lib/... (share lib)
├ ejb bundle
├ war bundle
├ other bundles

  • Integrating Apache Aries Application into Glassfish
    I am doing
  • Integrating Apache Aries Subsystem into Glassfish
    Waiting Subsystem's release

In any way, in the future, Subsystem should replace current private solutions from each vendor.

Thanks
--Tang

Comment by jthoennes [ 16/Apr/13 ]

Hello Tang,

thanks for your detailed about comment about OSGi support for EARs.

As we are in transition from the classic JEE modules to OSGi modules we are looking
for the support of hybrid applications (i.e. mixed OSGi and non-OSGi modules).

Would this be also covered by the Apache Aries integration?

Many thanks, Jörg

Comment by TangYong [ 16/Apr/13 ]

jthoennes,

For mixing OSGi and non-OSGi modules, Sahoo has done much.

>Would this be also covered by the Apache Aries integration?
I am investigating it. Pl. give me some time,

There are some things needing to notice:

1) my consideration is that we only integrate apache aries application(eba)(including part of blueprint) rather than all aries functions, because glassfish
osgi-javaee has offered many features(eg. osgi jpa, osgi jta...), I must select minimized set while integrating eba.

2) we must not influence current gf starting performance while integrating eba

3) so far, I felt that we need to make a bridge between deployment and eba.

Thanks
--Tang

Comment by TangYong [ 16/Apr/13 ]

jthoennes
CC: Sahoo

Initial investigation has been ended. and I have an integration plan. However, can not check in the plan because having some issues.

OK, I fistly said the integration plan.

1) creating three new directories in glassfish\modules

  • third-party\aries\application
  • third-party\aries\blueprint
  • third-party\aries\pre-requisites

2) putting the following aries related bundles into the above three directories

  • third-party\aries\application
    org.apache.aries.application.api-1.0.0.jar
    org.apache.aries.application.default.local.platform-1.0.0.jar
    org.apache.aries.application.deployment.management-1.0.0.jar
    org.apache.aries.application.install-1.0.0.jar
    org.apache.aries.application.management-1.0.0.jar
    org.apache.aries.application.modeller-1.0.0.jar
    org.apache.aries.application.resolver.noop-1.0.0.jar
    org.apache.aries.application.resolver.obr-1.0.0.jar
    org.apache.aries.application.runtime-1.0.0.jar
    org.apache.aries.application.utils-1.0.0.jar
  • third-party\aries\blueprint
    org.apache.aries.blueprint.api-1.0.0.jar
    org.apache.aries.blueprint.core-1.0.0.jar
  • third-party\aries\pre-requisites
    org.apache.aries.proxy-1.0.0.jar
    org.apache.aries.util-1.0.0.jar
    org.apache.felix.bundlerepository.jar
    slf4j-api-1.5.11.jar
    slf4j-simple-1.5.11.jar

3) add/modify the following into config\osgi.properties
glassfish.osgi.auto.install=\
$

{com.sun.aas.installRootURI}modules/endorsed/ \
${com.sun.aas.installRootURI}

modules/osgi-resource-locator.jar \
$

{com.sun.aas.installRootURI}modules/ \
${com.sun.aas.installRootURI}

modules/autostart/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/pre-requisites/ \
${com.sun.aas.installRootURI}

modules/third-party/aries/blueprint/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/application/

aries.bundles=\
${com.sun.aas.installRootURI}

modules/third-party/aries/pre-requisites/ \
$

{com.sun.aas.installRootURI}modules/third-party/aries/blueprint/ \
${com.sun.aas.installRootURI}

modules/third-party/aries/application/

glassfish.osgi.auto.start=\
$

{core.bundles}

\
$

{autostart.bundles} \
${aries.bundles}

glassfish.osgi.auto.start.level.2=${autostart.bundles}

\
$

{aries.bundles}

4) start-domain

5) putting your eba into glassfish\domains\domain1\autodeploy\bundles

6) using asadmin osgi lb to see whether the bundles in your eba have been deployed.

I will give an detailed steps in my blog about how to play with it including an eba sample.

[Analise]
I said that I can not check in the above plan because,

1) influence gf starting performance

  • Sahoo has removed org.apache.felix.bundlerepository.jar, however, I must put it back because of aries.
  • should not start these third-party bundles while starting gf, more reasonable doing is to start them while deploying eba.

2) deployment can not recognize eba's deployment
Currently, only executing "asadmin deploy --type=osgi .../xx.eba" has not any effect and causes failed deployment.So, must investigate
how to make a bridge between deployment and aries eba deployment. Thus, we can resolve 1)'s issue.
However, I have more urgent things, so I said this is my initial result.

Thanks
--Tang

Comment by TangYong [ 18/Apr/13 ]

jthoennes
CC: Sahoo

>I will give an detailed steps in my blog about how to play with it including an eba sample.
You can see concrete steps and test sample in the following:

http://osgizone.typepad.com/tangyong/2013/04/glassfish-osgi-integration-part1-integrating-apache-aries-application-into-glassfish-v4.html

Thanks
--Tang

Comment by jthoennes [ 05/Sep/13 ]

Hello,

this issues is planned for release 4.0.1. Is anybody working on this right now? When is this release due?

Thanks, Jörg

Comment by TangYong [ 05/Sep/13 ]

If exactly speaking, EAR OSGi Deployment has not a uniform standard, although OSGi EE has published a SubSystem Spec.
For the feature, there are three ways:

1. let us wait SubSystem Spec Implementation
The Subsystem Spec Implementation is charged by Apache Aries.

2. Using Apache Aries Application Feature
Just as what I said in my blog, however, this way has a backback that we need to arrange right bundles related to the feature.
Indeedly, we need some function liking Apache Karaf Feature to provision such feature automaticlly. However, this will change
GlassFish Kernel. You knonw , this will need more effort and also need to discuss with Sahoo carefully.

3. Implmenting a new Hybrid Application Bundle related to EAR.
This also needed to be dicuss with Sahoo. Eg. whether needing to implement it currently?

So, for your scene, I suggest that you can do it based on my blog.

If having any problem,

giving me your sample (pl. adding your sample into github or others which I can acess)

In the future, we will implement OSGi/CDI Spec firstly, however, once we felt your scene is most important, we will change plan and maybe firstly
implement the feature you mentioned.

Of Course, also pl. listening Sahoo's suggestion.

Thanks
Tang





[GLASSFISH-19359] @Observes method defined in a servlet of WAB can not be captured while loading OSGiServiceExtension Created: 20/Nov/12  Updated: 26/Nov/12

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

Type: Bug Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[Problem]
@Observes method defined in a servlet of WAB can not be captured while loading OSGiServiceExtension

[Background]
I defined a @Observes method in a servlet of WAB as following,

public void OnServiceRegistered(@Observes @ServiceContract(StockQuoteService.class) ServiceRegistered event){
...
}

While implementing CDI/OSGi event integration, OSGiServiceExtension will be loaded. By adding the second parameter into beforeBeanDiscovery method liking the following, I can get current BeanManager.

void beforeBeanDiscovery(@Observes BeforeBeanDiscovery bdd, BeanManager manager){
...

if (manager instanceof WeldManager)

{ this.manager = (WeldManager)manager; }

}

According to Weld Container LifeCycle Events's triggering process, while triggering afterBeanDiscovery event, the OnServiceRegistered @Observes method should be added into current BeanManager, however, by debugging and confirming, OnServiceRegistered @Observes method has not been found in current BeanManager. This will cause CDI/OSGi event integration can not work for WAB.

So, please siva and sahoo confirm whether this is a bug or not?



 Comments   
Comment by TangYong [ 20/Nov/12 ]

By debugging, I can confirm that while executing org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy()[1], OnServiceRegistered @Observes method has been found and added into manager, however, the @Observes method has not been found in BeanManager which is obtained from OSGiServiceExtension.

[1]:
for (ObserverMethodImpl<?, ?> observer : getEnvironment().getObservers()) {
if (Observers.isObserverMethodEnabled(observer, manager))

{ log.debug(FOUND_OBSERVER_METHOD, observer); observer.initialize(); ProcessObserverMethodImpl.fire(manager, observer); manager.addObserver(observer); }

}

Comment by TangYong [ 20/Nov/12 ]

For javaee bundle(WAB) scene, I have understood the reason why @Observes method has not been found in BeanManager which is obtained from OSGiServiceExtension. The reason is as following:

Mainly reason is that multi BeanDeploymentArchives and BeanDeployments which relate to javax.enterprise.inject.spi.Extension exist while WeldBootstrap starts to execute startInitialization(), such as,

・org.glassfish.osgicdi.impl.OSGiServiceExtension bdaType= UNKNOWN
・com.acme.FlowCDIExtension bdaType= UNKNOWN
・org.glassfish.jms.injection.JMSCDIExtension bdaType= UNKNOWN
・org.glassfish.sse.impl.ServerSentEventCdiExtension bdaType= UNKNOWN
・osgiapp3256168712323466773 bdaType= WAR
...

While beforeBeanDiscovery method(other lifecycle methods are also same ) is called, obtained BeanManager is related to org.glassfish.osgicdi.impl.OSGiServiceExtension rather than osgiapp3256168712323466773 because lifecycle oberser methods are only added into org.glassfish.osgicdi.impl.OSGiServiceExtension's BeanManager, so, @Observes method has not been found in the BeanManager.

If we want to obtain right BeanManager related to osgiapp3256168712323466773, I think that we only get the BeanManager from org.glassfish.weld.WeldDeployer.event() method, than register the Instance<Object> as OSGi Service in order that OSGiCDIContainerActivator can use the Instance<Object>.

Then, the reason that the issue does not happen on plain cdi osgi scene is that I directly trigger WELD SPI using only a BeanDeploymentArchive.

Comment by TangYong [ 22/Nov/12 ]

Now, the problem has been resolved and put into my newest patch which has been uploaded into GLASSFISH-19215.

Next, I will start to write fighterfish test case for the issue.

Comment by TangYong [ 23/Nov/12 ]

Today, two bugs has been fixed,

1) NPE happened on OSGiServiceExtension.findCurrentBundleId method

[Reason]
While deploying a javaee war with beans.xml(not hybrid app bundle), Instance will be not registered into OSGi registery, so needing to judge whether references is null, otherwise, the following NPE will happen.

Exception 0 :
java.lang.NullPointerException
at org.glassfish.osgicdi.impl.OSGiServiceExtension.findCurrentBundleId(OSGiServiceExtension.java:260)
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterDeploymentValidation(OSGiServiceExtension.java:230)
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:267)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:31)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:382)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:246)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:311)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:507)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:489)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1449)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1709)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:487)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:255)
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.glassfish.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:107)
at org.glassfish.jersey.server.model.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:146)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:80)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:354)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:349)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:97)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:204)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:180)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:796)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:306)
at org.glassfish.admin.rest.adapter.RestAdapter$1.service(RestAdapter.java:327)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:781)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)
. Please see server.log for more details.

Comment by TangYong [ 23/Nov/12 ]

2) NPE happened on OSGiServiceExtension.afterDeploymentValidation

[Reason]
While deploying a javaee war with beans.xml(not hybrid app bundle), because of deploying mode(for hybrid app bundle, there are two phrases, on the second phrase, cdi-osgi has been activated), cdi-osgi has been still in resolved state,
so, "BundleContext context = FrameworkUtil.getBundle(this.getClass()).getBundleContext()" will return null.

We must judge whether context is null. If null, the method will return directly. Otherwise, the exception will happen.

[#|2012-11-23T15:16:36.187+0900|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=10;_ThreadName=main;_TimeMillis=1353651396187;_LevelValue=1000;|Exception List with 1 exceptions:
Exception 0 :
java.lang.NullPointerException
at org.glassfish.osgicdi.impl.OSGiServiceExtension.afterDeploymentValidation(OSGiServiceExtension.java:229)
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:267)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75)
at org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:46)
at org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:31)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:382)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:246)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:311)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:507)
at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:387)
at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:223)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:249)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:288)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:420)
at org.glassfish.hk2.runlevel.internal.RunLevelContext.findOrCreate(RunLevelContext.java:119)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:1894)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:90)
at com.sun.enterprise.v3.server.AppServerStartup$StartupActivator.activate(AppServerStartup.java:527)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.activateRunLevel(RunLevelControllerImpl.java:828)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.upActiveRecorder(RunLevelControllerImpl.java:782)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$Worker.run(RunLevelControllerImpl.java:677)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl$SyncProceedToWorker.proceedTo(RunLevelControllerImpl.java:948)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:565)
at org.glassfish.hk2.runlevel.utilities.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:349)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:370)
at com.sun.enterprise.v3.server.AppServerStartup.run(AppServerStartup.java:256)
at com.sun.enterprise.v3.server.AppServerStartup.doStart(AppServerStartup.java:174)
at com.sun.enterprise.v3.server.AppServerStartup.start(AppServerStartup.java:165)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.start(GlassFishImpl.java:79)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.start(EmbeddedOSGiGlassFishImpl.java:73)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.start(GlassFishDecorator.java:63)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishImpl.start(OSGiGlassFishImpl.java:71)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:117)
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 com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)

Comment by TangYong [ 26/Nov/12 ]

Today, on testing a common WAR(not WAB, however, in Manifest.MF, "Bundle-SymbolicName" exists), the following exception happened while deploying the common WAR,

[#|2012-11-26T11:48:28.578+0900|SEVERE|44.0|javax.enterprise.system.tools.deployment.common|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353898108578;_LevelValue=1000;|Exception while invoking class org.glassfish.weld.WeldDeployer load method
java.lang.NullPointerException
at org.glassfish.weld.BeanDeploymentArchiveImpl.getBundleForCurrentBeanArchive(BeanDeploymentArchiveImpl.java:187)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:154)
at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:136)
at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:110)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:442)
at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:108)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:195)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:262)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:503)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:229)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:489)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:337)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1449)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:119)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1759)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1709)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:487)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:255)
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.glassfish.jersey.server.model.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:80)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:107)
at org.glassfish.jersey.server.model.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:146)
at org.glassfish.jersey.server.model.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:80)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:354)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:349)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:97)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:204)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:316)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:180)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:796)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:306)
at org.glassfish.admin.rest.adapter.RestAdapter$1.service(RestAdapter.java:327)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:189)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispatch(HK2Dispatcher.java:113)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:236)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:781)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:662)

#]

So, the reason is that I have not checked whether pa.getBundles(symbolicName, version) is null or not, so, the fixing way is adding result's checking.

private Bundle getBundleForCurrentBeanArchive(BundleContext context, String symbolicName, String version) {
PackageAdmin pa = (PackageAdmin) context.getService(context.getServiceReference(PackageAdmin.class.getName()));
Bundle[] bundles = pa.getBundles(symbolicName, version);
if (bundles != null)

{ return bundles[0]; }

return null;
}





[OSGi/CDI] CDI + OSGi event admin (GLASSFISH-15365)

[GLASSFISH-19358] Adding fighterfish test cases Created: 19/Nov/12  Updated: 22/Nov/12

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

Type: Sub-task Priority: Critical
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, An implementation has been finished, and Needing to add fighterfish test cases:

[Test Requirements]
Adding 4 bundles, called FooInf, FooBean1,
FooBean2, BarInf, BarBean, the dependency relationships are as following:

1) FooInf and BarInf are pure OSGi bundles
2) FooBean1 is an implementation of FooInf, and FooBean2 is another implementation of FooInf.
3) BarBean is an implementation of BarInf.
4) FooBean1 and FooBean2 are registered as OSGi Services using @Publish
5) BarBean uses FooInf as @OSGiService.
6) BarBean has a OnServiceRegistered event callback method liking the following:
public void OnServiceRegistered(@Observes @ServiceContract(FooInf.class) ServiceRegistered event){
.... //Call FooBean2's method
}

Firstly, we deploy FooInf and BarInf, then deploy FooBean1, deploy BarBean, finally we deploy FooBean2, if anything is ok, we should see that OnServiceRegistered can be called successfully and CDI/OSGi integration can notify BarBean that FooBean2 has been registered.

Of course, we can also deploy FooBean1 only and undeploy FooBean1, then deploy FooBean1 again, in this way, BarBean can be notified that an implementation of FooInf has been available.



 Comments   
Comment by TangYong [ 22/Nov/12 ]

Test cases need to add WAB scene(seeing GLASSFISH-19359)





[GLASSFISH-15225] [OSGi] CDI beans not accessible in web applications Created: 15/Dec/10  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1_b33
Fix Version/s: 4.1

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

Attachments: GZip Archive dummy-cdi-web-test.tar.gz     File dummy-web.war     XML File weld.faces-config.xml    
Issue Links:
Dependency
depends on GLASSFISH-15353 component id is not unregistered from... Resolved
Status Whiteboard:

Workaround: Use attached faces-config.xml

Tags: 3_1-exclude, 3_1-next, 3_1_1-scrubbed

 Description   

This seems to be related to GLASSFISH-14842.

However as that bug seems to be fixed this could be introduced by the OSGi/CDI integration.

Attached a test project ( dummy-cdi-web-test.tar.gz ) which is a maven project building a WAB. To see the issue immediately try to access it like this:

http://localhost:8080/dummy-web/?name=John

The error I then get is:

/index.xhtml @12,69 value="#

{dummyBean.name}

": Target Unreachable, identifier 'dummyBean' resolved to null

The application worked fine at least with 3.1 promoted b06.



 Comments   
Comment by Sanjeeb Sahoo [ 16/Dec/10 ]

Yes, I can reproduce this issue with latest build. If I deploy the war as a regular war, it works as expected. Siva has to tell us why this is not working as a WAB.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Analysis: A custom faces config provider org.glassfish.weld.jsf.WeldFacesConfigProvider is used to return the Weld related faces-config.xml to the JSF runtime and this is enabled for CDI applications.

While trying to search for faces config provider in:
ServiceFactoryUtils.getServiceEntries(String) line: 171
ConfigurationResourceProviderFactory.createProviders(ConfigurationResourceProviderFactory$ProviderType) line: 88
ConfigManager.getConfigurationResourceProviders(List<ConfigurationResourceProvider>, ProviderType) line: 467
ConfigManager.getFacesConfigResourceProviders() line: 450
ConfigManager.initialize(ServletContext) line: 321
ConfigureListener.contextInitialized(ServletContextEvent) line: 226
WebModule(StandardContext).contextListenerStart() line: 4683
WebModule.contextListenerStart() line: 531
WebModule(StandardContext).start() line: 5303
WebModule.start() line: 497
VirtualServer(ContainerBase).addChildInternal(Container) line: 917

for a WAR the web application classloader has visibility to urls from WebappClassLoader (delegate=true; repositories=WEB-INF/classes/) has
[org.glassfish.weld.jsf.WeldFacesConfigProvider] and hence the weld faces configuration is used.

For a WAB, OTOH, the OSGiWebDeploymentContext$WABClassLoader
only provides visiblity to [org.glassfish.osgiweb.OSGiFacesConfigResourceProvider], and this results in the weld JSF configuration not getting registered and hence injection fails.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Transferring to Sahoo to investigate further.

Comment by Sanjeeb Sahoo [ 17/Dec/10 ]

Thanks Siva for telling what's really different. I am looking for a fix. In the meanwhile, I can suggest this simple work around which I have verified by modifying the attached test case:

Package the attached weld.faces-config.xml in META-INF/ directory of the WAB. You don't have to change the name to faces-config.xml. JSF allows custom faces-config to have arbitrary prefix.

I am lowering the priority of this issue because of this work around.

Comment by Sanjeeb Sahoo [ 22/Dec/10 ]

Will be addressed in 3.2 as 3.1 is close to release. Use the suggested work around in the meanwhile.

Comment by chaoslayer [ 23/Dec/10 ]

OK, the plan vanilla CDI works now.

Therefore I just got one step further and added the primefaces library to test some things ( attached "dummy-web.war" ) and here comes the next gotcha:

INFO: Updated /srv/servers/glassfish/v31-b34/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Started bundle: file:/srv/servers/glassfish/v31-b34/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war
INFO: Expanded at file:/tmp/osgiapp1741957746419399825/
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: total number of classes with faces annotation = 0
SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5269)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:753)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1981)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1629)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2683)
at org.apache.catalina.core.StandardContext.addApplicationListener(StandardContext.java:1927)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureApplicationListener(TomcatDeploymentConfig.java:234)
at com.sun.enterprise.web.TomcatDeploymentConfig.configureWebModule(TomcatDeploymentConfig.java:93)
at com.sun.enterprise.web.WebModuleContextConfig.start(WebModuleContextConfig.java:272)
at com.sun.enterprise.web.WebModuleContextConfig.lifecycleEvent(WebModuleContextConfig.java:172)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5261)
... 25 more
Caused by: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:2793)
at org.apache.catalina.core.StandardContext.loadListener(StandardContext.java:4738)
at com.sun.enterprise.web.WebModule.loadListener(WebModule.java:1588)
at org.apache.catalina.core.StandardContext.addListener(StandardContext.java:2680)
... 32 more
Caused by: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:317)
at com.sun.enterprise.web.WebContainer.createListenerInstance(WebContainer.java:733)
at com.sun.enterprise.web.WebModule.createListenerInstance(WebModule.java:1966)
at org.apache.catalina.core.StandardContext.createListener(StandardContext.java:2791)
... 35 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:428)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:300)
... 38 more

WARNING: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:921)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:753)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1981)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1629)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)

SEVERE: Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:127)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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)

SEVERE: Exception while loading the app
INFO: Deleted /tmp/osgiapp1741957746419399825
SEVERE: Failed while deploying bundle org.glassfish.osgi.dummy-web [298]
WARNING: Failed to deploy bundle org.glassfish.osgi.dummy-web [298]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [298] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [298] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [298] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:128)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$100(JavaEEExtender.java:59)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.run(JavaEEExtender.java:165)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
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: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [298] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
... 10 more
Caused by: java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException: Error creating managed object for class org.jboss.weld.servlet.WeldListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:127)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
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

Comment by chaoslayer [ 23/Dec/10 ]

Well, the last error was introduced somehow because it seems that at least WAB's don't get updated properly.

If I shutdown GlassFish, remove any OSGi cache and startup again I see that it complains with NoClassDefFound which is totally correct on that bundle, but the same should be experienced using a bundle update.

Comment by Sanjeeb Sahoo [ 27/Dec/10 ]

After a lot of debugging, I can now explain why we are seeing a weired exception when we are trying to update the cdi enabled WAB. if we look at the stack, we see
Caused by: java.lang.NullPointerException
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:485)
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.createManagedBean(ManagedBeanManagerImpl.java:428)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManagedObject(InjectionManagerImpl.java:300)
... 38 more

The root cause of this is GLASSFISH-15353

Comment by Sanjeeb Sahoo [ 05/Jul/11 ]

Completely missed this bug for 3.1.1. Will definitely do it in 3.2.

Comment by TangYong [ 27/Nov/12 ]

Because of triggering the issue again, consider to increase the priority and investigate how to fix it.

Comment by TangYong [ 26/Mar/13 ]

Updating into 3/26 trunk, and done a confirmation as following(Having a big regression for Workaround):

Scene1: applying Workaround for the first attachment(dummy-cdi-web-test.tar.gz)

After directly putting weld.faces-config.xml into META-INF/ directory of the WAB, deploying the WAB(asadmin deploy --type=osgi D:\20130125\GLASSFISH-15225\dummy-web\target\dummy-web.war) has fatal exception as following:

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Critical error during deployment:
com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:353)
at com.sun.faces.config.processor.LifecycleConfigProcessor.addPhaseListeners(LifecycleConfigProcessor.java:132)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:111)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:239)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
Caused by: javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:384)
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:278)
... 34 more
Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener
at java.lang.ClassLoader.findClass(ClassLoader.java:522)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.sun.faces.util.Util.loadClass(Util.java:301)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
... 35 more
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00174] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Startup of context /dummy-web failed due to previous errors]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00175] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6099)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5916)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00108] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5920)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:273)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
... 25 more
Caused by: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:353)
at com.sun.faces.config.processor.LifecycleConfigProcessor.addPhaseListeners(LifecycleConfigProcessor.java:132)
at com.sun.faces.config.processor.LifecycleConfigProcessor.process(LifecycleConfigProcessor.java:111)
at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:152)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:239)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
... 28 more
Caused by: javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:384)
at com.sun.faces.config.processor.AbstractConfigProcessor.createInstance(AbstractConfigProcessor.java:278)
... 34 more
Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener
at java.lang.ClassLoader.findClass(ClassLoader.java:522)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.sun.faces.util.Util.loadClass(Util.java:301)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
... 35 more
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 900] [[
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Exception while loading the app]]

[2013-03-26T17:10:19.234+0900] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419234] [levelValue: 1000] [[
Undeployment failed for context /dummy-web]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 800] [[
Deleted D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\osgi-cache\felix\bundle292\data\applications\bundle297-1364285417875]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [SEVERE] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 1000] [[
Failed while deploying bundle org.glassfish.osgi.dummy-web [297]]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 800] [[
Removed bundle 297 against context path /dummy-web ]]

[2013-03-26T17:10:19.343+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364285419343] [levelValue: 900] [[
Failed to deploy bundle org.glassfish.osgi.dummy-web [297]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [297] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [297] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [297] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127)
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: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)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [297] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:198)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
... 10 more
Caused by: java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException:
Source Document: bundle://297.0:0/META-INF/weld.faces-config.xml
Cause: Unable to create a new instance of 'org.jboss.weld.jsf.WeldPhaseListener': javax.faces.FacesException: org.jboss.weld.jsf.WeldPhaseListener
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
... 12 more
]]

Scene2: putting the second attachment(dummy-web.war) into "autodeploy\bundles"

More exceptions happened in the server.log as following:

[2013-03-26T16:57:59.890+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiejb] [tid: _ThreadID=84 _ThreadName=fileinstall-D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1/autodeploy/bundles/] [timeMillis: 1364284679890] [levelValue: 800] [[
removedService: Found 0 no. of EJBs]]

[2013-03-26T16:57:59.906+0900] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=178 _ThreadName=Thread-3] [timeMillis: 1364284679906] [levelValue: 800] [[

    • BatchRuntimeHelper:: App Undeployed: null]]

[2013-03-26T16:57:59.921+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=84 _ThreadName=fileinstall-D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1/autodeploy/bundles/] [timeMillis: 1364284679921] [levelValue: 800] [[
Deleted D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\osgi-cache\felix\bundle292\data\applications\bundle296-1364284644890]]

[2013-03-26T16:57:59.921+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=84 _ThreadName=fileinstall-D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1/autodeploy/bundles/] [timeMillis: 1364284679921] [levelValue: 800] [[
Undeployed bundle org.glassfish.osgi.dummy-web [296]]]

[2013-03-26T16:58:00.406+0900] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=84 _ThreadName=Thread-3] [timeMillis: 1364284680406] [levelValue: 800] [[
Updated D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\autodeploy\bundles\dummy-web.war]]

[2013-03-26T16:58:00.406+0900] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=84 _ThreadName=Thread-3] [timeMillis: 1364284680406] [levelValue: 800] [[
Started bundle: file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/autodeploy/bundles/dummy-web.war]]

[2013-03-26T16:58:00.781+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284680781] [levelValue: 800] [[
Expanded at file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/]]

[2013-03-26T16:58:00.937+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284680937] [levelValue: 800] [[
uris = file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/WEB-INF/classes/, file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/WEB-INF/lib/Bundle296.jar, file:/D:/20130125/glassfish9/glassfish4/glassfish/domains/domain1/osgi-cache/felix/bundle292/data/applications/bundle296-1364284680250/WEB-INF/lib/primefaces-2.1.jar]]

[2013-03-26T16:58:01.625+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681625] [levelValue: 800] [[
total number of classes with faces annotation = 0]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.captcha.CaptchaValidator, reason: java.lang.NoClassDefFoundError: javax/faces/validator/Validator]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.view.View, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.imageswitch.ImageSwitch, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.growl.Growl, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.column.Column, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIColumn]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.inputswitch.InputSwitch, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.slider.Slider, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.focus.Focus, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphictext.GraphicText, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlGraphicImage]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.Draggable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.spreadsheet.Spreadsheet, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedcolumn.StackedColumnChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.656+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681656] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.Layout, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.application.Application, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.LayoutUnit, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.idlemonitor.IdleMonitor, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.panel.Panel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.fileupload.FileUpload, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.Droppable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.resource.Resource, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowitem.RowItem, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.menu.Menu, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.messages.Messages, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.series.ChartSeries, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.themeswitcher.ThemeSwitcher, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.column.ColumnChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.tree.UITreeNode, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.linkbutton.LinkButton, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowgroup.RowGroup, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.671+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681671] [levelValue: 900] [[
Unable to load class org.primefaces.component.notificationbar.NotificationBar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.inplace.Inplace, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.picklist.PickList, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabview.TabView, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.tableview.TableView, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.contextmenu.ContextMenu, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.confirmdialog.ConfirmDialog, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandbutton.CommandButton, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlCommandButton]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubutton.MenuButton, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.keyboard.Keyboard, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlInputText]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.rating.Rating, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.progressbar.ProgressBar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.Schedule, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.remotecommand.RemoteCommand, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.breadcrumb.BreadCrumb, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.terminal.Terminal, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.ScheduleEventDialog, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.navbarcontrol.NavBarControl, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.687+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681687] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabslider.TabSlider, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.poll.Poll, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecropper.ImageCropper, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.bar.BarChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.menuitem.MenuItem, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedbar.StackedBarChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.resizable.Resizable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubar.Menubar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.line.LineChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.inputmask.InputMask, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlInputText]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.uiajax.UIAjax, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.autocomplete.AutoComplete, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.703+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681703] [levelValue: 900] [[
Unable to load class org.primefaces.component.accordionpanel.AccordionPanel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.lightbox.LightBox, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.spinner.Spinner, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.watermark.Watermark, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.datalist.DataList, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.pie.PieChart, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.treetable.TreeTable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.ajaxstatus.AjaxStatus, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.captcha.Captcha, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandlink.CommandLink, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlCommandLink]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.dashboard.Dashboard, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.gmap.GMapInfoWindow, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.stack.Stack, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.718+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681718] [levelValue: 900] [[
Unable to load class org.primefaces.component.outputpanel.OutputPanel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.dock.Dock, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.effect.Effect, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.datagrid.DataGrid, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabview.Tab, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.carousel.Carousel, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.editor.Editor, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.calendar.Calendar, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.password.Password, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlInputText]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.dialog.Dialog, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIPanel]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.resources.Resources, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.push.Push, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.wizard.Wizard, reason: java.lang.NoClassDefFoundError: javax/faces/component/NamingContainer]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.message.Message, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.media.Media, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.734+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681734] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphicimage.GraphicImage, reason: java.lang.NoClassDefFoundError: javax/faces/component/html/HtmlGraphicImage]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.tree.Tree, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.tooltip.Tooltip, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIOutput]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.colorpicker.ColorPicker, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIInput]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.hotkey.Hotkey, reason: java.lang.NoClassDefFoundError: javax/faces/component/UICommand]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.datatable.DataTable, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.gmap.GMap, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.printer.Printer, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.submenu.Submenu, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.spreadsheet.Sheet, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIData]]

[2013-03-26T16:58:01.750+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681750] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecompare.ImageCompare, reason: java.lang.NoClassDefFoundError: javax/faces/component/UIComponentBase]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.renderkit.CoreRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.renderkit.HeadRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.accordionpanel.AccordionPanelRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.ajaxstatus.AjaxStatusRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.autocomplete.AutoCompleteRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.breadcrumb.BreadCrumbRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.calendar.CalendarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.captcha.CaptchaRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.carousel.CarouselRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.BaseChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.colorpicker.ColorPickerRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandbutton.CommandButtonRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.765+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681765] [levelValue: 900] [[
Unable to load class org.primefaces.component.commandlink.CommandLinkRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.confirmdialog.ConfirmDialogRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.contextmenu.ContextMenuRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dashboard.DashboardRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.datagrid.DataGridRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.datalist.DataListRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.datatable.DataTableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dialog.DialogRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.DraggableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dnd.DroppableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.dock.DockRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.editor.EditorRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.781+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681781] [levelValue: 900] [[
Unable to load class org.primefaces.component.effect.EffectRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.fileupload.FileUploadRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.focus.FocusRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.gmap.GMapRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.796+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681796] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphicimage.GraphicImageRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.graphictext.GraphicTextRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.growl.GrowlRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.hotkey.HotkeyRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.idlemonitor.IdleMonitorRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecompare.ImageCompareRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.imagecropper.ImageCropperRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.imageswitch.ImageSwitchRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.inplace.InplaceRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.inputmask.InputMaskRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.keyboard.KeyboardRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.LayoutRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.layout.LayoutUnitRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.812+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681812] [levelValue: 900] [[
Unable to load class org.primefaces.component.lightbox.LightBoxRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.linkbutton.LinkButtonRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.media.MediaRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.menu.MenuRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubar.MenubarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.menubutton.MenuButtonRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.message.MessageRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.messages.MessagesRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.notificationbar.NotificationBarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.outputpanel.OutputPanelRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.panel.PanelRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.828+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681828] [levelValue: 900] [[
Unable to load class org.primefaces.component.password.PasswordRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.picklist.PickListRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.poll.PollRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.printer.PrinterRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.progressbar.ProgressBarRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.push.PushRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.rating.RatingRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.remotecommand.RemoteCommandRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.resizable.ResizableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.resource.ResourceRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.resources.ResourcesRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.ScheduleEventDialogRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.schedule.ScheduleRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.843+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681843] [levelValue: 900] [[
Unable to load class org.primefaces.component.slider.SliderRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.spinner.SpinnerRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.spreadsheet.SpreadsheetRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.stack.StackRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabslider.TabSliderRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tabview.TabViewRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.terminal.TerminalRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.themeswitcher.ThemeSwitcherRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tooltip.TooltipRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.tree.TreeRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.treetable.TreeTableRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.uiajax.UIAjaxRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.watermark.WatermarkRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.859+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681859] [levelValue: 900] [[
Unable to load class org.primefaces.component.wizard.WizardRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.application.ApplicationRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.inputswitch.InputSwitchRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowgroup.RowGroupRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.rowitem.RowItemRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.tableview.TableViewRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.touch.component.view.ViewRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.bar.BarChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.column.ColumnChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.line.LineChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.875+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681875] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.pie.PieChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.890+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681890] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedbar.StackedBarChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.890+0900] [glassfish 4.0] [WARNING] [AS-WEB-UTIL-00035] [javax.enterprise.web.util] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681890] [levelValue: 900] [[
Unable to load class org.primefaces.component.chart.stackedcolumn.StackedColumnChartRenderer, reason: java.lang.NoClassDefFoundError: javax/faces/render/Renderer]]

[2013-03-26T16:58:01.953+0900] [glassfish 4.0] [INFO] [jsf.config.listener.version] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681953] [levelValue: 800] [[
コンテキスト '/dummy-web' の Mojarra 2.2.0-m12 (-SNAPSHOT 20130320-0201 https://svn.java.net/svn/mojarra~svn/tags/2.2.0-m12@11773) を初期化します]]

[2013-03-26T16:58:01.953+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284681953] [levelValue: 800] [[
Faces Config uris excluding the ones named as faces-config.xml = [bundle://296.1:0/META-INF/weld.faces-config.xml]]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Critical error during deployment:
com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:330)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:236)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
Caused by: javax.faces.FacesException: org.primefaces.context.PrimeExternalContextFactory
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:710)
at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:572)
at javax.faces.FactoryFinder.access$500(FactoryFinder.java:140)
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1120)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:328)
... 31 more
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1039)
at org.glassfish.weld.services.JCDIServiceImpl.injectManagedObject(JCDIServiceImpl.java:286)
at org.glassfish.faces.integration.GlassFishInjectionProvider.inject(GlassFishInjectionProvider.java:189)
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:695)
... 36 more
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327)
at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:161)
at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:59)
at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:153)
at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:70)
at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:44)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:65)
... 40 more
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00174] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Startup of context /dummy-web failed due to previous errors]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00175] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6099)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5916)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [AS-WEB-CORE-00108] [javax.enterprise.web.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5920)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
Caused by: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:273)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
... 25 more
Caused by: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:330)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:236)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:424)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214)
... 28 more
Caused by: javax.faces.FacesException: org.primefaces.context.PrimeExternalContextFactory
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:710)
at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:572)
at javax.faces.FactoryFinder.access$500(FactoryFinder.java:140)
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:1120)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:379)
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:328)
... 31 more
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1039)
at org.glassfish.weld.services.JCDIServiceImpl.injectManagedObject(JCDIServiceImpl.java:286)
at org.glassfish.faces.integration.GlassFishInjectionProvider.inject(GlassFishInjectionProvider.java:189)
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:695)
... 36 more
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327)
at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:161)
at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:59)
at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:153)
at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:70)
at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:44)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:65)
... 40 more
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 900] [[
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2279)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1925)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T16:58:02.140+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682140] [levelValue: 1000] [[
Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T16:58:02.156+0900] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682156] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
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: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)
]]

[2013-03-26T16:58:02.156+0900] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682156] [levelValue: 1000] [[
Exception while loading the app]]

[2013-03-26T16:58:02.156+0900] [glassfish 4.0] [SEVERE] [AS-WEB-GLUE-00192] [javax.enterprise.web] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682156] [levelValue: 1000] [[
Undeployment failed for context /dummy-web]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 800] [[
Deleted D:\20130125\glassfish9\glassfish4\glassfish\domains\domain1\osgi-cache\felix\bundle292\data\applications\bundle296-1364284680250]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [SEVERE] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 1000] [[
Failed while deploying bundle org.glassfish.osgi.dummy-web [296]]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [INFO] [] [org.glassfish.osgiweb] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 800] [[
Removed bundle 296 against context path /dummy-web ]]

[2013-03-26T16:58:02.187+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=91 _ThreadName=pool-16-thread-1] [timeMillis: 1364284682187] [levelValue: 900] [[
Failed to deploy bundle org.glassfish.osgi.dummy-web [296]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.osgi.dummy-web [296] failed because of following reason: Failed while deploying bundle org.glassfish.osgi.dummy-web [296] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [296] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127)
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: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)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.osgi.dummy-web [296] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:198)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:120)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
... 10 more
Caused by: java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.RuntimeException: com.sun.faces.config.ConfigurationException: Factory 'javax.faces.context.ExternalContextFactory' was not configured properly.
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:185)
... 12 more
]]

So, needing to investigate the reasons from scene1 and scene2 in depth.

Comment by TangYong [ 26/Mar/13 ]

About scene1, I have some interesting finding as following:

Noting the following exception info,

Caused by: java.lang.ClassNotFoundException: org.jboss.weld.jsf.WeldPhaseListener
at java.lang.ClassLoader.findClass(ClassLoader.java:522)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:257)
at com.sun.enterprise.v3.server.APIClassLoaderServiceImpl$APIClassLoader.loadClass(APIClassLoaderServiceImpl.java:222)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:170)
at org.glassfish.osgiweb.OSGiWebDeploymentContext$WABClassLoader.loadClass(OSGiWebDeploymentContext.java:153)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at com.sun.faces.util.Util.loadClass(Util.java:301)
at com.sun.faces.config.processor.AbstractConfigProcessor.loadClass(AbstractConfigProcessor.java:376)
... 35 more
]]

Noting an important change[1] from Weld 1.x --> Weld 2.x
[1]: https://community.jboss.org/wiki/WeldIntegratorGuide-ChangesForWeld20

"WeldPhaseListener has been removed. The listener served as a hook for activating / deactivating conversations. In CDI 1.1 (CDI-80) conversations are now available for pure Servlet requests and therefore conversation activation is handled in the WeldListener (which is a Servlet listener)."

The same issue can be found in [2],
[2]: https://community.jboss.org/thread/218292

I will confirm whether truly being caused by the change.

Comment by TangYong [ 26/Mar/13 ]

Adding priority into Major because the issue maybe related to Weld 2.x change.

Comment by TangYong [ 26/Mar/13 ]

From JBOSS guy(Jozef Hartinger)'s fixing[1], org.jboss.weld.jsf.WeldPhaseListener should be removed from faces-config.xml since weld 2.x.

[1]: https://source.jboss.org/browse/WeldCore/environments/servlet/core/src/main/resources/META-INF/faces-config.xml?r2=99d2f3568c5671a297319b8ef6d967b07b6279c7&r1=fb35e1d1b8106854b606c999ab634ab59b92045d

So, weld.faces-config.xml should be updated and remove the following

<lifecycle>
<phase-listener>org.jboss.weld.jsf.WeldPhaseListener</phase-listener>
</lifecycle>

Now, scene1 has OK! I will update the workaround.

Comment by Sanjeeb Sahoo [ 26/Mar/13 ]

Sorry, this didn't get due attention for 4.0.

Comment by TangYong [ 27/Mar/13 ]

Scene2 has been resolved and investigation result is as following,

While using primefaces 2.1 with CDI(Weld) in the sample(dummy-web.war), Scene2's exceptions will be caused by the following and caused the whole WAB's deployment failed.

Caused by: org.jboss.weld.exceptions.DefinitionException: Exception message for key UNABLE_TO_FIND_CONSTRUCTOR not found due to String index out of range: -1
at org.jboss.weld.util.Beans.getBeanConstructor(Beans.java:327)
....

[Analyze]
1 in primefaces 2.1, org.primefaces.context.PrimeExternalContextFactory does not offer a default or no-args constructor, so, in org.jboss.weld.util.Beans.getBeanConstructor method, "constructor" will be null, then, throwing a DefinitionException called "UNABLE_TO_FIND_CONSTRUCTOR" , thus, causing the above exception.

The exception also caused two bad results:
1) WebContainer.loadWebModule failed
2) WAB expanded failed

2 I investigated primefaces 2.x and 3.x and found an interesting thing as following:
In primefaces 3.x(eg. 3.5), org.primefaces.context.PrimeExternalContextFactory has not existed. So I made an experiment to replace primefaces-2.1.jar with primefaces-3.5.jar in the WAB's WEB-INF/lib. Then, after deploying the new WAB, the exceptions all did not happen. And can access "http://localhost:8080/dummy-web/" normally.

Only a issue is that while accessing "http://localhost:8080/dummy-web/", there are the following warning info:
"
Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace.
Warning: This page calls for XML namespace http://primefaces.prime.com.tr/ui declared with prefix p but no taglibrary exists for that namespace. "

The warning info is caused by [1]:
[1]: http://stackoverflow.com/questions/7565431/warning-this-page-calls-for-xml-namespace-http-primefaces-prime-com-tr-ui-dec

While modifying the sample's index.xhtml from xmlns="http://primefaces.prime.com.tr/ui" to xmlns="http://primefaces.org/ui" , although the warning has not disappeared, primefaces's tree tag was not still displayed normally. However, I think that this should be primefaces's using problems rather than gf's problems.

So, in a word, the Scene2 should belong to user's sample problem rather than gf's problem.

Thanks
--Tang





[GLASSFISH-6741] OSGi based EAR (all JARs are OSGi Bundles) deployment Created: 07/Nov/08  Updated: 13/Oct/12

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

Type: New Feature Priority: Major
Reporter: miro Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,741

 Description   

Hi,

One idea related with OSGi based EAR (all JARs are OSGi Bundles) deployment? If
you are interested I can start working on that idea?
For example the content in one OSGi based EAR file will be:
1. Core Java EE Application:
1.1. One or more EJB bundles. It is good all interfaces to be separated from
the implementation in different bundles.
1.2. One Web Application Bundle (JAR file)
1.3. One Java Web Start (JWS) Application Bundle (JAR file)
2. Libraries:
2.1. Zero or many libraries represented as bundles. For example Hibernate,
Apache, JDBC Drivers, etc.

It is good the Swing application (JWS) to be started in some OSGi Framework
which to retrive from the Server or another place signed Bundles (JARs). This
will require some changes in Java Network Launch Protocol (JNLP) because the 1st
action MUST be downloading of OSGi Framework (if this is a part of JDK7 then
this part will be skipped) and then to download and install all bundles from
which the main application bundles depends. As repository for bundles can be used:
1. The Server from where the application is started
2. Maven Repositories
3. OSGi Bundle Repository (OBR)

Regards,
Miro.



 Comments   
Comment by Hong Zhang [ 23/Mar/11 ]

assign to sahoo for initial evaluation

Comment by Sanjeeb Sahoo [ 23/Mar/11 ]

Will do this subsystem support is available in Felix

Comment by TangYong [ 13/Oct/12 ]

sahoo, what miro said is simlar to obr ondemand deployment, however, about osgi 5's subsytem, firstly, from david's blog[1], the Subsystems RI is being implemented in Apache Aries. If true, I have doubted whether felix will implement the important and complex feature or not. If felix will be not plan to implement it, whether we need to implement it self or not?

In addition, I have not found any info that felix will have a plan to implement the subsystem.

[1]: http://osgithoughts.blogspot.com/2012/06/osgi-enterprise-r5-specifications.html





[GLASSFISH-7086] Support passing of arguments to underlying JVM Created: 23/Jan/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 7,086

 Description   

When verifier is run on a large ear file (containing about 90 ejb modules)

verifier ear-file

it fails with

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

The exception seems to be generated when generating the reports. So I workted
around this by restricting the reports to failures only like:

verifier -rf ear-file



 Comments   
Comment by sekhar [ 23/Jan/09 ]

A way to pass JVM option to increase the heap size would be nice. Currently,
there seems to be no way to do this short of editing the verifier script in
<glassfish-install>/bin tree.

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

defect -> enhancement

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

Changed subject

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-7066] EJB3 bean silently not published if it inherits the Remote interface from a POJO Created: 19/Jan/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Attachments: GZip Archive BeanClassHierarchyTest.tar.gz    
Issuezilla Id: 7,066

 Description   

Consider the following scenario:

@Remote
public interface TheRealRemote {

String sayHello(String name);

}

public class SomeOrdinaryClassImplementingTheRealRemote implements TheRealRemote {

public String sayHello(String name)

{ return "Hello, " + name + "!"; }

}

@Stateless
public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote {

}

Using plain Glassfish v2 UR2 b04, the Verifier returns 0 failures, 0 warnings
and 0 errors for the EJB-JAR/EAR containing these classes. Deployment of the EAR
also seems to complete fine without any error messages.

However, the SLSB will not be properly deployed and its Remote interface not be
published into JNDI. Any attempts to call this bean will therefore fail.

But when we change TheRealBean to explicitly, but redundantly state that it
implements TheRealRemote:

@Stateless
public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote
implements TheRealRemote {

}

the SLSB deploys fine, its remote interface will be bound to JNDI and the bean
can successfully be called.

The error seems to be that some statical analysis on TheRealBean class fails to
detect that this class implements TheRealRemote indirectly, because it extends
another POJO class that implements it.

This issue has been found in a real-world customer application and was very hard
to debug due to the complete lack of any error messages other than the inability
to look up any Remote interfaces.

The attached NetBeans project contains the full source for a test case EAR.
Running the verifier on the EAR returns no errors, but TheRealRemote will not be
bound into JNDI after deployment. Then add the redundant "implements
TheRealRemote", and everything is fine.

Many thanks in advance for fixing this!



 Comments   
Comment by al130959 [ 19/Jan/09 ]

Created an attachment (id=2226)
Test case containing the scenario for issue #7066

Comment by Alexis MP [ 20/Jan/09 ]

adding myself to CC list

Comment by ksak [ 20/Jan/09 ]

Client views are not inherited through processing of super-classes. They can only be defined directly on
the bean class or through the deployment descriptor. This is an area that has been clarified in the 3.1
spec. See section 4.9.2.1 – Session Bean Superclasses. At best there could be some verifier warning,
though Changing category to verifier.

Comment by al130959 [ 20/Jan/09 ]

Still my question would be:

The EJB 3.0 spec did not make any statements regarding the need to explicitly
include superclass-implemented interfaces in its own interface list. If
implementing parent class interfaces this shall be explicitly handled and
required by the EJB 3.1 spec - then fine from the EJB container point of view.

But in this case I would at least require a mandatory message rejecting a
bean class that has been set up like in my example - it's definitely not a
nice-to have thing to have "at best"....

So please change the Verifier to reject my bean and point to this section for
the reason why - although it will be "interesting" to refuse deployment of an
EJB 3.0 SLSB due to restrictions only being raised for the first time in the EJB
3.1 spec...

Many thanks!

Andreas

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

As per conventions in verifier project, new assertions are classified as
enhancements. So, marking this issue as an enhancement.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-5385] Hide packages exported to be used by implementation modules Created: 26/Jul/08  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on GLASSFISH-6743 dataprovider.jar is not hidden from a... Resolved
Issuezilla Id: 5,385
Status Whiteboard:

v3_exclude

Tags: ee7ri_cleanup_deferred

 Description   

Add a mandatory directive in Export-Package for those packages that are only
supposed to be used by other implementation modules. Something like this:

Export-Package: com.sun.foo; mandatory:=GlassFish



 Comments   
Comment by Sanjeeb Sahoo [ 13/Aug/08 ]

The exact syntax looks like this:
Export-Package: com.sun.foo; private="true"; mandatory:=private

See section #3.6.5 of OSGi R4 spec.

Comment by kumara [ 19/Aug/08 ]

Add gfv3-prelude-include to status whiteboard

Comment by Sanjeeb Sahoo [ 20/Aug/08 ]

I have done it for org.apache.commons packages and asm packages. See:
http://fisheye4.atlassian.com/changelog/glassfish-svn/trunk/v3?cs=21885

Everyone needs to do the same for their modules in order to provide proper
isolation between applications and server run time.

Comment by Sanjeeb Sahoo [ 22/Aug/08 ]
      • Issue 5433 has been marked as a duplicate of this issue. ***
Comment by marina vatkina [ 28/Aug/08 ]

Fixed transaction/jta and transaction/jts:
http://fisheye4.atlassian.com/changelog/glassfish-svn/trunk?cs=22207.

Comment by Sanjeeb Sahoo [ 02/Sep/08 ]

Not a priority for prelude

Comment by kumara [ 24/Oct/08 ]

Reclassifying as P4 because these issues are not must fix for prelude release.
This issue will be scrubbed after prelude release and will be given the right
priority for v3 final release.

Comment by Sanjeeb Sahoo [ 10/Nov/08 ]

Fixed dependency. This is an umbrella bug.

Comment by kumara [ 30/Apr/09 ]

Remove excluded from status whiteboard. And back to P3.

Comment by Sanjeeb Sahoo [ 17/Sep/09 ]

Not many module owners have done it; in fact, only tx module has been fixed.
Marking it as v3_exclude.

Comment by kumara [ 07/Dec/09 ]

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 Sanjeeb Sahoo [ 12/Oct/10 ]

Will try to address this in 3.2

Comment by Sanjeeb Sahoo [ 12/Oct/10 ]

3.1-exclude

Comment by Tom Mueller [ 18/Oct/12 ]

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





[GLASSFISH-12275] Support Hibernate in OSGI EJB bundle Created: 16/Jun/10  Updated: 29/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: cameronr Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?threadID=150224


Issuezilla Id: 12,275

 Description   

As discussed on the forums
(http://forums.java.net/jive/thread.jspa?threadID=150224) the OSGI-JPA extension
for glassfish should provide support for Hibernate.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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 [ 13/Oct/12 ]

above link seemed to have been invalid, should be:

http://www.java.net/node/704186?force=952, sahoo has made an important reply at that time:

" think I know why it is not working. The osgi/jpa module is making a strong assumption about eclipselink. I need to make it extensible to support other persistence providers. "

Comment by TangYong [ 29/Nov/12 ]

Sahoo ever discussed hibernate enhance way[1] with Hibernate team, and it seemed that hibernate enhance has a litter complex and needs to investigate in depth.

[1]: https://forum.hibernate.org/viewtopic.php?f=1&t=1003355&start=0





[GLASSFISH-12276] Allow users to override system supplied META-INF/services files Created: 17/Jun/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: classloader
Affects Version/s: 3.1
Fix Version/s: not determined

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

Operating System: All
Platform: All


Issuezilla Id: 12,276

 Description   

Invert delegation while searching for META-INF/services file to will allow users
to override system supplied META-INF/services files.



 Comments   
Comment by sandoz [ 17/Jun/10 ]

And ensure that this works with GlassFish embedded?

I recently found out that my temporary hack i implemented for Jersey does work
with GF embedded

Comment by sandoz [ 17/Jun/10 ]

I meant to say:

"I recently found out that my temporary hack i implemented for Jersey does
not work with GF embedded "

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-12461] Need EJB and Web Extenders be synchronous bundle listeners? Created: 02/Jul/10  Updated: 18/Oct/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 12,461
Tags: ee7ri_cleanup_deferred

 Description   

I think it can be asynchronous listener?



 Comments   
Comment by Sanjeeb Sahoo [ 26/Aug/10 ]

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -m "Issue 12461: Make Web
and Ejb extenders asynchronous bundle event listeners. They need not be
synchronous event listeners because of the simple fact that an extender can come
into exeistence after the application bundle is READY."
osgi-javaee/osgi-ejb-container/src/main/java/org/glassfish/osgiejb/EJBExtender.java
osgi-javaee/osgi-web-container/src/main/java/org/glassfish/osgiweb/WebExtender.java
Sending
osgi-javaee/osgi-ejb-container/src/main/java/org/glassfish/osgiejb/EJBExtender.java
Sending
osgi-javaee/osgi-web-container/src/main/java/org/glassfish/osgiweb/WebExtender.java
Transmitting file data ..
Committed revision 40145.

Comment by Sanjeeb Sahoo [ 27/Oct/10 ]

I am going to revert my earlier check-in that made the extenders asynchronous
bundle event listeners as that causes a regression for bundles with lazy
activation policy. Currently, we rely on LAZY_ACTIVATION event and that's
delivered to synchronous event listeners only. I will keep this bug open as an
enhancement as I think we should be able to avoid using listeners altogether in
favour of BundleTracker.

Sending
osgi-javaee/osgi-javaee-base/src/main/java/org/glassfish/osgijavaeebase/JavaEEExtender.java
Transmitting file data .
Committed revision 42242.

Comment by Tom Mueller [ 18/Oct/12 ]

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





[GLASSFISH-12988] Guidance on Standalone EJB Server Created: 15/Aug/10  Updated: 08/Mar/12

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: v3.0.1
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: glassfisher Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,988

 Description   

Standalone EJB Server would be beneficial to host application entirely
consituted by EJBs. Some JEE AS providers already have this capacity.

Since GlassFish server is OSGi ready,
option 1) GlassFish can supply with the guidance on how to utilize subset of
GlassFish server modules for creation of standalone EJB server - What OSGi
bundles should remain but others be waived dynamically.
option 2) GlassFish can purposefully add a subcommand to asadmin utility for
dynamic creation of standalone EJB server.
option 3) GlassFish can be chosen to create static standalone EJB Server during
installation.

Origin: http://forums.java.net/jive/message.jspa?messageID=480097#480097



 Comments   
Comment by glassfisher [ 16/Aug/10 ]

option 4) GlassFish can be packed as neo GlassFish EJB Profile for distribution.

Comment by marina vatkina [ 16/Aug/10 ]

-> Sahoo

Comment by Sanjeeb Sahoo [ 16/Aug/10 ]

Marina,

OSGi-JavaEE is not the appropriate subcat for this RFE. I am happy to extend my
support for implementation of this feature. The first and foremost requirement
for addressing this RFE is to identify the set of bundles necessary for EJB
container to run. That is something EJB team has to come up with. My guess is
the set should contain nucleus + common javaee bundles + ejb-container
dependencies. To try out, keep these bundles in modules, delete everything else
and start server.

Sahoo

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-8521] stop-domain should stop OSGi framework if start-domain has started it Created: 14/Jun/09  Updated: 05/Apr/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: V3
Fix Version/s: future release

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

Operating System: All
Platform: Sun


Issuezilla Id: 8,521

 Description   

Currenty, stop-domain command does not stop OSGi framework. It only stops the
primordial bundle, but that can't stop bundles started outside the knowledge of
GF management agent. e.g., bundles in autodeploy-bundles/ which are managed by
fileinstall. SO, we must stop framework when we own it. Stopping framework will
ensure stopping of all bundles.



 Comments   
Comment by Sanjeeb Sahoo [ 24/Sep/09 ]

It's an RFE.

Comment by Tom Mueller [ 25/Jan/11 ]

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

Comment by Tom Mueller [ 05/Apr/11 ]

A fix for this issue was initially identified for possible inclusion in the 3.2 release, but after further 3.2 planning, the feature or improvement did not make the cut. This issue is being targeted for a future release. If based on a reevaluation, it is targeted for 3.2, then update the "fix version" again.





[GLASSFISH-12844] Session Persistence Feature for WAB Created: 30/Jul/10  Updated: 06/Mar/12

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

Type: New Feature Priority: Major
Reporter: casmeiron Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows 7
Platform: All


Attachments: File simple-cdi-osgi-test-1.0.war    
Issuezilla Id: 12,844

 Description   

In the latest version of glassfish v3.1 I notice that the session for WAB isn't
persisted, whether I redeploy my WAB the session is destroyed and that's bad for
the development process and even to the production environment. If I have a multi-
module apps, I don't want to session be recreated whether I redeploy one of the
modules.

I don't know if thats better as a configuration or default behavior but it's
important to have it somehow.

I'm goin' to attach the test case.



 Comments   
Comment by casmeiron [ 30/Jul/10 ]

Created an attachment (id=4616)
Every time you redeploy you gonna get a different object (as it has SessionScoped ann that proves the session persistence feature doesn't exist)

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-9335] Need a hook in application class loader to find resources not exported by OSGi bundles Created: 01/Sep/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 9,335

 Description   

See issue #8426 [1] for a background. Ideally, some kind of extender should have
been used by JAF, but we didn't want to change JAF. We addressed that issue by
adding some code in "Public API Class Loader" to look for META-INF/mailcap in
all the installed OSGi bundles. We already have similar code for
META-INF/services files.

Recently, in an email conversation with Bill, this issue again came up. Clearly
the current code is not very extensible. A few possibilities came up during the
discussion. They are listed below. The objective of this RFE is to find a proper
solution for this issue.

Option #1 - Make the resource finding logic configurable via a system property:
This is similar to bootdelegation property in OSGi. We can define a property like:
org.glassfish.appclassloader.resourcedelegation ::= path-description ( ','
path-description )*
path-description::= path-name | ( path-name '/' ) | ''

The /* wildcard means deep matching. e.g., META-INF/* would match all resources
starting with META-INF/.

Then, we can configure the property as META-INF/mailcap, META-INF/services/* to
mimic the current behavior.

Option #2 - Have some extra metadata to indicate what resources are exported:
Since most of the resources have a package name of META-INF, standard
export/import metadata of OSGi is not good enough. So, we can define some extra
metadata that bundle developers can use to tell us what resources they want to
make available to applications.

[1] https://glassfish.dev.java.net/issues/show_bug.cgi?id=8426



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-9165] Application bundling Jersey 1.0 is forced to use GF's copy of Jersey Created: 18/Aug/09  Updated: 07/Jan/13

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

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

Operating System: All
Platform: All


Attachments: Text File artifactory-delegate-false.txt     Text File artifactory-delegate-true.txt     Zip Archive mavenproject5.zip    
Issuezilla Id: 9,165

 Description   

Dropping the artifactory.war [1] in v3's autodeploy directory triggers the following scan error documented at http://forums.java.net/jive/thread.jspa?
messageID=360993.

This is a case of an application being forced to use Jersey 1.1 bundled in GlassFish v3 instead of the 1.0 library that it ships with.
Even with class loader delegation set to false Jersey 1.0 will look in META-INF/services of jersey installed in GF.

Of course it would be nice to have Jersey 1.0 apps run unmodified on 1.1 but only strict adherence to the JAX-RS specification offers compatibility
between 1.0 and 1.1 releases.

Removing jersey from the GFv3 distro sounds like a bad solution (glassfish-management depends on it).

An application should be able to ship and use its own set of libraries with some sort of "ignore system/GlassFish libraries" isolation at deploy time.

[1]: http://downloads.sourceforge.net/project/artifactory/artifactory/2.0/artifactory-2.0.7.war



 Comments   
Comment by Alexis MP [ 18/Aug/09 ]

adding Sahoo to CC list

Comment by Sanjeeb Sahoo [ 19/Aug/09 ]

Alexis,

It is kind of strange that jersey 1.1 is not compatible with 1.0. Anyway, that's
a separate issue altogether. But, it is a bit too much to expect that a
traditional Java EE application can override a server implementation module by
just including it in itself. Given all the spec requirements and implementation
challenge, it is quite impossible to support this.

On the other hand, these are the kind of things I expect an OSGi enabled
application [1] to be able to solve. Skip the step of downloading an extra jar
and copying it to autodeploy-bundles directory, as osgi-web-container.jar is now
part of modules/. So, I gave try like this:
$ start GlassFish
$ telnet localhost 6666
-> install webbundle:file:///tmp/artifactory-2.0.7.war
-> start 205 (where 205 is the bundle id reported by install command)

I am seeing an exception like this:
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor#0'
defined in class path resource [META-INF/spring/applicationContext.xml]: Cannot
resolve reference to bean 'txInterceptor' while setting bean property
'transactionInterceptor'; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'txInterceptor' defined in class path resource
[META-INF/spring/applicationContext.xml]: Cannot resolve reference to bean
'transactionManager' while setting bean property 'transactionManager'; nested
exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No
bean named 'transactionManager' is defined

I don't know enough about Spring to debug further. When does this error occur?
Can the submitter try it out and explain what's going wrong.

May be we need a simpler test case that just bundles jersey-1.0 jar and first
see if it can be handled or not.

Sahoo

[1] http://weblogs.java.net/blog/ss141213/archive/2009/06/osgi_enabled_we.html

Comment by sandoz [ 19/Aug/09 ]

Jersey's implementation of JAX-RS 1.1 is backwards compatible with 1.0. So if
you just depend on JAX-RS 1.0 features the same app should work with JAX-RS 1.1
(a long as you do not have both 1.0 and 1.1 JAX-RS implementations in the class
path!). I do agree that the version naming is confusing because we currently
include the JAX-RS version as the major/minor Jersey version.

I suspect the Spring-related error is due to class loading restrictions.

I agree with you about OSGi. Note that we do plan to make jersey fully
OSGi-enabled, i am not sure if that will help or not in this case.

A simpler test case would be most useful to verify it is works, we could use the
following sample:

http://download.java.net/maven/2/com/sun/jersey/samples/helloworld-webapp/1.0.3.1/helloworld-webapp-1.0.3.1-project.zip

when built there will be a war with the Jersey 1.0.3.1 jars present in WEB-INF/lib.

Comment by Sanjeeb Sahoo [ 19/Aug/09 ]

sandoz:
If jersey 1.1 is both a jersey 1.0 and 1.1 implementation, then why does things
not work if you just deploy a web app even if it bundles jersey-1.0.jar inside
it. After all, jersey-1.1.jar, which is provided by the server, should shadow
the bundled version and there is no need to even switch of classloader
delegation. I guess, I am missing something. What it is.

alexismp:
Do you know anything about the Spring framework error that I observed?

sandoz:
I tried using the simple test case you pointed to. I got the following error:
java.lang.NoSuchMethodError:
com.sun.jersey.server.impl.container.servlet.JSPTemplateProcessor.<init>(Lcom/sun/jersey/api/core/ResourceConfig;Ljava/lang/ThreadLocal;Ljava/lang/ThreadLocal;)V
at
com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:414)
at
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:235)
at
com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:448)
at
com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:169)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:281)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:442)
at javax.servlet.GenericServlet.init(GenericServlet.java:242)
...

What does this mean? I don't have the time to debug it, so I am asking you. May
be you know if this bundle is seeing some class incorrectly. May be we need to
adjust the OSGi metadata of the bundle as opposed to relying on the metadata
generated by the server. So, try adding OSGi metadata to the war file depending
on what this bundle imports/exports and see how it goes.

Sahoo

Comment by Alexis MP [ 19/Aug/09 ]

Sorry, my Spring knowledge is too limited. Class-loader visibility seems like the most likely cause.
Maybe repackaging the application to use Spring DM (the OSGi version of the Spring framework) would
help but that's beyond what would be a reasonable solution to the problem.

Comment by sandoz [ 19/Aug/09 ]

Jersey 1.1.x supports JAX-RS 1.0 and 1.1. Jersey currently does guarantee to
support two different versions of Jersey in the same VM unless they are fully
isolated by some external mechanism.

The main problem is that Jersey loads components declared in META-INF/service
files. Those files will be present in multiple jersey jars/modules of the same
version.

When two versions of Jersey, 1.0 and 1.1.0 say, are present, the version of
Jersey that gets initiated, say 1.0, will also attempt to load components
declared by 1.1.0 jars because of the way Classloader.getResources works.

Re the Spring exception: can you attach the full exception log, if any more, to
know what caused the NoSuchBeanDefinitionException.

Re the NoSuchMethodError: the error indicates that the JSPTemplateProcessor
class is being loaded from the Jersey version distributed with GF and not Jersey
version distributed in the war.

The relevant code in 1.0.3.1 is:

rc.getSingletons().add(new JSPTemplateProcessor(
resourceConfig,
requestInvoker.getThreadLocal(),
responseInvoker.getThreadLocal()));

public class JSPTemplateProcessor implements TemplateProcessor {
@Context HttpContext hc;

@Context ServletContext servletContext;

@Context UriInfo ui;

private final ThreadLocal<HttpServletRequest> requestInvoker;

private final ThreadLocal<HttpServletResponse> responseInvoker;

private final String basePath;

public JSPTemplateProcessor(
ResourceConfig resourceConfig,
ThreadLocal<HttpServletRequest> requestInvoker,
ThreadLocal<HttpServletResponse> responseInvoker) {

The JSPTemplateProcessor in Jersey 1.1.x is:

public class JSPTemplateProcessor implements TemplateProcessor {
private @Context HttpContext hc;

private @Context ServletContext servletContext;

private @Context ThreadLocal<HttpServletRequest> requestInvoker;

private @Context ThreadLocal<HttpServletResponse> responseInvoker;

private final String basePath;

public JSPTemplateProcessor(
@Context ResourceConfig resourceConfig) {

Note that the sample i pointed you to is not an OSGi-based sample, it will just
create a vanilla war file with jersey 1.0.3.1 jars included in the WEB-INF/lib.

My OSGi knowledge is very limited and Jakub (our resident Jersey expert is on
holiday this week) so i really do not know where to start.

Comment by Sanjeeb Sahoo [ 19/Aug/09 ]

sandoz:
In the case of traditional war, jersey-1.1 is higher up in the classloader
hierarchy, so why does jersey-1.0 get initiated in the first place?

Yes, later on when I looked at jersey-gf-bundle.jar, I realized that
JSPTemplateProcessor was getting picked up from jersey-1.1 implementation. That
leads me to think this class is exported by jersey-gf-bundle. Why? Is it not an
implementation artifact?

I think we should wait for Jakub to be back and then may be he needs to look at
two things:
1. OSGi metadata of Jersey bundle.
2. OSGi metadata of the test bundle to be able to use a bundled jersey
implementation.

Sahoo

Comment by sandoz [ 19/Aug/09 ]

The example i presented would apply for <class-loader delegate="false"/>.

However, the problem would still occur for <class-loader delegate="true"/> would
it not when the following applies?

When two versions of Jersey, 1.0 and 1.1.0 say, are present, the version of
Jersey that gets initiated, say 1.1.0, will also attempt to load components
declared by 1.0 jars because of the way Classloader.getResources works.

Comment by Sanjeeb Sahoo [ 19/Aug/09 ]

OK, I understand why things won't work when delegate=false.

When delegate=true, what is the problem with ClassLoader.getResources. It would
return META-INF/services found in both 1.1 and 1.0 jar, but 1.1 ones would be
ahead of 1.0 ones in the enumeration. How do you select a particular one?
Actually, does the code call getResources or getResource? getResource should
only return 1.1 resource.

Sahoo

Comment by sandoz [ 19/Aug/09 ]

For certain services Jersey selects all classes registered. It then tries to
instantiate them and ignore ones it cannot, reporting the instantiation errors,
and continues processing (a "keep on trucking" strategy).

Alexis said that for class loader <class-loader delegate="false"/> other errors
occurred but i do not know what they were. Alexis?
It is likely that Jersey 1.0 may not be as robust in ignoring certain errors
when attempting to instantiate components. Perhaps a move to Jersey 1.0.3.1 may
help?

Note that a META-INF/services file in say Jersey 1.0 may refer to a class that
still exists in say Jersey 1.1.x but that class is now abstract and is not
referred to in the META-INF/services file of Jersey 1.1.x. And, if course,
similar occurrences are possible if Jersey 1.1.x is loaded before Jersey 1.0.
Errors will be reported and processing will continue but it confuses the heck
out of developers because the situation i described has actually occurred
between 1.1.0 and 1.1.1 and we got some bemused questions.

The issue with including successfully instantiated components from different
versions is that there could be some subtle errors introduced. JAX-RS/Jersey
attempts to ensure that components registered before other components that
intersect in terms of "functionality" have priority. But, i cannot say for sure
whether some really subtle issues may result in the future e.g. an old component
get registered and instantiated successfully that is no longer relevant but yet
causes functional change.

All in all META-INF/services is a PITA! and is not suitable for a version-based
runtime module system where two or more versions of may co-exist in the same VM.

Perhaps we need a way to say in the sun-web.xml "please do include modules X, Y
and Z" in the classpath or a way to declare OSGi dependencies in the sun-web.xml
or at deployment (so the war does not require modification).

Comment by Alexis MP [ 19/Aug/09 ]

sandoz said:
> Alexis said that for class loader <class-loader delegate="false"/> other errors occurred but i do not know what they were. Alexis?

Let me attach files to this case with the full logs for both cases (class-loader delegate set to true or false).
With <class-loader delegate="false"/>, here's the stacktrace :

com.sun.jersey.spi.service.ServiceConfigurationError: com.sun.jersey.spi.HeaderDelegateProvider: The class
com.sun.jersey.core.impl.provider.header.LocaleProvider implementing provider interface com.sun.jersey.spi.HeaderDelegateProvider could not
be instantiated: null
at com.sun.jersey.spi.service.ServiceFinder.fail(ServiceFinder.java:413)
at com.sun.jersey.spi.service.ServiceFinder.access$600(ServiceFinder.java:146)
at com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator.hasNext(ServiceFinder.java:707)
at com.sun.jersey.impl.provider.RuntimeDelegateImpl.<init>(RuntimeDelegateImpl.java:79)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at javax.ws.rs.ext.FactoryFinder.newInstance(FactoryFinder.java:65)
at javax.ws.rs.ext.FactoryFinder.find(FactoryFinder.java:117)
at javax.ws.rs.ext.RuntimeDelegate.findDelegate(RuntimeDelegate.java:105)
at javax.ws.rs.ext.RuntimeDelegate.getInstance(RuntimeDelegate.java:91)
at javax.ws.rs.core.EntityTag.<clinit>(EntityTag.java:35)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at $Proxy156.<clinit>(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:588)
at com.sun.jersey.impl.application.WebApplicationImpl.createProxy(WebApplicationImpl.java:953)
at com.sun.jersey.impl.application.WebApplicationImpl.<init>(WebApplicationImpl.java:199)
at com.sun.jersey.impl.container.WebApplicationProviderImpl.createWebApplication(WebApplicationProviderImpl.java:52)
at com.sun.jersey.spi.container.WebApplicationFactory.createWebApplication(WebApplicationFactory.java:63)
at com.sun.jersey.spi.container.servlet.ServletContainer.create(ServletContainer.java:548)
at com.sun.jersey.spi.container.servlet.ServletContainer.load(ServletContainer.java:536)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:197)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1410)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1213)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4941)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5296)
at com.sun.enterprise.web.WebModule.start(WebModule.java:509)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:928)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:694)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1796)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1485)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:93)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:223)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:193)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:295)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:175)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:270)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:427)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:437)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:524)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:157)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:121)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:529)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:415)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:347)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:332)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:200)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.lang.ClassCastException
at java.lang.Class.cast(Class.java:2990)
at com.sun.jersey.spi.service.ServiceFinder$LazyObjectIterator.hasNext(ServiceFinder.java:665)
... 56 more

Comment by sandoz [ 19/Aug/09 ]

I have just tried deploying 1.0 and 1.0.3.1 helloworld web app samples on GF v3
build 59:

http://download.java.net/maven/2/com/sun/jersey/samples/helloworld-webapp/1.0/helloworld-webapp-1.0-project.zip

http://download.java.net/maven/2/com/sun/jersey/samples/helloworld-webapp/1.0.3.1/helloworld-webapp-1.0.3.1-project.zip

I do not get the same error from within initiation of the JAX-RS RuntimeDelegate.

For 1.0.3.1 i get the following error:

java.lang.ClassCastException
at java.lang.Class.cast(Class.java:2990)
at
com.sun.jersey.core.spi.component.ProviderServices.getProvidersAndServices(ProviderServices.java:122)
at
com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderFactory.init(StringReaderFactory.java:57)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:597)
at
com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:414)
at
com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:377)
at
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:242)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:449)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:169)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:281)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:442)
at javax.servlet.GenericServlet.init(GenericServlet.java:242)

The error is occuring when Jersey 1.0.3.1 is finding and instantiating instances
of StringReaderProvider implementatons registered in
META-INF/services/com.sun.jersey.spi.StringReaderProvider.

The following classes are registered in 1.0.3.1:

com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$TypeValueOf
com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$StringConstructor
com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$DateProvider
com.sun.jersey.server.impl.model.parameter.multivalued.JAXBStringReaderProviders$RootElementProvider

The following classes are registered in 1.1.1-ea:

com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$TypeFromStringEnum
com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$TypeValueOf
com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$TypeFromString
com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$StringConstructor
com.sun.jersey.server.impl.model.parameter.multivalued.StringReaderProviders$DateProvider
com.sun.jersey.server.impl.model.parameter.multivalued.JAXBStringReaderProviders$RootElementProvider

I think i can explain this behaviour as follows;

1) When 1.0.3.1 loads a class from a META-INF/services file that is present in
1.0.3.1 it uses class loader, A say.

2) When 1.0.3.1 loads a class from a META-INF/services file that is only
present in 1.1.1-ea it uses class loader, B say.

Class loader A and B will load two different Class instances of
StringReaderProvider, hence the class cast exception: a sub-class of
StringReaderProvider loaded by class loader B cannot be cast to the class of
StringReaderProvder loaded by class loader A.

I think this just re-enforces the requirement to correctly isolate the web app
using an appropriate feature of GF.

Comment by sandoz [ 19/Aug/09 ]

I forgot to state i deployed the samples using <class-loader delegate="false"/>.

Comment by Alexis MP [ 19/Aug/09 ]

Created an attachment (id=3108)
Log for artifactory deployment with class-loader delegate set to "true"

Comment by Alexis MP [ 19/Aug/09 ]

Created an attachment (id=3109)
Log for artifactory deployment with class-loader delegate set to "false"

Comment by sandoz [ 20/Aug/09 ]

1.0 META-INF/services/com.sun.jersey.spi.HeaderDelegateProvider

com.sun.jersey.impl.provider.header.LocaleProvider
com.sun.jersey.impl.provider.header.EntityTagProvider
com.sun.jersey.impl.provider.header.MediaTypeProvider
com.sun.jersey.impl.provider.header.CacheControlProvider
com.sun.jersey.impl.provider.header.NewCookieProvider
com.sun.jersey.impl.provider.header.CookieProvider
com.sun.jersey.impl.provider.header.URIProvider
com.sun.jersey.impl.provider.header.DateProvider
com.sun.jersey.impl.provider.header.StringProvider

1.1.1-ea META-INF/services/com.sun.jersey.spi.HeaderDelegateProvider

com.sun.jersey.core.impl.provider.header.LocaleProvider
com.sun.jersey.core.impl.provider.header.EntityTagProvider
com.sun.jersey.core.impl.provider.header.MediaTypeProvider
com.sun.jersey.core.impl.provider.header.CacheControlProvider
com.sun.jersey.core.impl.provider.header.NewCookieProvider
com.sun.jersey.core.impl.provider.header.CookieProvider
com.sun.jersey.core.impl.provider.header.URIProvider
com.sun.jersey.core.impl.provider.header.DateProvider
com.sun.jersey.core.impl.provider.header.StringProvider

Note that Jersey 1.0 is attempting to instantiate an instance of
"com.sun.jersey.core.impl.provider.header.LocaleProvider" that is declared in
Jersey 1.1.1-ea.

It is the same error that i described previously with StringReaderProvider. In
this case two different Class instances of HeaderDelegateProvider are created by
two different class loaders.

Comment by Jakub Podlesak [ 02/Sep/09 ]

Sahoo: could you please explain a bit, what
install webbundle:file:///tmp/artifactory-2.0.7.war
should do. The jersey jars bundled in the war do not contain any OSGi headers,
and also the jersey (OSGified) jars installed into GlassFish are missing any
version information. How is this supposed to work?

Comment by Sanjeeb Sahoo [ 02/Sep/09 ]

japod:
When you run
install webbundle:file:///tmp/artifactory-2.0.7.war
there is a built in URL handler in the server which will try to add some OSGi
metadata to the war file and the modified war file is installed in the OSGi
framework. You can configure the OSGi metadata by use of URL query parameters.
To see the default OSGi metadata that's generated, perform the above step and
see the OSGi metadata using "headers [bundle-id]" command.

To all:
I think it will help to have a conference call to understand why things don't
work wih the original war file with classloader delegation=true. I am still not
clear despite all the explanations provided by Paul.

Comment by sandoz [ 03/Sep/09 ]

Created an attachment (id=3165)
Simple web-based project reproducing the issues

Comment by sandoz [ 03/Sep/09 ]

I have attached a simple project that shows the cause of the problem and
hopefully that will help in understanding what is going on.

It loads service classes from

META-INF/services/com.sun.jersey.spi.HeaderDelegateProvider

and prints information from each entry like this, when a class is loaded from
the service file present in the war:

Class com.sun.jersey.impl.provider.header.LocaleProvider is assignable to
interface com.sun.jersey.spi.HeaderDelegateProvider
FIND: com.sun.jersey.spi.HeaderDelegateProvider
com/sun/jersey/spi/HeaderDelegateProvider.class
Class loader of class

jar:file:/Users/paulsandoz/Applications/GlassFish/glassfish-v3-preview-b61/glassfishv3/glassfish/domains/domain1/applications/mavenproject5/WEB-INF/lib/jersey-core-1.0.jar!/com/sun/jersey/spi/HeaderDelegateProvider.class
Context class loader

jar:file:/Users/paulsandoz/Applications/GlassFish/glassfish-v3-preview-b61/glassfishv3/glassfish/domains/domain1/applications/mavenproject5/WEB-INF/lib/jersey-core-1.0.jar!/com/sun/jersey/spi/Header

and:

Class com.sun.jersey.core.impl.provider.header.LocaleProvider is NOT assignable
to interface com.sun.jersey.spi.HeaderDelegateProvider
FIND: com.sun.jersey.spi.HeaderDelegateProvider
com/sun/jersey/spi/HeaderDelegateProvider.class
Class loader of class
bundle://6.0:1/com/sun/jersey/spi/HeaderDelegateProvider.class
Context class loader

jar:file:/Users/paulsandoz/Applications/GlassFish/glassfish-v3-preview-b61/glassfishv3/glassfish/domains/domain1/applications/mavenproject5/WEB-INF/lib/jersey-core-1.0.jar!/com/sun/jersey/spi/HeaderDelegateProvider.class

Notice that this shows that two HeaderDelegateProvider classes have been loaded,
one from the jar in the war, and one from GF.

Comment by sandoz [ 03/Sep/09 ]

Note that i forgot to add that i could fix for future releases by performing
isAssignable checks at appropriate places in Jersey's ServiceFinder. This, of
course, is not something that is immediately obvious to do unless one has some
hindsight

However, this may just result in pushing errors somewhere else. What we really
require is a way to isolate the web applications from certain modules
distributed with GF.

Comment by Sanjeeb Sahoo [ 03/Sep/09 ]

OK, I looked at your simplified test case. What you are seeing is a direct
result of switching of classloader delegation by setting delagation=false in
sun-web.xml. I have said this before, I understand why things won't work as
expected when delegation is switched off. Switching off delegation must be a
developer's last resort, as it can lead to all kinds of class constraint
violations.

Run your simple test case with delegation=true (this is the default value) and
tell me what you see. Do you see two versions of
com.sun.jersey.spi.HeaderDelegateProvider.class?

Comment by sandoz [ 03/Sep/09 ]

Class loader delegation set to true works, but... I feel we may be going around
in circles

The war depends Jersey 1.0 APIs in Jersey 1.0 jars to function correctly,
which is why class loader delegation was set to false, so that the Jersey 1.0
jars take precedence.

The war depends on the Jersey Spring integration. Which is why when class loader
delegation is set to true for the war the following exception is thrown:

SEVERE: WebModule[/artifactory]StandardWrapper.Throwable
java.lang.NoSuchMethodError:
com.sun.jersey.spi.container.WebApplication.initiate(Lcom/sun/jersey/api/core/ResourceConfig;Lcom/sun/jersey/spi/service/ComponentProvider;)V
at
org.artifactory.rest.servlet.ArtifactoryRestServlet.initiate(ArtifactoryRestServlet.java:51)
at
com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:242)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:455)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:178)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:281)
at
com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:442)
at javax.servlet.GenericServlet.init(GenericServlet.java:242)

(See the attachment that Alexis added).

The ArtifactoryRestServlet is extending the Jersey 1.0 ServletContainer, but in
Jersey 1.1.x the ServletContainer class has changed.

The only way this war will work on GF is if:

1) Jersey in GF is removed; or

2) They developers upgrade their app to the same version as in GF.

I fear are going to run into this issue again and again when GF is released
and potentialy in the future as well, if refactoring of service impl classes
occurs in later versions.

Unfortunately this the Java equivalent of DLL hell. Again, we need a way of
cleanly isolating web app deployments.

Comment by dochez [ 25/Sep/09 ]

providing a complete application isolation is not a supported feature of V3, public libraries should not
break public APIs during a .dot release. We should provide a solution for this problem in the next release.

Comment by Tom Mueller [ 06/Mar/12 ]

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 Tom Mueller [ 07/Jan/13 ]

Assigning to the classloader component for evaluation.





[GLASSFISH-8793] improve common serialization code to handle osgi bundle changes Created: 21/Jul/09  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 3.1
Fix Version/s: future release

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 8,793
Status Whiteboard:

v3_exclude

Tags: ee7ri_cleanup_deferred

 Description   

A number of container services (SFSB passivation / HTTP Session storing) require serializing objects to a
persistent store where the object mays be deserialized into a different JVM. Special osgi-aware logic is
needed in order to correctly handle the mapping of serialized classes to their respective osgi bundle. The
current logic assumes static bundle ids. This needs to be improved in order to handle the case where
modules are added or removed in between the serialization and deserialization.



 Comments   
Comment by Sanjeeb Sahoo [ 23/Sep/09 ]

We no longer flush the OSGi cache after a module is added or removed, so bundle
id remains unchanged. SO, I don't see the priority to make this improvement now.
Can we exclude this from v3 release? Ken, please change priority if you agree.

Comment by ksak [ 24/Sep/09 ]

So for the lifetime of a particular V3 installation the bundle id won't change? If that's true, then we can
close this.

For future reference, will that also be the case for a clustered version of V3? I assume in that case the
OSGI bundle adds/changes/deletions will be applied in a way that is uniform across the cluster such that
the bundle ids will match across server instances?

Comment by Sanjeeb Sahoo [ 24/Sep/09 ]

Ken,

That's not true. This bug is still relevant. Bundle id changes any time user
deletes osgi cache. It's just that, we no longer delete the cache anytime we
add/delete/update a bundle.

Bundle id is different across instances in a cluster as well.

Sahoo

Comment by ksak [ 24/Sep/09 ]

OK, sounds like it's safe enough to defer this to V3.1. It would be better behavior for a stand-alone
instance and we'll definitely need it for the cluster case. Thanks.

Comment by Sanjeeb Sahoo [ 24/Sep/09 ]

v3_exclude. For some reason, this bug shows up in v3 bug list.

Comment by Sanjeeb Sahoo [ 12/Oct/10 ]

target 3.2

Comment by Sanjeeb Sahoo [ 12/Oct/10 ]

3.1-exclude

Comment by Tom Mueller [ 18/Oct/12 ]

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





[GLASSFISH-7574] Each subsystem should have its own framework extension bundle Created: 10/Apr/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 7,574

 Description   

Earlier, we were using org.osgi.framework.system.packages variable to export
JDK packages that included both internal as well as standard packages. As the
standard package list does not change that often, it is OK to use the property
to export standard packages, but using it to export internal JDK APIs is
problematic. Different GF bundles depend on different set of internal JDK APIs.
So, relying on a single property becomes a bottleneck. Hence the idea is to
use framework extension bundle. For the time being, I have moved all the extra
packages to a single extension bundle called glassfish-extra-system-packages.
In future, we should break that into multiple bundles. e.g., one can be
supplied by security subsystem, one by metro, one by web container, another by
corba, etc. So, I am filing this umbrella task to achieve this.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-10891] [rfc 66] Hybrid web app's bundle-activator should run in web app's context Created: 08/Nov/09  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 10,891

 Description   

Bundle-Activator of a hybrid web app should run in webapp's context.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-11611] ejb-jar shared by different applications Created: 25/Feb/10  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: classloader
Affects Version/s: 3.1
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: felipegaucho Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,611

 Description   

— Scenario:

  • an ejb-jar containning the code related to a JPA persistence layer.
  • two (or more) web-applications that depends on the above ejb-jar.

— Today solution:

None, people need to invent alternative solutions like to deploy the ejb-jar in
the Glassfish lib folder or to re-pack the ejb-jar in each of the differente
applications. The former solution open a security breach and the latter forces a
complicated synchronization between the deployment artifacts every time the
persistence layer is modified.

People also reported problems using Hibernate with the ejb-jar shared through
the Glassfish lib folder. Since a Stateless session bean is already loaded in
one classloader, Glassfish throws exceptions if a second application tries to
load the same EJB.

— Proposed feature:

Glassfish should support the deployment of ejb-jar as "sharable resource",
including security management on what application can access the resource and
managing the classloader issues related to such feature.



 Comments   
Comment by rodgarcialima [ 25/Feb/10 ]
      • Issue 11611 has been confirmed by votes. ***
Comment by vladperl [ 25/Feb/10 ]

There are plenty cases when the deployment of ejb-jar as "sharable resource" make
perfect sense.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-11700] OSGi web app is always deployed to the default virtual server. Created: 18/Mar/10  Updated: 06/Mar/12

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

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

Operating System: Linux
Platform: Linux


Issuezilla Id: 11,700

 Description   

How i can pin one of my OSGI webapp to virtualhost?

i`m trying to use GF 3.1 trunk.

I`m deploying my bundle to server with command
"./bin/asadmin deploy --force=true --virtualservers cp.bill --type osgi
ControlPanel-0.0.2.jar"
Deploy is ok. Application startup ok and deploys with context root = "/".
In domain.xml i have application declaration
<application
location="$

{com.sun.aas.instanceRootURI}

/applications/ControlPanel-0.0.2/"
name="ControlPanel-0.0.2" object-type="user">
<property name="module-name" value="ControlPanel-0.0.2" />
<property name="defaultAppName" value="ControlPanel-0.0.2" />
<module name="ControlPanel-0.0.2">
<engine sniffer="osgi" />
</module>
</application>

and application mapping
<application-ref ref="ControlPanel-0.0.2" virtual-servers="cp.bill" />
this config is created by asadmin.

also i have virtualhost configured to work with ajp13

<virtual-server id="cp.bill" hosts="cp.bill.nodex.ru" network-listeners="ajp13" />

When i`m trying to open my app - GF displays to me default page.
When i`m trying to open / by ip (handled my default virtual server)- is displays
to me my app.

The problem is the OSGi web app is always deployed to the default virtual server.



 Comments   
Comment by Sanjeeb Sahoo [ 18/Mar/10 ]

Will look into it soon (after I am back from business trip).

Comment by Sanjeeb Sahoo [ 18/Mar/10 ]

The proposal I have in my mind is to define a header called "Virtual-Servers" in
MANIFEST.MF which will contain a list of virtual server names the web app needs
to be deployed at. In the absence of this header or if the header value is
empty, then the web app will be deployed in the default virtual server. I should
be able to add this support quickly. Thanks for asking for it. We always knew
about this issue, but in the absence of any real requirement, we didn't have a
pressing need to do it.

Comment by Sanjeeb Sahoo [ 19/Mar/10 ]

First version of the fix checked in:
This is an initial version of the fix which only supports one virtual server to
be set while deploying a WAB. Like Web-ContextPath, user has to supply this
information in MANIFEST.MF of the WAB. The header name is "Virtual-Servers."
When the header is absent or the header name is empty, we only deploy to default
virtual server. If user tries to set multiple virtual server in the manifest
header Virtual-Servers, a runtime exception is raised at this point of time
indicating that we don't yet support multiple virtual servers. We will fix it
when I have some more time. I will keep the bug open until then. Sending
osgi-javaee/osgi-web-container/src/main/java/org/glassfish/osgiweb/Constants.java
Sending
osgi-javaee/osgi-web-container/src/main/java/org/glassfish/osgiweb/OSGiWebDeploymentRequest.java
Transmitting file data ..
Committed revision 36048.

Pavel,

Pick a build which is built after this revision to test it out and send me your
comments.

Thanks,
Sahoo

Comment by mirackle [ 22/Mar/10 ]

I tried it.

It seems to bundle mapping to virtualserver is works. But i have
couple of strange bugs, when i`m try to deploy 2 bundles with "/" context
to different virtualservers.

One app just dissapear from it`s context (from default server) and show`s me a
plain page.
I will try to do some additional testing.

Comment by jluehe [ 23/Mar/10 ]

Sahoo, regarding your comment:

> In the absence of this header or if the header value is empty, then the
> web app will be deployed in the default virtual server.

I think this is consistent with how the CLI handles this situation: As part of
the fix for https://glassfish.dev.java.net/issues/show_bug.cgi?id=6645, we
changed
deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand to
interpret a missing --virtualservers command line argument to mean "all existing
virtual servers with the exception of __asadmin".

See DeployCommand#getVirtualServers for details

Comment by jluehe [ 23/Mar/10 ]

Additional comment: How do you access your app on virtual server
"cp.bill.nodex.ru"? Have you reconfigured DNS to have this domain mapped to your
local IP address?

One easy way to test virtual server deployments without having to reconfigure
DNS is via telnet, by specifying the target domain name as the value of the
"Host" request header, as follows:

telnet localhost <listener-port>
GET <request-uri> HTTP/1.1
Host: cp.bill.nodex.ru

Comment by mirackle [ 23/Mar/10 ]

>Additional comment: How do you access your app on virtual server
>"cp.bill.nodex.ru"? Have you reconfigured DNS to have this domain mapped to your
>local IP address?

Yes, of course.

Comment by mirackle [ 31/Mar/10 ]

There is strange trouble.

I have 2 OSGI WAB.
1. Deployed to default virtual server
2. Deployed to dedicated virtual server

Both WAB`s have context = "/"
Both uses JSF 2.

Steps to reproduce.
1. Deploy first - it works
2. Deploy second - it works
3. Redeploy second(couple times) - first not works

Comment by Sanjeeb Sahoo [ 31/Mar/10 ]

What change in behavior in app #1 do you observe? Is there anything significant
in server.log that can be used as hint? Is there a reproducible test case? If
so, send me to look into it.

Comment by mirackle [ 01/Apr/10 ]

I can reproduce this bug without any problem.

After step 3 app is deployed - server.log is empty.
After this when i`m going to pages of first wab - server
returns 500 error but without any page (plain, just headers) it seems just reset
connection after headers is sent.

About difference of app. Both uses Spring and Spring DM. Both uses JSF.
First uses Primefaces. Second uses Icefaces 2 Alpha2. GF - lastest trunk from 30
May 2010.

I will try to create test WAB`s and attach them to case.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-14323] Fix non-essential bootdelegation flags - optional portion of issue 11783 Created: 31/Oct/10  Updated: 11/Mar/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 14,323

 Description   

Refer to issue 11783. This issue is for bootdelegations mentiond under category
#a, #d, and #e in that bug. We need OSGi frameworks to support bootclasspath
extension. Not an urgent issue. I think there is an already RFE filed in Felix
for this feature which I am not able to find. I will add a link if I find it or
may be Richard knows about it.



 Comments   
Comment by TangYong [ 12/Oct/12 ]

It seemed to be the following link[1]
[1]: https://issues.apache.org/jira/browse/FELIX-1974

Comment by TangYong [ 12/Oct/12 ]

currently, felix framework 4.0.3 has been released and if being the link, according to the link, the felix improvement should be implemented on 4.2.0( Fix Version/s: framework-4.2.0 ).

So, indeedly is not an urgent issue.





[GLASSFISH-14076] Report an error on a ManagedBean or an EJB with missing no-arg or @Inject constructor Created: 19/Oct/10  Updated: 13/Dec/10

Status: Open
Project: glassfish
Component/s: verifier
Affects Version/s: 4.0
Fix Version/s: None

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

Operating System: All
Platform: Linux


Issuezilla Id: 14,076

 Description   

As per the Managed Beans specification, a @ManagedBean annotated ManagedBean
must have a no-arg constructor. Today deployment succeeds for a CDI-enabled
ManagedBean with a no-arg constructor, and it fails at runtime with an Weld
instantiation error as shown below:
Caused by: org.jboss.weld.exceptions.DeploymentException:
test.beans.org$jboss$weld$bean-
$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassf
ish$domains$domain1$applications$cdi-simple-managed-bean-interceptor-web$-
ManagedBean-class_test$beans$TestManagedBean_$$_WeldProxy
at
org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:600)
at
org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.j
ava:256)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:338)
at org.jboss.weld.context.DependentContext.get(DependentContext.java:62)
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:660)
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:734)
at
org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.ja
va:757)
at
org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:118
)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:840)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:852)
at
org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.jav
a:122)
at
org.glassfish.weld.services.InjectionServicesImpl.aroundInject(InjectionServices
Impl.java:134)
at
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:50)
at
org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:1
16)
at
org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.
java:227)
at
org.glassfish.weld.services.JCDIServiceImpl.createManagedObject(JCDIServiceImpl.
java:181)
at
com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.crea
teManagedBean(ManagedBeanManagerImpl.java:478)
at
com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.crea
teManagedBean(ManagedBeanManagerImpl.java:428)
at
com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.createManaged
Object(InjectionManagerImpl.java:300)
... 28 more
Caused by: org.jboss.weld.exceptions.DefinitionException:
test.beans.org$jboss$weld$bean-
$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassf
ish$domains$domain1$applications$cdi-simple-managed-bean-interceptor-web$-
ManagedBean-class_test$beans$TestManagedBean_$$_WeldProxy
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:223)
at
org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:594)
... 46 more
Caused by: java.lang.InstantiationException: test.beans.org$jboss$weld$bean-
$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassf
ish$domains$domain1$applications$cdi-simple-managed-bean-interceptor-web$-
ManagedBean-class_test$beans$TestManagedBean_$$_WeldProxy
at java.lang.Class.newInstance0(Class.java:340)
at java.lang.Class.newInstance(Class.java:308)
at
org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:
396)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess
.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureR
eflectionAccess.java:216)
at
org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.j
ava:391)
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:218)
... 47 more

#]

We could instead detect this error early during deployment of the archive and
fail deployment. Please see a proposed patch below for doing this.
[16:17:36] [siva@spiff ../gfv3/v3/deployment/dol] $ svn diff
Index:
src/main/java/com/sun/enterprise/deployment/annotation/handlers/ManagedBeanHandl
er.java
===================================================================

src/main/java/com/sun/enterprise/deployment/annotation/handlers/ManagedBeanHandl
er.java (revision 41835)
+++
src/main/java/com/sun/enterprise/deployment/annotation/handlers/ManagedBeanHandl
er.java (working copy)
@@ -54,6 +54,7 @@
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.lang.reflect.Method;
+import java.lang.reflect.Constructor;

import java.util.List;
import java.util.LinkedList;
@@ -98,6 +99,16 @@

Class managedBeanClass = (Class) element.getAnnotatedElement();

+ //check to see if the ManagedBean has a no-argument constructor
+ //see MB2 and MB.2.1.1
+ try

{ + Constructor c = managedBeanClass.getConstructor(null); + }

catch (NoSuchMethodException nsme)

{ + throw new IllegalStateException ("Class " + managedBeanClass + + " is not a valid EE ManagedBean class as it " + + "does not have a no-arg constructor. "); + }

+
managedBeanDesc.setBeanClassName(managedBeanClass.getName());



 Comments   
Comment by marina vatkina [ 20/Oct/10 ]

This is not as simple. As Managed Bean support constructor injection, it doesn't
need to have a no-arg constructor.

The Managed Bean specification, per se, doesn't support constructor based
injection. However it lets other specifications and MB implementations to
support MBs without a no-arg constructor [last part in the initial description
of MB.2 in the Managed Beans specification].

Since, in our container, we can only support constructor injection in cases
where Managed Beans are CDI Beans, we are left to conditions when a @ManagedBean
annotated bean is a CDI bean. As per section EE.5.20 (Java EE6 specification)
and Section 3.1.1 of the CDI 1.0 specification, this leaves us to cases where a
@ManagedBean annotated bean that has a @Inject annotated constructor alone can
be considered as a case where constructor based injection is supported.

So, we can modify the requirement and the proposed fix in this issue to consider
cases where a @ManagedBean neither has a no-arg constructor nor a constructor
that is annotated with @Inject, to be an error and fail deployment. So, for
instance in the scenarios below, Foo1 is allowed but Foo2 deployment would fail.

@ManagedBean
public class Foo1 {
...
//no no-arg constructor
...
@Inject
Foo1(Bar b)

{...}
...
}

@ManagedBean
public class Foo2 {
...
//no no-arg constructor
...
Foo2(Bar b){...}

...
}

Comment by marina vatkina [ 29/Oct/10 ]

We do not currently do constructor validation for EJBs either.

Comment by marina vatkina [ 29/Oct/10 ]

Transferring to verifier to add the assertions. As of Java EE 5 verifier
correctly identified missing no-arg constructor in a SLSB.

Comment by Sanjeeb Sahoo [ 09/Nov/10 ]

deferring to a future release.





[GLASSFISH-15499] Improve osgi metadata of core/bootstrap Created: 09/Jan/11  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1_b36
Fix Version/s: future release

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

Tags: ee7ri_cleanup_deferred

 Description   

Apply this patch after gate opens for 3.2
ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn diff core/bootstrap/osgi.bundle
Index: core/bootstrap/osgi.bundle
===================================================================
— core/bootstrap/osgi.bundle (revision 44286)
+++ core/bootstrap/osgi.bundle (working copy)
@@ -40,16 +40,16 @@

Bundle-Activator: com.sun.enterprise.glassfish.bootstrap.GlassFishMainActivator

    1. Please note we don't everything that's required by every class in this module.
    2. We only import packages required by GlassFishMainActivator and its dependencies
      +# Please note we don't mandatorily import everything that's required by every class in this module.
      +# We only import mandatorily packages required by GlassFishMainActivator and its dependencies
  1. such as EmbeddedOSGiGlassFishRuntimeBuilder. The rest of the dependencies are
    1. pulled in dynamically via DynamicImport-Package. By doing this, we will be able
      +# pulled in via optional import or dynamically via DynamicImport-Package. By doing this, we will be able
  2. to install and start this bundle in a vanilla OSGi environment and then bootstrap
    1. rest of GlassFish bundles. Please contact Sahoo or Bhavani before you make any change in this
      +# rest of GlassFish bundles. Please contact Sahoo before you make any change in this
  3. bundle's manifest.
    Import-Package: \
  • org.glassfish.embeddable,
  • org.osgi.*
    + org.glassfish.embeddable, org.osgi.*, \
    + *; resolution:=optional

DynamicImport-Package: *



 Comments   
Comment by Tom Mueller [ 18/Oct/12 ]

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





[GLASSFISH-15365] [OSGi/CDI] CDI + OSGi event admin Created: 27/Dec/10  Updated: 11/Dec/12

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

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

Attachments: Zip Archive GLASSFISH-15365-patch-20121211.zip    
Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19358 Adding fighterfish test cases Sub-task Open Sanjeeb Sahoo  
Tags: 3_1_x-exclude

 Description   

We should explore use of CDI event mechanism for OSGi event admin



 Comments   
Comment by TangYong [ 19/Nov/12 ]

CDI/OSGi Event Integration is in progress. Now, desgin of the integration is as following:

1 CDI/OSGi Event API

1) defining three CDI/OSGi Events

・ServiceRegistered
・ServiceModified
・ServiceUnregistering

2) defining a @ServiceContract Qualifier used for qualifying CDI/OSGi event

@Target(

{ PARAMETER }

)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier
public @interface ServiceContract {
/**

  • The specification class filtering the received
  • {@link javax.enterprise.event.Event}

    .
    */
    Class<?> value();
    }

By 1) and 2), a user can write the following observer method:

public void postOnActivator(@Observes @ServiceContract(StockQuoteService.class) ServiceRegistered event)

{ System.out.println("postOnActivator() method is getting : " + event.getServiceContractNames()); Set<String> set = ((StockQuoteService)event.getService()).getSymbols(); ... }

2 OSGi Service Listening
Adding ServiceListener into OSGiCDIContainerActivator and wraping OSGi Service Event into CDI/OSGi Event

3 Firing CDI/OSGi Event using CDI Event Interface
Here, I use Instance<Object> to select Event<Object> and fire CDI/OSGi Event. In order to get Instance<Object>, I need to register Instance<Object> related each Weld Container Instance as OSGi Services while getting Instance<Object> from OSGiServiceExtension class.

Note: while using Instance<Object> to select Event<Object>, Weld will call ACLSingletonProvider.get() , so we must take care of set TCCL.

4 Handling Instance<Object>'s Unregistering
While a bundle is in process of stopping or uninstalled, we must unregister OSGi Service of Instance<Object> which belongs to current bundle.

[Current State Of Integration]
Prototype has been made and fixing some bugs.

Comment by TangYong [ 19/Nov/12 ]

Currently, event integration has been tested between multi plain osgi bundles successfully, the following displayed that event callback method(OnServiceRegistered) can be called many times once MyServiceInf's implementation is available.

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|MyService has been registered OSGi Service!|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|SimpleStockQuoteServiceImpl::Initializing quotes|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|SimpleStockQuoteServiceImpl::getSymbols|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|Registered:[IBM, MSFT, HPQ, ORCL]|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|OnServiceRegistered() method is getting : [org.acme.myservice.api.MyServiceInf]|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|OnServiceRegistered(): MyService: Hello Word!|#]

[#|2012-11-19T22:44:35.656+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675656;_LevelValue=800;|Started sample.osgicdi.myservice [284]|#]

[#|2012-11-19T22:44:35.671+0900|INFO|44.0|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332675671;_LevelValue=800;|myservice was successfully deployed in 109 milliseconds.|#]

[#|2012-11-19T22:45:09.906+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332709906;_LevelValue=800;|Stopped sample.osgicdi.myservice [284]|#]

[#|2012-11-19T22:45:09.921+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332709921;_LevelValue=800;|Uninstalled sample.osgicdi.myservice [284]|#]

[#|2012-11-19T22:45:19.250+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719250;_LevelValue=800;|Installed sample.osgicdi.myservice [285] from reference:file:/D:/gf/1102/glassfish3/glassfish/domains/domain1/applications/myservice/|#]

[#|2012-11-19T22:45:19.250+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719250;_LevelValue=800;|Hello!|#]

[#|2012-11-19T22:45:19.265+0900|INFO|44.0|org.jboss.weld.Bootstrap|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719265;_LevelValue=800;|WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|MyService has been registered OSGi Service!|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|SimpleStockQuoteServiceImpl::Initializing quotes|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|SimpleStockQuoteServiceImpl::getSymbols|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|Registered:[IBM, MSFT, HPQ, ORCL]|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|OnServiceRegistered() method is getting : [org.acme.myservice.api.MyServiceInf]|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|OnServiceRegistered(): MyService: Hello Word!|#]

[#|2012-11-19T22:45:19.281+0900|INFO|44.0|javax.enterprise.logging.stdout|_ThreadID=12;_ThreadName=admin-listener(1);_TimeMillis=1353332719281;_LevelValue=800;|Started sample.osgicdi.myservice [285]|#]

Comment by TangYong [ 19/Nov/12 ]

However, there is a bug which is in process of investigation.
Once the observer method is in a servlet of WAB, the observer has not been triggered.

Comment by TangYong [ 20/Nov/12 ]

Currently, WAB's OSGi/CDI event integration is blocked by GLASSFISH-19359 and waiting for siva and sahoo's confirmation.

Comment by TangYong [ 22/Nov/12 ]

Because GLASSFISH-19359 has been resolved, now, starting to enter into fighterfish test phrase.

Comment by TangYong [ 11/Dec/12 ]

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





[GLASSFISH-15362] Improve design of OSGiContainer/BundleTracker interaction Created: 27/Dec/10  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1_b33
Fix Version/s: 4.1

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


 Description   

Currently the bundle tracker is owned by JavaEEExtender. It will probably make more sense to move it to OSGiContainer so that it can optimize tracking of bundles and make better use of Future API as well as ServiceTracker API to decide when to stop tracking bundles.






[GLASSFISH-15364] [OSGi/CDI] CDI + OSGi config admin Created: 27/Dec/10  Updated: 18/Oct/12

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

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

Tags: ee7ri_cleanup_deferred

 Description   

We should explore use of CDI event mechanism with OSGi config admin



 Comments   
Comment by Sanjeeb Sahoo [ 29/Apr/11 ]

Since this involves gathering requirement as well, this issue will be addressed on a best effort basis.

Comment by Tom Mueller [ 18/Oct/12 ]

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





[GLASSFISH-3266] TagLibrary Descriptor related tests may not be needed any more Created: 27/Jun/07  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 3,266

 Description   

Since verifier now calls JSPC to compile JSPs bundled in a war file, and the
JSPC parses/validates the TLDs, verifier does not have to validate any TLDs any
more. All the following tests might be redundant:
tests/web/TagClassExtendsValidInterface.java
tests/web/TagClassImplementsValidInterface.java
tests/web/TagLibPublicID.java
tests/web/TagNameIsUnique.java
tests/web/Taglib.java
tests/web/TaglibFunctionMethodTest.java
tests/web/TaglibFunctionSignatureIsValid.java
tests/web/TaglibListenerClassExists.java
tests/web/TaglibLocation.java
tests/web/TaglibUri.java

Please check them, and remove if so. This will speed up verifier. More over, we
might be able to remove the use of web/TagLibFactory from verifier.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-613] server call for validation only need adjustment Created: 27/Apr/06  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 613

 Description   

As of April 20, the entity-persistence module has been changed to delay some of
its initialization until the first EntityManager is created (rather than
initializing at the time the an EntityManagerFactory is created.)

This requires a change to the validation only feature.

Currently the validation only feature just creates and EntityManagerFactory.
It will now have to create an EntityManager in addition.

When this is done, the following code from
EntityManagerFactoryProvider.createContainerEntityManagerFactory should be
changed to remove the check for validation-only (Note, a separate bug will be
filed for a similar task for ddl generation. - when both bugs are fixed, the
call to factory.getServerSession(); should be removed.

// This code has been added to allow validation to occur without
actually calling createEntityManager
if (validationOnly || !ddlGeneration.equalsIgnoreCase(NONE))

{ factory.getServerSession(); }

 Comments   
Comment by tware [ 27/Apr/06 ]

see

https://glassfish.dev.java.net/issues/show_bug.cgi?id=612

for related bug

Comment by marina vatkina [ 03/May/06 ]

Reassigned module and owner

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-121] new assertion: getTransaction() must not be called for JTA entity manager Created: 28/Dec/05  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 121

 Description   

Secion 3.1.1 of Java Persistence API 1.0 PFD says the following:

/**

  • Return the resource-level transaction object.
  • The EntityTransaction instance may be used serially to
  • begin and commit multiple transactions.
  • @return EntityTransaction instance
  • @throws IllegalStateException if invoked on a JTA
  • EntityManager or an EntityManager that has been closed.
    */
    public EntityTransaction getTransaction();

Verifier should report error if a program uses getTransaction() on a JTA entity
manager.



 Comments   
Comment by Sanjeeb Sahoo [ 12/Feb/06 ]

Difficult to do without doing call flow analysis. This should be implemented
inside NB environment. Marking it as an RFE.
– Sahoo

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4836] Verifier result should be improved in case of missing classes Created: 21/Apr/08  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 4,836

 Description   

Today I noticed that when a needed class is missing, the verifier "just" prints
a very ugly stack trace:

Error Name :
com.sun.enterprise.tools.verifier.tests.persistence.DefaultProviderVerification
Error Description : java.lang.NoClassDefFoundError: junit/framework/TestCase

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:620)

at
com.sun.enterprise.loader.EJBClassLoader$DelegatingClassLoader.findClass(EJBClassLoader.java:1406)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

at
oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.isEntity(PersistenceUnitProcessor.java:316)

at
oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.getEntityClassNamesFromURL(PersistenceUnitProcessor.java:301)

at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcessor.buildEntityClassSetFromAnnotations(MetadataProcessor.java:501)

at
oracle.toplink.essentials.internal.ejb.cmp3.metadata.MetadataProcessor.buildEntityList(MetadataProcessor.java:462)

at
oracle.toplink.essentials.ejb.cmp3.persistence.PersistenceUnitProcessor.processORMetadata(PersistenceUnitProcessor.java:366)

at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:607)

at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createContainerEntityManagerFactory(EntityManagerFactoryProvider.java:244)

at
com.sun.enterprise.tools.verifier.tests.persistence.DefaultProviderVerification.check(DefaultProviderVerification.java:103)

at com.sun.enterprise.tools.verifier.CheckMgr.check(CheckMgr.java:133)

at
com.sun.enterprise.tools.verifier.persistence.PersistenceUnitCheckMgrImpl.check(PersistenceUnitCheckMgrImpl.java:96)

at
com.sun.enterprise.tools.verifier.CheckMgr.checkPersistenceUnits(CheckMgr.java:390)

at
com.sun.enterprise.tools.verifier.ejb.EjbCheckMgrImpl.check(EjbCheckMgrImpl.java:80)

at com.sun.enterprise.tools.verifier.BaseVerifier.verify(BaseVerifier.java:146)

at com.sun.enterprise.tools.verifier.ejb.EjbVerifier.verify(EjbVerifier.java:78)

at
com.sun.enterprise.tools.verifier.VerificationHandler.runVerifier(VerificationHandler.java:236)

at
com.sun.enterprise.tools.verifier.VerificationHandler.verifyArchive(VerificationHandler.java:141)

at com.sun.enterprise.tools.verifier.Verifier.verify(Verifier.java:144)

at com.sun.enterprise.tools.verifier.Verifier.main(Verifier.java:114)

Caused by: java.lang.ClassNotFoundException: junit.framework.TestCase

at
com.sun.enterprise.loader.EJBClassLoader.findClassData(EJBClassLoader.java:737)

at
com.sun.enterprise.loader.EJBClassLoader$DelegatingClassLoader.findClass(EJBClassLoader.java:1376)

at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)

... 23 more

That stack trace was not part of the result, but part of the verfier'S very own
status printout.

It would be great if there would be no stack trace in the veryfier's status
printout, but instead a nice message to be found in the result report (including
the stack trace).



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4831] Warnings should be warnings Created: 21/Apr/08  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 4,831

 Description   

I got the following message from the verifier:

INFO: Verifying: [ Simple ]
WARNUNG: Ignoring the @NamedQuery [Customer.findAll] speci
WARNUNG: Ignoring the @NamedQuery [Customer.ejbSelectAllNa
xists.
WARNUNG: Ignoring the @NamedQuery [Customer.findByName] sp
WARNUNG: Ignoring the @NamedQuery [Customer.ejbSelectFilte
xists.
INFO:

  1. of Failures : 1
  2. of Warnings : 0
  3. of Errors : 0
    INFO: Look in file "Simple.jar.txt" for detailed results.

As you can see, the verifier posts four warnings. But in the result it says:
zero warning. If the programmer doesn't take good care, and just looks for the
number of warnings, he might think that everything is ok. So he will not take
notice of the four warnings.

I would suggest that all warnings are summed up in the warnings sum.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4760] Verifier results in STDOUT instead of file Created: 14/Apr/08  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 4,760

 Description   

The verifier is a great developer tool, but there is one thing that is really
annoying: It outputs its results into files always. I would be really glad if
the result, either in XML or Plain Text format, would be printed just STDOUT /
STDERR instead of a file. It is much easier to handle for IDEs (as tools
typically output their results in STDOUT) and it is easier for the programmer
when using the tool at the command line.

I would suggest adding two new command line options:

Option 1 switches between output to file and output to STDOUT / STDERR. The
default should be to output to STDOUT / STDERR, as typical with CLI tools.

Option 2 switches between XML and Plain Text output. The default is plain text,
as typical with CLI tools.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-4718] Verifier should check names queries for correct QL syntax Created: 10/Apr/08  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 4,718

 Description   

I just noticed that the GlassFish server contained in Java EE 5 SDK (Sun Java
System Application Server 9.1_01) seems to not check for correct QL syntax of
named queries.

In my particular case, there was a typo: query="SELECTx adr FROM Address adr".

The verifier told me that there are no problems with my entity!

It would be great if the verifier would check for correct QL syntax of named
queries.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-1297] Verify Java SE archives that uses JPA Created: 12/Oct/06  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Attachments: Zip Archive issue_1297.zip    
Issuezilla Id: 1,297

 Description   

Please add support for verifcation of Java SE archives that uses JPA.

The work around is to turn Java SE jar to an appclient jar
by just having a manifest with Main-Class attribute in it.
The attached test case shows this workaround with usage, e.g.
javac -classpath $S1AS_HOME/lib/javaee.jar *.java
jar cvfm client.jar manifest *.class META-INF/persistence.xml
verifier -p client.jar
Look at result in the file called client.jar.txt.



 Comments   
Comment by sherryshen [ 12/Oct/06 ]

Created an attachment (id=503)
Testcase with README

Comment by marina vatkina [ 12/Oct/06 ]

It's in the verifier

Comment by sherryshen [ 19/Oct/06 ]

More examples of the workaround of JavaSE verifier are in issue 499 or issue 1294.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-1065] verifier does not show error for Lob/Id field Created: 01/Sep/06  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 1,065

 Description   

I have a class which does not cause a verifier error. It should because Lob Id
on the same field is not allowed:

@Id
@Lob
@Column(name = "GENRE", nullable = false)
private Object genre;



 Comments   
Comment by Sanjeeb Sahoo [ 09/Feb/07 ]

Marking as an enhancement.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-3845] Standalone verifier needs a domain named 'domain1' Created: 07/Nov/07  Updated: 06/Mar/12

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

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

Operating System: All
Platform: All


Issuezilla Id: 3,845

 Description   

When running standalone verifier, and there's no domain named 'domain1' the
verifier throws java.lang.NullPointerException.



 Comments   
Comment by Tom Mueller [ 06/Mar/12 ]

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





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

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

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

Tags: ee7ri_cleanup_deferred

 Description   

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

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



 Comments   
Comment by TangYong [ 13/Oct/12 ]

sahoo, previously, I have commented the following on osgi/cdi draft jira[1],
[1]:https://www.osgi.org/bugzilla/show_bug.cgi?id=141

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

@Stateless
@Local(

{UserAuthService.class})
@Publish
public class UserAuthServiceEJB2 implements UserAuthService { ... }

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

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

@Stateless
@Local({UserAuthService.class}

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

{ ... }

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

Comment by Tom Mueller [ 18/Oct/12 ]

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





[GLASSFISH-15760] Allow persistence units to be packaged outside of the deployment unit Created: 30/Jan/11  Updated: 19/Oct/11

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: None
Fix Version/s: future release

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

Attachments: Text File patch.txt    
Tags: 3_1_x-exclude

 Description   

Currently persistence units can only be packaged as part of the deployment unit and only then they are available to EMF/EM reolvers during resolution of @PersistnceContext and @PersistenceUnit or their equivalent JNDI operations. It will be good to allow application developers to package persistence units in standalone libraries or OSGi bundles so as to encourage modularity as well as getting better performance by sharing second level cache.

PFA a patch that adds necessary support in core for such a feature to be supported.



 Comments   
Comment by Mitesh Meswani [ 01/Feb/11 ]

The patch looks good to me. Please go ahead and check in when trunk opens up. Assigning back to you for the checkin

Comment by Sanjeeb Sahoo [ 29/Apr/11 ]

Deferring to a future release





[GLASSFISH-17155] CDI Events don't work when fired by a OSGi ServiceListener. Created: 06/Aug/11  Updated: 25/Mar/13

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

Type: