[GLASSFISH-21128] Incorrect context in ManagedThreadFactory Created: 10/Jul/14  Updated: 20/Feb/17

Status: In Progress
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: anthony.lai Assignee: rutujay
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

At page 3-27 of JSR236 spec, it is specified that the runnable that is executed will run with the context of the application component instance that created the ManagedThreadFactory instance.
But in the implementation of glassfish4, tasks will run with the context of the application component that called the newThread() method.






[GLASSFISH-21581] The thread pool's task queue is full, limit: 4096 Created: 07/Nov/16  Updated: 20/Feb/17

Status: In Progress
Project: glassfish
Component/s: concurrency
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: psgrandi Assignee: rutujay
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2013



 Description   

Hi, we're dealing with recurrent issue with thread pool with Glassfish 4.1.1, where the pool are getting full and the domain stop responding.

Attached files:
domain.xml
server.log
thread dumps.

We did some researches for similar problems and for contingency we tried to change the thread pool size to -1, but got an error on domain startup:

Shutting down server due to startup exception
java.lang.IllegalArgumentException: poolsize < 1
at org.glassfish.grizzly.threadpool.AbstractThreadPool.<init>(AbstractThreadPool.java:141)
at org.glassfish.grizzly.threadpool.SyncThreadPool.<init>(SyncThreadPool.java:71)
at org.glassfish.grizzly.threadpool.GrizzlyExecutorService.setImpl(GrizzlyExecutorService.java:104)
at org.glassfish.grizzly.threadpool.GrizzlyExecutorService.<init>(GrizzlyExecutorService.java:82)
at org.glassfish.grizzly.threadpool.GrizzlyExecutorService.createInstance(GrizzlyExecutorService.java:78)
at org.glassfish.grizzly.config.GenericGrizzlyListener.configureThreadPool(GenericGrizzlyListener.java:599)
at org.glassfish.grizzly.config.GenericGrizzlyListener.configure(GenericGrizzlyListener.java:307)
at com.sun.enterprise.v3.services.impl.GrizzlyProxy.initialize(GrizzlyProxy.java:124)
at com.sun.enterprise.v3.services.impl.GrizzlyService.createNetworkProxy(GrizzlyService.java:539)
at com.sun.enterprise.v3.services.impl.GrizzlyService.postConstruct(GrizzlyService.java:490)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:326)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:374)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:228)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2072)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1213)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1144)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)



 Comments   
Comment by rutujay [ 10/Feb/17 ]

Please provide the steps to reproduce the problem.

Comment by rutujay [ 15/Feb/17 ]

The steps which I followed are,
1. started the server using asadmin start-domain

Waiting for domain1 to start .....
Successfully started the domain : domain1
domain Location: /home/yrutuja/glassfish-repo/glassfish4/glassfish/domains/domain1
Log File: /home/yrutuja/glassfish-repo/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

2.Using the admin console localhost:4848 > Configurations -> server-config> Thread Pools -> hhtp-thread-pool -> max Queue Size = -1

3.Restart the domain using asadmin restart-domain

Successfully restarted the domain
Command restart-domain executed successfully.

The exception which you are facing occurs when you set max-thread-pool-size to -1, which is not advised.

If you followed some other steps other than mine, please let me know so that I can reproduce the bug.





[GLASSFISH-21387] asadmin deploy failure won't yield error code != 0 Created: 07/Jul/15  Updated: 20/Feb/17

Status: In Progress
Project: glassfish
Component/s: admin, deployment
Affects Version/s: 4.1
Fix Version/s: None

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

linux



 Description   

Normally when I deploy my application war the asadmin deploy command would return a exit code != 0 if there was a problem (for instance if a @Startup annotated method threw an exception).

If I deploy the same war to a special target I get an error message but a error code of 0.

dev@devapp:/opt/dev/gfbin> asadmin --user admin --passwordfile /opt/dev/gfbin/work/gf.pwd --port 10000 deploy --target devcluster /var/opt/dev/transfer/gf/myapp.war
Application deployed with name myapp.
Warning: Command _deploy did not complete successfully on server instance dev1: remote failure: Failed to load the application on instance dev1. The application will not run properly. Please fix your application and redeploy.
Exception while loading the app : javax.ejb.CreateException: Initialization failed for Singleton MyStartupBean. Please see server.log for more details.
Command deploy completed with warnings.
dev@devapp:/opt/dev/gfbin> echo $?
0


 Comments   
Comment by rutujay [ 15/Feb/17 ]

Please provide the application which you are deploying.

Comment by rutujay [ 20/Feb/17 ]

When you deploy the application war normally using asadmin deploy command do you still get the final message as, Command deploy completed with warnings, or is it something else?





[GLASSFISH-21677] Need to remove -Xbootclasspath from domain.xml Created: 14/Feb/17  Updated: 17/Feb/17  Resolved: 17/Feb/17

Status: Resolved
Project: glassfish
Component/s: JDK9
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Arindam Bandyopadhyay Assignee: Ryan Lubke
Resolution: Fixed Votes: 0
Labels: jdk9-int
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK9


Tags: jdk9-int

 Description   

As an http2 integration effort , <jvm-options>-Xbootclasspath/p:$

{com.sun.aas.installRoot}

/lib/grizzly-npn-bootstrap.jar</jvm-options>
is added in appserver/admin/template/src/main/resources/config/domain.xml as a temporary fix as JDK team does not back ports the ALPN support from JDK9 to 8 yet .

-Xbootclasspath does not work with jdk9 . The other jdk9 incompatible options like MaxPermSize, endorsed and ext we can remove from domain.xml and GF starts up successfully .So we can continue testing GlassFish with jdk9 .However if we remove -Xbootclasspath from domain.xml we get Grizzly exception on startup.So unless -Xbootclasspath is removed from domain.xml , no work can be started to make GlassFish jdk9 compatible .



 Comments   
Comment by Ryan Lubke [ 17/Feb/17 ]

Sending appserver/admin/template/src/main/resources/config/domain.xml
Sending nucleus/admin/template/src/main/resources/config/domain.xml
Sending nucleus/core/extra-jre-packages/pom.xml
Sending nucleus/packager/nucleus-grizzly/src/main/assembly/nucleus-grizzly.xml
Sending nucleus/pom.xml
Transmitting file data .....done
Committing transaction...
Committed revision 64566.





[GLASSFISH-21542] Update jboss.logging Created: 11/May/16  Updated: 17/Feb/17  Resolved: 17/Feb/17

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 4.1.1
Fix Version/s: 5.0

Type: Task Priority: Major
Reporter: djmj Assignee: ankur.kathuria
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Update jboss.logging to new 3.3 final to be consistent with latest hibernate ORM 5 requiremenet



 Comments   
Comment by ankur.kathuria [ 17/Feb/17 ]

Commit at Revision: 64553





[GLASSFISH-21409] Encoding mapping key search error Created: 07/Aug/15  Updated: 17/Feb/17

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mahairod Assignee: Kokil_Jain
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Fedora 22, jdk8, glassfish-4.1, LC_NAME="ru_RU.UTF-8"


Tags: config, encoding, wait

 Description   

Method getCharset of class org.apache.catalina.util.CharsetMapper does mot recognise locale string if it consists of parts separated by "-". As a result <locale-encoding-mapping-list> setting of web.xml is not working properly.



 Comments   
Comment by Kokil_Jain [ 17/Feb/17 ]

I am unable to reproduce the bug.
Can you please provide with the exact steps to reproduce the bug and also the sample application ?

Comment by mahairod [ 17/Feb/17 ]

it;s enough to place encoding mappings tio web.xml of any webapp and deploy it





[GLASSFISH-21494] Double checked locking problem Created: 26/Jan/16  Updated: 17/Feb/17  Resolved: 17/Feb/17

Status: Resolved
Project: glassfish
Component/s: cmp
Affects Version/s: 4.1.1, 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: AppChecker Assignee: rutujay
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes


 Description   

It seems that there are two identical double checked locking problems:

1) https://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/persistence/cmp/model/src/main/java/com/sun/jdo/api/persistence/model/jdo/impl/PersistenceElementImpl.java?rev=64243

private PropertyChangeSupport _support;
....
....
if (_support == null)
{
synchronized(this)

{ // new test under synchronized block if (_support == null) _support = new PropertyChangeSupport(_element); }

}

2) https://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/persistence/cmp/model/src/main/java/com/sun/jdo/api/persistence/model/mapping/impl/MappingElementImpl.java?rev=64243

private PropertyChangeSupport _support;
....
....
if (_support == null)
{
synchronized(this)

{ // new test under synchronized block if (_support == null) _support = new PropertyChangeSupport(this); }

}

Actually it is not very hard to fix. It is needed just to add violate modifier into _support field declaration like it's done here: https://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/web/web-naming/src/main/java/org/apache/naming/java/javaURLContextFactory.java?rev=64243 (line 109)

Possible defect was found by AppChecker static analyzer (http://cnpo.ru/en/solutions/appchecker.php)



 Comments   
Comment by rutujay [ 27/Jan/17 ]

What was the jdk version used for testing ?

Comment by AppChecker [ 31/Jan/17 ]

jdk version doesn't matter. We've checked the source code with static analyzer.

Comment by rutujay [ 31/Jan/17 ]

okay, but is it a double checked locking problem ? If you look at both the files the method which has these lines of code is synchronized.

Comment by rutujay [ 17/Feb/17 ]

Double checked locking removed as the method is synchronized.
Committed revision 64562.





[GLASSFISH-21670] Implement SERVLET_SPEC-73 Created: 02/Feb/17  Updated: 16/Feb/17

Status: In Progress
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 day, 7 hours, 16 minutes
Original Estimate: Not Specified

Attachments: Text File 20170215-2221Z-GLASSFISH-21670.patch     Text File 20170216-2146Z-GLASSFISH-21670-tests.patch    
Issue Links:
Related
is related to SERVLET_SPEC-73 Provide a way to find out mapping typ... In Progress
Tags: servlet_4_0
Sprint: MS 3 Sprint 2

 Description   

Track implementation work of SERVLET_SPEC-73



 Comments   
Comment by Ed Burns [ 02/Feb/17 ]

It looks like the mapping logic in question happens in Grizzly, in org.glassfish.http.server.util.Mapper.internalMapWrapper().

Comment by Ed Burns [ 02/Feb/17 ]

Grizzly has a MappingData data structure that is populated by that method. It looks like the necessary information for the Servlet API Mapping interface is understood within internalMapWrapper(), but not all of it that is necessary for Mapping is saved. I think we can fix that.

Comment by Ed Burns [ 03/Feb/17 ]

Patch to grizzly 2.3.x.

Comment by Ed Burns [ 03/Feb/17 ]

Patch to GlassFish trunk. Assumes Servlet API from branch is in local maven repo.

Comment by Ed Burns [ 06/Feb/17 ]

Patch to Grizzli 2.3.x.

Comment by Ed Burns [ 06/Feb/17 ]

Tests.

Comment by Ed Burns [ 15/Feb/17 ]

Implement and test attributes and getServletMapping().

Comment by Ed Burns [ 16/Feb/17 ]

Assert correctness of existing implementation.





[GLASSFISH-21307] Secure Client-Initiated Renegotiation cannot be disabled: DoS Danger Created: 21/Feb/15  Updated: 16/Feb/17

Status: In Progress
Project: glassfish
Component/s: security
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: nabizamani Assignee: gururaja1234
Resolution: Unresolved Votes: 0
Labels: TLS, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)


Tags: DoS, glassfish, renegotiation, security, tls

 Description   

Glassfish 4.1 supports Secure Client-Initiated Renegotiation. However, this opens all doors for DoS attacks, see https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks

As Ivan Ristić found out there was an undocumented ability to disable client-initiated renegotiation in Java 8 (see http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-java-8.html). However, this seems not to work at all (I guess it has been removed + it is undocumented anyway)! In other words: adding the following to <jdk1.8-HOME>/jre/lib/security/java.security does not help at all (whereas I think OpenJDK has support for this, but I did not crosscheck this):

jdk.tls.rejectClientInitiatedRenegotiation=true
jdk.tls.rejectClientInitiatedRenego=true

I have not found anything that allows to disable Secure Client-Initiated Renegotiation in the Glassfish settings. Since there seems to be no way to
disable it globally via JSSE (<jdk1.8-HOME>/jre/lib/security/java.security) I believe that Glassfish should introduce a way to disable it somehow. I believe this is very critical.



 Comments   
Comment by Anthony Vanelverdinghe [ 22/Feb/15 ]

jdk.tls.rejectClientInitiatedRenegotiation is a system property, so simply adding a JVM Option "-Djdk.tls.rejectClientInitiatedRenegotiation=true" (Configurations -> server-config -> JVM Settings -> JVM Options) should work

Comment by nabizamani [ 22/Feb/15 ]

You are absolutely right, that does the trick. I simply did not recognize that it's a system property (although it is mentioned as such in Ivan's article) because at the same time I was working on jdk.tls.disabledAlgorithms in <jdk1.8-HOME>/jre/lib/security/java.security to disable RC4 (so I just got a little bit confused)...

However, I don't feel very safe using the undocumented system property via JVM options in a production environment because it's just undocumented. Using something undocumented means it could be removed with the next java update and therefore I would need to check if it is still available or not whenever I update my jdk. Therefore I still believe that there should be an explicit Glassfish setting directly in Glassfish. On the other side, everything would be fine if jdk.tls.rejectClientInitiatedRenegotiation would be a documented system property.

Does that sound reasonable? What do you think?

Comment by Anthony Vanelverdinghe [ 22/Feb/15 ]

It actually is documented in the "Compatibility Guide for JDK 8" [1], where it says: "In Oracle's JSSE provider, a new system property, jdk.tls.rejectClientInitializedRenego, is defined to reject client initialized renegotiation in server side. If the system property is set to true, the server side does not accept client initialized renegotiation, and fails with a fatal handshake_failure alert if the receiving client initialized the renegotiation request."

I doubt this property is ever going away. And surely it won't go away in a minor release. So as long as you read the compatibility guides with every major release (which you should do anyway), you're safe.

I don't like the idea of "an explicit GlassFish setting", because of:
1) duplication: it would just duplicate setting the appropriate JVM Option
2) confusion: if the explicit setting is set to false, but the JVM Option is manually set to true, what should happen?

In my opinion, the question is simply: should GlassFish add this option to the default JVM Options, yes or no? And my answer would be "yes".

[1] http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999198

Comment by nabizamani [ 22/Feb/15 ]

You are right again - it is documented. However, it is documented as jdk.tls.rejectClientInitializedRenego and not as jdk.tls.rejectClientInitializedRenegotiation.
I have just tested both system properties and only jdk.tls.rejectClientInitializedRenegotiation seems to work - the one that is not documented! Of course, I should stick with jdk.tls.rejectClientInitializedRenego as this is the one that is documented, but it seems not to work.
Can you somehow verify this? Maybe this is just a documentation error in the Compatibility Guide for JDK 8?

I also agree that duplication is not a good idea and avoiding confusion is also a good idea.
You question is correct: should GlassFish add this option to the default JVM Options, yes or no?
My answer is YES as well.

Comment by Anthony Vanelverdinghe [ 22/Feb/15 ]

It's just an oversight in the compatibility guide: in the guide there's a link to the bug report [1], where you will see another related bug, namely "JDK-8017049 - rename property jdk.tls.rejectClientInitializedRenego" [2]
So I bet it went like this: initially this functionality was implemented with a property named "jdk.tls.rejectClientInitializedRenego" & a note was added to the compatibility guide. Later, the developers realized it was clearer to use "jdk.tls.rejectClientInitiatedRenegotiation", so they renamed the property & changed the implementation, but forgot to have the compatibility guide updated.

[1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7188658
[2] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8017049

Comment by nabizamani [ 22/Feb/15 ]

Thank you Anthony, that clarifies a lot. I guessed something like that...
So let's wait and see if "-Djdk.tls.rejectClientInitiatedRenegotiation=true" will be added as default JVM option to the next release of Glassfish or not.

Comment by gururaja1234 [ 16/Feb/17 ]

As there is a workaround available i.e; we can add the JVM option jdk.tls.rejectClientInitiatedRenegotiation=true to domain.xml moving the priority of this bug from critical to Major.





[GLASSFISH-21308] Support for TLS_FALLBACK_SCSV to prevent downgrade attack Created: 21/Feb/15  Updated: 16/Feb/17

Status: In Progress
Project: glassfish
Component/s: security
Affects Version/s: 4.1
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: nabizamani Assignee: gururaja1234
Resolution: Unresolved Votes: 3
Labels: TLS, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)


Tags: DoS, glassfish, renegotiation, security, tls

 Description   

see https://community.qualys.com/thread/13896 and especially see
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/



 Comments   
Comment by vahid_shirvani [ 29/Sep/15 ]

My setup is very similar to yours

Ubuntu 14.04 LTS Server x64,
java 1.8.0_60 + JCE Unlimited Strength,
GlassFish Server Open Source Edition 4.1 (build 13)

I even upgraded the OpenSSL to version 1.0.1j but it still didn't solve the issue. The ssllabs test complained.
Accoring to this link https://community.qualys.com/thread/13896 upgrading the Openssl shall solve the issue.

EDIT: Glassfish does not use OpenSSL. Instead it uses the JSSE which has not been patched yet.

Comment by gururaja1234 [ 16/Feb/17 ]

There is a bug in JSSE raised for the similar issue https://bugs.openjdk.java.net/browse/JDK-8061798. As this might be solved by the JDK team we will wait for this bug resolution downgrading the bugs priority from critical to major.





[GLASSFISH-21656] list-jms-resources fails if operand is clustered instance Created: 05/Jan/17  Updated: 16/Feb/17  Resolved: 16/Feb/17

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.2.2, 4.1, 4.1.1, 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: yama0428 Assignee: mskdeepak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

asadmin list-jms-resources fails if operand is clustered instance.
On the other hand, other list commands can be executed even if operand is clustered instance.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-jms-resources instance
remote failure: The list-jms-resources command is not allowed on target instance because it is part of cluster cluster
Command list-jms-resources failed.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-jdbc-resources instance
jdbc/__default
Command list-jdbc-resources executed successfully.

C:\glassfish-4.1.1\glassfish4\glassfish\bin>asadmin list-connector-resources instance
jms/__defaultConnectionFactory
Command list-connector-resources executed successfully.

This is the patch for this problem.

ListJMSresources.java
@PerLookup
@CommandLock(CommandLock.LockType.NONE)
@I18n("list.jms.resources")
@ExecuteOn({RuntimeType.DAS})
@TargetType({CommandTarget.DAS,CommandTarget.STANDALONE_INSTANCE,CommandTarget.CLUSTER,CommandTarget.DOMAIN,CommandTarget.CLUSTERED_INSTANCE})
@RestEndpoints({
    @RestEndpoint(configBean=Resources.class,
        opType=RestEndpoint.OpType.GET, 
        path="list-jms-resources", 
        description="list-jms-resources")
})
public class ListJMSResources implements AdminCommand {


 Comments   
Comment by mskdeepak [ 19/Jan/17 ]

Fixed in r64405





[GLASSFISH-21477]  @PersistenceContext cannot inject into a CDI bean if this bean is inside EAR's lib Created: 03/Jan/16  Updated: 16/Feb/17

Status: In Progress
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: drupalspring Assignee: pranjal.sahay
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is the issue of GLASSFISH-19317 but it seems that it still happen.

Also create the same issue at https://github.com/payara/Payara/issues/587.



 Comments   
Comment by pranjal.sahay [ 02/Feb/17 ]

Hi,

I am unable to reproduce the above issue. I followed steps similar to those as described at https://github.com/payara/Payara/issues/587
Please provide a sample app where the issue is being seen.





[GLASSFISH-21484] Observed CDI event anotated with TransactionPhase.AFTER_SUCCESS throws IllegalStateException: Transaction is not active in the current thread Created: 20/Jan/16  Updated: 16/Feb/17

Status: In Progress
Project: glassfish
Component/s: None
Affects Version/s: 4.1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: fmachado Assignee: pranjal.sahay
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I'm not sure if this is an issue that should be fixed on Glassfish or Weld side but, as I was not able to replicate it with the latest Wildfly version, I'm reporting here first.

From a JMS message that was received asynchronously, I'm calling a Stateless LocalBean that, at some point, will fire a CDI event. With another SLB that I'm using as the event handler, a method annotated with @Observes(during = TransactionPhase.AFTER_SUCCESS) will fail and throw java.lang.IllegalStateException: Transaction is not active in the current thread if this method tries to access any EJB (even if it is annotated with @TransactionManagement(TransactionManagementType.BEAN)).

[2016-01-20T03:57:41.238+0100] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=101 _ThreadName=p: thread-pool-1; w: 1] [timeMillis: 1453258661238] [levelValue: 900] [[
  Exception during Singleton ResourceHandler processing
java.lang.IllegalStateException: Transaction is not active in the current thread.
	at com.sun.enterprise.transaction.JavaEETransactionImpl.checkTransationActive(JavaEETransactionImpl.java:722)
	at com.sun.enterprise.transaction.JavaEETransactionImpl.registerSynchronization(JavaEETransactionImpl.java:692)
	at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.checkTransaction(SimpleEjbResourceHandlerImpl.java:120)
	at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.<init>(SimpleEjbResourceHandlerImpl.java:69)
	at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.getResourceHandler(SimpleEjbResourceHandlerImpl.java:88)
	at com.sun.ejb.containers.AbstractSingletonContainer.setResourceHandler(AbstractSingletonContainer.java:182)
	at com.sun.ejb.containers.AbstractSingletonContainer.createEjbInvocation(AbstractSingletonContainer.java:171)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:192)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy185.isEnabled(Unknown Source)
	at com.fmachado.jeetest.ejb.__EJB31_Generated__MySingleton__Intf____Bean__.isEnabled(Unknown Source)
	at com.fmachado.jeetest.ejb.event.MyBusinessEventHandler.handleEvent(MyBusinessEventHandler.java:27)
	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:497)
	at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
	at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
	at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
	at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:46)
	at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
	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:497)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
	at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
	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:497)
	at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
	at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
	at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
	at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
	at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
	at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
	at com.sun.proxy.$Proxy183.handleEvent(Unknown Source)
	at com.fmachado.jeetest.ejb.event.__EJB31_Generated__MyBusinessEventHandler__Intf____Bean__.handleEvent(Unknown Source)
	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:497)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:414)
	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
	at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at com.fmachado.jeetest.ejb.event.MyBusinessEventHandler$Proxy$_$$_Weld$EnterpriseProxy$.handleEvent(Unknown Source)
	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:497)
	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
	at org.jboss.weld.event.DeferredEventNotification$1.execute(DeferredEventNotification.java:63)
	at org.jboss.weld.event.DeferredEventNotification$RunInRequest.run(DeferredEventNotification.java:100)
	at org.jboss.weld.event.DeferredEventNotification.run(DeferredEventNotification.java:57)
	at org.jboss.weld.event.TransactionSynchronizedRunnable.afterCompletion(TransactionSynchronizedRunnable.java:54)
	at com.sun.jts.jta.SynchronizationImpl.after_completion(SynchronizationImpl.java:156)
	at com.sun.jts.CosTransactions.RegisteredSyncs.distributeAfter(RegisteredSyncs.java:191)
	at com.sun.jts.CosTransactions.TopCoordinator.afterCompletion(TopCoordinator.java:2589)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:414)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:622)
	at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:331)
	at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:174)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
	at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:719)
	at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:503)
	at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
	at org.glassfish.ejb.mdb.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1326)
	at org.glassfish.ejb.mdb.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1301)
	at org.glassfish.ejb.mdb.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:86)
	at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:143)
	at com.sun.proxy.$Proxy258.afterDelivery(Unknown Source)
	at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:361)
	at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
	at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
	at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
]]

I'm attaching a PoC that can be easily built and deployed.



 Comments   
Comment by fmachado [ 20/Jan/16 ]

I uploaded the PoC and complete server log files ( from both 4.1 and 4.1.1 versions) to my Dropbox account:
https://www.dropbox.com/sh/abpmiiriqmc50sp/AAAMvvbeM__xV5yOrl85WSOja

Deploy, open http://localhost:8080/jeetest-web/MyServlet?payload=somepayload and check your server.log file.

Thanks for your help guys!

Comment by gimlet [ 01/Feb/16 ]

Hi! I had explored that issue. Updating of Weld to version 2.2.16-Final solves it.

Comment by rhadoo_io [ 07/Mar/16 ]

i get a similar exception:

[2016-03-07T13:14:41.224+0000] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=170 _ThreadName=__ejb-thread-pool1] [timeMillis: 1457356481224] [levelValue: 900] [[
Exception during Singleton ResourceHandler processing
java.lang.IllegalStateException: Transaction is not active in the current thread.
at com.sun.enterprise.transaction.JavaEETransactionImpl.checkTransationActive(JavaEETransactionImpl.java:722)
at com.sun.enterprise.transaction.JavaEETransactionImpl.registerSynchronization(JavaEETransactionImpl.java:692)
at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.checkTransaction(SimpleEjbResourceHandlerImpl.java:120)
at com.sun.ejb.containers.SimpleEjbResourceHandlerImpl.getResourceList(SimpleEjbResourceHandlerImpl.java:96)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getExistingResourceList(JavaEETransactionManagerSimplified.java:610)
at com.sun.enterprise.resource.pool.PoolManagerImpl.handleLazilyAssociatedConnectionPools(PoolManagerImpl.java:606)
at com.sun.enterprise.resource.pool.PoolManagerImpl.postInvoke(PoolManagerImpl.java:596)
at com.sun.enterprise.resource.pool.PoolManagerImpl.afterPostInvoke(PoolManagerImpl.java:575)
at org.glassfish.api.invocation.InvocationManagerImpl.postInvoke(InvocationManagerImpl.java:244)
at org.glassfish.jms.injection.AbstractJMSContextManager.cleanup(AbstractJMSContextManager.java:141)
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:497)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98)
at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:91)
at org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:131)
at org.glassfish.jms.injection.JMSCDIExtension$LocalPassivationCapableBean.destroy(JMSCDIExtension.java:216)
at org.jboss.weld.util.bean.IsolatedForwardingBean.destroy(IsolatedForwardingBean.java:50)
at org.glassfish.cdi.transaction.TransactionScopedBean.afterCompletion(TransactionScopedBean.java:112)
at com.sun.jts.jta.SynchronizationImpl.after_completion(SynchronizationImpl.java:146)
at com.sun.jts.CosTransactions.RegisteredSyncs.distributeAfter(RegisteredSyncs.java:191)
at com.sun.jts.CosTransactions.TopCoordinator.afterCompletion(TopCoordinator.java:2589)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:414)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:622)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:331)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:175)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
at com.sun.ejb.containers.EJBContainerTransactionManager.completeNewTx(EJBContainerTransactionManager.java:723)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:519)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4566)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2074)
at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:114)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

but upgrading weld doesn't seem to help:
asadmin osgi lb | grep 'Weld OSGi'
29|Resolved | 1|Weld OSGi Bundle (2.2.16.Final)





[GLASSFISH-21640] JMS message in server.log is logged only message key. Created: 16/Dec/16  Updated: 16/Feb/17  Resolved: 01/Feb/17

Status: Closed
Project: glassfish
Component/s: jms
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yama0428 Assignee: mskdeepak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JMS message in server.log is logged only message key.
So I can not check the url of the broker.

[2016-12-16T10:16:34.857+0900] [glassfish 4.1] [INFO] [] [javax.enterprise.resource.jms] [tid: _ThreadID=74 _ThreadName=Recovery Helper Thread] [timeMillis: 1481850994857] [levelValue: 800] [[
  addresslist.setjmsservice.provider]]

[2016-12-16T10:16:34.858+0900] [glassfish 4.1] [INFO] [] [javax.enterprise.resource.jms] [tid: _ThreadID=74 _ThreadName=Recovery Helper Thread] [timeMillis: 1481850994858] [levelValue: 800] [[
  jms.connection.url]]

I think this is regression.
After rev. 62588, LogDomains is not used in appserver/jms/jms-core.

MQAddressList.java before rev.62588
    static Logger logger = LogDomains.getLogger(MQAddressList.class,  LogDomains.JMS_LOGGER);
MQAddressList.java after rev.62588
    private static final Logger logger = Logger.getLogger(ActiveJmsResourceAdapter.JMS_MAIN_LOGGER);

So I think LogDomains should be used again to obtain the valid logger.



 Comments   
Comment by mskdeepak [ 05/Jan/17 ]

The change mentioned above(rev. 62588) has changed the logger object.
Earlier, the following used to work:

ActiveJmsResourceAdapter.java:1595
_logger.log(Level.INFO, "jms.connection.url", val);

Now, since we are not using LogDomains, this is not working. So, the following change needs to be made:

ActiveJmsResourceAdapter.java:1595
_logger.log(Level.INFO, "jms.connection.url : {0}", new Object[]{val});

The changes made in revision 62588 have changed the logger objects in the JMS module. We need to make the corresponding changes(as shown above) for other log messages affected in this module.

Comment by mskdeepak [ 30/Jan/17 ]

Rather than the above temporary solution, this bug requires a change in JMS logging according to the logging guide(https://glassfish.java.net/wiki-archive/Logging%20Guide.html).

Comment by mskdeepak [ 01/Feb/17 ]

Resolved in r64458





[GLASSFISH-21680] Appclient embedded-RA accessibility check on RA lookup is incorrect and is bypassed anyway on subsequent lookups Created: 16/Feb/17  Updated: 16/Feb/17

Status: Open
Project: glassfish
Component/s: other
Affects Version/s: 3.1.2.2, 4.0, 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregn123 Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If a Glassfish appclient program invokes an Embedded Resource Adapter, Glassfish performs an accessibility check on lookup() of the RA, to ensure that "only the application that has the embedded resource adapter can access the resource adapter".
Problem is, this check doesn't work properly. For such an application, it causes (the first) lookup() of the RA to fail, reporting that the application is not allowed to access the RA.
Worse, if a subsequent lookup() of the RA is attempted, it works fine (so the check is bypassed anyway).

I believe that this issue has existed in GlassfishV3 onwards.

I have created a JavaEE application that reproduces the problem. I have tried to keep it as simple as possible.

The following files are provided:

TestRAEAR.ear: EAR file which includes appclient program and embedded resource adapter
setup.bat: Batch file to deploy the application, create necessary RA resources, retrieve client stubs etc.
runclient.bat: Runs the appclient program
cleanup.bat: Batch file to undeploy the application and cleanup etc.

### Please see the comments below for this bug report, for a link to the GitHub repository containing these files. ###

The client application source code (included within the client in the EAR file) is simply:


import javax.naming.InitialContext;
import javax.jms.ConnectionFactory;

public class Main {
	public static void main(String[] args) {
		ConnectionFactory cf = null;
		try {
			InitialContext context = new InitialContext();
			cf = (ConnectionFactory)context.lookup("eis/genericra");
		} catch (Exception ex) {
			ex.printStackTrace();
			System.exit(1);
		} finally {
			/* nothing, yet */
		}
		return;
	}

	public Main() {
		super();
	}
}

Follow the steps below to reproduce the issue:

1) Edit each of the batch files and make sure GF_HOME and JAVA_HOME are set correctly to match your environment.
2) Make sure that Glassfish application server is running (e.g. "asadmin start-domain")
3) Run "setup.bat"
4) Run "runclient.bat" to run the appclient application. A stacktrace like the following is produced:


javax.naming.CommunicationException: Communication exception for SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitConte
xtFactory, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl} [Root
exception is java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.RemoteException: ; nested exception is:
        javax.naming.NamingException: Unable to lookup resource : eis/genericra [Root exception is javax.naming.NamingException: Lookup failed for 'eis/genericr
a' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.
presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Only the applica
tion that has the embedded resource adapter [ TestRAEAR#genericra ] can access the resource adapter]]]
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:513)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
        at javax.naming.InitialContext.lookup(InitialContext.java:417)
        at Main.main(Main.java:10)
        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:498)
        at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:446)
        at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:184)
        at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
Caused by: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.RemoteException: ; nested exception is:
        javax.naming.NamingException: Unable to lookup resource : eis/genericra [Root exception is javax.naming.NamingException: Lookup failed for 'eis/genericr
a' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.
presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Only the applica
tion that has the embedded resource adapter [ TestRAEAR#genericra ] can access the resource adapter]]
        at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:230)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:211)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
        at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
        at com.sun.enterprise.naming.impl._SerialContextProvider_DynamicStub.lookup(com/sun/enterprise/naming/impl/_SerialContextProvider_DynamicStub.java)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)
        ... 10 more
Caused by: java.rmi.RemoteException: ; nested exception is:
        javax.naming.NamingException: Unable to lookup resource : eis/genericra [Root exception is javax.naming.NamingException: Lookup failed for 'eis/genericr
a' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.
presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Only the applica
tion that has the embedded resource adapter [ TestRAEAR#genericra ] can access the resource adapter]]
        at com.sun.enterprise.naming.impl.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:146)
        at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
        at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
        at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
        at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
        at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
        at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
        at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
        at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
        at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
        at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
        at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
        at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
        at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: javax.naming.NamingException: Unable to lookup resource : eis/genericra [Root exception is javax.naming.NamingException: Lookup failed for 'eis/gener
icra' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.im
pl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NamingException: Only the appl
ication that has the embedded resource adapter [ TestRAEAR#genericra ] can access the resource adapter]]
        at org.glassfish.resourcebase.resources.api.ResourceProxy.throwResourceNotFoundException(ResourceProxy.java:113)
        at org.glassfish.resourcebase.resources.api.ResourceProxy.create(ResourceProxy.java:89)
        at com.sun.enterprise.naming.impl.RemoteSerialContextProviderImpl.lookup(RemoteSerialContextProviderImpl.java:137)
        ... 16 more
Caused by: javax.naming.NamingException: Lookup failed for 'eis/genericra' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.Se
rialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.n
aming} [Root exception is javax.naming.NamingException: Only the application that has the embedded resource adapter [ TestRAEAR#genericra ] can access the resou
rce adapter]
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
        at javax.naming.InitialContext.lookup(InitialContext.java:417)
        at javax.naming.InitialContext.lookup(InitialContext.java:417)
        at org.glassfish.resourcebase.resources.naming.ResourceNamingService.lookup(ResourceNamingService.java:236)
        at org.glassfish.resourcebase.resources.api.ResourceProxy.create(ResourceProxy.java:87)
        ... 17 more
Caused by: javax.naming.NamingException: Only the application that has the embedded resource adapter [ TestRAEAR#genericra ] can access the resource adapter
        at com.sun.enterprise.resource.naming.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:123)
        at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
        at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:527)
        at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:487)
        ... 22 more

5) Run "runclient.bat" to run the appclient application AGAIN. Output like the following is produced (i.e. runs without error):

Mmm DD, 2017 H:MM:SS XX org.hibernate.validator.internal.util.Version <clinit>
INFO: HV000001: Hibernate Validator 5.2.4.Final
Mmm DD, 2017 H:MM:SS XX com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl sendStopToResourceAdapter
INFO: RAR7094: TestRAEAR#genericra shutdown successful.

You can run the application again and again, and it runs without the error seen on the first lookup().

If you stop and restart the application server and re-run the client application, the stacktrace occurs again when it's run the first time.

e.g.

asadmin restart-domain
runclient.bat

6) Run "cleanup.bat" to undeploy the application and cleanup etc.

Possible Resolution:

I tracked down the cause of this problem in the app server, to the "checkAccessibility()" method in the "com.sun.enterprise.connectors.service.ConnectorService" class (connectors-runtime.jar). It's checking the classloader of the accessing class against the classloaders in the classloader hierarchy of the parent of the classloader that loaded that RAR file, hoping to find match. I can't see how it could ever find a match (and thus allow access) because we're comparing classloaders used at runtime against those used at deployment. Maybe it used to work on an old version of Glassfish - maybe.
Anyway, it is interesting that there is a commented-out condition in the source code, in the accessibility check:

    public boolean checkAccessibility(String rarName, ClassLoader loader) {
        ActiveResourceAdapter ar = _registry.getActiveResourceAdapter(rarName);
        if (ar != null && loader != null) { // If RA is deployed

            ClassLoader rarLoader = ar.getClassLoader();

            //If the RAR is not standalone.
            if (rarLoader != null && ConnectorAdminServiceUtils.isEmbeddedConnectorModule(rarName)
                /*&& (!(rarLoader instanceof ConnectorClassFinder))*/) {
                ClassLoader rarLoaderParent = rarLoader.getParent();
                ClassLoader parent = loader;
                while (true) {
                ...

If this is uncommented and the class re-built, then the accessibility check succeeds (at least in the case of this test program) and the error doesn't occur.

So, given that the commented-out code should actually be enabled, we have the following patch:


Index: ConnectorService.java
===================================================================
--- ConnectorService.java	(revision 64551)
+++ ConnectorService.java	(working copy)
@@ -43,6 +43,7 @@
 import com.sun.appserv.connectors.internal.api.ConnectorConstants;
 import com.sun.appserv.connectors.internal.api.ConnectorRuntimeException;
 import com.sun.appserv.connectors.internal.api.ConnectorsUtil;
+import com.sun.appserv.connectors.internal.api.ConnectorClassFinder;
 import com.sun.enterprise.config.serverbeans.Resource;
 import com.sun.enterprise.config.serverbeans.ResourcePool;
 import com.sun.enterprise.connectors.ActiveResourceAdapter;
@@ -380,7 +381,7 @@
 
             //If the RAR is not standalone.
             if (rarLoader != null && ConnectorAdminServiceUtils.isEmbeddedConnectorModule(rarName)
-                /*&& (!(rarLoader instanceof ConnectorClassFinder))*/) {
+                && (!(rarLoader instanceof ConnectorClassFinder))) {
                 ClassLoader rarLoaderParent = rarLoader.getParent();
                 ClassLoader parent = loader;
                 while (true) {

I looked back at the history of the ConnectorService class. It seems like the code above was checked-in for GlassfishV3 with the "&& (!(rarLoader instanceof ConnectorClassFinder))" commented-out. No explanation as to why. So it's been like this for a long time.



 Comments   
Comment by gregn123 [ 16/Feb/17 ]

Please refer to files located here: https://github.com/gregn123/GLASSFISH-21680





[GLASSFISH-21673] Implement default-context-path Created: 09/Feb/17  Updated: 15/Feb/17

Status: In Progress
Project: glassfish
Component/s: web_container
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 3 Sprint 2

 Description   

See SERVLET_SPEC-137






[GLASSFISH-21633] http-compression web devtest fails Created: 09/Dec/16  Updated: 15/Feb/17

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: jwells
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

build:
[mkdir] Created dir: /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/devtests/web/httpCompression/build
[javac] /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/devtests/web/httpCompression/build.xml:74: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 1 source file to /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/devtests/web/httpCompression/build

all:
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=on
[java] configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=on
[java]
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=force
[java] configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=force
[java]
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=false
[java]
[java] remote failure: javax.validation.ValidationException: HV000149: An exception occurred during message interpolation
[java] HV000149: An exception occurred during message interpolation
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=true
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=1024
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=off
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=on
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=force
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=false
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=true
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=1024
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] asadmin --host localhost.localdomain --port 45707 --user admin --passwordfile /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true set configs.config.server-config.network-config.protocols.protocol.http-listener-1.http.compression=off
[java]
[java] remote failure: Could not change the attributes: Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java] Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http
[java]
[java] Generating report at /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - gzip-compressed-output-off: PASS -
[java] - gzip-set-compression-on: PASS -
[java] - gzip-compressed-output-on: PASS -
[java] - gzip-set-compression-force: PASS -
[java] - gzip-compressed-output-force: PASS -
[java] - gzip-set-compression-false: PASS -
[java] - gzip-set-compression-true: PASS -
[java] - gzip-set-compression-1024: FAIL -
[java] - gzip-compressed-output-1024: PASS -
[java] - gzip-set-compression-off: FAIL -
[java] - gzip-compressed-output-off-2: PASS -
[java] - lzma-compressed-output-off: PASS -
[java] - lzma-set-compression-on: FAIL -
[java] - lzma-compressed-output-on: PASS -
[java] - lzma-set-compression-force: FAIL -
[java] - lzma-compressed-output-force: PASS -
[java] - lzma-set-compression-false: PASS -
[java] - lzma-set-compression-true: PASS -
[java] - lzma-set-compression-1024: FAIL -
[java] - lzma-compressed-output-1024: PASS -
[java] - lzma-set-compression-off: FAIL -
[java] - lzma-compressed-output-off-2: PASS -
[java] -----------------------------------------
[java] - Total PASS : 16 -
[java] - Total FAIL : 6 -
[java] - Total DID NOT RUN : 0 -
[java] -----------------------------------------

Continuous build:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-trunk-web-devtests-continuous/lastSuccessfulBuild/artifact/appserv-tests/test_results.html

Nightly build:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-lw-web-devtests/406/artifact/appserv-tests/test_results.html



 Comments   
Comment by liangzzhang [ 12/Jan/17 ]

[2017-01-07T10:59:34.325+0800] [glassfish 5.0] [SEVERE] [NCLS-CORE-00003] [javax.enterprise.system.core] [tid: _ThreadID=66 _ThreadName=admin-listener(1)] [timeMillis: 1483757974325] [levelValue: 1000] [[
Exception while running a command
javax.validation.ValidationException: HV000149: An exception occurred during message interpolation
at org.hibernate.validator.internal.engine.ValidationContext.interpolate(ValidationContext.java:431)
at org.hibernate.validator.internal.engine.ValidationContext.createConstraintViolation(ValidationContext.java:300)
at org.hibernate.validator.internal.engine.ValidationContext.createConstraintViolations(ValidationContext.java:261)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateSingleConstraint(ConstraintTree.java:456)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateConstraints(ConstraintTree.java:127)
at org.hibernate.validator.internal.engine.constraintvalidation.ConstraintTree.validateConstraints(ConstraintTree.java:87)
at org.hibernate.validator.internal.metadata.core.MetaConstraint.validateConstraint(MetaConstraint.java:73)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateMetaConstraint(ValidatorImpl.java:617)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:580)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForSingleDefaultGroupElement(ValidatorImpl.java:524)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:492)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:457)
at org.hibernate.validator.internal.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:407)
at org.hibernate.validator.internal.engine.ValidatorImpl.validate(ValidatorImpl.java:205)
at org.jvnet.hk2.config.WriteableView.canCommit(WriteableView.java:316)
at org.jvnet.hk2.config.Transaction.canCommit(Transaction.java:90)
at org.jvnet.hk2.config.Transaction.commit(Transaction.java:109)
at org.jvnet.hk2.config.ConfigSupport.apply(ConfigSupport.java:395)
at com.sun.enterprise.v3.admin.SetCommand.set(SetCommand.java:481)
at com.sun.enterprise.v3.admin.SetCommand.execute(SetCommand.java:178)
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:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:407)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.MissingResourceException: Can't find bundle for base name org.hibernate.validator.ValidationMessages, locale en_US
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1564)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1387)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:1082)
at org.jvnet.hk2.config.MessageInterpolatorImpl.interpolate(MessageInterpolatorImpl.java:151)
at org.jvnet.hk2.config.MessageInterpolatorImpl.interpolate(MessageInterpolatorImpl.java:111)
at org.hibernate.validator.internal.engine.ValidationContext.interpolate(ValidationContext.java:422)
... 77 more
]]

Comment by liangzzhang [ 12/Jan/17 ]

The issue is caused by "Config bean already locked GlassFishConfigBean.org.glassfish.grizzly.config.dom.Http". Then all the following tests could not set config correctly.
The Config bean was locked because "java.util.MissingResourceException: Can't find bundle for base name org.hibernate.validator.ValidationMessages, locale en_US". This is called by org.jvnet.hk2.config.MessageInterpolatorImpl.interpolate.
I noticed that Glassfish already had a JIRA TASK GLASSFISH-15196 for the current issue.

Comment by jwells [ 15/Feb/17 ]

Is this intermittent? I just ran it and it worked for me:

[java] -----------------------------------------
[java] - gzip-compressed-output-off: PASS -
[java] - gzip-set-compression-on: PASS -
[java] - gzip-compressed-output-on: PASS -
[java] - gzip-set-compression-force: PASS -
[java] - gzip-compressed-output-force: PASS -
[java] - gzip-set-compression-false: PASS -
[java] - gzip-set-compression-true: PASS -
[java] - gzip-set-compression-1024: PASS -
[java] - gzip-compressed-output-1024: PASS -
[java] - gzip-set-compression-off: PASS -
[java] - gzip-compressed-output-off-2: PASS -
[java] - lzma-compressed-output-off: PASS -
[java] - lzma-set-compression-on: PASS -
[java] - lzma-compressed-output-on: PASS -
[java] - lzma-set-compression-force: PASS -
[java] - lzma-compressed-output-force: PASS -
[java] - lzma-set-compression-false: PASS -
[java] - lzma-set-compression-true: PASS -
[java] - lzma-set-compression-1024: PASS -
[java] - lzma-compressed-output-1024: PASS -
[java] - lzma-set-compression-off: PASS -
[java] - lzma-compressed-output-off-2: PASS -
[java] -----------------------------------------
[java] - Total PASS : 22 -
[java] - Total FAIL : 0 -
[java] - Total DID NOT RUN : 0 -
[java] -----------------------------------------





[GLASSFISH-21520] file user commands fail if server instance is running. Created: 02/Mar/16  Updated: 15/Feb/17

Status: Open
Project: glassfish
Component/s: admin, security
Affects Version/s: 4.1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yama0428 Assignee: Yamini K B
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

asadmin create-file-user command always fails if server instance is running.

D:\glassfish4\glassfish\bin>asadmin start-cluster cluster
Command start-cluster executed successfully.

D:\glassfish4\glassfish\bin>asadmin start-cluster cluster2
Command start-cluster executed successfully.

D:\glassfish4\glassfish\bin>asadmin create-file-user --target cluster2 myuser1
Enter the user password>
Enter the user password again>
remote failure: An error occurred during replication
Failure: Command create-file-user failed on server instance instance: remote failure: Configuration for target cluster2 not found.
Command create-file-user failed.

D:\glassfish4\glassfish\bin>asadmin create-file-user --target server myuser2
Enter the user password>
Enter the user password again>
remote failure: An error occurred during replication
Failure: Command create-file-user failed on server instance instance: remote failure: Configuration for target server not found.
Failure: Command create-file-user failed on server instance cluster2_1: remote failure: Configuration for target server not found.
Command create-file-user failed.

The same problem exists in update-file-user, delete-file-user command.

D:\glassfish4\glassfish\bin>asadmin update-file-user --target server --groups group1 myuser2
remote failure: An error occurred during replication
Failure: Command update-file-user failed on server instance instance: remote failure: Configuration for target server not found.
Failure: Command update-file-user failed on server instance cluster2_1: remote failure: Configuration for target server not found.
Command update-file-user failed.
D:\glassfish4\glassfish\bin>asadmin delete-file-user --target server  myuser2
remote failure: An error occurred during replication
Failure: Command delete-file-user failed on server instance instance: remote failure: Configuration for target server not found.
Failure: Command delete-file-user failed on server instance cluster2_1: remote failure: Configuration for target server not found.
Command delete-file-user failed.


 Comments   
Comment by gururaja1234 [ 15/Feb/17 ]

seems this issue belongs to admin module.





[GLASSFISH-21370] Periodic Deadlock in EJB Timer Service Created: 02/Jun/15  Updated: 15/Feb/17

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0
Fix Version/s: None

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

Red Hat Enterprise Linux 6



 Description   

Occasionally while attempting to redeploy an application the redeployment will fail due to what appears to be a deadlock situation with the EJB Timer service. This happens fairly infrequently, perhaps 6 times in the last two years. However, when it does happen the only recourse is to restart GlassFish forcefully, which is fairly invasive since the redeploy with the "--keepstate=true" option allows redeployment without downtime. The problem prevents all application deployment/redeployment/undeployment, and GlassFish starting/stopping/restarting so during one of these events I must forcefully kill the Glassfish process (kill -9 on Linux) . It appears that the EJB Timer Service uses the EclipseLink ORM library to store timer information in a Derby database and encounters a Lock timeout situation. The stack trace from the most recent incident follows:

[2015-06-02T12:32:53.965-0400] [glassfish 4.0] [WARNING] [] [org.eclipse.persistence.session.file:/opt/glassfish/4/glassfish/domains/domain1/applications/ejb-timer-service-app/WEB-INF/classes/___EJB__Timer__App] [tid: _ThreadID=5374 _ThreadName=Thread-2966] [timeMillis: 1433262773965] [levelValue: 900] [[

Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
Error Code: 30000
Call: SELECT "TIMERID" FROM "EJB_TIMER_TBL" WHERE ("CONTAINERID" = ?)
bind => [1 parameter bound]
Query: ReportQuery(name="findTimerIdsByContainer" referenceClass=TimerState sql="SELECT "TIMERID" FROM "EJB_TIMER_TBL" WHERE ("CONTAINERID" = ?)")
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:679)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
at org.eclipse.persistence.sessions.server.ClientSession.executeCall(ClientSession.java:248)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:299)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:694)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2714)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllReportQueryRows(ExpressionQueryMechanism.java:2651)
at org.eclipse.persistence.queries.ReportQuery.executeDatabaseQuery(ReportQuery.java:847)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:899)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1114)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:402)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1202)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2894)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1797)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1779)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1744)
at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:468)
at org.glassfish.ejb.persistent.timer.TimerBean.findTimerIdsByContainer(TimerBean.java:115)
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:497)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy307.findTimerIdsByContainer(Unknown Source)
at org.glassfish.ejb.persistent.timer.PersistentEJBTimerService.stopTimers(PersistentEJBTimerService.java:643)
at com.sun.ejb.containers.BaseContainer.stopTimers(BaseContainer.java:2422)
at com.sun.ejb.containers.BaseContainer.onShutdown(BaseContainer.java:4191)
at org.glassfish.ejb.startup.SingletonLifeCycleManager.doShutdown(SingletonLifeCycleManager.java:172)
at org.glassfish.ejb.startup.EjbApplication.stop(EjbApplication.java:293)
at org.glassfish.internal.data.EngineRef.stop(EngineRef.java:161)
at org.glassfish.internal.data.ModuleInfo.stop(ModuleInfo.java:324)
at org.glassfish.internal.data.ApplicationInfo.stop(ApplicationInfo.java:380)
at com.sun.enterprise.v3.server.ApplicationLifecycle.unload(ApplicationLifecycle.java:1056)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:2125)
at com.sun.enterprise.v3.server.ApplicationLifecycle.disable(ApplicationLifecycle.java:113)
at com.sun.enterprise.v3.server.ApplicationLoaderService.stopApplication(ApplicationLoaderService.java:497)
at com.sun.enterprise.v3.server.ApplicationLoaderService.preDestroy(ApplicationLoaderService.java:465)
at org.jvnet.hk2.internal.ClazzCreator.preDestroyMe(ClazzCreator.java:294)
at org.jvnet.hk2.internal.ClazzCreator.dispose(ClazzCreator.java:358)
at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:473)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.destroyOne(AsyncRunLevelContext.java:196)
at org.jvnet.hk2.internal.ServiceHandleImpl.destroy(ServiceHandleImpl.java:159)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$DownAllTheWay.run(CurrentTaskFuture.java:583)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture.go(CurrentTaskFuture.java:120)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.proceedTo(AsyncRunLevelContext.java:296)
at org.glassfish.hk2.runlevel.internal.RunLevelControllerImpl.proceedTo(RunLevelControllerImpl.java:66)
at com.sun.enterprise.v3.server.AppServerStartup.proceedTo(AppServerStartup.java:532)
at com.sun.enterprise.v3.server.AppServerStartup.stop(AppServerStartup.java:485)
at com.sun.enterprise.glassfish.bootstrap.GlassFishImpl.stop(GlassFishImpl.java:88)
at com.sun.enterprise.glassfish.bootstrap.GlassFishDecorator.stop(GlassFishDecorator.java:68)
at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl.stop(EmbeddedOSGiGlassFishImpl.java:82)
at com.sun.enterprise.v3.admin.StopServer.doExecute(StopServer.java:79)
at com.sun.enterprise.v3.admin.StopDomainCommand.execute(StopDomainCommand.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at org.glassfish.api.AsyncImpl$1$1.run(AsyncImpl.java:76)
Caused by: java.sql.SQLTransactionRollbackException: A lock could not be obtained within the time requested
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.closeOnTransactionError(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedResultSet.next(Unknown Source)
at com.sun.gjc.spi.base.ResultSetWrapper.next(ResultSetWrapper.java:103)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processResultSet(DatabaseAccessor.java:754)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:653)
... 80 more
Caused by: java.sql.SQLException: A lock could not be obtained within the time requested
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 92 more
Caused by: ERROR 40XL1: A lock could not be obtained within the time requested
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentLockSet.zeroDurationLockObject(Unknown Source)
at org.apache.derby.impl.services.locks.AbstractPool.zeroDurationlockObject(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentPool.zeroDurationlockObject(Unknown Source)
at org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForRead(Unknown Source)
at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lockPositionForRead(Unknown Source)
at org.apache.derby.impl.store.access.conglomerate.GenericScanController.fetchRows(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapScan.fetchNextGroup(Unknown Source)
at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(Unknown Source)
at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown Source)
... 85 more
]]

[2015-06-02T12:32:53.970-0400] [glassfish 4.0] [WARNING] [ejb.system_exception] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=5374 _ThreadName=Thread-2966] [timeMillis: 1433262773970] [levelValue: 900] [[
EJB5184:A system exception occurred during an invocation on EJB TimerBean, method: public java.util.Set org.glassfish.ejb.persistent.timer.TimerBean.findTimerIdsByContainer(long)]]



 Comments   
Comment by slominskir [ 02/Jun/15 ]

The stack trace above shows that it is impossible to cleanly shutdown GlassFish when the EJB Timer service is stuck in this unusual state. Deployment is also impossible.

Comment by gururaja1234 [ 15/Feb/17 ]

can you look at this link https://wiki.apache.org/db-derby/LockDebugging.
it has more information about "Configuring deadlock detection and lock wait timeouts"





[GLASSFISH-21476] Resource not available in @Singleton @Predestroy method Created: 22/Dec/15  Updated: 15/Feb/17

Status: In Progress
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

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

openjdk version "1.8.0_66
Ubuntu 15.10



 Description   

It seems like resources are not available to a Singleton's @Predestroy method.

@PreDestroy
public void cleanup() {
logger.info("*** Application shutting down. Dropping temporary tables ***");
try

{ connection = dataSource.getConnection(); Statement statement = connection.createStatement(); statement.execute("drop table TABLE1"); statement.execute("drop table TABLE2"); connection.close(); connection = null; }

catch (SQLException sqle)

{ sqle.printStackTrace(); }

}
The call to getConnection() fails with the error "No Pool Meta Data object associated with the pool". Note that the getConnection() call is successful in the @PostConstruct methods.

Is it a Bug in the application server implementation? If not, what is the most elegant way to drop temporary tables?

(Using Glassfish 4.1.1 + Derby DB. The datasource is created using glassfish-resources.xml deployed with the EAR

<resources>
<jdbc-resource pool-name="EmbeddedDerbyPool"
jndi-name="java:app/jdbc/ActionBazaarDS" />
<jdbc-connection-pool name="EmbeddedDerbyPool"
res-type="javax.sql.DataSource"
datasource-classname="org.apache.derby.jdbc.EmbeddedDataSource"
is-isolation-level-guaranteed="false">
<property name="databaseName" value="memory:action-bazaar-db"/>
<property name="createDatabase" value="create"/>
</jdbc-connection-pool>
</resources>



 Comments   
Comment by gururaja1234 [ 15/Feb/17 ]

Can you provide this feedback to the EJB 3.2 Expert Group.
and provide your feedback here https://java.net/projects/ejb-spec/lists/users/archive.





[GLASSFISH-21678] Resource definitions in a pojo of an app client module are not processed Created: 15/Feb/17  Updated: 15/Feb/17

Status: Open
Project: glassfish
Component/s: standalone_client
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pabhat Assignee: Kokil_Jain
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have noticed an issue with GlassFish (used 5.0 for my testing, probably this issue is there in the earlier versions as well) where the Java EE resource definitions in POJOs of an application client module are not processed by the application client container. However the resource definitions in POJOs of of a web module (probably same holds good for an EJB module as well, although I have not tested that) are processed during deployment.



 Comments   
Comment by pabhat [ 15/Feb/17 ]

I don't see a way to attach the sample .ear file, may be I don't have the necessary permissions. I will send the sample app and the instructions I have followed to Yamini, over e-mail.





[GLASSFISH-21679] Remove delete option for JDBC Resource jdbc/__default Created: 15/Feb/17  Updated: 15/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 5.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: pabhat Assignee: prasads
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The default JDBC Resource with JNDI nme jdbc/__default is used internally for the Java EE platform spec defined default DataSource - java:comp/DefaultDataSource. Right now, deleting this resource from the admin console (probably using MBean operations as well) is possible. Once this JDBC resource is deleted, default DataSource won't be provisioned for Java EE applications, which is a must from the platform specification.

GlassFish should evaluate this and see whether delete option can be disabled for this JDBC resource.






[GLASSFISH-21672] Intermittent failures in gf-trunk-build-continuous Created: 06/Feb/17  Updated: 15/Feb/17

Status: In Progress
Project: glassfish
Component/s: bean-validator, sqe-test
Affects Version/s: 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: ankur.kathuria
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In gf-trunk-build-continuous, I notice that we have the following intermittent failures:
test.bv.servlet.simple.SimpleBVServletTestNG.executeServlet
test.jpa.jpavalidation.JpaValidationTestNG.validatePersist

e.g. http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/288/

In one of my local env, I almost see this happens all the time. But it is working for my another env.



 Comments   
Comment by Romain Grécourt [ 06/Feb/17 ]

See appserver/tests/quicklook/bean-validator

The test is composed of a servlet and a client:

  • BVIntegrationTestServlet(/test)
  • SimpleBVServletTestNG

The servlet outputs HTML that is parsed by the client to make assertions.
Here are the regular expression used by the client:

            String[] regexesToFind = {
		"(?s)(?m).*Obtained ValidatorFactory: org.hibernate.validator.(internal.)*engine.ValidatorFactoryImpl.*",
                "(?s)(?m).*case1: No ConstraintViolations found.*",
                "(?s)(?m).*case2: caught IllegalArgumentException.*",
                "(?s)(?m).*case3: ConstraintViolation: message: may not be null propertyPath: listOfString.*",
                "(?s)(?m).*case3: ConstraintViolation: message: may not be null propertyPath: lastName.*",
                "(?s)(?m).*case3: ConstraintViolation: message: may not be null propertyPath: firstName.*",
                "(?s)(?m).*case4: No ConstraintViolations found.*"
            };

Looking at the console output for an UNSTABLE run, I see the following:

[testng] FAILED: validatePersist
   [testng] java.lang.AssertionError: Unexpected Results expected:<true> but was:<false>
   [testng] 	at test.jpa.jpavalidation.JpaValidationTestNG.validatePersist(JpaValidationTestNG.java:86)
   [testng] ... Removed 26 stack frames
   [testng] SKIPPED: validateUpdate

The original response content is not printed out by the test.
We need to update the test client to print the full reponse in case assertions failed.

Comment by Shing Wai Chan [ 07/Feb/17 ]

We got a 500 status code with the following stack trace in server.log:

StandardWrapperValve[SimpleBVServlet]: Servlet.service() for servlet SimpleBVServlet threw exception
javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:110)
at simple_bv_servlet.SimpleBVServlet.doGet(SimpleBVServlet.java:67)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1580)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:258)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:652)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:591)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
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:526)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573)
at java.lang.Thread.run(Thread.java:745)

Comment by ankur.kathuria [ 13/Feb/17 ]

Not able to reproduce the issue locally, but looking at above stackTrace it seems hibernate-validator.jar is not available/loaded. While the test failure in hudson is because of validation violation.

I had added few logging statement in SimpleBVServlet which shows that
" violations = beanValidator.validateValue(Person.class, "nonExistentProperty", listOfString);"
is not throwing IllegalArgumentException (which is expected) intermittently.

Latest failed job: http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-trunk-ql-continuous/573/
Continuing with further analysis.

Comment by Shing Wai Chan [ 14/Feb/17 ]

I have updated my workspace and rerun QL locally. The above exception is gone. Look like "case2" is missing.

[testng] Response content:
[testng] <html><head><title>SimpleBVServlet</title></head><body><p>Obtained ValidatorFactory: org.hibernate.validator.internal.engine.ValidatorFactoryImpl@4e8dd3bb.</p><h1>Validating person class using validateValue with valid property</h1><p>case1: No ConstraintViolations found.</p><h1>Validating person class using validateValue with invalid property</h1><h1>Validating invalid person instance using validate.</h1><p>case3: No ConstraintViolations found.</p><h1>Validating valid person.</h1><p>case4: No ConstraintViolations found.</p></body></html>
[testng]
[testng] FAILED: executeServlet
[testng] java.lang.AssertionError: Unable to find match for regex (?s)(?m).case2: caught IllegalArgumentException. in output from request to http://localhost:8080/simple-bv-servlet/test expected:<true> but was:<false>
[testng] at test.bv.servlet.simple.SimpleBVServletTestNG.executeServlet(SimpleBVServletTestNG.java:135)
[testng] ... Removed 25 stack frames
[testng]
[testng] ===============================================
[testng] bv_servlet_simple
[testng] Tests run: 1, Failures: 1, Skips: 0
[testng] ===============================================

Comment by ankur.kathuria [ 15/Feb/17 ]

Is this test failure consistent in your local environment ?





[GLASSFISH-21543] Invalid resource when using application scoped resource in EAR Created: 17/May/16  Updated: 15/Feb/17

Status: In Progress
Project: glassfish
Component/s: None
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: petrhejl Assignee: srinik76
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

1) create EE7 EAR project with ejb and web
2) define jdbc resource and pool using java:module scope in glassfish-resources.xml in ejb module
3) define persistence unit in ejb using the jdbc resource in ejb
4) define stateless session bean
5) inject EnitityManager to the bean:
@PersistenceContext(unitName = "myUnit")
private EntityManager em;
6) deploy the EAR and it will fail with invalid resource

Standalone web module using java:app works fine. Moving the persistence.xml and glassfish-resources.xml to EAR and using java:app also works fine.



 Comments   
Comment by petrhejl [ 17/May/16 ]

I may attach/provide sample project.

Comment by petrhejl [ 17/May/16 ]

I've attached the test project to original NetBeans issue.
https://netbeans.org/bugzilla/attachment.cgi?id=159782

Comment by srinik76 [ 15/Feb/17 ]

unable to import the project and requesting to attach the ear for reproducing the issue. adding the label waiting on filer.





[GLASSFISH-21666] Implement programmatic jsp-file Created: 25/Jan/17  Updated: 14/Feb/17  Resolved: 14/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 7 hours, 54 minutes
Original Estimate: Not Specified

Attachments: Text File 20170127-1551Z-SERVLET_SPEC-16-mods.patch     Text File 20170127-1601-GLASSFISH-21666.patch     File guessNumber-1.0.war    
Tags: servlet_4_0
Sprint: MS 3 Sprint 2

 Description   

See SERVLET_SPEC-16



 Comments   
Comment by Ed Burns [ 27/Jan/17 ]

Remove "whitespace only" changes at Shing-wai's request.

Comment by Ed Burns [ 27/Jan/17 ]

Diff with "whitespace only" changes removed, at Shing-wai's request.

Comment by Shing Wai Chan [ 14/Feb/17 ]

Per discussion in EG, we will add ServletContext#addJspFile rather than using the patch above.

Comment by Shing Wai Chan [ 14/Feb/17 ]

Sending web-core/src/main/java/org/apache/catalina/core/StandardContext.java
Sending web-glue/src/main/java/com/sun/enterprise/web/WebModule.java
Transmitting file data ..
Committed revision 64545.





[GLASSFISH-21244] appclient documentation tells CLASSPATH but APPCPATH must be used Created: 29/Oct/14  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: steffen_ Assignee: Kokil_Jain
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux


Tags: CLASSPATH, appclient

 Description   

Documentation [1] tells, "appclient" supports both CLASSPATH and -classpath, but none works (probably because internally "java -jar" is forced, which seems to ignore -classpath). This is very bad for testing, because to run the test via appclient, there are dependencies to EJB @Remote interfaces, junit or whatever.

Interestingly, there is an undocumented APPCPATH which works as expected for CLASSPATH. This took me almost a whole day, and I guess others could also trap into this pitfall, so I think at least the documentation should be fixed.

Transscript of the error:

$ CLASSPATH=XyzMockRemote-1.0.jar /home/glassfish/glassfish3/glassfish/bin/appclient -client IntegrationTest-1.0.jar
Exception in thread "main" java.lang.NoClassDefFoundError: com/.../XyzMockRemote

Documentation also mentioned -classpath, which does not work either. Fortunately there is APPCPATH working:

$ APPCPATH=XyzMockRemote-1.0.jar /home/glassfish/glassfish3/glassfish/bin/appclient -client IntegrationTest-1.0.jar
remote mock.getVersion() = Mock 1.0
...

[1] http://docs.oracle.com/cd/E26576_01/doc.312/e24938/appclient.htm






[GLASSFISH-21247] How to access admin console http instead of https Created: 04/Nov/14  Updated: 14/Feb/17

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

Type: Task Priority: Minor
Reporter: gtulasidhar Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

STAGE



 Description   

Hi Team,
We need access admin console http instead of https.

Could you please give me steps to do this.

Thanks,
Tulasidhar



 Comments   
Comment by smillidge-c2b2 [ 04/Nov/14 ]

Run

asadmin disable-secure-admin
asadmin restart-domain domain1

where domain1 is your domain name

Comment by gtulasidhar [ 05/Nov/14 ]

it is working in same system.i need remote system...could you please help me......

Comment by gtulasidhar [ 05/Nov/14 ]

Just i want use local or remote only with http....please help me on this.......

Comment by Anissa Lam [ 05/Nov/14 ]

For security reason, to access a remote system, it is requried that you enable secure admin and launch the admon console with https.
There is no way to use http for remote access.

Comment by gtulasidhar [ 06/Nov/14 ]

ok thanks for update.In same network computers not working,but working in windows servers.Is there any chance to work all same network systems ?

Thanks,
Tulasidhar

Comment by Anissa Lam [ 06/Nov/14 ]

I am not sure what you mean here. Please clarify.

Comment by Masoud Kalali [ 07/Dec/15 ]

Considering that I am no longer active in GlassFish space I am assigning all the tickets to Chris Kasso in Java EE/ Application Servers team and he can reassign them as appropriate.





[GLASSFISH-21256] Debug not shown correctly on General Information in the admin console Created: 15/Nov/14  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: smillidge-c2b2 Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When looking at the General Information of a stand alone instance or the DAS the Debug setting is not shown correctly if Debug is enabled in the JVM settings but not on the command line.



 Comments   
Comment by smillidge-c2b2 [ 15/Nov/14 ]

This Payara commit fixes the issue

https://github.com/payara/Payara/commit/cd27e368cd8b2de196f21d1c7fe47d4497487bec





[GLASSFISH-21259] admin-thread-pool is created after logging in the admin console Created: 26/Nov/14  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2.2, 4.1
Fix Version/s: None

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


 Description   

domain.xml of server-config has the definition of admin-thread-pool.

        <network-listeners>
          <network-listener port="8080" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="8181" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="4848" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="admin-thread-pool"></network-listener>
        </network-listeners>
        <transports>
          <transport name="tcp"></transport>
        </transports>
      </network-config>
      <thread-pools>
          <thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
          <thread-pool name="http-thread-pool" max-queue-size="4096"></thread-pool>
          <thread-pool name="thread-pool-1" max-thread-pool-size="200"/>
      </thread-pools>

On the other hand, default-config doesn't have admin-thread-pool,
and http-thread-pool is referenced by admin-listener.

             <network-listeners>
                 <network-listener address="0.0.0.0" port="${HTTP_LISTENER_PORT}" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool" />
                 <network-listener address="0.0.0.0" port="${HTTP_SSL_LISTENER_PORT}" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool" />
                 <network-listener port="${ASADMIN_LISTENER_PORT}" protocol="admin-listener" transport="tcp" name="admin-listener" thread-pool="http-thread-pool" />
             </network-listeners>
             <transports>
                 <transport name="tcp" />
             </transports>
         </network-config>
         <thread-pools>
             <thread-pool name="http-thread-pool" />
             <thread-pool max-thread-pool-size="200" idle-thread-timeout-in-seconds="120" name="thread-pool-1" />
         </thread-pools>

Therefore, created clusters don't have admin-thread-pool.

However, after logging in the admin console, admin-thread-pool is created to default-config and clusters.
Generated admin-thread-pool is not referenced by admin-listener, and admin-thread-pool seems to be a ejb-thread-pool.

        <network-listeners>
          <network-listener port="${HTTP_LISTENER_PORT}" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="${HTTP_SSL_LISTENER_PORT}" protocol="http-listener-2" transport="tcp" name="http-listener-2" thread-pool="http-thread-pool"></network-listener>
          <network-listener port="${ASADMIN_LISTENER_PORT}" protocol="pu-protocol" transport="tcp" name="admin-listener" thread-pool="http-thread-pool"></network-listener>
        </network-listeners>
        <transports>
          <transport name="tcp"></transport>
        </transports>
      </network-config>
      <thread-pools>
        <thread-pool name="http-thread-pool"></thread-pool>
        <thread-pool name="thread-pool-1" max-thread-pool-size="200"></thread-pool>
        <thread-pool name="admin-thread-pool" max-thread-pool-size="50" max-queue-size="256"></thread-pool>
      </thread-pools>

Why?






[GLASSFISH-21260] Cannot start instance on working cluster Created: 26/Nov/14  Updated: 14/Feb/17

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

Type: Bug Priority: Major
Reporter: dungld Assignee: pranjal.sahay
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 4.1 b13
Java 7 update 51 64bit
debian 7.5 64bit



 Description   

I built a Glassfish cluster work properly. It has 3 machine

  • 1 machine for DAS
  • 2 machines for SSH nodes.

SSH nodes are configured to connect database via Connection Pool

When I start the cluster from new, everything work well.

But when I stop 1 instance, and restart it, it take too long time to start and cannot work properly (it cannot auto run webapps are deployed).

I viewed log file on that instance, and found the last section:

[2014-11-26T15:57:21.217+0700] [glassfish 4.1] [INFO] [] [org.eclipse.persistence.session.file:/home/gbsofts/glassfish4/glassfish/nodes/gbweb1node/gbweb1instance/applications/gbear/gbeejb_jar/_gbePU] [tid: _ThreadID=15 _ThreadName=RunLevelControllerThread-1416992190038] [timeMillis: 1416992241217] [levelValue: 800] [[
EclipseLink, version: Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd]]

Every time I restart instance, it stop at this section.

What happen with this, Glassfish or EclipseLink or anything else?



 Comments   
Comment by davidwinters1980 [ 26/Nov/14 ]

Hi,

Could you take a stack trace after you have restarted the instance whereby the instance appears to hang? Also have you any ejb timer based applications deployed to the cluster?

Thanks,
David

Comment by dungld [ 26/Nov/14 ]

I stack trace glassfish at the hang moment as your request.

Please download here: https://drive.google.com/file/d/0B30EeVPAcvhvejJwRS1kVzZYR1E/view

They are 2 files:
stacktrace_1.log : data at the hang point appears
stacktrace_2.log: data after 5 minute when the hang appear

I don't use any EJB Timer on my application.

Thank you for support!

Comment by davidwinters1980 [ 26/Nov/14 ]

Hi,

Based on the stack traces you sent forward, this issue appears to be the same as https://java.net/jira/browse/GLASSFISH-21175

If you do not require XA transactions to be recovered on GF startup then disabling automatic recovery on the transaction manager should resolve this issue. This issue is a result of transaction recovery until to finish completely when GF starts up since there are other XA resources which are in use by other containers/services at server start up time. As a result the transaction recovery thread sits in a wait() indefinitely.

I have provided a patch for this in the jira above but it has not been merged into trunk however we have integrated a patch for this issue on Payara 4.1.144 which can be found here: http://www.payara.co.uk/downloads

If you wish to test with Payara and let us know if that helps.

Comment by davidwinters1980 [ 26/Nov/14 ]

Payara 4.1.144 commit: https://github.com/payara/Payara/commit/9e287e47b7ae18f571e8bb3adacae2b453082758

Comment by dungld [ 27/Nov/14 ]

Thank you for your comment. I disabled automatic recovery feature and that issue disappears. I have few question about this bug:
1. Why don’t Glassfish team fix this bug when receive your code?
2. Is Payara a clone of Glassfish? If Glassfish fix some bugs or improve new features, does Payara also do that?





[GLASSFISH-21266] Start domain does not follow savelogin/savemasterpassword rules Created: 09/Dec/14  Updated: 14/Feb/17

Status: In Progress
Project: glassfish
Component/s: configuration
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ender01 Assignee: Yamini K B
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

OS X 10.10.1 (14B25)


Issue Links:
Duplicate
is duplicated by GLASSFISH-20819 glassfish 4 domain-start command getM... In Progress
Tags: asadmin, password, start-domain

 Description   

Created a domain with following:
./bin/asadmin --passwordfile ./PASS_FILE --user admin create-domain --portbase 9000 --savemasterpassword --savelogin domain2

PASS_FILE:
AS_ADMIN_PASSWORD=password
AS_ADMIN_MASTERPASSWORD=password

Starting the domain now asks for the password:
./bin/asadmin start-domain domain2
Enter master password (3) attempt(s) remain)>

If I enter the password, all other asadmin commands work as expected, including stop-domain, with out having to enter the password. Even enable-secure-admin worked fine.

It seems odd that saving the password information doesn't work for the start-domain command.



 Comments   
Comment by ender01 [ 09/Dec/14 ]

Output of the create-domain command:

Using port 9048 for Admin.
Using port 9080 for HTTP Instance.
Using port 9076 for JMS.
Using port 9037 for IIOP.
Using port 9081 for HTTP_SSL.
Using port 9038 for IIOP_SSL.
Using port 9039 for IIOP_MUTUALAUTH.
Using port 9086 for JMX_ADMIN.
Using port 9066 for OSGI_SHELL.
Using port 9009 for JAVA_DEBUGGER.
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=rohan.local,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=rohan.local-instance,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
Domain domain2 created.
Domain domain2 admin port is 9048.
Domain domain2 admin user is "admin".
Admin login information for host [localhost] and port [9048]
is being overwritten with credentials provided because the
--savelogin option was used during the create-domain command.
Login information relevant to admin user name [admin]
for this domain [domain2] stored at
[/Users/nick/.gfclient/pass] successfully.
Make sure that this file remains protected.
Information stored in this file will be used by
administration commands to manage this domain.
Command create-domain executed successfully.

Comment by rdelaplante [ 05/May/15 ]

I also have the same issue. The create-domain command does not save a master-password file in the new domain's directory:

/opt/glassfish/bin/asadmin create-domain --savemasterpassword=true --domainproperties domain.adminPort=4865:domain.instancePort=8097:http.ssl.port=8197 mydomain

I've tried --savemasterpassword=true and --savemasterpassword but neither work. When I try to start the service created with the create-service command, it tells me:

The Master Password is required to start the domain. No console, no prompting possible. You should either create the domain with --savemasterpassword=true or provide a password file with the --passwordfile option.
Command start-domain failed.

Comment by rdelaplante [ 05/May/15 ]

I forgot to mention that this is GlassFish 4.1 running on Debian Linux and JDK 8. Earlier I had GlassFish 3.1.1.2 and JDK 7 installed on the same machine and never had a problem with --savemasterpassword=true not working. The problem started with GlassFish 4.1 (I don't know about 4.0)

Comment by rdelaplante [ 05/May/15 ]

My workaround is to use the following command to create the master-password file after the domain has been created:

/opt/glassfish/bin/asadmin change-master-password --savemasterpassword=true mydomain

The domain should be stopped when you run this command.

Comment by Tobb [ 06/May/15 ]

Same issue here, --savemasterpassword doesn't seem to work. I am able to start the domain if I supply the --passwordfile parameter along with the start-domain command. Running Windows Server 2008 R2 Enterprise.

Comment by francisco_cpg [ 26/May/15 ]

Same problem here.
Using same workaround proposed by rdelaplante.
Why this issue is stopped?

Comment by rdelaplante [ 26/May/15 ]

Deliberate sabotage by the WebLogic group? jk

Comment by payara_steve [ 16/Jun/15 ]

This is fixed in Payara.

Commit reference is https://github.com/payara/Payara/commit/f859223a9886574f20a22476db9e237c3fa266da

I can provide a patch if you want one. I've signed the CLA.

Comment by francisco_cpg [ 16/Jun/15 ]

Hello payara_steve.
I didn't know about payara.
I took a look at http://www.payara.co.uk/. It seems nice.
But what is the main motivation about this project?

Comment by francisco_cpg [ 16/Jun/15 ]

I think my answers are here
http://www.payara.co.uk/downloads

Payara’s Relationship to GlassFish
Built from GlassFish 4.1
Public Open Source Development
GitHub
Quarterly Releases
(incorporating revisions from upstream projects e.g. Metro, Tyrus, Jersey etc.)
Patches
Fixes pushed to upstream GlassFish
Payara - Optimised for Production
Production Tuned Domain Configuration
Secured by Default
Focus on maintaining and enhancing production capabilities
Remove all unused modules

Comment by Vinay Vishal [ 26/Jun/15 ]

master-password file ideally should reside inside domain root directory and not inside config directory as is currently happening when create-domain command is run with --savemasterpassword option specified.

Glassfish security guide too mentions it.

"For a domain, the master password is kept in domain-dir/master-password"

Glassfish-Security-Guide(Page 1-4)

Fix will soon be made available for this.





[GLASSFISH-21297] asadmin set command throws NPE on beans with read only properties Created: 04/Feb/15  Updated: 14/Feb/17

Status: In Progress
Project: glassfish
Component/s: admin
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lgathy Assignee: Yamini K B
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When setting some configurable attribute via asadmin set command, the operation fails with "remote failure: Cannot change the element: null".
To reproduce, execute:
asadmin set configs.config.default-config.java-config.jvm-options=-server



 Comments   
Comment by lgathy [ 04/Feb/15 ]

I have isolated the root cause of this and prepared a small patch that worked for me. I do not seem to have right to attach the patch here, but I can send it via email (or copy-paste it into a comment here).

Short description on the problem: in nucleus/core/kernel module com.sun.enterprise.v3.admin.SetCommand.setLeafElement iterates through all the methods of the parent bean to find the appropriate setter method. In line 539 the expression bean.model.toProperty(m) could return null, thus the method will raise a NPE. If the appropriate setter method is located after such a method in the returned array of methods then the attribute could never be set. In case of configs.config.default-config.java-config.jvm-options the parent class is com.sun.enterprise.config.serverbeans.JavaConfig, it throws an exception when reaching the getJavacOptionsAsList() method making e.g. jvmOptions property impossible to set.

Proposed solution is to check if bean.model.toProperty(m) returns null and continue to the next method.

Comment by lgathy [ 06/Feb/15 ]

Here is my patch:

Index: nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java
===================================================================
--- nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java	(revision 63760)
+++ nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/admin/SetCommand.java	(working copy)
@@ -536,7 +536,9 @@
                     // collection parameter that parameterized with the right type
                     Class argClasses[] = m.getParameterTypes();
                     Type argTypes[] = m.getGenericParameterTypes();
-                    if (!bean.model.toProperty(m).xmlName().equals(elementName) ||
+                    ConfigModel.Property prop = bean.model.toProperty(m);
+                    if (prop == null ||
+                            !prop.xmlName().equals(elementName) ||
                             argClasses.length != 1 ||
                             !Collection.class.isAssignableFrom(argClasses[0]) ||
                             argTypes.length != 1 ||




[GLASSFISH-21319] javax.inject.jar missing in javaee.jar Created: 27/Feb/15  Updated: 14/Feb/17

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

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: rutujay
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the GlassFish lib directory there's a javaee.jar that just contains
a manifest Class-Path header referring to other jar files. It's missing
javax.inject.jar. And it includes weld-osgi-bundle.jar, which has no javax
classes in it.






[GLASSFISH-21330] asadmin list-applications --long doesn't include enabled status if --terse is set Created: 17/Mar/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Bill Shannon Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

$ asadmin list-applications --long
NAME TYPE STATUS
jtest <web> enabled
$ asadmin --terse list-applications --long
jtest <web>

Output should be:
jtest <web> enabled

--long is not the opposite of --terse, it probably should've been named --enabled.



 Comments   
Comment by Bill Shannon [ 17/Mar/15 ]

Here's the fix:

Index: ListComponentsCommand.java
===================================================================
— ListComponentsCommand.java (revision 63694)
+++ ListComponentsCommand.java (working copy)
@@ -180,7 +180,7 @@

for (Application app : apps) {
String[] currentRow;

  • if( !terse && long_opt ){
    + if( long_opt ){
    currentRow = new String[] { app.getName(), getAppSnifferEngines(app, true), getLongStatus(app) }

    ;
    @@ -198,7 +198,7 @@
    int numCols = 2;
    String[] headings = new String[]

    {"NAME", "TYPE", "STATUS"}

    ;
    int longestValue[] = new int[numCols];

  • if ( !terse && long_opt ) {
    + if ( long_opt )
    Unknown macro: { numCols = 3; longestValue = new int[] {headings[0].length(), headings[1].length(), headings[2].length() }; }




[GLASSFISH-21332] java.util.logging and different resource bundles Created: 18/Mar/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 4.1
Fix Version/s: None

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

Oracle JDK8



 Description   

I have a project that has a few JAR files. In one JAR I have a logger defined as
Logger.getLogger("net.trajano.oidc", "META-INF/Messages")

In another JAR which depends on the previous one I have a logger defined as,

Logger.getLogger("net.trajano.oidc.jaspic", "META-INF/JaspicMessages")

The reason I had different names was because if I kept the same only the Messages in the previous one is used rather than the one local to the JAR file. That is a problem on its own.

I had also created a JUnit test to see if I am even allowed to have different resource bundles to see if it is a JDK issue, but it seems to be okay.

Here is the link to the branch of my project that demonstrates the issue

https://github.com/trajano/openid-connect/tree/bad-logger

The error message I get is this.

Caused by: java.lang.IllegalArgumentException: META-INF/Messages != META-INF/JaspicMessages
at java.util.logging.Logger.setupResourceInfo(Logger.java:1928)
at java.util.logging.Logger.getLogger(Logger.java:564)
at net.trajano.openidconnect.jaspic.internal.Log.<clinit>(Log.java:25)






[GLASSFISH-21333] Error when set jvm-options "-Dcom.sun.appserv.iiop.endpoints=host1:port1,host2:port2" in jvm cluster settings Created: 18/Mar/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 4.1
Fix Version/s: None

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

Linux Centos 6.5 64bits



 Description   

I have an frontend and backend application communicate whith remote EJB.
When I set jvm-options "-Dcom.sun.appserv.iiop.endpoints=host1:port1,host2:port2" in jvm frontend cluster settings and I start it I obtain this error :

java.lang.IllegalStateException: Service org.glassfish.gms.bootstrap.GMSAdapterService was started at level 1 but it has a run level of 10.

In the class : com.sun.enterprise.naming.impl.SerialInitContextFactory#getInitialContext, the boolean useLB is set to true. Then the com.sun.enterprise.naming.impl.SerialInitContextFactory#getORB method is call.
In the method org.glassfish.enterprise.iiop.impl.GlassFishORBManager#setFOLBProperties it created a new IiopFolbGmsClient( services ). In this class there is a call to gmsAdapterService = services.getService(GMSAdapterService.class);. A this line cannot create the GMSAdapterService because it start with runlevel 10.

Maybe I don't understand how to set the IIOP loadbalancing ?






[GLASSFISH-21356] Validation : Ensure that valid resource-adapter name is specified in @ConnectionFactoryDefinition/@AdministeredObjectDefinition Created: 08/May/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: jca
Affects Version/s: 4.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: Jagadish Assignee: Vinay Vishal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As per the java-doc of @ConnectionFactoryDefinition.resourceAdapter(), the resource adapter specified must be available during deployment time:
http://docs.oracle.com/javaee/7/api/javax/resource/ConnectionFactoryDefinition.html#resourceAdapter%28%29

It implicitly indicates that deployment of the application archive that has these annotations (@ConnectionFactoryDefinition, @AdministeredObjectDefinition") can be failed if the resource-adapter name is invalid.

Today, GlassFish does not fail deployment of the archive, instead during first time lookup of the resource, the lookup will fail. Need to fix this behavior and make sure that validation is done as part of application deployment.






[GLASSFISH-21357] Entity Tables are not created during deployment time Created: 10/May/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: configuration, deployment
Affects Version/s: 4.1
Fix Version/s: None

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

GlassFish Server Open Source Edition 4.1 (build 13) with latest JDK 8


Tags: create, deployment, entity, generate, jpa, persistence, table

 Description   

It seems that in Glassfish 4.1 DB tables for JPA entity classes are not generated during deployment time. Previously, when deploying the application with the correct persistence.xml file and with generation type "create" (in GF 4.1 this would be <property name="javax.persistence.schema-generation.database.action" value="create"/>) then the tables should be created at deployment time.

This does not happen anymore. It seems to be a change of behavior and has caused heavy backwards compatibility issues for us after migrating from GF 3.1.2.2 to GF 4.1. It seems that since Glassfish 4.1 you need to use your PU somewhere before the tables are created. In other words: tables are created only when they are needed the first time.

The following stack overflow articles discuss that topic as well:

http://stackoverflow.com/questions/25489359/entity-table-is-not-creating-using-jpa-2-1

https://stackoverflow.com/questions/25935866/how-to-use-jpa-with-java-ee-7-glassfish-4-1-and-maven-on-javadb/28841583#28841583



 Comments   
Comment by Lukas Jungmann [ 11/May/15 ]

if you're using eclipselink, then adding 'eclipselink.deploy-on-startup=true' to your persistence.xml should resolve the problem

Comment by nabizamani [ 07/Dec/15 ]

No progress after 6 months? This is a Java EE spec incompatibility or at least a change of the behavior from 3.1.2.2 to 4.1.x! How could the Java EE spec compliance tests pass??? I can see that this ticket is assigned to Masoud Kalali, but he has zero activity since May this year! So what is going on at Oracle?????

Comment by Masoud Kalali [ 07/Dec/15 ]

Considering that I am no longer active in GlassFish space I am assigning all the tickets to Chris Kasso in Java EE/ Application Servers team and he can reassign them as appropriate.

Comment by nabizamani [ 14/Apr/16 ]

Another 4 months have passed and no reaction. That means almost 1 year is over and there is no reaction!
No one at Oracle interested to work on this?





[GLASSFISH-21364] Bump eclipselink version to solve jdk8 related issues Created: 27/May/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rainerschamm Assignee: ankur.kathuria
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Can we please bump the eclipselink version so that the following bug is solved:

  • IndirectList is missing the new sort method introduced in Java 8

As described here:

http://stackoverflow.com/questions/26816650/java8-collections-sort-sometimes-does-not-sort-jpa-returned-lists

and described here:

http://stackoverflow.com/questions/27935032/foreach-and-sort-dont-work-and-cannot-set-breakpoints-in-blocks

The eclipselink bugs are:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=433075
https://bugs.eclipse.org/bugs/show_bug.cgi?id=446236

Target milestone is: 2.7.0

Maybe they will fix it for 2.6 though.

In any case it would be really important for JDK8 users get this into Glassfish 4.2 please.



 Comments   
Comment by rainerschamm [ 27/May/15 ]

Sorry the other bug title is:

  • Stream API gets no results

And I see that its fixed in 2.6. But the list issue is not fixed in a release yet.





[GLASSFISH-21376] There is a "null" in the log name Created: 17/Jun/15  Updated: 14/Feb/17

Status: In Progress
Project: glassfish
Component/s: logging
Affects Version/s: 4.1
Fix Version/s: None

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

linux


Issue Links:
Duplicate
is duplicated by GLASSFISH-21375 There is a "null" in the log name Closed
is duplicated by GLASSFISH-21377 There is a "null" in the log name Closed

 Description   

My servlet used the following source to print log.

ServletContext sc = this.getServletContext();
sc.log("This is a servlet context log method");

the following message is printted in server.log,but there is a "null" in the log name.I think it is a bug .

[2015-06-17T18:27:48.057+0900] [glassfish 4.1] [INFO] [] [javax.enterprise.web] [tid: _ThreadID=39 _ThreadName=http-listener-1(12)] [timeMillis: 1434533268057] [levelValue: 800] WebModule[null] ServletContext.log():This is a servlet context log method





[GLASSFISH-21383] restart-domain has 2 java processes with use a lot of memory Created: 29/Jun/15  Updated: 14/Feb/17

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

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

java8
windows server 2012 r2



 Description   

my glassfish runs on the windows server 2012 R2 as a service when i try to restart the a domain by asadmin it restart not correct.

I found 2 java processes with use a lot of memory after the restart
1.
"C:\Program Files\Java\jdk1.8.0_45\bin\java.exe" cp D:/DEVELOPMENT/Software/glassfish4/glassfish/modules/glassfish.jar -XX:+UnlockDiagnosticVMOptions -XX:NewRatio=2 -XX:+UseCompressedOops -XX:MaxPermSize=512m -Xmx2048m -server -javaagent:/DEVELOPMENT/Software/glassfish4/glassfish/lib/monitor/flashlight-agent.jar -Djavax.xml.accessExternalSchema=all -Djavax.net.ssl.trustStore=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/cacerts.jks -Djdk.corba.allowOutputStreamSubclass=true -Dfelix.fileinstall.dir=D:\DEVELOPMENT\Software\glassfish4\glassfish/modules/autostart/ -Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command,org.apache.felix.shell.remote,org.apache.felix.fileinstall -Dcom.sun.aas.installRoot=D:\DEVELOPMENT\Software\glassfish4\glassfish -Dfelix.fileinstall.poll=5000 -Djava.endorsed.dirs=D:\DEVELOPMENT\Software\glassfish4\glassfish/modules/endorsed;D:\DEVELOPMENT\Software\glassfish4\glassfish/lib/endorsed -Djava.security.policy=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/server.policy -Dosgi.shell.telnet.maxconn=1 -Dfelix.fileinstall.bundles.startTransient=true -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory -Dfelix.fileinstall.log.level=2 -Djavax.net.ssl.keyStore=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/keystore.jks -Djava.security.auth.login.config=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/login.conf -Dfelix.fileinstall.disableConfigSave=false -Dfelix.fileinstall.bundles.new.start=true -Dcom.sun.aas.instanceRoot=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL -Dosgi.shell.telnet.port=6666 -Dgosh.args=nointeractive -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as -Dosgi.shell.telnet.ip=127.0.0.1 -DANTLR_USE_DIRECT_CLASS_LOADING=true -Djava.awt.headless=true -Dcom.ctc.wstx.returnNullForDefaultNamespace=true "-Djava.ext.dirs=C:\Program Files\Java\jdk1.8.0_45/lib/ext;C:\Program Files\Java\jdk1.8.0_45/jre/lib/ext;D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/lib/ext" -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver "-Djava.library.path=C:/Program Files/IBM/OnDemand Web Enablement Kit/V9.0/api;C:/Program Files/IBM/OnDemand Web Enablement Kit/V9.0/lib64;C:/Program Files/IBM/OnDemand Web Enablement Kit/V9.0;D:/DEVELOPMENT/Software/glassfish4/glassfish/lib;C:/ProgramData/Oracle/Java/javapath;C:/Windows/Sun/Java/bin;C:/Windows/System32;C:/Windows;C:/Windows/System32/wbem;C:/Windows/System32/WindowsPowerShell/v1.0;C:/Program Files/Microsoft SQL Server/120/DTS/Binn;C:/Program Files/Microsoft SQL Server/Client SDK/ODBC/110/Tools/Binn;C:/Program Files (x86)/Microsoft SQL Server/120/Tools/Binn;C:/Program Files/Microsoft SQL Server/120/Tools/Binn;C:/Program Files (x86)/Microsoft SQL Server/120/Tools/Binn/ManagementStudio;C:/Program Files (x86)/Microsoft SQL Server/120/DTS/Binn;C:/Program Files/Mercurial;C:/Program Files (x86)/MSBuild/12.0/Bin;C:/Program Files/TortoiseSVN/bin;C:/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit" com.sun.enterprise.glassfish.bootstrap.ASMain -upgrade false -domaindir D:/DEVELOPMENT/Software/glassfish4/glassfish/domains/AP10DVL -read-stdin true -asadmin-args --host,,,localhost,,,port,,,4848,,,user,,,admin,,,passwordfile,,,D:/temp/glassfish_passwords.txt,,,secure=false,,,terse=false,,,echo=false,,,interactive=false,,,start-domain,,,verbose=false,,,watchdog=true,,,debug=false,,,-domaindir,,,D:\DEVELOPMENT\Software\glassfish4\glassfish\domains,,,AP10DVL -domainname AP10DVL -instancename server -type DAS -verbose false -asadmin-classpath D:/DEVELOPMENT/Software/glassfish4/glassfish/modules/admin-cli.jar -debug false -asadmin-classname com.sun.enterprise.admin.cli.AdminMain

2.
"C:\Program Files\Java\jdk1.8.0_45\bin\java.exe" cp D:/DEVELOPMENT/Software/glassfish4/glassfish/modules/glassfish.jar -XX:+UnlockDiagnosticVMOptions -XX:NewRatio=2 -XX:+UseCompressedOops -XX:MaxPermSize=512m -Xmx2048m -server -javaagent:/DEVELOPMENT/Software/glassfish4/glassfish/lib/monitor/flashlight-agent.jar -Djavax.xml.accessExternalSchema=all -Djavax.net.ssl.trustStore=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/cacerts.jks -Djdk.corba.allowOutputStreamSubclass=true -Dfelix.fileinstall.dir=D:\DEVELOPMENT\Software\glassfish4\glassfish/modules/autostart/ -Dorg.glassfish.additionalOSGiBundlesToStart=org.apache.felix.shell,org.apache.felix.gogo.runtime,org.apache.felix.gogo.shell,org.apache.felix.gogo.command,org.apache.felix.shell.remote,org.apache.felix.fileinstall -Dcom.sun.aas.installRoot=D:\DEVELOPMENT\Software\glassfish4\glassfish -Dfelix.fileinstall.poll=5000 -Djava.endorsed.dirs=D:\DEVELOPMENT\Software\glassfish4\glassfish/modules/endorsed;D:\DEVELOPMENT\Software\glassfish4\glassfish/lib/endorsed -Djava.security.policy=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/server.policy -Dosgi.shell.telnet.maxconn=1 -Dfelix.fileinstall.bundles.startTransient=true -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise.config.serverbeans.AppserverConfigEnvironmentFactory -Dfelix.fileinstall.log.level=2 -Djavax.net.ssl.keyStore=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/keystore.jks -Djava.security.auth.login.config=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/config/login.conf -Dfelix.fileinstall.disableConfigSave=false -Dfelix.fileinstall.bundles.new.start=true -Dcom.sun.aas.instanceRoot=D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL -Dosgi.shell.telnet.port=6666 -Dgosh.args=nointeractive -Dcom.sun.enterprise.security.httpsOutboundKeyAlias=s1as -Dosgi.shell.telnet.ip=127.0.0.1 -DANTLR_USE_DIRECT_CLASS_LOADING=true -Djava.awt.headless=true -Dcom.ctc.wstx.returnNullForDefaultNamespace=true "-Djava.ext.dirs=C:\Program Files\Java\jdk1.8.0_45/lib/ext;C:\Program Files\Java\jdk1.8.0_45/jre/lib/ext;D:\DEVELOPMENT\Software\glassfish4\glassfish\domains\AP10DVL/lib/ext" -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver "-Djava.library.path=C:/Program Files/IBM/OnDemand Web Enablement Kit/V9.0/api;C:/Program Files/IBM/OnDemand Web Enablement Kit/V9.0/lib64;C:/Program Files/IBM/OnDemand Web Enablement Kit/V9.0;D:/DEVELOPMENT/Software/glassfish4/glassfish/lib;C:/Program Files/Java/jdk1.8.0_45/jre/bin;C:/Windows/Sun/Java/bin;C:/Windows/System32;C:/Windows;C:/ProgramData/Oracle/Java/javapath;C:/Windows/System32/wbem;C:/Windows/System32/WindowsPowerShell/v1.0;C:/Program Files/Microsoft SQL Server/120/DTS/Binn;C:/Program Files/Microsoft SQL Server/Client SDK/ODBC/110/Tools/Binn;C:/Program Files (x86)/Microsoft SQL Server/120/Tools/Binn;C:/Program Files/Microsoft SQL Server/120/Tools/Binn;C:/Program Files (x86)/Microsoft SQL Server/120/Tools/Binn/ManagementStudio;C:/Program Files (x86)/Microsoft SQL Server/120/DTS/Binn;C:/Program Files/Mercurial;C:/Program Files (x86)/MSBuild/12.0/Bin;C:/Program Files/TortoiseSVN/bin;C:/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit;D:/DEVELOPMENT/Software/glassfish4/glassfish/domains/AP10DVL/config" com.sun.enterprise.glassfish.bootstrap.ASMain -upgrade false -domaindir D:/DEVELOPMENT/Software/glassfish4/glassfish/domains/AP10DVL -read-stdin true -asadmin-args --host,,,localhost,,,port,,,4848,,,user,,,admin,,,passwordfile,,,D:/temp/glassfish_passwords.txt,,,secure=false,,,terse=false,,,echo=false,,,interactive=false,,,start-domain,,,verbose=false,,,watchdog=true,,,debug=false,,,-domaindir,,,D:\DEVELOPMENT\Software\glassfish4\glassfish\domains,,,AP10DVL -domainname AP10DVL -instancename server -type DAS -verbose false -asadmin-classpath D:/DEVELOPMENT/Software/glassfish4/glassfish/modules/admin-cli.jar -debug false -asadmin-classname com.sun.enterprise.admin.cli.AdminMain

When i try to stop the service it will not stop, I have to kill them

After i have to killed all processes from the service I have also delete the "generated" folder. Now works the server correct after a restart






[GLASSFISH-21408] long logger class names do not appear on admin site after being added Created: 06/Aug/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: pbelbin Assignee: sumasri
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all



 Description   

after adding a longish class name to the log configuration page, and hitting 'save' (and receiving a 'success' response), the class name and level is not visible on the web page.

examination of the logging.properties file reveals that the setting was saved.

it just isn't visible on the admin gui.



 Comments   
Comment by fredaabedi [ 13/Oct/15 ]

Hello, are you planning to fix this issue?

Thank you,
Fred





[GLASSFISH-21448] Can not enable secure admin Created: 23/Oct/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: configuration, security
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: muellermi Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7



 Description   

1. Start GlassFish admin console
2. choose server, Secure Admin
GF displays "an error occured"

3. click onto enable...

GF displays internal error:
HTTP Status 500 - Internal Server Error

type Exception report

messageInternal Server Error

descriptionThe server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

root cause

javax.faces.component.UpdateModelException: javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

root cause

javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null

note The full stack traces of the exception and its root causes are available in the GlassFish Server Open Source Edition 4.1.1 logs.
GlassFish Server Open Source Edition 4.1.1

Excerpt from log:
[2015-10-23T09:42:58.356+0200] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=46 _ThreadName=admin-listener(3)] [timeMillis: 1445586178356] [levelValue: 900] [[
StandardWrapperValve[FacesServlet]: Servlet.service() for servlet FacesServlet threw exception
javax.el.PropertyNotFoundException: Target Unreachable, 'null' returned null
at com.sun.el.parser.AstValue.getTarget(AstValue.java:192)
at com.sun.el.parser.AstValue.setValue(AstValue.java:226)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:294)
at javax.faces.component.UIInput.updateModel(UIInput.java:832)
at javax.faces.component.UIInput.processUpdates(UIInput.java:749)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIForm.processUpdates(UIForm.java:281)
at javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:1291)
at javax.faces.component.UIViewRoot.processUpdates(UIViewRoot.java:1254)
at com.sun.faces.lifecycle.UpdateModelValuesPhase.execute(UpdateModelValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:233)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:678)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Unknown Source)
]]

[2015-10-23T09:44:31.411+0200] [glassfish 4.1] [INFO] [] [org.glassfish.admingui] [tid: _ThreadID=47 _ThreadName=admin-listener(4)] [timeMillis: 1445586271411] [levelValue: 800] [[
Exception Occurred :null]]



 Comments   
Comment by pczurak [ 25/Mar/16 ]

I am getting the same issue with Glassfish version 4.1.1 running on Linux
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Has anyone found a fix for this?

Comment by hora1806 [ 31/Mar/16 ]

I have the same issue.

I did workaround

asadmin enable-secure-admin

Comment by phendley [ 31/Mar/16 ]

I have seen something similar in past and while not 100% positive, I believe a problem may be that there has to be non-empty password in effect. I believe one can enable the secure admin by doing sequence similar to following:
asadmin change-admin-password (not sure if we need to recycle GF afterwards??)
asadmin enable-secure-admin (not sure if we need to recycle GF afterwards??)
-phendley

Comment by pczurak [ 31/Mar/16 ]

I've found a workaround
Installed Glassfish 4.1 and then updated Glassfish to 4.1.1





[GLASSFISH-21452] No Content-Type header for JSON files Created: 26/Oct/15  Updated: 14/Feb/17

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

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


 Description   

When serving a static JSON file, GlassFish doesn't send a Content-Type header. Such files are not recognized by Firefox as JSON and thus cannot be parsed correctly. The following mapping should be added to $DOMAIN/config/default-web.xml:

  <mime-mapping>
    <extension>json</extension>
    <mime-type>application/json</mime-type>
  </mime-mapping>


 Comments   
Comment by Masoud Kalali [ 07/Dec/15 ]

Considering that I am no longer active in GlassFish space I am assigning all the tickets to Chris Kasso in Java EE/ Application Servers team and he can reassign them as appropriate.





[GLASSFISH-21456] javax.naming.NameNotFoundException: jdbc Created: 30/Oct/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: 4.1
Fix Version/s: None

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

Mac OSX, Java 1.8



 Description   

Hi, I have a web application written in Netbeans that does a JNDI lookup of jdbc/SomeName and it works fine in GF 4.1 when using jvm 1.7.

When I switch GF to use jvm 1.8 I encounter the following stack trace:

2015-10-29 20:29:10,312-ERROR-[RunLevelControllerThread-1446164949966]-[DBAuthenticator.java:56]-com.ge.de.security.authentication.implementation.database.DBAuthenticator.setProperties: javax.naming.NamingException: Lookup failed for 'jdbc/CDBDataSource' in SerialContext[myEnv=

{java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

[Root exception is javax.naming.NameNotFoundException: jdbc]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at com.ge.de.cnms.db.jndi.JNDIDataSourceFactory.getDataSource(JNDIDataSourceFactory.java:159)



 Comments   
Comment by jroberts66z [ 30/Oct/15 ]

Per what I know about JNDI lookups, it should have worked just fine in 1.8, so I am assuming this is a bug in GF. The Web application is using <class-loader delegate="false"/> in glassfish-web.xml and the JARs inside the lib directory are:

WEB-INF/lib/CoverityWS.jar
WEB-INF/lib/activation-1.1.jar
WEB-INF/lib/all-themes-1.0.10.jar
WEB-INF/lib/cnms-dao.jar
WEB-INF/lib/cnms-db.jar
WEB-INF/lib/cnms-entity.jar
WEB-INF/lib/cnms-transaction.jar
WEB-INF/lib/cnms-util.jar
WEB-INF/lib/com.ge.de.authenticator.jar
WEB-INF/lib/com.ge.de.cov.reports.jar
WEB-INF/lib/com.ge.de.email.jar
WEB-INF/lib/com.ge.de.entity.jar
WEB-INF/lib/commons-codec-1.2.jar
WEB-INF/lib/commons-dbcp-1.4.jar
WEB-INF/lib/commons-digester-1.8.jar
WEB-INF/lib/commons-fileupload-1.2.jar
WEB-INF/lib/commons-httpclient-3.1.jar
WEB-INF/lib/commons-io-1.4.jar
WEB-INF/lib/commons-lang-2.3.jar
WEB-INF/lib/commons-logging-1.1.jar
WEB-INF/lib/commons-pool-1.5.5.jar
WEB-INF/lib/esapi-2.1.0.jar
WEB-INF/lib/fscontext.jar
WEB-INF/lib/jcommon-1.0.23.jar
WEB-INF/lib/jfreechart-1.0.19.jar
WEB-INF/lib/jndi.jar
WEB-INF/lib/log4j-1.2.16.jar
WEB-INF/lib/mail-1.4.jar
WEB-INF/lib/omnifaces-1.11.jar
WEB-INF/lib/primefaces-5.2.jar
WEB-INF/lib/providerutil.jar
WEB-INF/lib/quartz-2.2.1.jar
WEB-INF/lib/quartz-jobs-2.2.1.jar
WEB-INF/lib/slf4j-api-1.6.6.jar
WEB-INF/lib/slf4j-log4j12-1.6.6.jar
WEB-INF/lib/xchart-2.4.3.jar

There are also the following JAR files in domains/domain1/lib directory:

rw-rr- 1 carlroberts staff 15032 Oct 29 18:45 ../domains/domain1/lib/DatabaseRealm.jar
rw-rr- 1 carlroberts staff 39945 Oct 29 18:45 ../domains/domain1/lib/cnms-dao.jar
rw-rr- 1 carlroberts staff 44052 Oct 29 18:45 ../domains/domain1/lib/cnms-db.jar
rw-rr- 1 carlroberts staff 4774 Oct 29 18:45 ../domains/domain1/lib/cnms-entity.jar
rw-rr- 1 carlroberts staff 16725 Oct 29 18:45 ../domains/domain1/lib/cnms-transaction.jar
rw-rr- 1 carlroberts staff 61395 Oct 29 18:45 ../domains/domain1/lib/cnms-util.jar
rw-rr- 1 carlroberts staff 54932 Oct 29 18:45 ../domains/domain1/lib/com.ge.de.authenticator.jar
rw-rr- 1 carlroberts staff 138433 Oct 29 18:45 ../domains/domain1/lib/com.ge.de.entity.jar
rw-rr- 1 carlroberts staff 30085 Oct 29 18:45 ../domains/domain1/lib/commons-codec-1.2.jar
rw-rr- 1 carlroberts staff 571259 Oct 29 18:45 ../domains/domain1/lib/commons-collections-3.2.jar
-rwxr-xr-x 1 carlroberts staff 160519 Oct 29 18:45 ../domains/domain1/lib/commons-dbcp-1.4.jar
rw-rr- 1 carlroberts staff 143602 Oct 29 18:45 ../domains/domain1/lib/commons-digester-1.8.jar
rw-rr- 1 carlroberts staff 53082 Oct 29 18:45 ../domains/domain1/lib/commons-fileupload-1.2.jar
rw-rr- 1 carlroberts staff 305001 Oct 29 18:45 ../domains/domain1/lib/commons-httpclient-3.1.jar
rw-rr- 1 carlroberts staff 245274 Oct 29 18:45 ../domains/domain1/lib/commons-lang-2.3.jar
rw-rr- 1 carlroberts staff 52915 Oct 29 18:45 ../domains/domain1/lib/commons-logging-1.1.jar
-rwxr-xr-x 1 carlroberts staff 100193 Oct 29 18:45 ../domains/domain1/lib/commons-pool-1.5.5.jar
rw-rr- 1 carlroberts staff 367021 Oct 29 18:45 ../domains/domain1/lib/esapi-2.1.0.jar
-rwxr-xr-x 1 carlroberts staff 22769 Oct 29 18:45 ../domains/domain1/lib/fscontext.jar
-rwxr-xr-x 1 carlroberts staff 98496 Oct 29 18:45 ../domains/domain1/lib/jndi.jar
rw-rr- 1 carlroberts staff 481534 Oct 29 18:45 ../domains/domain1/lib/log4j-1.2.16.jar
rw-rr- 1 carlroberts staff 968670 Oct 29 18:45 ../domains/domain1/lib/mysql-connector-java-5.1.35-bin.jar
-rwxr-xr-x 1 carlroberts staff 77116 Oct 29 18:45 ../domains/domain1/lib/providerutil.jar





[GLASSFISH-21420] user audit Created: 22/Aug/15  Updated: 14/Feb/17  Resolved: 14/Feb/17

Status: Closed
Project: glassfish
Component/s: None
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Azlan Assignee: Yamini K B
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

UAT



 Description   

Hi,

need to know this for audit perspective that where can i find the logs of when and which users had login in glassfish admin console.

Regards.
Azlan



 Comments   
Comment by Yamini K B [ 14/Feb/17 ]

To enable audit logging, two steps are required:
1. On the Security page, select the Audit Logging Enabled checkbox to enable audit logging.

2. Set the auditOn property for the active audit module to true.

Restart the domain and you should be able to see messages like following in server.log:

[glassfish 5.0] [INFO] [] [javax.enterprise.system.core.security.com.sun.enterprise.security.ee] [tid: _ThreadID=44 _ThreadName=admin-listener(3)] [timeMillis: 1487078911603] [levelValue: 800] [[
Audit: [Web] Authorization for user = (null) and permission type = (hasUserDataPermission) for request GET /common/index.jsf returned =true]]
[glassfish 5.0] [INFO] [] [javax.enterprise.system.core.security.com.sun.enterprise.security.ee] [tid: _ThreadID=46 _ThreadName=admin-listener(5)] [timeMillis: 1487078913018] [levelValue: 800] [[
Audit: Authentication for user = (admin) under realm = (admin-realm) returned = true]]

Comment by Yamini K B [ 14/Feb/17 ]

Closing issue since query has been answered.

Comment by Azlan [ 14/Feb/17 ]

yamini i see glassfish 5.0 in above comments, can you please confirm how can i get the same as in glassfish 4.0 there is a issue regarding connection pool and application deployment.

Comment by Yamini K B [ 14/Feb/17 ]

http://download.java.net/glassfish/





[GLASSFISH-21419] session limit Created: 22/Aug/15  Updated: 14/Feb/17

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

Type: Task Priority: Major
Reporter: Azlan Assignee: Joe Di Pol
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

can you guide me how to change the number of session of glassfish to one session only. that is if a user is login from one browser he cant login from any other browsers. and also guide me how to decrease the session timeout so that it will come to 1 minute.

Thanks.



 Comments   
Comment by Azlan [ 14/Feb/17 ]

Dear Team,

Kindly expedite as this is urgently required.





[GLASSFISH-21459] asadmin stop-domain/restart-domain always gets timeout running in docker Created: 04/Nov/15  Updated: 14/Feb/17

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

Type: Bug Priority: Major
Reporter: boboliu Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File asadmin.log    

 Description   

we are testing integration eclipselink to glassfish with docker, we build the glassfish.zip from trunk, and install it into a docker image, the start-domain works, but after that stop-domain/restart-domain always get timeout which is causing gf quicklook test failures. everying is working when in docker interactive mode(docker run -it), but it just keeps get timeout running in docker with non-interactive mode. attachment is the log restart-domain after start-domain.






[GLASSFISH-21526] Access Logs are not being pruned in accordance with Max File Count Created: 07/Mar/16  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 3.1.2, 4.0, 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: gzkramer Assignee: mskdeepak
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SLES 11.3



 Description   

While using Glassfish with rotating access logs, I ran into an issue where I ran out of disk space on a VM because the excess access logs (as defined by the Max File Count and/or 'com.sun.enterprise.server.logging.max_history_files") were not being pruned.

After some investigation, it seemed as though PEAccessLogValve.java in the web-glue module was supposedly responsible for pruning older access logs. More specifically, the open() method contained the logic for deleting the excess access logs. Unfortunately there seemed to be at least one issue (possibly more) within open()'s logic. In the second conditional which contains the logic for pruning access logs, there are extraneous conditions which can cause the access log deletion to be unreachable. The conditional says if (rotatable && !addDateTimeStampToFirstAccessLogFile && !firstAccessLogFile) then you can begin the logic for checking if an access log should be deleted. Because of the "!addDateTimeStampToFirstAccessLogFile" condition, if you are timestamping your first access log you can never delete old access logs.






[GLASSFISH-21418] upgrading glassfish to newer version Created: 22/Aug/15  Updated: 14/Feb/17  Resolved: 14/Feb/17

Status: Closed
Project: glassfish
Component/s: None
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Azlan Assignee: Yamini K B
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

DEV



 Description   

Hi,

We need to upgrade our glassfish environment wothout loosing configuration and clusters.

Thanks



 Comments   
Comment by Yamini K B [ 14/Feb/17 ]

You can refer to GlassFish upgrade guide:
https://glassfish.java.net/docs/4.0/upgrade-guide.pdf

Comment by Azlan [ 14/Feb/17 ]

thanks yamini will upgrade using the instruction manual and will get back to you if anything required.





[GLASSFISH-21674] "Statement Leak Reclaim" checkbox in "Edit JDBC Connection Pool Advanced Attributes" screen cannot be disabled Created: 10/Feb/17  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 5.0
Fix Version/s: None

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


 Description   

"Statement Leak Reclaim" checkbox in "Edit JDBC Connection Pool Advanced Attributes" screen cannot be disabled.

Follow the steps below in Admin console.

1. Create a new JDBC Connection Pool. (eg. MyJDBC)
2. Open the JDBC Connection Pool which has been created (eg. MyJDBC) from the Navigation tree.
3. Click on "Advanced" tab to open the "Edit JDBC Connection Pool Advanced Attributes".
4. Enable the "Statement Leak Reclaim" checkbox and click "Save" button.
5. Go to another screen and come back to this "Advanced" tab to refresh the screen. Confirm that "Statement Leak Reclaim" checkbox is enabled as a result of Step 4.
6. Now disable the "Statement Leak Reclaim" checkbox and click "Save" button.
7. Go to another screen and come back to this "Advanced" tab to refresh the screen.
Bug: You will find "Statement Leak Reclaim" checkbox is not saved correctly. It is still enabled even if this has been disabled in Step 6.






[GLASSFISH-21676] From time to time auto-deployed directory is empty (...\generated\jsp\x.y.z) Created: 14/Feb/17  Updated: 14/Feb/17

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

Type: Bug Priority: Major
Reporter: michal.gawin Assignee: Vinay Vishal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 10



 Description   

I'm deploying 3 wars.
All are in autodeploy directory and .autodeploystatus directory indicates that all 3 were deployed.
Folder applications also has them unpacked.
But the problem is with directory generated were one war has directory which is empty.

Removing appropriate file from .autodeploystatus redeploy it properly (in folder generated\jsp is directory with files).



 Comments   
Comment by michal.gawin [ 14/Feb/17 ]

Attempt to connect returns 403.

Server logs:

[#|2017-02-13T13:47:06.970+0100|INFO|glassfish 4.0|javax.enterprise.system.core.security|_ThreadID=26;_ThreadName=http-listener-1(5);_TimeMillis=1486990026970;_LevelValue=800;|
JACC Policy Provider: Failed Permission Check, context(x.y.z/x_y_z)- permission(("javax.security.jacc.WebUserDataPermission" "/index.jsp" "GET"))|#]
Comment by michal.gawin [ 14/Feb/17 ]

Status code 403 is related with granted.policy which is empty.
If war will be redeployed (see steps from description) this file will have defined some rules.





[GLASSFISH-21254] Usertransactions are blocked by firewall Created: 14/Nov/14  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: jts
Affects Version/s: 3.1.2
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: riksweeney Assignee: pranjal.sahay
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows (or any client / server setup separated by a firewall)


Tags: firewall, usertransaction

 Description   

EJB method calls are blocked by the firewall if run in a UserTransaction. This appears to be because the server will attempt to connect to the client on a different port to the original, which the firewall will then block.

Steps to reproduce are fairly straightforward.

1. Ensure that the firewall has been configured to allow EJB lookups.
2. Deploy an EJB with a method that has a transaction type of REQUIRED or SUPPORTS to the web server.
3. On the client machine, look up the UserTransaction and call begin().
4. Next, look up the EJB and call the method with the transaction type of REQUIRED or SUPPORTS.
5. The client code will eventually time out and stacktrace. The webserver log file will report that the connection to the client machine failed.

If the UserTransaction.begin() method is never called, then the method invocation will succeed as expected.



 Comments   
Comment by riksweeney [ 21/Nov/14 ]

[#|2014-11-10T04:21:43.852+0000|WARNING|glassfish3.1.2|javax.enterprise.system.core.transaction.com.sun.jts.jta|_ThreadID=16;_ThreadName=Thread-4;|JTS5071: Unexpected error occurred in registerSynchronization
org.omg.CORBA.COMM_FAILURE: FINE: IOP00410001: Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: xx.xx.xxx.x; port: 52574 vmcid: OMG minor code: 1 completed: No
at sun.reflect.GeneratedConstructorAccessor168.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy149.connectFailure(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:257)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at org.omg.CosTransactions._CoordinatorStub.register_synchronization(_CoordinatorStub.java:235)
at com.sun.jts.CosTransactions.TopCoordinator.register_synchronization(TopCoordinator.java:2430)
at com.sun.jts.jta.TransactionState.registerSynchronization(TransactionState.java:433)
at com.sun.jts.jta.TransactionImpl.registerSynchronization(TransactionImpl.java:313)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.createImportedTransaction(JavaEETransactionManagerSimplified.java:1551)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.getTransaction(JavaEETransactionManagerJTSDelegate.java:279)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getTransaction(JavaEETransactionManagerSimplified.java:922)
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4703)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4616)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy568.findAll(Unknown Source)
at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
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.RuntimeException: java.net.ConnectException: Connection timed out: connect
at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:339)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:242)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:274)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at org.omg.CosTransactions._CoordinatorStub.register_synchronization(_CoordinatorStub.java:235)
at com.sun.jts.CosTransactions.TopCoordinator.register_synchronization(TopCoordinator.java:2430)
at com.sun.jts.jta.TransactionState.registerSynchronization(TransactionState.java:433)
at com.sun.jts.jta.TransactionImpl.registerSynchronization(TransactionImpl.java:314)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.createImportedTransaction(JavaEETransactionManagerSimplified.java:1551)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.getTransaction(JavaEETransactionManagerJTSDelegate.java:279)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getTransaction(JavaEETransactionManagerSimplified.java:922)
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4703)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4616)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy568.findAll(Unknown Source)
at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:215)
... 5 more
Caused by: java.net.ConnectException: Connection timed out: connect
at sun.nio.ch.Net.connect(Native Method)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:532)
at com.sun.corba.ee.impl.orbutil.ORBUtility.openSocketChannel(ORBUtility.java:110)
at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createSocket(IIOPSSLSocketFactory.java:324)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:242)
at com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.<init>(SocketOrChannelConnectionImpl.java:270)
at com.sun.corba.ee.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:129)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:223)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:228)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:431)
at org.omg.CosTransactions._CoordinatorStub.register_synchronization(_CoordinatorStub.java:235)
at com.sun.jts.CosTransactions.TopCoordinator.register_synchronization(TopCoordinator.java:2430)
at com.sun.jts.jta.TransactionState.registerSynchronization(TransactionState.java:433)
at com.sun.jts.jta.TransactionImpl.registerSynchronization(TransactionImpl.java:313)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.createImportedTransaction(JavaEETransactionManagerSimplified.java:1551)
at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.getTransaction(JavaEETransactionManagerJTSDelegate.java:279)
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.getTransaction(JavaEETransactionManagerSimplified.java:922)
at com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4703)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4616)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1914)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy568.findAll(Unknown Source)
at sun.reflect.GeneratedMethodAccessor133.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
... 5 more





[GLASSFISH-21280] Transaction attribute in subclass is ignored if a generic supertype exist Created: 29/Dec/14  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: martinandersson.com Assignee: gururaja1234
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 1 week
Time Spent: Not Specified
Original Estimate: 1 week
Environment:

Tested on Windows 7 x64 and Windows 8 x64


Tags: annotations, ejb-container, inheritance, transactionmanager

 Description   

According to "Common Annotations" spec as well as the EJB spec, supertype transaction attribute annotations are "always ignored" if the subclass override a method. Only if the superclass has a method not overridden by the subclass do annotations put in the superclass apply.

This work as long as the supertype, whether that be a class or interface, is not generic. As soon as it is, GlassFish behave in the other way around: ignoring the most specific subclass annotations and instead use annotations declared in the supertype.

Full description, specification quotes as well as test cases is located here (the project is a working Maven project, clone + build and all tests are executed using Arquillian):

https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/master/src/test/java/com/martinandersson/javaee/ejb/transactions/AnnotationInheritanceTest.java

In a separate project my mine that first exposed this issue, I have no workaround to apply. I have to stop using GlassFish or begin a new architectural design. Given that transactions are an intrinsic part of applications, as well as inheritance is a common method for code reuse in object oriented design, I consider this bug "critical". Also note that WildFly 8.2.0 pass all the tests provided in the link.






[GLASSFISH-21289] JMS broker fails on concurrent writes to single topic when using distributed transactions. Created: 17/Jan/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: jiggster Assignee: mskdeepak
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested with glass fish-embedded on Windows 7 & Mac OSX 10.10.1


Tags: 4-0-b78

 Description   

When multiple threads write to single JMS topic (only tested with topic, but that might be true for the queues also), each in its own distributed transaction, the broker fails with an error like the one below:

Jan 17, 2015 10:13:51 PM com.sun.messaging.jms.ra.DirectXAResource validateAndSaveXidTransactionID
INFO: DXAR:start():Warning: XAResource with state COMPLETE received diff Xid for open txnId:switching transactionId:
DXAR  Xid=(GlobalTransactionID=[B@1d8256f1, BranchQualifier=[B@42963311) 
DXAR TXid=5598056773328087040
got   Xid=(GlobalTransactionID=[B@1c462fe0, BranchQualifier=[B@47c43f17) 
got  TXid=5598056773328088320
Jan 17, 2015 10:13:51 PM com.sun.messaging.jms.ra.DirectXAResource prepare
SEVERE: prepareTransaction (XA) on JMSService:jmsdirect failed for connectionId:5598056773326219776 due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Bad transaction state transition. Cannot perform operation PREPARE_TRANSACTION(56) (XAFlag=null) on a transaction in state STARTED(1).
Jan 17, 2015 10:13:51 PM com.sun.jts.CosTransactions.RegisteredResources distributePrepare
WARNING: JTS5031: Exception [java.lang.RuntimeException: javax.transaction.xa.XAException] on Resource [prepare] operation.
Jan 17, 2015 10:13:51 PM com.sun.messaging.jms.ra.DirectXAResource rollback
SEVERE: rollbackTransaction (XA) on JMSService:jmsdirect failed for connectionId:5598056773326219776:transactionId=5598056773328088320 due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Transaction XID mismatch 6A696767626F6F6B2E6C6F63616C2C7365727665722C503130302C013B0000004D8FBEF96A696767626F6F6B2E6C6F63616C2C7365727665722C50313030, expected 6A696767626F6F6B2E6C6F63616C2C7365727665722C503130302C013C0000004D8FBEF96A696767626F6F6B2E6C6F63616C2C7365727665722C50313030 for transaction 5598056773328088320
Jan 17, 2015 10:13:51 PM com.sun.jts.jtsxa.OTSResourceImpl rollback
WARNING: JTS5068: Unexpected error occurred in rollback
javax.transaction.xa.XAException
	at com.sun.messaging.jms.ra.DirectXAResource.rollback(DirectXAResource.java:738)
	at com.sun.messaging.jms.ra.DirectXAResource.rollback(DirectXAResource.java:689)
	at com.sun.jts.jta.TransactionState._rollback(TransactionState.java:202)
	at com.sun.jts.jta.TransactionState.rollback(TransactionState.java:180)
	at com.sun.jts.jtsxa.OTSResourceImpl.rollback(OTSResourceImpl.java:333)
	at com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1040)
	at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2291)
	at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:391)
	at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:231)
	at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:622)
	at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:331)
	at com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate.commitDistributedTransaction(JavaEETransactionManagerJTSDelegate.java:185)
	at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.commit(JavaEETransactionManagerSimplified.java:859)
	at com.sun.enterprise.transaction.UserTransactionImpl.commit(UserTransactionImpl.java:212)
	at com.ibm.jbatch.container.transaction.impl.JTAUserTransactionAdapter.commit(JTAUserTransactionAdapter.java:91)
	at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeChunk(ChunkStepControllerImpl.java:620)
	at com.ibm.jbatch.container.impl.ChunkStepControllerImpl.invokeCoreStep(ChunkStepControllerImpl.java:684)
	at com.ibm.jbatch.container.impl.BaseStepControllerImpl.execute(BaseStepControllerImpl.java:144)
	at com.ibm.jbatch.container.impl.ExecutionTransitioner.doExecutionLoop(ExecutionTransitioner.java:112)
	at com.ibm.jbatch.container.impl.JobThreadRootControllerImpl.originateExecutionOnThread(JobThreadRootControllerImpl.java:110)
	at com.ibm.jbatch.container.util.BatchWorkUnit.run(BatchWorkUnit.java:80)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
Caused by: com.sun.messaging.jmq.jmsservice.JMSServiceException: rollbackTransaction: rollback transaction failed. Connection ID: 5598056773326219776, Transaction ID: 5598056773328088320, XID: (Available at FINE log level) Caused by:com.sun.messaging.jmq.jmsserver.util.BrokerException: Transaction XID mismatch 6A696767626F6F6B2E6C6F63616C2C7365727665722C503130302C013B0000004D8FBEF96A696767626F6F6B2E6C6F63616C2C7365727665722C50313030, expected 6A696767626F6F6B2E6C6F63616C2C7365727665722C503130302C013C0000004D8FBEF96A696767626F6F6B2E6C6F63616C2C7365727665722C50313030 for transaction 5598056773328088320
	at com.sun.messaging.jmq.jmsserver.service.imq.JMSServiceImpl.rollbackTransaction(JMSServiceImpl.java:1718)
	at com.sun.messaging.jms.ra.DirectXAResource.rollback(DirectXAResource.java:714)
	... 27 more
Caused by: com.sun.messaging.jmq.jmsserver.util.BrokerException: Transaction XID mismatch 6A696767626F6F6B2E6C6F63616C2C7365727665722C503130302C013B0000004D8FBEF96A696767626F6F6B2E6C6F63616C2C7365727665722C50313030, expected 6A696767626F6F6B2E6C6F63616C2C7365727665722C503130302C013C0000004D8FBEF96A696767626F6F6B2E6C6F63616C2C7365727665722C50313030 for transaction 5598056773328088320
	at com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.rollbackTransaction(ProtocolImpl.java:921)
	at com.sun.messaging.jmq.jmsserver.service.imq.JMSServiceImpl.rollbackTransaction(JMSServiceImpl.java:1706)
	... 28 more

I've created a test case that reproduces the issue quite repeatedly - it's available on github.

The test case consists of a batch job that contains a single chunk-style step with partition mapper (step's partitioned as the problem occurs in a concurrent environment). ItemReader creates random number (between MIN and MAX as defined in SimplePartitionMapper) of entity instances of type Subscriber. ItemProcessor does nothing, but sleeps for 50 ms. Item writer persists entities created by the reader and then publishes the collection of items to JMS topic (in a single distributed transaction) and here's where the problem occurs. Will try to provide the more detailed description of the test case in the README.md file on github.



 Comments   
Comment by stephanbauer7 [ 11/Mar/15 ]

Hi,
I have the same problem with Queues in Glassfish 4.1. I am also using XA-Transactions.

Information:   11 Mrz 2015 10:55:53,039 [p: thread-pool-1; w: 3] DEBUG org.apache.ibatis.logging.jdbc.BaseJdbcLogger:132 - ==>  Preparing: delete from ACT_RU_EVENT_SUBSCR where ID_ = ? and REV_ = ?
Information:   11 Mrz 2015 10:55:53,039 [pool-22-thread-3] DEBUG org.activiti.engine.impl.db.DbSqlSession:828 - executing: delete JobEntity [id=42532]
Information:   11 Mrz 2015 10:55:53,039 [pool-22-thread-3] DEBUG org.apache.ibatis.logging.jdbc.BaseJdbcLogger:132 - ooo Using Connection [com.sun.gjc.spi.jdbc40.ConnectionWrapper40@4e70cf77]
Schwerwiegend:   commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:6980944495603333120 and onePhase:true due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Transaction XID mismatch 6D75686861676C2C7365727665722C50333730302C000C000000660039086D75686861676C2C7365727665722C5033373030, expected 6D75686861676C2C7365727665722C50333730302C000B000000660039086D75686861676C2C7365727665722C5033373030 for transaction 6980944495768780544
Information:   11 Mrz 2015 10:55:53,039 [p: thread-pool-1; w: 3] DEBUG org.apache.ibatis.logging.jdbc.BaseJdbcLogger:132 - ==> Parameters: 40068(String), 1(Integer)
Information:   11 Mrz 2015 10:55:53,039 [pool-22-thread-3] DEBUG org.apache.ibatis.logging.jdbc.BaseJdbcLogger:132 - ==>  Preparing: delete from ACT_RU_JOB where ID_ = ? and REV_ = ?
Schwerwiegend:   rollbackTransaction (XA) on JMSService:jmsdirect failed for connectionId:6980944495603333120:transactionId=6980944495768780544 due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Transaction XID mismatch 6D75686861676C2C7365727665722C50333730302C000C000000660039086D75686861676C2C7365727665722C5033373030, expected 6D75686861676C2C7365727665722C50333730302C000B000000660039086D75686861676C2C7365727665722C5033373030 for transaction 6980944495768780544
Information:   11 Mrz 2015 10:55:53,040 [p: thread-pool-1; w: 3] DEBUG org.apache.ibatis.logging.jdbc.BaseJdbcLogger:132 - <==    Updates: 1
Comment by amyk [ 11/Mar/15 ]

Assuming the test case follows the JMS and Java EE spec (haven't looked at it myself) in using transaction, JMS Session, JMSContext etc., I suspect this is likely an issue with jms-service DIRECT (or EMBEDDED) mode for it uses a completely different path in JMSRA to interact with broker. I'd suggest first check the test case to ensure spec compliance, then try jms-service LOCAL mode.





[GLASSFISH-21313] Ordering of Cipher Suites kills Forward Secrecy with major browsers Created: 23/Feb/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: nabizamani Assignee: gururaja1234
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04 LTS Server x64, java 1.8.0_31 + JCE Unlimited Strength, GlassFish Server Open Source Edition 4.1 (build 13)


Tags: ciper, forward, order,, secrecy, suites,

 Description   

https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy

This is the list of supported cipher suites (when disabling RC4 via JSSE) as received via "asadmin list-supported-cipher-suites" (see below).
As you can see the following cipher suites are nor really "top listed", which means that for major browsers Forward Secrecy is disabled because the selected cipher suite does not support it:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
there are some more...

Here is a list of some of the affected browsers:
IE 11 / Win 7 R via TLS 1.2 ==> TLS_RSA_WITH_AES_128_CBC_SHA256
IE 8-10 / Win 7 R via TLS 1.0 ==> TLS_RSA_WITH_AES_128_CBC_SHA

Glassfish should at least allow to change the order of the "server-side" list of supported cipher suites. Furthermore, Java has even introduced an API for listening a little more to "what the client wants", see http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html :

Cipher Suite Preference:
During TLS handshaking, the client requests to negotiate a cipher suite from a list of cryptographic options that it supports, starting with its first preference. Then, the server selects a single cipher suite from the list of cipher suites requested by the client. Normally, the selection honors the client's preference. However, to mitigate the risks of using weak cipher suites, the server may select cipher suites based on its own preference rather than the client's preference, by invoking the method SSLParameters.setUseCipherSuitesOrder(true).

That means it would also be great to apply SSLParameters.setUseCipherSuitesOrder(bool) via asadmin settings (probably on the http-linteners ssl section).

#####################################################
And here is the complete list of cypher suites (RC4 is disabled):
#####################################################

$ /home/glassfish/bin/asadmin list-supported-cipher-suites
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_DH_anon_WITH_AES_256_GCM_SHA384
TLS_DH_anon_WITH_AES_128_GCM_SHA256
TLS_DH_anon_WITH_AES_256_CBC_SHA256
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA256
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_NULL_SHA256
TLS_ECDHE_ECDSA_WITH_NULL_SHA
TLS_ECDHE_RSA_WITH_NULL_SHA
SSL_RSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_anon_WITH_NULL_SHA
SSL_RSA_WITH_NULL_MD5



 Comments   
Comment by nabizamani [ 23/Feb/15 ]

For example, this would allow forward secrecy in IE on Win 7 (maybe there are better cipher suites that allow forward secrecy and which are supported by the different IE versions):

IE 11 / Win 7 R via TLS 1.2 ==> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
IE 8-10 / Win 7 R via TLS 1.0 ==> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

But unfortunately Glassfish only selects this, which has no Forward Secrecy as I believe to know:

IE 11 / Win 7 R via TLS 1.2 ==> TLS_RSA_WITH_AES_128_CBC_SHA256
IE 8-10 / Win 7 R via TLS 1.0 ==> TLS_RSA_WITH_AES_128_CBC_SHA





[GLASSFISH-21324] Glassfish logger is broken Created: 05/Mar/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: logging
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: oleksiys Assignee: mskdeepak
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

IMO the Glassfish logger is completely broken.
When I log a message with parameters.

For example I have an object:

public class Counter {
       private int i;
       public void set(int i) {this.i = i;};
       public void inc() {i++;}
       public int getCount() { return i;}
       public String toString() {return "" + i;}
}

and I try to log the Counter state like:

LOGGER.log(Level.INFO, "counter={0}", new Object[] {counter});

the LOGGER will pass the actual logging task to a separate thread, where counter.toString() will be resolved. But the problem is that by that time the counter could be changed, recycled etc... by the original thread,

for example the output of this code:

counter.set(1);
LOGGER.log(Level.INFO, "counter={0}", new Object[] {counter});
counter.inc();

is undetermined, but I want it to be only "1", I don't want it to be "2" or anything else.






[GLASSFISH-21326] deployment of a EJB with a CDI injection from a different jar fail Created: 12/Mar/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: tiran1984 Assignee: Vinay Vishal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

i try to deploy a application with a EJB which make a CDI injection from a different jar. But the deployment fails.

A simple CDI injection in the same jar works

I get these exception:

Exception during lifecycle processing
org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408: Unsatisfied dependencies for type CDIOutOfEJB with qualifiers @Default
at injection point [BackedAnnotatedField] @Inject private com.ducktail.ejb.EJBImpl.outofEJB
at com.ducktail.ejb.EJBImpl.outofEJB(EJBImpl.java:0)

The deployment of the same ear on wildfly works



 Comments   
Comment by jjsnyder83 [ 24/Mar/15 ]

Please provide a reproducible test case.

Comment by tiran1984 [ 24/Mar/15 ]

How can i attach my project?

Comment by jjsnyder83 [ 16/Apr/15 ]

You can mail it to me: j.j.snyder@oracle.com

Comment by tiran1984 [ 05/May/15 ]

I send the test case! Did you received?

Comment by jjsnyder83 [ 07/May/15 ]

Yes I have it. I see why it's failing. You should be able to work around the issue by putting the testbl-3.7.0-SNAPSHOT.jar into the Ear's lib directory.

Comment by jjsnyder83 [ 11/May/15 ]

I believe this is closely related to or a duplicate of these issues:
https://java.net/jira/browse/GLASSFISH-15119
https://java.net/jira/browse/GLASSFISH-15249

Comment by tiran1984 [ 03/Jun/15 ]

No it work the deployment but I get a lot of warnings!

PWC6351: In TLD scanning, the supplied resource file:/D:/glassfish4/glassfish/domains/DOMAIN1/applications/CNEAR/commons-codec-1.3.jar does not exist
java.io.FileNotFoundException: D:\glassfish4\glassfish\domains\DOMAIN1\applications\CNEAR\commons-codec-1.3.jar (The system cannot find the file specified)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:220)
at java.util.zip.ZipFile.<init>(ZipFile.java:150)
at java.util.jar.JarFile.<init>(JarFile.java:166)

How can I resolve this?

Comment by tiran1984 [ 03/Jun/15 ]

An other error by the deployment is

Exception during lifecycle processing
java.lang.IllegalArgumentException: Could not find sub module [fmcalRCP.war] as defined in application.xml
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:560)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:229)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:232

I can not reproduce it! I will get him sporadically!

Comment by jjsnyder83 [ 03/Jun/15 ]

Please provide full exception stacks so we can determine where the exception starts.

Comment by tiran1984 [ 03/Jun/15 ]

2015-06-03T13:11:47.556+0200] [glassfish 4.1] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=58 _ThreadName=admin-listener(4)] [timeMillis: 1433329907556] [levelValue: 1000] [[
Exception during lifecycle processing
java.lang.IllegalArgumentException: Could not find sub module [cmcalRCP.war] as defined in application.xml
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:560)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:229)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:232)
at org.glassfish.javaee.core.deployment.DolProvider.processDOL(DolProvider.java:193)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:227)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:96)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:881)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:821)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:377)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
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:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:404)
at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
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:497)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:151)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:171)
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:104)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:387)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:331)
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:103)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:297)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:254)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:365)
at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:173)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:179)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.portunif.PUFilter.handleRead(PUFilter.java:231)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
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:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)
]]

[2015-06-03T13:11:47.582+0200] [glassfish 4.1] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=58 _ThreadName=admin-listener(4)] [timeMillis: 1433329907582] [levelValue: 1000] [[
Exception while deploying the app [CMEAR] : Could not find sub module [cmcalRCP.war] as defined in application.xml]]

Comment by jjsnyder83 [ 03/Jun/15 ]

It appears to be something wrong with the application deployment.

Comment by tiran1984 [ 12/Jun/15 ]

during the deployment the application folder will not complete deleted. The folder can also not deleted from file system manuel . I have to restart the server for successful deploy or delete

It is always the same path "applications\EAR\test_war\WEB-INF\lib"
It is possilbe to find out which process lock the jar?

Comment by Vinay Vishal [ 12/Jun/15 ]

This issue could be similar to https://java.net/jira/browse/GLASSFISH-21261 which has already been fixed in revision 63874. Can you please give it a try with latest glassfish build and let us know?

http://download.java.net/glassfish/4.1/nightly/latest-glassfish.zip

Comment by tiran1984 [ 12/Jun/15 ]

Nothing changed, when i tried quick

in the ear folder I have the file .glassfishStaleFiles with
_war/
_war/WEB-INF/
_war/WEB-INF/lib/
_war/WEB-INF/lib/bl-3.7.0-SNAPSHOT.jar
lib/
lib/bl-3.7.0-SNAPSHOT.jar

this is a jar which have a beans.xml for weld cdi, it is always the this file which could not deleted

Comment by tiran1984 [ 22/Jun/15 ]

can someone help?
when I remove the beans.xml, the undeploy works fine but the CDI is disabled

Comment by jjsnyder83 [ 23/Jun/15 ]

Please send me new app and I'll try it out.





[GLASSFISH-21365] No content from web application without web.xml Created: 27/May/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: petrhejl Assignee: Vinay Vishal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

1) download GF 4.1 and unzip it
2) cd glassfish4/glassfish/bin
3) ./asadmin
4) start-domain
5) change-admin-password (configure admin password to glassfish)
6) enable-secure-admin
7) stop-domain
8) start-domain
9) deploy the simplest Java EE 7 app without any descriptor (web.xml) - for example: curl -v --insecure --user admin:glassfish https://127.0.0.1:4848/__asadmin/deploy?DEFAULT=/home/petr/NetBeansProjects/WebApplication1/dist/WebApplication1.war\&force=true\&name=WebApplication1\&contextroot=/WebApplication1
10) Access the aplication: curl -v http://localhost:8080/WebApplication1/
11) No content:
< HTTP/1.1 200 OK

  • Server GlassFish Server Open Source Edition 4.1 is not blacklisted
    < Server: GlassFish Server Open Source Edition 4.1
    < X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 4.1 Java/Oracle Corporation/1.7)
    < Date: Wed, 27 May 2015 12:34:43 GMT
    < Content-Length: 0

In the server log:
WEB9100: No WebSecurityManager found for context WebApplication1/WebApplication1

The issue persists until the deployment of the first app containing web.xml.



 Comments   
Comment by lprimak [ 04/Jan/17 ]

Will be solved by Payara as part of https://github.com/payara/Payara/issues/1070





[GLASSFISH-21380] plaintext default-principal-password Created: 26/Jun/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 4.0, 4.1, 4.1.1
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: ytroch Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: password, security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all tested


Tags: password, secuirty

 Description   

enabling "Default-principal to role mapping" makes te password appear in the domain.xml file.
disabling the option again leaves the plaintext passwords in the domain.xml file.

mentioned on bug 8032, fixed for gui, not domain.xml.






[GLASSFISH-21382]  A system exception occurred during an invocation on EJB Created: 27/Jun/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: dyego Assignee: gururaja1234
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 14 + 5GB of ram + SSD 80GB



 Description   

In my application, randomily i get :

[2015-06-26T20:53:36.645-0300] [glassfish 4.1] [WARNING] [AS-EJB-00056] [javax.enterprise.ejb.container] [tid: _ThreadID=892 _ThreadName=p: thread-pool-1; w: 796] [timeMillis: 1435362816645] [levelValue: 900] [[
A system exception occurred during an invocation on EJB PaisesNacionalidadesRepositoryRJ, method: public us.linkedby.link.selo.entities.RjPaisesnacionalidades us.linkedby.link.selo.service.referenciarj.paisesnacionalidades.PaisesNacionalidadesRepositoryRJ.getRjPaisesnacionalidadesByNomePais(java.lang.String)]]

[2015-06-26T20:53:36.645-0300] [glassfish 4.1] [WARNING] [] [javax.enterprise.ejb.container] [tid: _ThreadID=892 _ThreadName=p: thread-pool-1; w: 796] [timeMillis: 1435362816645] [levelValue: 900] [[

javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
at com.sun.ejb.containers.EJBContainerTransactionManager.useClientTx(EJBContainerTransactionManager.java:361)
at com.sun.ejb.containers.EJBContainerTransactionManager.preInvokeTx(EJBContainerTransactionManager.java:255)
at com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:4524)
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1986)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:210)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy337.getRjPaisesnacionalidadesByNomePais(Unknown Source)
at us.linkedby.link.selo.service.referenciarj.paisesnacionalidades._EJB31_GeneratedPaisesNacionalidadesRepositoryRJIntf__Bean_.getRjPaisesnacionalidadesByNomePais(Unknown Source)
at us.linkedby.link.selo.service.referenciarj.paisesnacionalidades.PaisesNacionalidadesServiceRJ.getRjPaisesnacionalidadesCodigoByNomePais(PaisesNacionalidadesServiceRJ.java:69)
at sun.reflect.GeneratedMethodAccessor354.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

But, this occurs if i call 15k times the EJB method... and ocurs in diferents parts of my code...



 Comments   
Comment by dyego [ 27/Jun/15 ]

only in linux, on windows doest occurs

Comment by dyego [ 27/Jun/15 ]

The transaction is maked to rollback in diferent points on execution and this error occurs after that...

If i invoce 10k times the EJB method this not occurs..

11k not occurs...

15k occurs...

help!





[GLASSFISH-21412] CLONE - EJB + JAX-RS don't work with updated example Created: 11/Aug/15  Updated: 14/Feb/17

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

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

Issue Links:
Cloners
clones GLASSFISH-20654 EJB + JAX-RS don't work on the simple... Resolved

 Description   
/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package pcrl.model.services;

import javax.annotation.ManagedBean;
import javax.ejb.Stateless;
import javax.enterprise.context.RequestScoped;
import pcrl.model.entities.RepairLocation;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.PersistenceUnit;
import javax.transaction.Transactional;
import javax.ws.rs.BeanParam;
import javax.ws.rs.POST;
import javax.ws.rs.Path;


/**
 *
 * @author walec51
 */
@Stateless
@Path("/api/RepairLocationRepository")
public class RepairLocationRepository {
    
    @PersistenceContext
    private EntityManager em;
    
    @POST
    @Path("add")
    public void add(@BeanParam RepairLocation rl) {
        em.persist(rl);
    }
}

SEVERE:   WebModule[/PcRepairLocations]Exception starting filter pcrl.PcrlApplication
java.lang.InstantiationException
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:135)
	at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:5297)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:5909)
	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:2278)
	at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1924)
	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.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:537)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at org.glassfish.deployment.admin.ReDeployCommand.execute(ReDeployCommand.java:131)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
	at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
	at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	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:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.IllegalStateException: Error when configuring to use the EJB interceptor binding API. JAX-RS EJB integration can not be supported.
	at org.glassfish.jersey.gf.ejb.EjbComponentProvider.registerEjbInterceptor(EjbComponentProvider.java:168)
	at org.glassfish.jersey.gf.ejb.EjbComponentProvider.bind(EjbComponentProvider.java:200)
	at org.glassfish.jersey.server.ApplicationHandler.bindWithComponentProvider(ApplicationHandler.java:809)
	at org.glassfish.jersey.server.ApplicationHandler.bindProvidersAndResources(ApplicationHandler.java:741)
	at org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:388)
	at org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:157)
	at org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:280)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:289)
	at org.glassfish.jersey.internal.Errors$2.call(Errors.java:286)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.processWithException(Errors.java:286)
	at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:277)
	at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:262)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
	at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:379)
	at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
	at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:131)
	... 53 more
Caused by: java.lang.reflect.InvocationTargetException
	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.glassfish.jersey.gf.ejb.EjbComponentProvider.registerEjbInterceptor(EjbComponentProvider.java:163)
	... 70 more
Caused by: java.lang.NullPointerException
	at com.sun.ejb.containers.InternalInterceptorBindingImpl.registerInterceptor(InternalInterceptorBindingImpl.java:97)
	... 75 more


 Comments   
Comment by atrajano [ 12/Aug/15 ]

It didn't clone the comments as I expected... here is the text that should've gone up on the description

I am encountering the same error on GlassFish 4.1

I created a simple example

https://github.com/trajano/test/tree/local-beans

A simple @Stateless SLSB
A JAX-RS resource annotated with @Stateless
The resource has an @EJB reference
The @PostConstruct method simply does a System.out

In my example it fails the moment the resource SLSB is postconstructed

http://localhost:8080/test-war/V1/resource





[GLASSFISH-21438] java.lang.NoClassDefFoundError: javax/xml/parsers/ParserConfigurationException Created: 09/Oct/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: grantjennings Assignee: Srini
Resolution: Unresolved Votes: 3
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OSX 10.11



 Description   

This bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=463169

is in the release version of GF 4.1.1.

Eclipse Persistence Services - 2.6.1.v20150605
Bug was fixed in eclipselink on 2015-06-26

Applications dependent on moxy are undeployable.



 Comments   
Comment by Lvdberg [ 30/Nov/15 ]

Several attempts to get this working failed. Just moved back to 4.1....

Comment by khonraad [ 30/Nov/15 ]

Exactly the same problem here

Comment by Yamini K B [ 14/Feb/17 ]

GlassFish 4.1.1 uses EclipseLink 2.6.1 RC1 which was released on 5-JUN-2015

The version in trunk is 2.6.3 M1. Can you please try with GlassFish 5.0?





[GLASSFISH-21462] adminGUI does not load the classpath from manifest.mf to the precompilejsp in Application Deploy module Created: 05/Nov/15  Updated: 14/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui, classloader, deployment, ejb_container
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ccagf Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: jspc, precompilejsp, waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PWC6112, admin-gui, admingui, deploy, java.lang.ClassNotFoundException:, jspc, precompilejsp

 Description   

in adminGUI ==> Applications ==> Deploy Applications or Modules ==> Precompile JSPs:

if You choose the Option - Precomplier works with JARs included in the LIB
But Fails when 3rd Party Jars are refeneced in the manifest.mf file - as the Glassfish Precomplier is not reading the class path from manifest.mf.

In Glassfish Version 2.1.1 It Works - Stopped working since Glassfish v3.
Does Not work on Glassfish 4.1.1

Sugested BUG Fix - adminGUI (when precompilejsp is checked) also needs to Read the Manifest.MF's Class-Path and pass it on to the jspc compiler.

Error: PWC6112
java.lang.ClassNotFoundException:

Just FYI - When I pass the class-path part of jspc and copmile it works - so the bug surely is on the adminGUI console



 Comments   
Comment by sumasri [ 14/Feb/17 ]

I created a web application and referred third party jar in manifest.mf file and created war file for deploying.
Deployed that app and is working as expected. I do not see any issue as specified in the issue.
If you still see the issue, please provide me the app and exact steps to reproduce the issue.





[GLASSFISH-21675] clean up SSL settings in web devtests Created: 10/Feb/17  Updated: 14/Feb/17  Resolved: 14/Feb/17

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: None
Fix Version/s: 5.0

Type: Bug Priority: Minor
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 3 Sprint 2

 Description   

In current GlassFish, https is enabled by default.
So there is no need to enable the https listener for testing.
In GlassFish appserv-tests, there are some tests enable/disable https listeners, and part of them even restart the listeners, too.
We would like to clean this up. This will speed up the web devtest running time.



 Comments   
Comment by Shing Wai Chan [ 13/Feb/17 ]

Sending formLoginTransportGuaranteeConfidential/build.xml
Sending keepAliveTimeoutSSL/build.xml
Sending portUnification/src/main/java/org/glassfish/devtests/web/portunif/PortUnificationTest.java
Sending redirectPort/build.xml
Sending servlet-3.0/transportProtectedAnnotation/build.xml
Sending servletSSLRequestAttributes/build.xml
Sending ssl/build.xml
Sending sslClientAuthUnprotectedResourceGetClientCert/build.xml
Sending sslCookie/build.xml
Sending sslMultiSelector/build.xml
Sending sslServerName/WebTest.java
Sending virtualServerChangeHttpListenerWebappNoLongerAccessible/build.xml
Sending weldJsfLoginPage/build.xml
Sending wrongTransport/src/main/java/wrongtransport/HttpRedirectElement.java
Sending wrongTransport/src/main/java/wrongtransport/WrongTransportSSL.java
Transmitting file data ...............
Committed revision 64535.





[GLASSFISH-21626] The Number of Connections is incorrect (negative value) when leak timeout occurs in JDBC monitoring Created: 22/Nov/16  Updated: 14/Feb/17

Status: In Progress
Project: glassfish
Component/s: monitoring
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: tak09 Assignee: srinik76
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 5.0-b01


Issue Links:
Blocks
is blocked by GLASSFISH-21272 JDBC Monitoring MBeans not working in... Open

 Description   

Issue:

The Number of Connections is incorrect in JDBC monitoring when "Statement Leak Reclaim" is enabled and timeout occurs.

Check the following metrics in the monitoring:

  • numconnfree (The number becomes "Expected + 1". However, this should not occur. When the connection leak timeout occurs, the connection is discarded. It is not returned to the pool.)
  • numconnreleased (The number becomes "Expected + 1". However, this should not occur. When the connection leak timeout occurs, the connection is discarded. It is not returned to the pool.)
  • numconnused (The number becomes "Expected - 1". However, this should not occur. This value becomes negative but it shouldn't become negative.)

This bug is reproduced in the following condition:
1. Enable "Statement Leak Reclaim"
2. Get a JDBC Connection from an application
3. "Leak Timeout" occurs in the Connection of 2.
4. The applicaiton calls close() to close the Connection of 2.

Steps to Reproduce Issue:
1. Create a table on JavaDB
Create a table as the example use JavaDB.
a. Start JavaDB
asadmin start-database
b. Create a table
.\glassfish4\javadb\bin\ij
ij> connect 'jdbc:derby://localhost:1527/sun-appserv-samples;create=true';
ij> create table mytable(mycol1 varchar(20), mycol2 varchar(20));
ij> insert into mytable values('data1', 'data1');
ij> insert into mytable values('data2', 'data2');
ij> commit;
ij> select * from mytable;
ij> exit;

2. Ensure JDBC Resource and JDBC Connection exist.
The test program uses "DerbyPool" and "jdbc/__default" which are already created by the default installation of Glassfish.

3. Enable "Statement Leak Reclaim" and change "Statement Leak Timeout"
In the GUI, navigate to "Resources>JDBC>JDBC Connection Pool>DerbyPool".
In "Advanced" tab, enable "Statement Leak Reclaim" and change "Statement Leak Timeout" to "5" Seconds.

4. Turn on Monitoring for JDBC
Set HIGH for JDBC monitoring
asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH

5. Deploy Web application

6. Open Web application.
http://localhost:8080/WebApplication2/Hello (It takes about 10 sec, as there is sleep 10sec in the Web application. When the application is completed, the contents of "select * from mytable" is displayed.)

7. Check the statistics using REST interface while waiting 10 sec.
http://localhost:4848/monitoring/domain1/server/resources/DerbyPool
Check the following metrics:

  • numconnfree
  • numconnreleased
  • numconnused

8. Check the above statistics using REST again after loading the Web application is finished. (After 10 sec sleep)

Check the followings:

  • numconnfree (The number becomes "Expected + 1")
  • numconnreleased (The number becomes "Expected + 1")
  • numconnused (The number becomes "Expected - 1")


 Comments   
Comment by tak09 [ 22/Nov/16 ]

The test web application can be downloaded here.
https://www.dropbox.com/s/94rqd7ntds5filg/WebApplication2.war?dl=0

Comment by srinik76 [ 17/Jan/17 ]

Tested the above steps with latest revision 64402. After accessing the application checked the following

http://localhost:4848/monitoring/domain1/server/resources/DerbyPool

The number of connections used does not become negative. It remains zero with high watermark as 1. Not reproducible with latest build

Comment by srinik76 [ 17/Jan/17 ]

Cannot reproduce with latest build

Comment by srinik76 [ 18/Jan/17 ]

Reopening to add a label : waiting_on_filer

Comment by tak09 [ 08/Feb/17 ]

I have confirmed that this bug is actually blocked by GLASSFISH-21272 – without the fix for that bug, the JDBC monitoring statistics ('numconnfree', 'numconnrelease' and 'numconnused') are not updated properly. Bug #21272 must be fixed before bug #21626 can be reproduced.

I apologise for this missing information in my previous comment. I had already applied the full patches supplied for GLASSFISH-21272 and GLASSFISH-21276 to my Glassfish 5.0 build so that I could view the MBean statistics.

Comment by tak09 [ 08/Feb/17 ]

Bug #21272

First, please follow the steps below to reproduce GLASSFISH-21272.

1. Turn on Monitoring for JDBC
Set HIGH for JDBC monitoring
asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
2. Open the Web application which I have supplied.
http://localhost:8080/WebApplication2/Hello
3. Start jconsole and enter the following address in Remote Process.
service:jmx:rmi://localhost:8686/jndi/rmi://localhost:8686/jmxrmi
4. In "MBeans" tab, open
"amx>jdbc-connection-pool-mon>/mon/server-mon[server]>resources/DerbyPool>Attributes" in tree.
Then, you will find the values are displayed as "Unavailable" in red. Please see the attached screen capture.
5. Please fix this issue as suggested by smillidge-c2b2 in GLASSFISH-21272.
When this issue is fixed these values are shown as "javax.management.openmbean.CompositeDataSupport".

Comment by tak09 [ 08/Feb/17 ]

Screen capture of jconsole
https://www.dropbox.com/s/o4konguyl5sjocf/jmx_jdbc-connection-pool-mon_DerbyPool.gif?dl=0

Comment by tak09 [ 08/Feb/17 ]

Bug #21276

GLASSFISH-21276 is a similar bug to #21272.
The status in the bug ticket is shown as "RESOLVED" but I have noticed that this bug has not been fixed yet has only been partially fixed. (Only 10 of the 19 MBean classes in the provided patch have been fixed in Glassfish.) I recommend that you fix #21276 together with #21272, as these two are almost same issues. Please see my comment in bug #21276 for details.

Comment by tak09 [ 08/Feb/17 ]

Bug #21626 (This bug ticket)

Once you have confirmed the above bugs (#21272 and #21276) are fixed, you can start working on this bug #21626.

Reproducing bug:
Now, please follow the steps below to reproduce this bug.

1. Create a table on JavaDB
2. Ensure JDBC Resource and JDBC Connection Pool "DerbyPool" exist.
3. Enable "Connection Leak Reclaim" and change "Connection Leak Timeout"
In the GUI, navigate to "Resources>JDBC>JDBC Connection Pool>DerbyPool".
In "Advanced" tab, enable "Connection Leak Reclaim" and change "Connection Leak Timeout" to "5" Seconds.
Please note that in my previous comment "Statement Leak Reclaim" and "Connection Leak Timeout" are incorrect.
"Connection Leak Reclaim" and "Connection Leak Timeout" are correct. I apologize for the incorrect statements.
4. Turn on Monitoring for JDBC
5. Deploy Web application
6. Open Web application.
http://localhost:8080/WebApplication2/Hello
7. Check the statistics using REST interface or Jconsole while waiting 10 sec.
8. Check the above statistics using REST or Jconsole again after loading the Web application is finished. (After 10 sec sleep)
You can check the value using either REST interface or Jconsole.

Fixing bug:
The following is the suggested fix for the incorrect value of 'numconnfree', 'numconnrelease' and 'numconnused' below.
These are patch for Glassfish 5.0 b02.

/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/ConnectionPool.java
Index: ConnectionPool.java
===================================================================
--- ConnectionPool.java                (revision 64457)
+++ ConnectionPool.java             (working copy)
@@ -1017,7 +1017,7 @@
             freeUnenlistedResource(h);
         }
         
-        if (poolLifeCycleListener != null) {
+        if (poolLifeCycleListener != null && !h.getDestroyByLeakTimeOut()) {
             poolLifeCycleListener.connectionReleased(h.getId());
         }
         if (_logger.isLoggable(Level.FINE)) {
@@ -1063,7 +1063,7 @@
                 // Put it back to the free collection.
                 ds.returnResource(resourceHandle);
                 //update the monitoring data
-                if (poolLifeCycleListener != null) {
+                if (poolLifeCycleListener != null && !resourceHandle.getDestroyByLeakTimeOut()) {
                     poolLifeCycleListener.decrementConnectionUsed(resourceHandle.getId());
                     poolLifeCycleListener.incrementNumConnFree(false, steadyPoolSize);
                 }
@@ -1641,6 +1641,7 @@
         String msg = localStrings.getString("reclaim.leaked.connection", poolInfo);
         _logger.log(Level.INFO, msg);
         ds.removeResource(handle);
+        handle.setDestroyByLeakTimeOut(true);
         notifyWaitingThreads();

     }

                
/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/ResourceHandle.java
Index: ResourceHandle.java
===================================================================
--- ResourceHandle.java               (revision 64457)
+++ ResourceHandle.java            (working copy)
@@ -97,6 +97,8 @@
     private int usageCount; //holds the no. of times the handle(connection) is used so far.
     private int partition;

+    private boolean isDestroyByLeakTimeOut = false; 
+
     static private long getNextId() {
         synchronized (ResourceHandle.class) {
             idSequence++;
@@ -388,4 +390,12 @@
     public boolean isBusy(){
         return busy;
     }
+
+    public boolean getDestroyByLeakTimeOut(){ 
+        return isDestroyByLeakTimeOut; 
+    }
+
+    public void setDestroyByLeakTimeOut(boolean isDestroyByLeakTimeOut){ 
+        this.isDestroyByLeakTimeOut = isDestroyByLeakTimeOut; 
+    }
}

Comment by srinik76 [ 08/Feb/17 ]

As per filer, this issue can be reproduced only when issue GLASSFISH-21272 is fixed.





[GLASSFISH-21664] Implement Servlet 4.0 Server Push Created: 24/Jan/17  Updated: 13/Feb/17

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

Type: Task Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVLET_SPEC-134 Provide API supporting HTTP/2 Server ... In Progress
Tags: servlet_4_0
Sprint: MS 3 Sprint 2

 Description   

Implementation issue for SERVLET_SPEC-134.






[GLASSFISH-21440] Webservices don't work properly in 4.1.1 Created: 12/Oct/15  Updated: 13/Feb/17

Status: Open
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: setup Assignee: Vinay Vishal
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Ubuntu 15.04



 Description   

After switching from 4.1 to 4.1.1 webservices fail with error 500
server-log

[2015-10-11T07:32:14.904+1000] [glassfish 4.1] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=34 _ThreadName=http-listener-1(5)] [timeMillis: 1444512734904] [levelValue: 900] [[
  StandardWrapperValve[javax.ws.rs.core.Application]: Servlet.service() for servlet javax.ws.rs.core.Application threw exception
java.lang.NoClassDefFoundError: Could not initialize class org.eclipse.persistence.jaxb.BeanValidationHelper
	at org.eclipse.persistence.jaxb.JAXBBeanValidator.isConstrainedObject(JAXBBeanValidator.java:257)
	at org.eclipse.persistence.jaxb.JAXBBeanValidator.shouldValidate(JAXBBeanValidator.java:208)
	at org.eclipse.persistence.jaxb.JAXBMarshaller.validateAndTransformIfNeeded(JAXBMarshaller.java:587)
	at org.eclipse.persistence.jaxb.JAXBMarshaller.marshal(JAXBMarshaller.java:481)
	at org.eclipse.persistence.jaxb.rs.MOXyJsonProvider.writeTo(MOXyJsonProvider.java:949)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86)
	at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
	at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130)
	at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:683)
	at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:424)
	at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:414)
	at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:312)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:292)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
	at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:460)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:386)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:334)
	at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221)
	at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.glassfish.tyrus.servlet.TyrusServletFilter.doFilter(TyrusServletFilter.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.setupit.experiment.controller.util.URLFilter.doFilter(URLFilter.java:122)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)

------------------------------------------------------------

@Entity
@Table(name = "TITLE")
@XmlRootElement
@NamedQueries({
    @NamedQuery(name = "Title.findAll", query = "SELECT t FROM Title t"),
    @NamedQuery(name = "Title.findById", query = "SELECT t FROM Title t WHERE t.id = :id"),
    @NamedQuery(name = "Title.findByTitle", query = "SELECT t FROM Title t WHERE t.title = :title"),
    @NamedQuery(name = "Title.findByFullTitle", query = "SELECT t FROM Title t WHERE t.fullTitle = :fullTitle")})
public class Title implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Basic(optional = false)
    @Column(name = "id")
    private Integer id;
    @Basic(optional = false)
    @NotNull
    @Size(min = 1, max = 45)
    @Column(name = "title")
    private String title;
    @Size(max = 1024)
    @Column(name = "full_title")
    private String fullTitle;
    @OneToMany(mappedBy = "title")
    private List<User> userList;

    public Title() {
    }

    public Title(Integer id) {
        this.id = id;
    }

    public Title(Integer id, String title) {
        this.id = id;
        this.title = title;
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public String getFullTitle() {
        return fullTitle;
    }

    public void setFullTitle(String fullTitle) {
        this.fullTitle = fullTitle;
    }

    @XmlTransient
    public List<User> getUserList() {
        return userList;
    }

    public void setUserList(List<User> userList) {
        this.userList = userList;
    }

    @Override
    public int hashCode() {
        int hash = 0;
        hash += (id != null ? id.hashCode() : 0);
        return hash;
    }

    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof Title)) {
            return false;
        }
        Title other = (Title) object;
        if ((this.id == null && other.id != null) || (this.id != null && !this.id.equals(other.id))) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return title + " (id=" + id + " )";
    }
    
}

-----------------------------------

@Stateless
@Path("title")
public class TitleService extends AbstractFacade<Title> {
    @PersistenceContext(unitName = "org.setupit_experiment_war_1.0PU")
    private EntityManager em;

    public TitleService() {
        super(Title.class);
    }

    @GET
    @Path("{id}")
    @Produces({MediaType.APPLICATION_JSON})
    public Title find(@PathParam("id") Integer id) {
        return super.find(id);
    }

    @GET
    @Override
    @Produces({MediaType.APPLICATION_JSON})
    public List<Title> findAll() {
        List<Title> lt = super.findAll();
        return lt;
    }

    @Override
    protected EntityManager getEntityManager() {
        return em;
    }
    
}

---------------------------

    <servlet>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <url-pattern>/services/*</url-pattern>
    </servlet-mapping>


 Comments   
Comment by reza_rahman [ 12/Oct/15 ]

I can confirm this happens with Cargo Tracker as well. It's a fairly serious usability problem.

Comment by Vinay Vishal [ 14/Oct/15 ]

Bean validation was introduced in Eclipselink 2.6.0 and that is where the NoClassDefFoundError is thrown.

This could be a case of missing entries in MANIFEST.MF in org.eclipse.persistence.moxy osgi bundle. Following link suggests so.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=463169
https://java.net/jira/browse/JERSEY-2888

Comment by Lukas Jungmann [ 14/Oct/15 ]

this seems to be fixed with eclipselink-2.6.1-RC2

Comment by Vinay Vishal [ 14/Oct/15 ]

Thanks Lukas, it worked when I tried locally with eclipselink-2.6.1-RC2.

Comment by setup [ 14/Oct/15 ]

I just tried to replace eclipselink-2.6.1-RC1 with eclipselink-2.6.1-RC2. it didn't resolve the problem. Any other suggestions?

Comment by Vinay Vishal [ 15/Oct/15 ]

In my case, I rebuilt Glassfish locally after bumping up eclipselink version. Its working fine for me. May be you can try stopping the domain, cleaning up your osgi-cache inside domains/<domain> directory, restart the domain and see if it works?

Comment by nicof6786 [ 15/Oct/15 ]

Hi,
I tried to get around this issue using Jackson as a media provider.
I ran into a similar issue even though it was not blocking.
On the first call and only on the first call to a Jax-Rs resource I get the following error :

java.lang.NoClassDefFoundError: com/fasterxml/jackson/module/jaxb/JaxbAnnotationIntrospector
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator._resolveIntrospector(JsonMapperConfigurator.java:109)
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator._resolveIntrospectors(JsonMapperConfigurator.java:84)
        at com.fasterxml.jackson.jaxrs.cfg.MapperConfiguratorBase._setAnnotations(MapperConfiguratorBase.java:120)
        at com.fasterxml.jackson.jaxrs.json.JsonMapperConfigurator.getDefaultMapper(JsonMapperConfigurator.java:45)
        at com.fasterxml.jackson.jaxrs.base.ProviderBase.locateMapper(ProviderBase.java:864)
        at com.fasterxml.jackson.jaxrs.base.ProviderBase.writeTo(ProviderBase.java:588)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:265)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:106)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:86)
        at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
        at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130)
        at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:683)
        at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:424)
        at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:414)
        at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:312)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
        at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
        at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
        at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:292)
        at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1139)
        at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:460)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:386)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:334)
        at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:221)
        at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
        at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
        at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
        at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:416)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:283)
        at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
        at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
        at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
        at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
        at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
        at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
        at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
        at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
        at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
        at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
        at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
        at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
        at java.lang.Thread.run(Thread.java:745)

The subsequent calls work fine.
Should I declare another issue ?

Comment by xwibao [ 19/Oct/15 ]

That nasty JERSEY-2888 definitely crept into GlassFish 4.1.1 :-\

As a quick & dirty fix, one can find glassfish/modules/org.eclipse.persistence.moxy.jar and fix META-INF/MANIFEST.MF inside it. Simply append the following to Import-Package:

,org.xml.sax.helpers,javax.xml.parsers;resolution:=optional,javax.naming;resolution:=optional

and restart. That worked for me.

Comment by setup [ 26/Oct/15 ]

Thank you!

Editing glassfish/modules/org.eclipse.persistence.moxy.jar helps

Comment by sebastian2 [ 30/Nov/15 ]

Hi there,
this bug is also blocking us from updating to the new Glassfish version.

Comment by pdurbin [ 04/Dec/15 ]

This issue is blocking us from upgrading from Glassfish 4.1 to Glassfish 4.1.1 because bean validation isn't working in the latter. Please see the following comment for details and a stacktrace: https://github.com/IQSS/dataverse/issues/2628#issuecomment-158197478

At https://javabot.evanchooly.com/logs/%23glassfish/2015-12-04 Ed Burns mentioned that this issue (GLASSFISH-21440) is the one I should be tracking so if "bean validation" could be added to the title, I would really appreciate it. We're looking forward to a release that has the bug fix (Glassfish 4.1.2 or whatever). We'll pass on Glassfish 4.1.1. (We already do enough patching of Glassfish 4.1 per the GitHub issue above and our goal is to avoid making our users patch Glassfish.)

Thanks for Glassfish. It's great. We're looking forward to upgrading. (I kind of want to play with Ozark.

Comment by Pavel Bucek [ 04/Dec/15 ]

If you just wan't to "play", you can checkout and build glassfish trunk, I believe the issue is resolved there.

Comment by basler [ 22/Dec/15 ]

This bug is blocking my upgrade, but the moxy patch listed above worked.

Comment by nabizamani [ 23/Jan/16 ]

Hello Oracle!!!! I can confirm this bug also exists also on Mac OS.

It's such a pity that you don't care about this serious issue! I'm writing tutorials based on Glassfish and I just decided to drop Glassfish for all my future tutorials because the quality of GF is disgusting compared to the times it was managed by Sun! I will use Tomcat instead, congrats!! I'm so disappointed. It's such a shame that this obvious issue is not even assigned yet!

Comment by atiqkhaled [ 09/Apr/16 ]

Hi
Did you try it for XML. I mean replace xml on @Produces(

{MediaType.APPLICATION_JSON}

) . Hope it works then.

Comment by nabizamani [ 14/Apr/16 ]

Helloooo Oracle, anyone working on this???

Comment by andradeb.david [ 23/May/16 ]

Hi in this post is a solution .
http://ayudasdesarrollo.blogspot.com.co/2016/05/glassfish-441-falla-con-jax-rs-y-json.html

Comment by sombriks [ 18/Jun/16 ]

hello,

i can confirm that the bug still there.

i know that java.net stuff is being deactivated, however this bug is going to be one year old soon, even though the solution is documented here.

The solution is there like a couple of weeks after the bug was reported.

Comment by sentonimo [ 23/Dec/16 ]

Hi everybody:
I solved this error, but a little bit different than andradeb.david. I made the changes he wrote, but then I got the error related in other thread, https://java.net/jira/browse/GLASSFISH-21141
After this last error, I solved putting a forgotten JAR in the /module folder of Glassfish 4.1.1; this JAR is https://mvnrepository.com/artifact/com.fasterxml.jackson.module/jackson-module-jaxb-annotations/2.5.1 , which have the same version of the others JARs of Jackson. So, I stopped the server, deleted the OSGI-CACHE, put this jar on the folder /modules of Glassfish, started the server and all the errors are solved now.

The "bug" of Glassfish it's only forgetted JAR, just it all.

Hope useful for someone.
And, come on! It's only a missed JAR, it's not a big bug, a little sympathy for the great team of Glassfish, they're making always a good work

UPDATE: Actually the solution it's more ease than I figured out; with the solution of andradeb.david you will downgrade the library org.eclipse.persistence.moxy.jar, and it's no need. You only have to do this simple steps:
1) Open de original org.eclipse.persistence.moxy.jar with your favorite extractor and edit de META-INF/MANIFEST.MF. Include into the file, at the end of the block of "Import-Package:" this:

org.xml.sax.helpers,javax.xml.parsers, javax.naming

2) Save the jar, stop the server, clean de osgi-cache from Glassfih Domain, restart and that's all.
3) Probably, after solve this error, you will get the error cited at https://java.net/jira/browse/GLASSFISH-21141

I hope this solve all the errors for all of you. It was only a little error, forgotten "Imports" at the MANIFEST.MF, that's all. After this, server works perfectly, with his originals JARs and versions.





[GLASSFISH-21646] countbytesreceived and countbytestransmitted count the value of requests to admin-listener Created: 21/Dec/16  Updated: 13/Feb/17  Resolved: 13/Feb/17

Status: Closed
Project: glassfish
Component/s: monitoring, web_container
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: yama0428 Assignee: srinik76
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Even if request are not sent to web applications,
countbytesreceived and countbytestransmitted are not zero.

http://localhost:4848/monitoring/domain1/server/http-service/server/request/countbytesreceived

countbytesreceived

    count : 1013
    lastsampletime : 1482281113361
    description : The number of bytes received
    unit : count
    name : CountBytesReceived
    starttime : 1482281097714

This is because HttpServiceStatsProvider does not check the virtual server.
This is the patch for this problem.

HttpServiceStatsProvider.java
    @ProbeListener("glassfish:web:http-service:dataReceivedEvent")
    public void dataReceivedEvent(
        @ProbeParam("size") int size,
        @ProbeParam("hostName") String hostName) {
        if ((hostName != null) && (hostName.equals(virtualServerName))) {
            countBytesReceived.increment(size);
        }
    }

    @ProbeListener("glassfish:web:http-service:dataSentEvent")
    public void dataSentEvent(
        @ProbeParam("size") long size,
        @ProbeParam("hostName") String hostName) {
        if ((hostName != null) && (hostName.equals(virtualServerName))) {
            countBytesTransmitted.increment(size);
        }
    }
RequestProbeProvider.java
    @Probe(name="dataReceivedEvent")
    public void dataReceivedEvent(
        @ProbeParam("size") int size,
        @ProbeParam("hostName") String hostName) {}

    @Probe(name="dataSentEvent")
    public void dataSentEvent(
        @ProbeParam("size") long size,
        @ProbeParam("hostName") String hostName) {}
VirtualServer.java#addProbes(boolean globalAccessLoggingEnabled)
                    grizzlyListener.getTransport().getConnectionMonitoringConfig().addProbes(new ConnectionProbe.Adapter() {

                        RequestProbeProvider requestProbeProvider = webContainer.getRequestProbeProvider();

                        @Override
                        public void onReadEvent(Connection connection, Buffer data, int size) {
                            if (requestProbeProvider != null) {
                                requestProbeProvider.dataReceivedEvent(size, _id);
                            }
                        }

                        @Override
                        public void onWriteEvent(Connection connection, Buffer data, long size) {
                            if (requestProbeProvider != null) {
                                requestProbeProvider.dataSentEvent(size, _id);
                            }
                        }
                    });



 Comments   
Comment by srinik76 [ 16/Jan/17 ]

Fix generated as per the patch provided in the bug. The attributes are not getting counted when requests are not sent to web applications.

Review generated and sent to the group for review request.

Comment by srinik76 [ 13/Feb/17 ]

Sending appserver/web/admin/src/main/java/org/glassfish/web/admin/monitor/HttpServiceStatsProvider.java
Sending appserver/web/admin/src/main/java/org/glassfish/web/admin/monitor/RequestProbeProvider.java
Sending appserver/web/web-glue/src/main/java/com/sun/enterprise/web/VirtualServer.java
Transmitting file data ...
Committed revision 64533.
Devtest added
Sending devtests/admin/cli/src/admin/monitoring/Jira.java
Transmitting file data .
Committed revision 64534.





[GLASSFISH-21576] javamail debug log is not logged. Created: 01/Nov/16  Updated: 13/Feb/17  Resolved: 13/Feb/17

Status: Resolved
Project: glassfish
Component/s: mail
Affects Version/s: 3.1.2.2, 4.1, 4.1.1, 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: yama0428 Assignee: mskdeepak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

javamail debug log is not logged if I use javamail resource created by asadmin command.

ex)

asadmin create-javamail-resource --target server --mailuser=test@sample.com --fromaddress=test@sample.com --mailhost=127.0.0.1 --storeprotocol=imap --storeprotocolclass=com.sun.mail.imap.IMAPStore --transprotocol=smtp --transprotocolclass=com.sun.mail.smtp.SMTPTransport --description=description1 --property mail-password=password:mail-debug=true mail/MySession

Following logs are NOT logged to server.log

DEBUG: trying to connect to host "127.0.0.1", port 143, isSSL false
* OK IMAPrev1
A0 CAPABILITY
 CAPABILITY IMAP4 IMAP4rev1 CHILDREN IDLE QUOTA SORT
A0 OK CAPABILITY completed
|#]

This is the patch for this problem.
Two line are removed.

org.glassfish.resources.javamail.naming.MailNamingObjectFactory.java
        Properties props = config.getMailProperties();
        javax.mail.Session s = javax.mail.Session.getInstance(props, new MailSessionAuthenticator(props));
        if("smtps".equals(props.getProperty("mail.transport.protocol"))) {
            s.setProtocolForAddress("rfc822", "smtps");
        }
-       s.setDebugOut(new PrintStream(new MailLogOutputStream()));
-       s.setDebug(true);

        return s;


 Comments   
Comment by mskdeepak [ 25/Jan/17 ]

The logs you mentioned are logged under the "javax.mail" logger. Please set the log level of this logger to "FINE" or "FINER" depending on the amount of output you want to view the messages in server.log.

Comment by mskdeepak [ 13/Feb/17 ]

Fixed in r64532. Added JavaMail logger(javax.mail) into the list-loggers and list-log-levels command output.

Modified Paths:
---------------
trunk/main/appserver/logging/logging.properties
trunk/main/appserver/resources/javamail/javamail-connector/pom.xml
trunk/main/appserver/resources/javamail/javamail-connector/src/main/java/org/glassfish/resources/javamail/MailLogOutputStream.java

Comment by mskdeepak [ 13/Feb/17 ]

Fixed in r64532





[GLASSFISH-21465] TimerService createCalendarTimer with dayOfWeek Created: 15/Nov/15  Updated: 13/Feb/17

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rsoika Assignee: Kokil_Jain
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: timer

 Description   

Can you please reopen the following bug

https://java.net/jira/browse/GLASSFISH-20673

or at least give some feedback to the comunity.

===
Ralph



 Comments   
Comment by Kokil_Jain [ 13/Feb/17 ]

I am still unable to reproduce the bug(getting the expected output).
Current Date : Sun Feb 12 15:14:41 IST 2017
Here are the server log messages:

SCHEDULE : ScheduleExpression [second=0;minute=12;hour=15;dayOfMonth=*;month=*;dayOfWeek=1-5;year=*;timezoneID=null;start=null;end=null]

NEXT_TIMEOUT : Mon Feb 13 15:12:00 IST 2017

Can i know your system settings? Which OS are you on?
And also if you can provide the server logs of the latest run.





[GLASSFISH-21545] Websocket Container init error Created: 01/Jun/16  Updated: 13/Feb/17

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

Type: Bug Priority: Major
Reporter: Huangyun Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK 1.8 Glassfish 4.1.1 Spring 4.2.6



 Description   

Maven:
<properties>
<spring.version>4.2.6.RELEASE</spring.version>
</properties>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>$

{spring.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>${spring.version}

</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-websocket</artifactId>
<version>$

{spring.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-messaging</artifactId>
<version>${spring.version}

</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-tx</artifactId>
<version>$

{spring.version}

</version>
<scope>compile</scope>
</dependency>

<websocket:message-broker>
<websocket:stomp-endpoint path="/monitor">
<websocket:sockjs websocket-enabled="true"/>
</websocket:stomp-endpoint>
<websocket:simple-broker prefix="/topic, /queue"/>
</websocket:message-broker>

then, start glassfish 4.1.1, the console radom show:

Servlet.service() for servlet dispatcher threw exception
java.lang.IllegalArgumentException: No 'javax.websocket.server.ServerContainer' ServletContext attribute. Are you running in a Servlet container that supports JSR-356?



 Comments   
Comment by sumasri [ 02/Feb/17 ]

Please provide the detailed steps to reproduce the issue in Glassfish.





[GLASSFISH-21276] A number of monitor mbeans are broken Created: 20/Dec/14  Updated: 13/Feb/17  Resolved: 24/Mar/15

Status: Resolved
Project: glassfish
Component/s: amx
Affects Version/s: 4.1
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: smillidge-c2b2 Assignee: srinik76
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: javaee_ri_fix, payara

 Description   

The following MBeans have broken attributes for statistics gathering. A RuntimeException is thrown when the attributes are accessed.

servlet-instance-mon
bean-pool-mon
bean-method-mon
singleton-bean-mon
message-driven-bean-mon
security-realm-mon
equest-mon
ThreadPoolStatsImpl
transaction-service-mon
stateless-session-bean-mon



 Comments   
Comment by smillidge-c2b2 [ 20/Dec/14 ]

Forgot to say this is 4.1 GlassFish

Comment by smillidge-c2b2 [ 20/Dec/14 ]

This Payara commit fixes the issue https://github.com/payara/Payara/commit/17587c03b928018765c496332f6fb3164c53d8e7

Comment by Arindam Bandyopadhyay [ 09/Mar/15 ]

I was working to add the fix in glassfish. Please provide the test case for this issue.

Comment by smillidge-c2b2 [ 11/Mar/15 ]

Hi Arindam,

Just access their attributes through VisualVM MBean browser or JConsole you will see some attributes give an error.

Steve

Comment by Arindam Bandyopadhyay [ 24/Mar/15 ]

Fixed in trunk/main
Committed revision 63803.

Comment by tak09 [ 08/Feb/17 ]

This is a comment for #21276.

The Payara patch provided by smillidge-c2b2 was only partially applied to Glassfish, so this bug still exists for many MBeans. For example, stateless session beans now monitor statistics correctly, but the statistics for stateful session beans still do not work.

Please compare the latest version of Glassfish source code and "Payara commit fixes" of 21/Dec/14.
In some files, "getStatistic()" has been removed as suggested by smillidge-c2b2. While in other files, this issue has not been fixed at all.

The following files have already been fixed in Glassfish:
(getStatistic() has already been removed in revision 63803 on 24/Mar/2015.)

/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/monitoring/stats/EjbMethodStatsProvider.java

/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/monitoring/stats/EjbMonitoringStatsProvider.java

/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/monitoring/stats/EjbPoolStatsProvider.java

/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/monitoring/stats/StatelessSessionBeanStatsProvider.java

/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/mdb/monitoring/stats/MessageDrivenBeanStatsProvider.java

/appserver/orb/orb-connector/src/main/java/org/glassfish/enterprise/iiop/util/ThreadPoolStatsImpl.java

/appserver/transaction/jta/src/main/java/com/sun/enterprise/transaction/monitoring/TransactionServiceStatsProvider.java

/appserver/web/admin/src/main/java/org/glassfish/web/admin/monitor/HttpServiceStatsProvider.java

/appserver/web/admin/src/main/java/org/glassfish/web/admin/monitor/ServletInstanceStatsProvider.java

/nucleus/security/core/src/main/java/com/sun/enterprise/security/auth/realm/RealmStatsProvider.java

The following files have not been modified in Glassfish:
(Please remove getStatistic() from the following files.)

/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/monitor/ConnectorConnPoolAppStatsProvider.java 

/appserver/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/pool/monitor/ConnectorConnPoolStatsProvider.java

/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/monitoring/stats/EjbCacheStatsProvider.java 

/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/monitoring/stats/EjbTimedObjectStatsProvider.java

/appserver/ejb/ejb-container/src/main/java/com/sun/ejb/monitoring/stats/StatefulSessionBeanStatsProvider.java

/appserver/ejb/ejb-container/src/main/java/org/glassfish/ejb/security/application/EjbSecurityStatsProvider.java

/appserver/persistence/entitybean-container/src/main/java/org/glassfish/persistence/ejb/entitybean/container/stats/EntityBeanStatsProvider.java

/nucleus/deployment/common/src/main/java/org/glassfish/deployment/monitor/DeploymentLifecycleStatsProvider.java

/nucleus/security/core/src/main/java/com/sun/enterprise/security/WebSecurityDeployerStatsProvider.java

Please kindly re-open this case and fix the bug.

There is another bug ticket which is similar to this ticket.
https://java.net/jira/browse/GLASSFISH-21272
Please fix bug #21272 together with this bug.





[GLASSFISH-21647] maxqueued is always zero Created: 21/Dec/16  Updated: 13/Feb/17  Resolved: 13/Feb/17

Status: Resolved
Project: glassfish
Component/s: monitoring, web_container
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: yama0428 Assignee: pranjal.sahay
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

maxqueued is always zero.

http://localhost:4848/monitoring/domain1/server/network/http-listener-1/connection-queue

maxqueued

    count : 0
    lastsampletime : -1
    description : Maximum size of the connection queue
    unit : count
    name : MaxQueued
    starttime : 1482281096124

peakqueued

    count : 1
    lastsampletime : 1482282338225
    description : Largest number of connections that were in the queue simultaneously
    unit : count
    name : PeakQueued
    starttime : 1482281096124

maxqueued is the maximum size of the connection queue.
So it is invalid because default queue size is 4096.

This is the patch for this problem.

ThreadPoolMonitor.java
    public ThreadPoolMonitor(GrizzlyMonitoring grizzlyMonitoring,
            String monitoringId, ThreadPoolConfig config) {
        this.grizzlyMonitoring = grizzlyMonitoring;
        this.monitoringId = monitoringId;

        if (grizzlyMonitoring != null) {
            final ThreadPoolStatsProvider threadPoolStatsProvider =
                    grizzlyMonitoring.getThreadPoolStatsProvider(monitoringId);
            if (threadPoolStatsProvider != null) {
                threadPoolStatsProvider.setStatsObject(config);
                threadPoolStatsProvider.reset();
            }

            final ConnectionQueueStatsProvider connectionQueueStatsProvider =
                    grizzlyMonitoring.getConnectionQueueStatsProvider(monitoringId);
            if (connectionQueueStatsProvider != null) {
                connectionQueueStatsProvider.setStatsObject(config);
                connectionQueueStatsProvider.reset();
                connectionQueueStatsProvider.setMaxTaskQueueSizeEvent(monitoringId, config.getQueueLimit());
            }
        }
    }


 Comments   
Comment by pranjal.sahay [ 13/Feb/17 ]

The fix for https://java.net/jira/browse/GLASSFISH-21648 : 64531 also fixes this bug.





[GLASSFISH-21648] corethreads and maxthreads are always zero Created: 21/Dec/16  Updated: 13/Feb/17  Resolved: 13/Feb/17

Status: Resolved
Project: glassfish
Component/s: monitoring, web_container
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: yama0428 Assignee: srinik76
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

corethreads and maxthreads are always zero.
http://localhost:4848/monitoring/domain1/server/network/thread-pool

corethreads

    count : 0
    lastsampletime : -1
    description : Core number of threads in the thread pool
    unit : count
    name : CoreThreads
    starttime : 1482283022005
maxthreads

    count : 0
    lastsampletime : -1
    description : Maximum number of threads allowed in the thread pool
    unit : count
    name : MaxThreads
    starttime : 1482283022005

This is the patch for this problem.
It isn't needed to register ThreadPoolStatsProvider twice.

GlassFishNetworkListener.java
     @Override
     public void start() throws IOException {
         super.start();
     }


 Comments   
Comment by srinik76 [ 18/Jan/17 ]

Fixed the issue and and fix sent to review.

Comment by srinik76 [ 13/Feb/17 ]

Commited the fix.

Sending GlassfishNetworkListener.java
Transmitting file data .
Committed revision 64531.

Comment by srinik76 [ 13/Feb/17 ]

Checked in the fix





[GLASSFISH-21532] com.sun.jts.CosTransactions.GlobalTID breaks the equals/hashCode contract Created: 09/Apr/16  Updated: 13/Feb/17

Status: In Progress
Project: glassfish
Component/s: jts
Affects Version/s: 4.1
Fix Version/s: None

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


 Description   

Whilst testing JTS transaction propagation between glassfish and other application servers I hit a recovery problem (which I reported via https://java.net/projects/glassfish/lists/dev/archive/2016-04/message/0) caused by implementation of the GlobalTID.hashCode() method. It is possible to create to GlobalTID instances with are the same according to the equals method but have different hash codes. A simple test showing the problem is:

GlobalTID Test
import org.omg.CosTransactions.otid_t;
import com.sun.jts.CosTransactions.GlobalTID;

public class X {
    public static void main(String[] args) {
        test();
    }

    public static void test() {
        otid_t otid1 = toOtid("xyz".getBytes(), "a".getBytes());
        otid_t otid2 = toOtid("xyz".getBytes(), "".getBytes());

        GlobalTID tid1 = new GlobalTID(otid1);
        GlobalTID tid2 = new GlobalTID(otid2);

        if (!tid1.equals(tid2))
            throw new AssertionError("GlobalTIDs should be equal");

        // equal objects must have the same hashCode
        if (tid1.hashCode() != tid2.hashCode())
            throw new AssertionError("equal GlobalTID objects should have the same hash code");
    }

    private static otid_t toOtid(byte[] gtid, byte[] bqual) {
        otid_t otid = new otid_t();

        otid.formatID = 0;
        otid.tid = new byte[gtid.length + bqual.length];
        otid.bqual_length = bqual.length;

        /*
         * gtrid must be first then immediately followed by bqual.
         * bqual must be between 1 and 64 bytes if for XA.
         */

        System.arraycopy(gtid, 0, otid.tid, 0, gtid.length);
        System.arraycopy(bqual, 0, otid.tid, gtid.length, bqual.length);

        return otid;
    }
}

To compile and run the example put the following three jars on the classpath:

export CLASSPATH=.:glassfish-corba-omgapi.jar:jts.jar:common-util.jar



 Comments   
Comment by lprimak [ 28/Dec/16 ]

Fixed in Payara by https://github.com/payara/Payara/pull/1256





[GLASSFISH-21572] AS-WEB-GLUE-00078 is logged to the server.log although both tls11-enabled and tls12-enabled are true. Created: 25/Oct/16  Updated: 13/Feb/17

Status: In Progress
Project: glassfish
Component/s: security, web_container
Affects Version/s: 4.1, 4.1.1, 5.0
Fix Version/s: None

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


 Description   

When tls-enabled is set to false,
AS-WEB-GLUE-00078 is logged to the server.log although both tls11-enabled and tls12-enabled are still true.

Reproducible steps are as follows.

C:\glassfish411\glassfish\bin>asadmin set cluster.network-config.protocols.protocol.http-listener-2.ssl.tls-enabled=false
Warning: Instance instance seems to be offline; command set was not replicated to that instance
cluster.network-config.protocols.protocol.http-listener-2.ssl.tls-enabled=false
Command set executed successfully.

C:\glassfish411\glassfish\bin>asadmin start-cluster cluster
Command start-cluster executed successfully.

This is the message.

[2016-10-25T10:25:52.263+0900] [glassfish 4.1] [WARNING] [AS-WEB-GLUE-00078] [javax.enterprise.web] [tid: _ThreadID=18 _ThreadName=RunLevelControllerThread-1477358749362] [timeMillis: 1477358752263] [levelValue: 900] [[
  All SSL protocol variants disabled for network-listener http-listener-2, using SSL implementation specific defaults]]

This is the patch for this problem.

PECoyoteConnector#configureSSL
        if (Boolean.valueOf(sslConfig.getTlsEnabled())) {
            if (needComma) {
                sslProtocolsBuf.append(", ");
            } else {
                needComma = true;
            }
            sslProtocolsBuf.append("TLSv1");
        }
        if (Boolean.valueOf(sslConfig.getTls11Enabled())) {
            if (needComma) {
                sslProtocolsBuf.append(", ");
            } else {
                needComma = true;
            }
            sslProtocolsBuf.append("TLSv1.1");
        }
        if (Boolean.valueOf(sslConfig.getTls12Enabled())) {
            if (needComma) {
                sslProtocolsBuf.append(", ");
            }
            sslProtocolsBuf.append("TLSv1.2");
        }
        if (Boolean.valueOf(sslConfig.getSsl3Enabled()) ||
                Boolean.valueOf(sslConfig.getTlsEnabled())) {
            sslProtocolsBuf.append(", SSLv2Hello");
        }





[GLASSFISH-21663] Integrate latest Servlet 4.0 API into GlassFish trunk Created: 24/Jan/17  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 5.0

Type: Task Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 2 Sprint 2

 Description   

The first step in re-activating work on Servlet 4.0 RI is to integrate the latest API into GlassFish trunk.



 Comments   
Comment by Shing Wai Chan [ 26/Jan/17 ]

After fixing on all servlet jar dependencies, servlet api jar version 4.0.0-b01 has been integrated to GlassFish.





[GLASSFISH-21473] Http access log is not written after changing network-config properties. Created: 05/Dec/15  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 4.1
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: yama0428 Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If I send an invalid http request(no Host header),

GET / HTTP/1.1

Http acccess log is logged.

"127.0.0.1" "NULL-AUTH-USER" "05/Dec/2015:16:45:19 +0900" "GET / HTTP/1.1" 400 0 

However, http access log is not written after setting network-config properties.

asadmin set server.network-config.protocols.protocol.http-listener-1.http.timeout-seconds=60

The cause is com.sun.enterprise.web.VirtualServer.
GenericGrizzlyListener is recreated by changing network-config properties.

However,
addProbes method is not called when network-config property is changed.



 Comments   
Comment by Shing Wai Chan [ 10/Jan/17 ]

This issue has been fixed when we fix GLASSFISH-21642 access-logging-bad-requests web devtests fails in Hudson.





[GLASSFISH-21637] network-listener-target web devtest fails in nightly Hudson Created: 09/Dec/16  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Nightly build:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-lw-web-devtests/406/artifact/appserv-tests/test_results.html

run:
[java] Running test
[java]
[java] Invoking url: http://localhost.localdomain:45713/web-networkListenerTarget/ServletTest
[java] Response code: 404 Expected code: 200
[java] Generating report at /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - networkListenerTarget: FAIL -
[java] -----------------------------------------
[java] - Total PASS : 0 -
[java] - Total FAIL : 1 -
[java] - Total DID NOT RUN : 0 -
[java] -----------------------------------------



 Comments   
Comment by Shing Wai Chan [ 05/Jan/17 ]

After fixing the nightly hudson setup for GLASSFISH-21631, this issue has been resolved, too.





[GLASSFISH-21631] sso-failover web devtest failed in nightly Hudson run Created: 08/Dec/16  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

[java] HTTP/1.1 401 Unauthorized
[java] Server: GlassFish Server Open Source Edition 5.0
[java] X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 5.0 Java/Oracle Corporation/1.8)
[java] WWW-Authenticate: Basic realm=""
[java] Content-Language:
[java] Content-Type: text/html
[java] Date: Tue, 06 Dec 2016 12:42:45 GMT
[java] Connection: close
[java] Content-Length: 1090
[java]
[java] <Unable to render embedded object: File (//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>GlassFish Server Open Source Edition 5.0 - Error report</title><style type="text/css"><) not found.--H1

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}

H2

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}

H3

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}

BODY

{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;}

B

{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}

P

{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}

A

{color : black;}

HR

{color : #525D76;}

--></style> </head><body><h1>HTTP Status 401 - Unauthorized</h1><hr/><p><b>type</b> Status report</p><p><b>message</b>Unauthorized</p><p><b>description</b>This request requires HTTP authentication.</p><hr/><h3>GlassFish Server Open Source Edition 5.0 </h3></body></html>
[java] java.lang.Exception: Missing Set-Cookie response header
[java] at WebTest.run(Unknown Source)
[java] at WebTest.main(Unknown Source)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
[java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
[java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
[java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
[java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
[java] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[java] at org.apache.tools.ant.Task.perform(Task.java:348)
[java] at org.apache.tools.ant.Target.execute(Target.java:390)
[java] at org.apache.tools.ant.Target.performTasks(Target.java:411)
[java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
[java] at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
[java] at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
[java] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
[java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
[java] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[java] at java.lang.reflect.Method.invoke(Method.java:498)
[java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[java] at org.apache.tools.ant.Task.perform(Task.java:348)
[java] at org.apache.tools.ant.Target.execute(Target.java:390)
[java] at org.apache.tools.ant.Target.performTasks(Target.java:411)
[java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
[java] at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
[java] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[java] at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
[java] at org.apache.tools.ant.Main.runBuild(Main.java:809)
[java] at org.apache.tools.ant.Main.startAnt(Main.java:217)
[java] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
[java] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
[java] Generating report at /scratch/BUILD_AREA/workspace/gf-lw-web-devtests/appserv-tests/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - ha-sso-failover: FAIL -
[java] -----------------------------------------
[java] - Total PASS : 0 -
[java] - Total FAIL : 1 -
[java] - Total DID NOT RUN : 0 -
[java] -----------------------------------------

Nightly build:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-lw-web-devtests/406/artifact/appserv-tests/test_results.html



 Comments   
Comment by Shing Wai Chan [ 09/Dec/16 ]

The test passes in my local machine.
When the test passes, it got a 302 rather than 401 above.

Comment by Shing Wai Chan [ 22/Dec/16 ]

An issue is identified in Hudson setup that related to the error message above.

Comment by Shing Wai Chan [ 22/Dec/16 ]

The issue is resolved after the Hudson setup change.

Comment by Shing Wai Chan [ 04/Jan/17 ]

This is a Hudson setup issue. The setup in Hudson has been fixed.





[GLASSFISH-21632] non-blocking-output web devtest fails in continuous Hudson run Created: 08/Dec/16  Updated: 09/Feb/17  Resolved: 09/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 5.0
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Continuous build:
http://gf-hudson.us.oracle.com/hudson/view/GlassFish/view/Trunk%20Continuous/job/gf-trunk-web-devtests-continuous/lastSuccessfulBuild/artifact/appserv-tests/test_results.html



 Comments   
Comment by Shing Wai Chan [ 08/Dec/16 ]

run:
[java]
[java] 0: 6467472
[java] aaaaaaaaaaaaaaaaaaaa...aaaaaaaaaaaaaaaaaaaa
[java]
[java] Sleeping 5 sec
[java] Generating report at /scratch/BUILD_AREA/workspace/gf-trunk-web-devtests-continuous/appserv-tests/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - non-blocking-output: FAIL -
[java] -----------------------------------------
[java] - Total PASS : 0 -
[java] - Total FAIL : 1 -
[java] - Total DID NOT RUN : 0 -
[java] -----------------------------------------

Comment by Shing Wai Chan [ 15/Dec/16 ]

------------------------------------------------------------------------
r64359 | swchan2 | 2016-12-13 10:30:56 -0800 (Tue, 13 Dec 2016) | 2 lines

set a smaller socket output buffer and use raw socket

------------------------------------------------------------------------
r64354 | swchan2 | 2016-12-12 12:46:28 -0800 (Mon, 12 Dec 2016) | 2 lines

change socket write bufffer

------------------------------------------------------------------------





[GLASSFISH-21668] Implement get/set SessionTimeout in ServletContext Created: 31/Jan/17  Updated: 09/Feb/17  Resolved: 09/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 3 Sprint 1

 Description   

The specification is summarized in issue SERVLET_SPEC-70.



 Comments   
Comment by Shing Wai Chan [ 09/Feb/17 ]

r64510 | swchan2 | 2017-02-06 15:48:49 -0800 (Mon, 06 Feb 2017) | 2 lines

GLASSFISH-21668 Implement get/set SessionTimeout in ServletContext





[GLASSFISH-20917] a wrong implementation for web-fragment.xml with <distributable/> issue Created: 06/Dec/13  Updated: 09/Feb/17  Resolved: 09/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: 5.0

Type: Bug Priority: Major
Reporter: jumperchen Assignee: Shing Wai Chan
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

fail with both Glassfish 3 and 4 version


Tags: servlet_4_0
Sprint: MS 3 Sprint 1

 Description   

If a web application contains with a jar (for example Spring 3.2.2 version) that enables the attribute <distributable/> in the web-fragment.xml, this setting will cause glassfish server run in cluster environment.

You may refer to this fixed in Spring's tracker - https://jira.springsource.org/browse/SPR-10219

To reproduce this issue is to save a non-serializable object to session attribute, for example

<%
   session.setAttribute( "test", new java.io.ByteArrayOutputStream(20) );
%>

Note that the web.xml doesn't specify the <distributable/>.



 Comments   
Comment by Shing Wai Chan [ 09/Jun/14 ]

The implementation matches the spec.
The spec seems to have an issue here.
I have filed a spec issue as follows:
https://java.net/jira/browse/SERVLET_SPEC-89

Comment by Shing Wai Chan [ 31/Jan/17 ]

Per discussion in EG, an app is distributable if web.xml and web-fragment.xml with <distributable/> element. We will update the implementation in GlassFish.

Comment by Shing Wai Chan [ 06/Feb/17 ]

Revisions:
----------
64467

Modified Paths:
---------------
trunk/main/appserver/deployment/dol/src/main/java/com/sun/enterprise/deployment/WebBundleDescriptor.java
trunk/main/appserver/web/web-glue/src/main/java/org/glassfish/web/deployment/util/WebBundleValidator.java
trunk/main/appserver/web/web-glue/src/main/java/org/glassfish/web/deployment/descriptor/WebBundleDescriptorImpl.java





[GLASSFISH-21564] Unable to create http-listeners Created: 22/Sep/16  Updated: 09/Feb/17

Status: In Progress
Project: glassfish
Component/s: None
Affects Version/s: 4.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dNhax Assignee: rutujay
Resolution: Unresolved Votes: 0
Labels: waiting_on_filer
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 10 x64
NetBeans 8.1
GlassFish Server 4.1.1



 Description   

It seems that the server is not able to create the http-listeners in time (marked with !!!)

Launching GlassFish on Felix platform
Sep 21, 2016 3:56:05 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner createBundleProvisioner
INFORMATION: Create bundle provisioner class = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner.
Sep 21, 2016 3:56:05 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner$DefaultCustomizer getLocations
WARNUNG: Skipping entry because it is not an absolute URI.
Sep 21, 2016 3:56:05 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner$DefaultCustomizer getLocations
WARNUNG: Skipping entry because it is not an absolute URI.
Sep 21, 2016 3:56:06 PM com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner startBundles
WARNUNG: Can not start bundle file:/C:/Program%20Files/glassfish-4.1.1/glassfish/modules/core.jar because it is not contained in the list of installed bundles.
Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime@3f6b4900 in service registry.
#!## LogManagerService.postConstruct : rootFolder=C:\Program Files\glassfish-4.1.1\glassfish
#!## LogManagerService.postConstruct : templateDir=C:\Program Files\glassfish-4.1.1\glassfish\lib\templates
#!## LogManagerService.postConstruct : src=C:\Program Files\glassfish-4.1.1\glassfish\lib\templates\logging.properties
#!## LogManagerService.postConstruct : dest=C:\Users\Tobias\AppData\Roaming\NetBeans\8.1\config\GF_4.1.1\domain1\config\logging.properties
Information: Running GlassFish Version: GlassFish Server Open Source Edition 4.1.1 (build 1)
Information: Server log file is using Formatter class: com.sun.enterprise.server.logging.ODLLogFormatter
Information: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
Information: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
Information: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
Information: Network listener http-listener-1 on port 8080 disabled per domain.xml
Information: Authorization Service has successfully initialized.
Information: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
Information: JTS5014: Recoverable JTS instance, serverId = [100]
Schwerwiegend: Application previously deployed is not at its original location any more: file:/E:/Work/Projects/Java/XWars/XWars-ear/target/gfdeploy/XWars-ear/
! ! ! Warnung: Instance could not be initialized. Class=interface org.glassfish.grizzly.http.server.AddOn, name=http-listener-2, realClassName=org.glassfish.grizzly.http2.Http2AddOn
Information: Grizzly Framework 2.3.23 started in: 20ms - bound to [/0.0.0.0:8181]
Warnung: Instance could not be initialized. Class=interface org.glassfish.grizzly.http.server.AddOn, name=admin-listener, realClassName=org.glassfish.grizzly.http2.Http2AddOn
Information: Grizzly Framework 2.3.23 started in: 1ms - bound to [/0.0.0.0:4848]
Information: Grizzly Framework 2.3.23 started in: 1ms - bound to [/0.0.0.0:3700]
Information: GlassFish Server Open Source Edition 4.1.1 (1) startup time : Felix (10.819ms), startup services(1.002ms), total(11.821ms)
Information: Grizzly Framework 2.3.23 started in: 1ms - bound to [/0.0.0.0:7676]
Information: Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishImpl@32b9bd12 as OSGi service registration: org.apache.felix.framework.ServiceRegistrationImpl@576c5536.
Information: JMXStartupService has started JMXConnector on JMXService URL service:jmx:rmi://Tobias-PC.fritz.box:8686/jndi/rmi://Tobias-PC.fritz.box:8686/jmxrmi
Information: HV000001: Hibernate Validator 5.1.2.Final
! ! ! Warnung: Instance could not be initialized. Class=interface org.glassfish.grizzly.http.server.AddOn, name=http-listener-2, realClassName=org.glassfish.grizzly.http2.Http2AddOn
Information: Grizzly Framework 2.3.23 started in: 15ms - bound to [/0.0.0.0:8181]
Warnung: Originally deployed application at E:\Work\Projects\Java\XWars\XWars-ear\target\gfdeploy\XWars-ear not found
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: visiting unvisited references
Information: Java security manager is disabled.
Information: Entering Security Startup Service.
Information: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
Information: Security Service(s) started successfully.
Information: de.dnhax.xwars.persistence.entities.Player actually got transformed
Information: EclipseLink, version: Eclipse Persistence Services - 2.6.3.v20160428-59c81c5
Information: /file:/E:/Work/Projects/Java/XWars/XWars-ear/target/gfdeploy/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT_jar/_XWarsPU login successful
! ! ! Information: Created HTTP listener http-listener-2 on host/port 0.0.0.0:8181
Information: Created HTTP listener admin-listener on host/port 0.0.0.0:4848
Information: Created virtual server server
Information: Created virtual server __asadmin
Information: Setting JAAS app name glassfish-web
Information: Virtual server server loaded default web module
Information: JTS5014: Recoverable JTS instance, serverId = [3700]
Information: Portable JNDI names for EJB XWarsLogicImpl: [java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/XWarsLogicImpl!de.dnhax.xwars.logic.XWarsLogic, java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/XWarsLogicImpl]
Information: Glassfish-specific (Non-portable) JNDI names for EJB XWarsLogicImpl: de.dnhax.xwars.logic.XWarsLogic#de.dnhax.xwars.logic.XWarsLogic, de.dnhax.xwars.logic.XWarsLogic
Information: Portable JNDI names for EJB PlayerAccess: [java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/PlayerAccess, java:global/XWars-ear/XWars-ejb-1.0.0-SNAPSHOT/PlayerAccess!de.dnhax.xwars.persistence.PlayerAccess]
Information: WELD-000900: 2.2.13 (Final)
WARN: WELD-001700: Interceptor annotation class javax.ejb.PostActivate not found, interception based on it is not enabled
WARN: WELD-001700: Interceptor annotation class javax.ejb.PrePassivate not found, interception based on it is not enabled
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] public org.glassfish.jms.injection.JMSCDIExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] org.glassfish.sse.impl.ServerSentEventCdiExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] org.glassfish.sse.impl.ServerSentEventCdiExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>, BeanManager) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] public org.glassfish.jms.injection.JMSCDIExtension.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
WARN: WELD-000411: Observer method [BackedAnnotatedMethod] private org.glassfish.jersey.ext.cdi1x.internal.CdiComponentProvider.processAnnotatedType(@Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using @WithAnnotations or a generic type with bounds.
Information: Mojarra 2.2.12 ( 20150720-0848 https://svn.java.net/svn/mojarra~svn/tags/2.2.12@14885) für Kontext '/xwars' wird initialisiert.
Information: RewritePhaseListener starting up.
Information: Monitoring jndi:/server/xwars/WEB-INF/faces-config.xml for modifications
Information: Running on PrimeFaces 6.0
Information: RewriteFilter starting up...
Information: Loaded [4] org.ocpsoft.rewrite.servlet.spi.RewriteLifecycleListener [org.ocpsoft.rewrite.prettyfaces.PrettyFacesRewriteLifecycleListener<-100>, org.ocpsoft.rewrite.faces.FacesRewriteLifecycleListener<0>, org.ocpsoft.rewrite.servlet.impl.DefaultRewriteLifecycleListener<2147483647>, org.ocpsoft.rewrite.servlet.config.lifecycle.JoinRewriteLifecycleListener<2147483647>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.RequestCycleWrapper [org.ocpsoft.rewrite.servlet.impl.HttpRewriteRequestCycleWrapper<0>]
Information: Loaded [1] org.ocpsoft.rewrite.spi.RewriteProvider [org.ocpsoft.rewrite.servlet.impl.DefaultHttpRewriteProvider<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.RewriteResultHandler [org.ocpsoft.rewrite.servlet.impl.HttpRewriteResultHandler<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.InboundRewriteProducer [org.ocpsoft.rewrite.servlet.impl.HttpInboundRewriteProducer<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.OutboundRewriteProducer [org.ocpsoft.rewrite.servlet.impl.HttpOutboundRewriteProducer<0>]
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.ContextListener [org.ocpsoft.rewrite.prettyfaces.PrettyConfigContextListener<0>]
Information: Loaded [0] org.ocpsoft.rewrite.servlet.spi.RequestListener []
Information: Loaded [1] org.ocpsoft.rewrite.servlet.spi.RequestParameterProvider [org.ocpsoft.rewrite.prettyfaces.PrettyFacesRequestParameterProvider<0>]
Information: Loaded [1] org.ocpsoft.rewrite.el.spi.ExpressionLanguageProvider [org.ocpsoft.rewrite.faces.FacesExpressionLanguageProvider<30>]
Information: Loaded [1] org.ocpsoft.rewrite.spi.InvocationResultHandler [org.ocpsoft.rewrite.faces.NavigatingInvocationResultHandler<100>]
Information: Loaded [0] org.ocpsoft.common.spi.ServiceEnricher []
Information: Loaded [1] org.ocpsoft.rewrite.spi.ConfigurationCacheProvider [org.ocpsoft.rewrite.servlet.impl.ServletContextConfigurationCacheProvider<0>]
Information: Loaded [2] org.ocpsoft.rewrite.config.ConfigurationProvider [org.ocpsoft.rewrite.annotation.config.AnnotationConfigProvider<100>, org.ocpsoft.rewrite.prettyfaces.PrettyFacesRewriteConfigurationProvider<1>]
Information: Loaded [0] org.ocpsoft.rewrite.spi.RuleCacheProvider []
Information: Loaded [1] org.ocpsoft.rewrite.spi.GlobalParameterProvider [org.ocpsoft.rewrite.instance.WildcardParameterProvider<0>]
Information: Rewrite 3.4.1.Final initialized.
Information: Loading application XWars-ear#XWars-web-1.0.0-SNAPSHOT.war at [/xwars]
Information: XWars-ear was successfully deployed in 10.439 milliseconds.



 Comments   
Comment by rutujay [ 30/Jan/17 ]

Does the server start successfully?

Comment by dNhax [ 30/Jan/17 ]

Yes, and the server is reachable through https.

The issue I originally had seems to be a NetBeans issue: https://netbeans.org/bugzilla/show_bug.cgi?id=268195

Comment by rutujay [ 03/Feb/17 ]

Did you try with any other IDE?

Comment by rutujay [ 08/Feb/17 ]

I deployed a secure web application on Glassfish 4.1.1 using Netbeans IDE 8.1, after deploying the application firefox opens the correct URL i.e. https://localhost:8181/SampleWebApp/ on both Ubuntu 16.04 and Windows 10. For using https with Glasssfish you need to configure ssl in your applications web.xml, https://docs.oracle.com/cd/E19159-01/820-1072/6ncp48v4d/index.html
If you still face the same problem please provide a sample application with which you are facing this problem.

Comment by dNhax [ 08/Feb/17 ]

I did not try with another IDE.

My web.xml contains the relevant security constraint.

As I said: this seems to be a NetBeans issue as also stated here: https://github.com/payara/Payara/issues/1108

Comment by rutujay [ 09/Feb/17 ]

Thanks for the reference.

I deployed the application you gave here, https://github.com/payara/Payara/issues/1108 , do you face the same problem when you run the XWars-web alone?

Why do you feel it is a Netbeans issue?





launch link in web app ignore virtual server (GLASSFISH-2918)

[GLASSFISH-19495] Parent issue is not resolved in GF-3.1.2.2 Created: 06/Jan/13  Updated: 08/Feb/17

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1.2.2
Fix Version/s: 9.1pe

Type: Sub-task Priority: Major
Reporter: mahairod Assignee: sumasri
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF developer profile


Issue Links:
Cloners
is cloned by GLASSFISH-21413 CLONE - Parent issue is not resolved ... Open
Tags: admin-gui, regression, virtual_server

 Description   

Parent issue is not resolved in GF-3.1.2.2. While using multiple virtual servers and deploying just tto particular ones it's not availbale to launch application normally through admin gui






[GLASSFISH-21665] Import Servlet 4.0 Schemas into GlassFish trunk Created: 24/Jan/17  Updated: 08/Feb/17  Resolved: 08/Feb/17

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Ed Burns Assignee: james.shapiro
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet_4_0
Sprint: MS 3 Sprint 1

 Description   

The Java EE 8 schemas are being actively developed at <https://svn.java.net/svn/glassfish~svn/trunk>. This issue requests the schemas relevant to Servlet 4.0 to be included in the GlassFish tree and build.



 Comments   
Comment by james.shapiro [ 08/Feb/17 ]

Copyrights were updated as well.





[GLASSFISH-21410] Invalidating Session using POST via JAX-RS creates IOException Created: 09/Aug/15  Updated: 08/Feb/17

Status: Open
Project: glassfish
Component/s: grizzly-kernel, jax-rs, web_container
Affects Version/s: 4.1
Fix Version/s: None

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


 Description   

Given the following sample code

@Path("session")
@Stateless
public class Resource2 {

@GET
@Path("create")
public Response create(@Context HttpServletRequest req)

{ req.getSession().setAttribute("foo", "bar"); return Response.ok(req.getSession().getAttribute("foo")).build(); }

@POST
@Path("invalidate")
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Response invalidate(@Context HttpServletRequest req,
@FormParam("foo") String foo)

{ HttpSession session = req.getSession(false); Object foox = session.getAttribute(foo); session.invalidate(); return Response.temporaryRedirect(URI.create("http://slashdot.org/")).build(); }

}

I get the following stack trace

java.io.IOException
at org.glassfish.grizzly.http.io.InputBuffer.skip(InputBuffer.java:721)
at org.glassfish.grizzly.http.server.Request.skipPostBody(Request.java:2078)
at org.glassfish.grizzly.http.server.Request.parseRequestParameters(Request.java:2032)
at org.glassfish.grizzly.http.server.Request.getParameter(Request.java:1066)
at org.apache.catalina.connector.Request.getParameter(Request.java:1552)
at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:448)
at org.jboss.weld.servlet.ConversationContextActivator.determineConversationId(ConversationContextActivator.java:182)
at org.jboss.weld.context.http.LazyHttpConversationContextImpl.checkContextInitialized(LazyHttpConversationContextImpl.java:93)
at org.jboss.weld.context.http.LazyHttpConversationContextImpl.destroy(LazyHttpConversationContextImpl.java:85)
at org.jboss.weld.context.http.HttpSessionContextImpl.destroy(HttpSessionContextImpl.java:59)
at org.jboss.weld.servlet.HttpContextLifecycle.sessionDestroyed(HttpContextLifecycle.java:152)
at org.jboss.weld.servlet.WeldInitialListener.sessionDestroyed(WeldInitialListener.java:133)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:910)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:854)
at org.apache.catalina.session.StandardSession.expire(StandardSession.java:842)
at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1603)
at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:204)
at net.trajano.test.Resource2.invalidate(Resource2.java:44)

The invalidation seems to be asynchronous since the redirect still works. And it seems that the POST content stream was already closed by the time it reaches InputBuffer.skip.

Perhaps it shouldn't throw an IOException and instead if it is closed just silently not read any more data?






[GLASSFISH-21415] GF4.1 :: glassfish embedded jar's eclipseLink(2.5.2) has duplicate schema issue Created: 19/Aug/15  Updated: 08/Feb/17  Resolved: 08/Feb/17

Status: Closed
Project: glassfish
Component/s: embedded
Affects Version/s: 4.1
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: vikramalvaj Assignee: Bhavanishankar
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by vikramalvaj [ 19/Aug/15 ]

eclipseLink 2.5.2 that comes with GF4.1 has duplicate schema issue as reported below

https://www.eclipse.org/forums/index.php/t/798163/

As discussed in the above link, the issue is resolved with eclipseLink 2.6.0

However the glassfish-embedded-4.1 jar (which has eclipseLink 2.5.2) used for testing projects has the same issue.

Need an updated glassfish embedded jar 4.1 with the eclipselink issue resolved

Comment by vikramalvaj [ 19/Aug/15 ]

Fix is as simple as replacing org.eclipse.persistence.sequencing.TableSequence class in eclipse 2.5.2 with one available in 2.6.0

However the same should be available as a maven repo

Comment by Yamini K B [ 08/Feb/17 ]

Eclipse link was updated in one of the later 4.1 builds.





[GLASSFISH-21416] CA certs trust store out of date Created: 20/Aug/15  Updated: 08/Feb/17

Status: Open
Project: glassfish
Component/s: configuration, security
Affects Version/s: 4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cplummer Assignee: Yamini K B
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Mac OS X 10.10.5
JDK 7



 Description   

The glassfish4/glassfish/domains/domain1/config/cacerts.jks file is out of date. The trust store has 76 entries in it, while the current JDK 8 release (8u60) cacerts trust store has 93 entries and JDK 7u79 has 92 entries.

Specifically, the store is missing entrustrootcag2 which I need for an integration with an external vendor. If I connect via SSL with the JDK in a standalone client, it works - using glassfish 4.1, it fails in the handshake since it doesn't trust the signing authority.

It's not really clear to me why glassfish maintains a separate cacerts.jks trust store from the JDK; my workaround for this issue will be to point at the JDK's cacerts file instead.



 Comments   
Comment by grimmeld [ 12/Oct/15 ]

There is a clear need for a cacerts.jks file that is seperate from the JDK, as you would want to manage this on a per-domain basis. This means that with one glassfish server environment and 2 domains, you have 2 different cacerts.jks files. If you have to compromise one domain with adding a self-signed certificate to the truststore, then the other domain is still safe.

But I'm equally curious why the default shipped cacerts.jks isn't being kept up-to-date.

Comment by Masoud Kalali [ 07/Dec/15 ]

Considering that I am no longer active in GlassFish space I am assigning all the tickets to Chris Kasso in Java EE/ Application Servers team and he can reassign them as appropriate.

Comment by slominskir [ 10/Nov/16 ]

I wanted to simply remove the -Djavax.net.ssl.trustStore= JVM option from GlassFish so the default system one would be used. This turned out to not work as then GlassFish won't start as it says the master password is bad. It seems GlassFish requires its own cacerts file or otherwise it complains that the master password is bad (I guess the master password is used to open the cacerts file).

Created a new issue to track: GLASSFISH-21586

Comment by slominskir [ 26/Jan/17 ]

I believe the majority of users do NOT want to have multiple cacerts files and would rather simply use the JDK default trust store. That should be the default path. It turns out that path is actually made harder as simply deleting the custom cacerts and removing the JRE argument doesn't work. You can however, create a link and that seems to work.





[GLASSFISH-21417] Weld Exception is thrown during RENDER phase of JSF lifecycle in Glassfish 4.1. Created: 21/Aug/15  Updated: 08/Feb/17

Status: Open
Project: glassfish
Component/s: cdi, jsf
Affects Version/s: 4.1
Fix Version/s: None

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

Ubuntu Linux 15.04/14.04
Java 8



 Description   

Weld Exception is thrown during RENDER phase of JSF lifecycle in Glassfish 4.1.

It used to be thrown during EXECUTE phase in Glassfish 3.1.2.

Here the two stacktraces from Glassfish 4.1:

Severe: Error Rendering View[/index.xhtml]
org.jboss.weld.context.NonexistentConversationException: WELD-000321: No conversation found to restore for id 10
at org.jboss.weld.context.AbstractConversationContext.initialize(AbstractConversationContext.java:259)
at org.jboss.weld.context.http.LazyHttpConversationContextImpl.initialize(LazyHttpConversationContextImpl.java:68)
at org.jboss.weld.context.http.LazyHttpConversationContextImpl.checkContextInitialized(LazyHttpConversationContextImpl.java:93)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:74)
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:740)
at org.jboss.weld.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:107)
at org.jboss.weld.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:90)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:188)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:180)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:208)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
at com.sun.el.parser.AstValue.getBase(AstValue.java:151)
at com.sun.el.parser.AstValue.getValue(AstValue.java:200)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:112)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194)
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182)
at javax.faces.component.UIOutput.getValue(UIOutput.java:174)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:355)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:164)
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:923)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1906)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1902)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1902)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:459)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:136)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:125)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
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:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)

Here the stacktrace from Glassfish 3.1.2.2

SEVERE: WELD-000321 No conversation found to restore for id 10
org.jboss.weld.context.NonexistentConversationException: WELD-000321 No conversation found to restore for id 10
at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:221)
at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108)
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:85)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:603)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1550)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:745)

The problem is that JSF is not able to follow the exception handler's navigation handler redirect in RENDER phase.

Find additional information here:

https://java.net/jira/browse/JAVASERVERFACES-3870



 Comments   
Comment by timr99 [ 21/Aug/15 ]

How can I attach a reproducer?

Comment by jjsnyder83 [ 25/Aug/15 ]

This appears to be a jsf bug not a cdi bug. Reassigning it to Ed.





[GLASSFISH-21422] Windows, the redeployment to DAS of an enabled app with --force=true - failed on Glasfish 4.1 Created: 31/Aug/15  Updated: 08/Feb/17

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

Type: Bug Priority: Major
Reporter: atrajano Assignee: Vinay Vishal
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones GLASSFISH-18376 Windows, the redeployment to DAS of ... Resolved
Tags: 3_1_2-exclude

 Description   

Build 23, Windows machines. The redeployment with --force=true to DAS failed for several apps. See, for example, error messages that were created in the server.log during redeployment of stateless-simple.ear with --force=true. I've attached stateless-simple.ear.

EPLOYMENT stateless-simple
[#|2012-02-17T09:35:08.501-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=21;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB TheGreeter: [java:global/stateless-simple/stateless-simpleEjb/TheGreeter, java:global/stateless-simple/stateless-simpleEjb/TheGreeter!samples.ejb.stateless.simple.ejb.GreeterHome]|#]

[#|2012-02-17T09:35:08.501-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=21;_ThreadName=Thread-2;|EJB5182:Glassfish-specific (Non-portable) JNDI names for EJB TheGreeter: [greeter]|#]

[#|2012-02-17T09:35:08.907-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=21;_ThreadName=Thread-2;|WEB0671: Loading application stateless-simple#stateless-simple.war at [helloworld]|#]

[#|2012-02-17T09:35:08.970-0800|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=21;_ThreadName=Thread-2;|stateless-simple was successfully deployed in 1,344 milliseconds.|#]

DISABLE stateless-simple
ENABLE stateless-simple
[#|2012-02-17T09:35:12.188-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=18;_ThreadName=Thread-2;|EJB5181:Portable JNDI names for EJB TheGreeter: [java:global/stateless-simple/stateless-simpleEjb/TheGreeter, java:global/stateless-simple/stateless-simpleEjb/TheGreeter!samples.ejb.stateless.simple.ejb.GreeterHome]|#]

[#|2012-02-17T09:35:12.188-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=18;_ThreadName=Thread-2;|EJB5182:Glassfish-specific (Non-portable) JNDI names for EJB TheGreeter: [greeter]|#]

[#|2012-02-17T09:35:12.548-0800|INFO|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=18;_ThreadName=Thread-2;|WEB0671: Loading application stateless-simple#stateless-simple.war at [helloworld]|#]

[#|2012-02-17T09:35:12.548-0800|INFO|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=37;_ThreadName=Thread-2;|CORE10010: Loading application stateless-simple done in 0 ms|#]

REDEPLOY --FORCE stateless-simple
[#|2012-02-17T09:35:14.282-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=19;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.282-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=19;_ThreadName=Thread-2;|Exception while locating sub archive: stateless-simple.war|#]

[#|2012-02-17T09:35:14.298-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=19;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.298-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=19;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.313-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=39;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.329-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=19;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.329-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=19;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.345-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=19;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.407-0800|WARNING|glassfish3.1.2|javax.enterprise.system.tools.deployment.com.sun.enterprise.deploy.shared|_ThreadID=19;_ThreadName=Thread-2;|DPL8031: Ignoring stateless-simple_war/ because the containing archive C:\hudson\workspace\deployment-w\glassfish3\glassfish\domains\domain1\applications\stateless-simple recorded it as a pre-existing stale file|#]

[#|2012-02-17T09:35:14.407-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=19;_ThreadName=Thread-2;|Exception while deploying the app [stateless-simple]|#]

[#|2012-02-17T09:35:14.407-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=19;_ThreadName=Thread-2;|Could not find sub module [stateless-simple.war] as defined in application.xml
java.lang.IllegalArgumentException: Could not find sub module [stateless-simple.war] as defined in application.xml
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(ApplicationArchivist.java:585)
at com.sun.enterprise.deployment.archivist.ApplicationArchivist.openWith(ApplicationArchivist.java:258)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openWith(ApplicationFactory.java:240)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:175)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:94)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:827)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:769)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)

#]

[#|2012-02-17T09:35:14.423-0800|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=19;_ThreadName=Thread-2;|Exception while deploying the app [stateless-simple] : Could not find sub module [stateless-simple.war] as defined in application.xml|#]



 Comments   
Comment by atrajano [ 31/Aug/15 ]

Re-open because this is failing on Glassfish 4.1