[GLASSFISH-15176] Need a null check in org.glassfish.deployment.admin.GetHostAndPortCommand Created: 14/Dec/10  Updated: 14/Dec/10  Resolved: 14/Dec/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: None
Fix Version/s: 3.1_b33

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

Issue Links:
Dependency
blocks GLASSFISH-15174 NullPointerException while running as... Resolved

 Description   

In org.glassfish.deployment.admin.GetHostAndPortCommand, we have

String vsHttpListeners = virtualServer.getNetworkListeners();
List<String> vsHttpListenerList =
StringUtils.parseStringList(vsHttpListeners, " ,");

for (String vsHttpListener : vsHttpListenerList) {

Note that vsHttpListeners may be null here.
One may like to add a null check here.



 Comments   
Comment by Hong Zhang [ 14/Dec/10 ]

Yeah, we can add the null check if the main issue gets approved to check into 3.1. Otherwise we will fix it in 3.2.

Comment by Hong Zhang [ 14/Dec/10 ]

added a null check as shingwai suggested





[GLASSFISH-15166] Network listeners get updated unnecessarily when http-service is updated Created: 14/Dec/10  Updated: 15/Dec/10  Resolved: 14/Dec/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1_b32
Fix Version/s: 3.1_b33

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

Tags: 3_1-approved

 Description   

Network listeners get updated unnecessarily when http-service is updated. We should avoid this to improve performance since this loops around the whole set of network listeners.



 Comments   
Comment by Amy Roh [ 14/Dec/10 ]

Historically, http-listeners needed to get updated since they were under http-service but this is no longer the case.

Simple patch to avoid updating http-listeners unnecessarily. Ran web devtests and no regression due to the patch.

Index: src/main/java/com/sun/enterprise/web/WebContainer.java
===================================================================
— src/main/java/com/sun/enterprise/web/WebContainer.java (revision 43845)
+++ src/main/java/com/sun/enterprise/web/WebContainer.java (working copy)
@@ -3017,12 +3017,6 @@
}
}

  • List<NetworkListener> listeners = serverConfig.getNetworkConfig().getNetworkListeners().getNetworkListener();
  • if (listeners != null) {
  • for (NetworkListener httpListener : listeners) { - updateConnector(httpListener, httpService); - }
  • }
    }
Comment by Shing Wai Chan [ 14/Dec/10 ]

We may like to remove the unnecessary call of http-service, too.

Comment by Amy Roh [ 14/Dec/10 ]

How bad is its impact?

Any dynamic reconfig event such as create-virtual-server or create-network-listener will update http-service. WebContainer.updateHttpService unnecessarily looks through the set of network-listeners.

How often does it happen?

Whenever dynamic reconfig happens

How much effort is required to fix it?

Patch provided above

What is the risk of fixing it?

Minimum. All web devtests pass with the patch

Comment by Nazrul [ 14/Dec/10 ]

Approved for checkin

Comment by Amy Roh [ 14/Dec/10 ]

Sending web/web-core/src/main/java/org/apache/catalina/core/StandardHost.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
Transmitting file data ..
Committed revision 43861.

network-listener will only be updated if virtual-server.network-listeners has been changed.

Comment by Amy Roh [ 15/Dec/10 ]

Sending web/web-core/src/main/java/org/apache/catalina/core/StandardHost.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
Sending web/web-glue/src/main/java/com/sun/enterprise/web/reconfig/WebConfigListener.java
Transmitting file data ...
Committed revision 43879.





[GLASSFISH-15116] verifier does not allow "*" as servlet name in filter mapping Created: 11/Dec/10  Updated: 11/Dec/10  Resolved: 11/Dec/10

Status: Resolved
Project: glassfish
Component/s: verifier
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b33

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP


Attachments: File web25.war    

 Description   

My web.xml has the following filter mapping:

<filter-mapping>
<filter-name>Afilter</filter-name>
<servlet-name>*</servlet-name>
</filter-mapping>

The Servlet 2.5 spec allows use of the special servlet name '*', see SRV.18.0.2 Filter All Dispatches.

The verifier however, complains:

Test Name : tests.web.FilterMapping
Test Assertion : Filter mapping should be a correct URL or a servlet-name within the application. Please refer to Java Servlet 2.5 Specification Section #SRV.6.2.4 for further information.
Test Description : For [ web25 ]
Filter Mapping for [ Afilter ] has invalid servlet-name

(it also correctly reports some other errors in my app; please ignore them)



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

Good catch.

Sending verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/tests/web/FilterMapping.java
Transmitting file data .
Committed revision 43723.





[GLASSFISH-15115] FileNotFoundException from verifier Created: 11/Dec/10  Updated: 11/Dec/10  Resolved: 11/Dec/10

Status: Resolved
Project: glassfish
Component/s: verifier
Affects Version/s: None
Fix Version/s: 3.1_b33

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP


Attachments: File rar1.rar    

 Description   

On GFv2.1.1, the verifier reported the following error in my app:

Test Assertion : The connector deployment descriptor has the expected PubidLiteral "-//Sun Microsystems, Inc.//DTD J2EE Connector 1.0//EN".
Test Description : For [ rar1 ]
Error: The deployment descriptor for rar1 does not have the expected PubidLiteral "

{1}".

(Note the "{1}

", there seems to be a small bug).

On GFv3.1b33, the verifier reports:

Error Description : java.io.FileNotFoundException: file:\C:\DOCUME~1\diesk\LOCALS~1\Temp\exploded20101211104457\rar1\META-INF\ra.xml (The filename, directory name, or volume label syntax is incorrect)

at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)



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

ss141213@Sahoo:/space/ss141213/WS/gf/v3/verifier$ svn commit -m "Issue 15115"
Sending verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/connector/ConnectorCheckMgrImpl.java
Sending verifier/verifier-impl/src/main/resources/com/sun/enterprise/tools/verifier/LocalStrings.properties
Transmitting file data ..
Committed revision 43721.





[GLASSFISH-15113] NPE when specifying non-app to verifier Created: 11/Dec/10  Updated: 11/Dec/10  Resolved: 11/Dec/10

Status: Resolved
Project: glassfish
Component/s: verifier
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b33

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP


Attachments: File whitebox-notx.rar    

 Description   

In GFv2.1 the verifier would fail gracefully when accidentally specifying something other than an application to it (such as file of different format or even just a directory name):

Error Description : java.io.IOException: Cannot determine the Java EE module type for D:\tests\GFv3.1\glassfish-3.1-b33-12_10_2010\glassfish3\glassfish\bin

GFv3.1b33 however, chokes:

Error Description : java.lang.NullPointerException

at com.sun.enterprise.tools.verifier.DescriptorFactory.createApplicationDescriptor(DescriptorFactory.java:147)

at com.sun.enterprise.tools.verifier.Verifier.initStandalone(Verifier.java:380)

at com.sun.enterprise.tools.verifier.Verifier.init(Verifier.java:188)

at com.sun.enterprise.tools.verifier.VerifierMain.main(VerifierMain.java:86)

Reproducible as easy as:

D:\tests\GFv3.1\glassfish-3.1-b33-12_10_2010\glassfish3\glassfish>bin\verifier bin

but same happened with a proper (non Java EE) file.



 Comments   
Comment by Dies Koper [ 11/Dec/10 ]

I'm attaching an application that causes the same stacktrace.
GFv2.1.1's verifier reports no errors in the archive.
But I believe that's wrong: ra.xml should be in a directory called META-INF.

Comment by Sanjeeb Sahoo [ 11/Dec/10 ]

ss141213@Sahoo:/space/ss141213/WS/gf/v3/verifier$ svn commit -m "Issue 15113: Report proper exception if a non-ee app is supplied"
Sending verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/DescriptorFactory.java
Sending verifier/verifier-impl/src/main/java/com/sun/enterprise/tools/verifier/Verifier.java
Transmitting file data ..
Committed revision 43718.





[GLASSFISH-15112] NPE from Verifier Created: 11/Dec/10  Updated: 11/Dec/10  Resolved: 11/Dec/10

Status: Resolved
Project: glassfish
Component/s: verifier
Affects Version/s: 3.1_b33
Fix Version/s: 3.1_b33

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

WinXP


Attachments: Java Archive File isjee_verifier_ejb1.jar    

 Description   

Message from verifier does not show what's wrong with the app:

The report file has a NPE:

Test Description : For [ isjee_verifier_ejb1#cmp-jpa-ejb ]
Exception [EclipseLink-28018] (Eclipse Persistence Services - 2.2.0.v20101020-r8375): org.eclipse.persistence.exceptions.EntityManagerSetupException

Exception Description: Predeployment of PersistenceUnit [cmp-jpa-ejb] failed.

Internal Exception: java.lang.NullPointerException

The stdout is full of repetitive internal messages:

D:\tests\GFv3.1\glassfish-3.1-b33-12_10_2010\glassfish3\glassfish>bin\verifier d:\shared\javaee\isjee_verifier_ejb1.jar
INFO: Total time to parse domain.xml: 79 milliseconds
INFO: Cannot find javadb client jar file, derby jdbc driver will not be available by default.
INFO: Verifying: [ isjee_verifier_ejb1 ]
WARNING: setRuntimeDDPresent method not implemented
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
Visiting non-standard Signature object
WARNING: setRuntimeDDPresent method not implemented
WARNING: setRuntimeDDPresent method not implemented
WARNING: setRuntimeDDPresent method not implemented
INFO:

  1. of Failures : 1
  2. of Warnings : 0
  3. of Errors : 0
    INFO: Look in file "isjee_verifier_ejb1.jar.txt" for detailed results.


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

svn rev 43720





[GLASSFISH-15095] Nucleus distribution is completely broken - can't start because of missing grizzly comet packages Created: 10/Dec/10  Updated: 13/Dec/10  Resolved: 13/Dec/10

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_b33

Type: Bug Priority: Blocker
Reporter: Sanjeeb Sahoo Assignee: Ryan Lubke
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File osgi.bundle     XML File pom.xml     XML File pom.xml    
Issue Links:
Dependency
depends on GLASSFISH-15094 Nucleus distribution is completely br... Resolved
blocks GLASSFISH-15092 Nucleus distribution is completely br... Closed

 Description   

After addressing issue 15093 and 15094, I now face this problem while starting nucleus:

WARNING: Exception while starting bundle org.glassfish.core.kernel [53]
org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.core.kernel [53]: Unable to resolve 53.0: missing requirement [53.0] package; (&(package=com.sun.enterprise.admin.util)(version>=3.1.0)) [caused by: Unable to resolve 55.0: missing requirement [55.0] package; (&(package=com.sun.enterprise.config.serverbeans)(version>=3.1.0)) [caused by: Unable to resolve 14.0: missing requirement [14.0] package; (&(package=com.sun.grizzly.config.dom)(version>=1.9.0)) [caused by: Unable to resolve 12.0: missing requirement [12.0] package; (&(package=com.sun.grizzly.comet)(version>=1.9.24))]]]
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3404)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1714)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.jvnet.hk2.osgimain.Main.start(Main.java:154)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1822)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1739)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:619)

Looking at OSGi cache, I see bundle 12 is grizzly-config.jar and it indeed imports grizzly comet packages. Why? It was not importing comet packages earlier - not at least in the version of grizzly-config distributed in glassfish 3.0.1.



 Comments   
Comment by oleksiys [ 10/Dec/10 ]

Justin, can you pls. take a look?

Comment by Sanjeeb Sahoo [ 10/Dec/10 ]

making it a blocker as I need this fix ASAP to carry on using nucleus distro. we can't pull in grizzly-comet to nucleus, because that brings in javax.servlet as well.

Comment by Justin Lee [ 10/Dec/10 ]

How can I replicate this exception and where does it show up? And why are two different versions of grizzly (1.9.0 and 1.9.24) being listed? I'll attach the osgi.bundle file. It's been the same for months now. Not sure why this error is just now coming up? Is the nucleus code that showed this error tested often?

Comment by Justin Lee [ 10/Dec/10 ]

these are the build files. they've been this way, more or less, for months.

Comment by Sanjeeb Sahoo [ 10/Dec/10 ]

No, you can't reproduce unless you apply the patch for issue 15094. But, you don't have to reproduce the issue to fix it. You just have to inspect the medatadata of grizzly-config.jar to see that it does import comet packages. If you still don't know where to look for this metadata, then just open the META-INF/MANIFEST.MF and look for 'comet' there. I actually verified grizzly-config source code and I see it does reference comet code - this has to be a bad design somewhere.

Why 1.9.0 is appearing in Felix exception is because appserver is still probably built with 1.9.0 version of grizzly, but you can safely ignore all that. Just focus on how to avoid dependency on grizzly-comet from grizzly-config.

Comment by Sanjeeb Sahoo [ 10/Dec/10 ]

Dependency has to be first introduced in code:

ss141213@Sahoo:/space/ss141213/WS/grizzly/v1.9.24/modules/modules/config$ svn annotate ./src/main/java/com/sun/grizzly/config/GrizzlyEmbeddedHttp.java | grep comet
4222 cheeser import com.sun.grizzly.comet.CometAsyncFilter;
3798 oleksiys Boolean.getBoolean("v3.grizzly.cometSupport"))) {
4387 cheeser enableAsyncHandler(habitat, "comet", CometAsyncFilter.class);

It shows someone called cheeser has edited a couple of lines that introduced comet dependency in config project!!!

Comment by Justin Lee [ 10/Dec/10 ]

You can see the osgi.bundle we're using. We're only exporting the config packages. Why is hk2 adding everything else in the manifest? we only export two packages explicitly.

Comment by Justin Lee [ 10/Dec/10 ]

That code has been that way for a long, long time. There's no apparent reason this should suddenly start causing a problem.

Comment by Dhiru Pandey [ 10/Dec/10 ]

Using svn log and the code browsing on Grizzly project page - looks like the import for com.sun.grizzly.comet.CometAsyncFilter happened on 2009-10-27. See http://java.net/projects/grizzly/sources/svn/revision/3801 and then click the diffs for GrizzlyEmbeddedHttp.java

I don't think this is something new that Justin has done. He is correct this has not changed for a while and predates v3. Something else is going on here

Comment by Justin Lee [ 10/Dec/10 ]

The problem here doesn't appear to be in grizzly. This code hasn't changed in a long time.

Comment by Sanjeeb Sahoo [ 10/Dec/10 ]

Come on. How can one go by dates alone to confirm what was integrated in gfv3.0.1? You mean every change happening now in any part of grizzly codebase is getting integrated in gf3.1? I just saw they have a 3.2 like branch where they are doing something which is probably not being part of gf3.1. Something like that must have happened in 3.0.x timeframe as well or the dependency was once introfuced in 3.0.x times frame which was removed by the time 3.0.1 was FCSed. I kind of remember Jerome raising this issue once.

Fortunately, source code control systems don't forget. Here is what I see:

GF3.0.1 FCS is shipped with grizzly-config version 1.9.18-o. If you don't trust me, go download 3.0.1 fcs and look at the manifest of grizzly-config.jar that's there.

Currently the version of grizzly-config that's integrated with GF3.1 trunk is 1.9.24.

Now, compare the versions that are really used in gf3.0.1 fcs and gf3.1 trunk:

ss141213@Sahoo:/space/ss141213/WS/grizzly/v1.9.24/modules/config$ svn diff https://svn.java.net/svn/grizzly~svn/tags/1_9_18o/modules/config/src/main/java/com/sun/grizzly/config/GrizzlyEmbeddedHttp.java https://svn.java.net/svn/grizzly~svn/tags/1_9_24/modules/config/src/main/java/com/sun/grizzly/config/GrizzlyEmbeddedHttp.java | grep -i comet
+import com.sun.grizzly.comet.CometAsyncFilter;

  • final boolean mayEnableComet = !"admin-listener".equalsIgnoreCase(networkListener.getName());
  • configureProtocol(networkListener, protocol, habitat, mayEnableComet);
  • boolean mayEnableComet) {
  • if (mayEnableComet && (GrizzlyConfig.toBoolean(http.getCometSupportEnabled()) || Boolean
  • .getBoolean("v3.grizzly.cometSupport"))) {
    + if (mayEnableAsync && (GrizzlyConfig.toBoolean(http.getCometSupportEnabled()) ||
    + Boolean.getBoolean("v3.grizzly.cometSupport"))) {
    configureComet(habitat);
  • habitat, mayEnableComet);
  • private final void configureComet(Habitat habitat) {
  • final AsyncFilter cometFilter = habitat.getComponent(AsyncFilter.class, "comet");
  • if (cometFilter != null) {
    + private void configureComet(Habitat habitat) {
    + enableAsyncHandler(habitat, "comet", CometAsyncFilter.class);
  • asyncHandler.addAsyncFilter(cometFilter);

More over,
ss141213@Sahoo:/space/ss141213/WS/grizzly/v1.9.24/modules/config$ svn annotate ./src/main/java/com/sun/grizzly/config/GrizzlyEmbeddedHttp.java | grep comet
4222 cheeser import com.sun.grizzly.comet.CometAsyncFilter;

I think someone has also introduced websocket dependency lately in grizzly-config.

Comment by Dhiru Pandey [ 12/Dec/10 ]

You are correct Sahoo - my reasoning for this was erroneous. I too verified that comet packages were not imported in 3.0.1 ... it appears that this was introduced in 3.1.

I am not sure what is the extent of change required to fix this issue - I will let the Grizzly team investigate that. I wish this issue was brought up earlier in the development cycle - rather than few days before HCF (MS7)

I am curious though - what are the issue(s) with Nucleus distribution including comet ?

Comment by Sanjeeb Sahoo [ 13/Dec/10 ]

I won't be surprised if someone actually tells me comet dependency was included earlier only to be subsequently removed by the time v3.0.1 was fcsed.

I have addressed the two other nucleus issues after I discovered them that night. Until this is actually fixed (which does not seem difficult given it was once removed earlier), I can't tell what other issues are with nucleus. This is a blocker. I doubt there are many issues with nucleus at this point of time though.

Comment by oleksiys [ 13/Dec/10 ]

we have a fix.
Ryan will integrate the Grizzly 1.9.26 and close the issue.

Comment by Ryan Lubke [ 13/Dec/10 ]

Grizzly 1.9.26 has been integrated (revision 43797).





[GLASSFISH-15093] Nucleus distribution is completely broken - can't start because of missing simple-glassfish-api.jar Created: 10/Dec/10  Updated: 14/Dec/10  Resolved: 14/Dec/10

Status: Resolved
Project: glassfish
Component/s: packaging
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_b33

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

Issue Links:
Dependency
blocks GLASSFISH-15092 Nucleus distribution is completely br... Closed

 Description   

I tried to run nucleus distro and it refuses to start:

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ java -jar
/space/ss141213/WS/gf/v3/distributions/nucleus/target/stage/glassfish3/glassfish/modules/glassfish.jar

Listening for transport dt_socket at address: 9009
Launching GlassFish on Felix platform
Exception in thread "main" java.lang.Error: java.io.IOException: No such
file:
/space/ss141213/WS/gf/v3/distributions/nucleus/target/stage/glassfish3/glassfish/modules/simple-glassfish-api.jar
at
com.sun.enterprise.glassfish.bootstrap.ASMainHelper.createOSGiFrameworkLauncherCL(ASMainHelper.java:543)
at
com.sun.enterprise.glassfish.bootstrap.ASMainHelper.createLauncherCL(ASMainHelper.java:508)
at
com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:92)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: java.io.IOException: No such file:
/space/ss141213/WS/gf/v3/distributions/nucleus/target/stage/glassfish3/glassfish/modules/simple-glassfish-api.jar
at
com.sun.enterprise.glassfish.bootstrap.ClassPathBuilder.addJar(ClassPathBuilder.java:72)
at
com.sun.enterprise.glassfish.bootstrap.ASMainHelper$ClassLoaderBuilder.addBootstrapApiJar(ASMainHelper.java:621)
at
com.sun.enterprise.glassfish.bootstrap.ASMainHelper.createOSGiFrameworkLauncherCL(ASMainHelper.java:539)
... 3 more

The reason is simple: missing simple-glassfish-api.jar in modules/. When
I look at various pom.xmls, I see it is part of web or glassfish distro
probably because of a compile dependency on it from
web/web-embed/api/pom.xml.



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

Fixed:
ss141213@Sahoo:~/bugs/ACC-distro$ svn commit -m "Issue 15093: make simple-glassfish-api.jar part of all distro by adding a compile time dependency on it from glassfish.jar" !$
svn commit -m "Issue 15093: make simple-glassfish-api.jar part of all distro by adding a compile time dependency on it from glassfish.jar" ~/WS/gf/v3/core/bootstrap/pom.xml
Sending home/ss141213/WS/gf/v3/core/bootstrap/pom.xml
Transmitting file data .
Committed revision 43845.





[GLASSFISH-15080] HA SSO with incorrect session data Created: 09/Dec/10  Updated: 14/Dec/10  Resolved: 14/Dec/10

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1_b33

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: 3_1-approved

 Description   

Given a cluster with instance inst1, inst2 and inst3,
web container availability service and sso-failover are enabled.
Also the corresponding user/password is set up for a given realm.
Deploy a simple counter web app A and B with --availabilityenabled=true.

Scenario 1 (Incorrect behavior):
a) Access web app A in inst1, login and see the correct counter 0.
And then access app B in inst1 without login and see the expected counter 0.
b) stop-local-instance inst1
c) Access web app B in inst2, without login, but the counter is 0 (which should be 1).
Access web app A in inst2, without login, and see the expected counter 1.

Scenario 2 (Correct behavior):
a) Access web app A in inst1, login and see the correct counter 0.
And then access app B in inst1 twice without login and see the expected counter 1.
b) stop-local-instance inst1
c) Access web app B in inst2, without login, and see the expected counter 2.
Access web app A in inst2, without login, and see the expected counter 1.

Both scenarios are working before.



 Comments   
Comment by Shing Wai Chan [ 14/Dec/10 ]

With the recent shoal 1.5.23 integration, the issue is resolved.
Per discussion with Mahesh, we would like to add a toString for debugging:

— web/web-ha/src/main/java/org/glassfish/web/ha/authenticator/HASingleSignOnEntryMetadata.java (revision 43845)
+++ web/web-ha/src/main/java/org/glassfish/web/ha/authenticator/HASingleSignOnEntryMetadata.java (working copy)
@@ -131,4 +131,18 @@
boolean removeHASessionData(HASessionData sessionData)

{ return sessionDataSet.remove(sessionData); }

+
+ @Override
+ public String toString() {
+ return "HASingleSignOnEntryMetadata

{" + + "id='" + id + '\'' + + ", authType='" + authType + '\'' + + ", sessionDataSet.size=" + sessionDataSet.size() + + ", username='" + username + '\'' + + ", realmName='" + realmName + '\'' + + ", lastAccessTime=" + lastAccessTime + + ", maxIdleTime=" + maxIdleTime + + ", version=" + version + + '}

';
+ }
}

Comment by Shing Wai Chan [ 14/Dec/10 ]

Fix in shoal version 1.5.23.

Checkin debug statement:
Sending web/web-ha/src/main/java/org/glassfish/web/ha/authenticator/HASingleSignOnEntryMetadata.java
Transmitting file data .
Committed revision 43853.

Comment by Nazrul [ 14/Dec/10 ]

Approved for checkin





[GLASSFISH-15079] asadmin create-virtual-server fires extra events causing performance issue Created: 09/Dec/10  Updated: 09/Dec/10  Resolved: 09/Dec/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1_b33

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   

asadmin create-virtual-server fires extra events for org.jvnet.hk2.config.type.Property CHANGE: docroot, accesslog.
This causes performance issue.

The corresponding code is in web/admin: CreateVirtualServer.java
The issue is that docroot and accesslog are regarded as property rather than attributes.
This causes the extra property change event.



 Comments   
Comment by Shing Wai Chan [ 09/Dec/10 ]

Sending src/main/java/org/glassfish/web/admin/cli/CreateVirtualServer.java
Transmitting file data .
Committed revision 43644.





[GLASSFISH-15077] Client-Cert authentication failed Created: 09/Dec/10  Updated: 18/Feb/11  Resolved: 10/Dec/10

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

Type: Bug Priority: Major
Reporter: sonialiu Assignee: Ryan Lubke
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

solaris10


Attachments: Text File server.log    
Tags: 3-1-regression, 3_1-verified

 Description   

build: promoted build 32
The httpsclientcert test started to fail since b29, earlier I thought it was related to a SSL bug that CTS filed, so I did not open a bug. But it seems it is a different issue. I have to open a new bug for it.
Steps to reproduce the bug:
1. Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT=:pserver:cvsguest@sunsw.sfbay.sun.com:/m/jws)
cd appserver-sqe
ant -f bootstrap.xml co-security
2. install GF V3.1, start domain
3. Setup env. variables
S1AS_HOME <GF installation dir> (example: /export/sonia/v3/glassfishv3/glassfish
SPS_HOME <workspace dir> (example: /export/sonia/appserver-sqe)
ANT_HOME <ant dir>
JAVA_HOME <java dir>
5. cd appserver-sqe/pe/security/ssl, run "ant setup".
6. cd appserver-sqe/pe/security/ssl, run "ant all". The test failed:
[java] %% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
[java] [read] MD5 and SHA1 hashes: len = 16
[java] 0000: 14 00 00 0C 48 33 6B 5D E1 53 4E 93 23 67 B6 4C ....H3k].SN.#g.L
[java] SSLClient:: SSL handshake done...
[java] GET /httpsclientauth/clientcertservlet HTTP/1.0
[java] main, WRITE: TLSv1 Application Data, length = 65
[java] main, READ: TLSv1 Application Data, length = 1599
[java] HTTP/1.1 400 Bad Request
[java] X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1-SNAPSHOT Java/Sun Microsystems Inc./1.6)
[java] Server: GlassFish Server Open Source Edition 3.1-SNAPSHOT
[java] Pragma: No-cache
[java] Cache-Control: no-cache
[java] Expires: Wed, 31 Dec 1969 16:00:00 PST
[java] Content-Type: text/html
[java] Content-Length: 1192
[java] ===>Body length=1192
[java] Date: Thu, 09 Dec 2010 22:52:33 GMT
[java] Connection: close
[java]
[java] ===>Reached end of headers section. Body should start!
[java] <Unable to render embedded object: File (//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html><head><title>GlassFish Server Open Source Edition 3.1-SNAPSHOT - 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 400 - No client certificate chain in this request</h1><hr/><p><b>type</b> Status report</p><p><b>message</b>No client certificate chain in this request</p><p><b>description</b>The request sent by the client was syntactically incorrect (No client certificate chain in this request).</p><hr/><h3>GlassFish Server Open Source Edition 3.1-SNAPSHOT</h3></body></html===>body read with content length=1192
[java] main, called close()
[java] main, called closeInternal(true)
[java] main, SEND TLSv1 ALERT: warning, description = close_notify
[java] main, WRITE: TLSv1 Alert, length = 18
[java] main, called close()
[java] main, called closeInternal(true)
[java] main, called close()
[java] main, called closeInternal(true)
[java] HTTP/1.1 400 Bad RequestX-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1-SNAPSHOT Java/Sun Microsystems Inc./1.6)Server: GlassFish Server Open Source Edition 3.1-SNAPSHOTPragma: No-cacheCache-Control: no-cacheExpires: Wed, 31 Dec 1969 16:00:00 PSTContent-Type: text/htmlContent-Length: 1192Date: Thu, 09 Dec 2010 22:52:33 GMTConnection: close<Unable to render embedded object: File (//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html><head><title>GlassFish Server Open Source Edition 3.1-SNAPSHOT - 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 400 - No client certificate chain in this request</h1><hr/><p><b>type</b> Status report</p><p><b>message</b>No client certificate chain in this request</p><p><b>description</b>The request sent by the client was syntactically incorrect (No client certificate chain in this request).</p><hr/><h3>GlassFish Server Open Source Edition 3.1-SNAPSHOT</h3></body></html
[java] Writing the output to file - /export/sonia/appserver-sqe/pe/security/ssl/httpsclientauth/httpsbody.html
[java] Flush the output to file - /export/sonia/appserver-sqe/pe/security/ssl/httpsclientauth/httpsbody.html
[java] Done writing the output to file - /export/sonia/appserver-sqe/pe/security/ssl/httpsclientauth/httpsbody.html
[java] WS HOME appserver-sqe
[java] *** Goldenfiles comparision and report updation **
[java] Expected:/export/sonia/appserver-sqe/pe/security/ssl/httpsclientauth/goldenfiles/clientcertservlet.html;actualFile=/export/sonia/appserver-sqe/pe/security/ssl/httpsclientauth/httpsbody.html
[java] *** Golden File mismatch ***
[java] 1.Expected:<html><head><title>Certificate Authorization Servlet</title></head><body><center><h3>Certificate Authorization Servlet</h3></center><hr><b>getUserPrincipal():</b>EMAILADDRESS=jagadesh.munta@sun.com, CN=Jagadesh Munta, OU=Java Web Services, O="Sun Microsystems, Inc.", L=Santa Clara, ST=California, C=US<br><b>getAttribute():</b> returns correct value.<br><b>isUserInRole("MANAGER"):</b> True. The user belongs to the Role that is Authorized to access this Servlet.<br></body></html>
[java] 2.Actual:<Unable to render embedded object: File (//www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html><head><title>GlassFish Server Open Source Edition 3.1-SNAPSHOT - 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 400 - No client certificate chain in this request</h1><hr/><p><b>type</b> Status report</p><p><b>message</b>No client certificate chain in this request</p><p><b>description</b>The request sent by the client was syntactically incorrect (No client certificate chain in this request).</p><hr/><h3>GlassFish Server Open Source Edition 3.1-SNAPSHOT</h3></body></html
[java] Generating report at /export/sonia/appserver-sqe/test_results.xml
[java]
[java]
[java] -----------------------------------------
[java] - HTTPS-CLIENT-CERT-Auto-Client-Authentication-test-PKCS12-CS: FAIL -
[java] -----------------------------------------
[java] Total PASS: 0
[java] Total FAIL: 1
[java] Total DNR: 0

– I have attached the server.log. Thanks.



 Comments   
Comment by kumarjayanti [ 10/Dec/10 ]

I debugged this issue and it is the same regression issue as CR 7000192 (which is affecting client-cert scenarios in CTS).

Lines 143-148 of SSLAuthenticator.java

X509Certificate certs[] = (X509Certificate[])
request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR);
if ((certs == null) || (certs.length < 1))

{ certs = (X509Certificate[]) request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR); }

the value of certs at the end of execution of above code is still null and hence we see the request is failed after that and we get the following the response :

HTTP Status 400 - No client certificate chain in this request</h1><hr/><p><b>type</b> Status report</p><p><b>message</b>No client certificate chain in this request</p><p><b>description</b>The request sent by the client was syntactically incorrect (No client certificate chain in this request).</p><hr/><h3>GlassFish Server Open Source Edition 3.1-SNAPSHOT</h3>

Comment by Dhiru Pandey [ 10/Dec/10 ]

Assigning to Ryan — since he is fixing the root cause for this issue (Bugster ID 7000192)

Comment by Ryan Lubke [ 10/Dec/10 ]

Issue is resolved.

GlassFish revision: 43708
Grizzly revision: 5496.





[GLASSFISH-15058] The <resource-ref> and <resource-env-ref> tags in web.xml are not checked properly during deployment Created: 08/Dec/10  Updated: 10/Dec/10  Resolved: 10/Dec/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_b33

Type: Bug Priority: Major
Reporter: jasonw401 Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP


Attachments: File SampleServletJDBC.war    

 Description   

If a web.xml contains an invalid <res-type> of <resource-ref>, the application can still be deployed without error.

<resource-ref>
<res-ref-name>jdbc/myDS</res-ref-name>
<res-type>dummy</res-type>
<res-auth>Container</res-auth>
</resource-ref>

I am not sure if this behaviour is expected in GlassFish V3.1, but GlassFish V2.1 gives an error message in server log:"java.lang.IllegalArgumentException: [dummy] is not an allowed property value type".

A similiar issue is if the web.xml contains an empty name in the <resource-env-ref-type> tag of <resource-env-ref>,
<resource-env-ref>
<resource-env-ref-name></resource-env-ref-name>
<resource-env-ref-type>test.AdminObject</resource-env-ref-type>
</resource-env-ref>

the deployment failed but the error in server log is not clear:

[#|2010-12-09T12:01:57.328+1100|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=16;_ThreadName=Thread-1;|The log message is null.
java.lang.NullPointerException
at com.sun.enterprise.deployment.util.EjbBundleValidator.computeRuntimeDefault(EjbBundleValidator.java:1121)
at com.sun.enterprise.deployment.util.EjbBundleValidator.accept(EjbBundleValidator.java:857)
at com.sun.enterprise.deployment.WebBundleDescriptor.visit(WebBundleDescriptor.java:1988)
at com.sun.enterprise.deployment.Application.visit(Application.java:1780)

In GlassFish V2.1, the following error message appears in server log: "Invalid content was found starting with element 'resource-env-ref-type'".

Please see attached for the test application.



 Comments   
Comment by Hong Zhang [ 10/Dec/10 ]

We now have validation for the resource ref and reject invalid ref type.

Now for empty ref type, we will reject the deployment by this error message: java.lang.IllegalArgumentException: [null] is not an allowed property value type

And for invalid ref type like foo, we will reject the deployment by this error message: java.lang.IllegalArgumentException: [foo] is not an allowed property value type





[GLASSFISH-15057] [REGRESSION][BLOCKING]Appclient doesn't take $ in a file path Created: 08/Dec/10  Updated: 18/Feb/11  Resolved: 12/Dec/10

Status: Closed
Project: glassfish
Component/s: standalone_client
Affects Version/s: None
Fix Version/s: 3.1_b33

Type: Bug Priority: Critical
Reporter: sonialiu Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

linux


Tags: 3-1-regression, 3_1-blocking, 3_1-verified

 Description   

build: promoted build 31, 32
Appclient doesn't take a jar file which file path contains a $ character. This issue caused 150+ test cases failed.

See the appclient run output below:

bash-3.2$ pwd
/export/hudson/workspace/sonia-v31-jms-linux-smon/appserver-sqe/build/pe/i386_apg-sqe2_Linux/$

{module}/archive
bash-3.2$ ls
jms-jmsejbappAppClient jms-jmsejbappApp.ear jms-jmsejbapp-ejb.jar lib
jms-jmsejbappAppClient.jar jms-jmsejbapp-client.jar jms-jmsejbapp-par.jar

bash-3.2$ /export/hudson/workspace/sonia/glassfish3/glassfish/bin/appclient -client /export/hudson/workspace/sonia-v31-jms-linux-smon/appserver-sqe/build/pe/i386_apg-sqe2_Linux/${module}

/archive/jms-jmsejbappAppClient.jar -name jms-jmsejbappAppClient mytest
Unable to access jarfile /export/hudson/workspace/sonia-v31-jms-linux-smon/appserver-sqe/build/pe/i386_apg-sqe2_Linux//archive/jms-jmsejbappAppClient.jar

If I don't have the $ character in the path, the appclient run passed.



 Comments   
Comment by sonialiu [ 08/Dec/10 ]

update tag

Comment by Tim Quinn [ 08/Dec/10 ]

Sonia,

Did this exact use case work in the past?

What is happening is that the shell is - as expected - trying to substitute the value of the environment variable "module" into the command where $

{module} appears. Because that env. var. is not defined, the shell substitutes an empty string. That's why you see the two adjacent slashes in the resulting path.

If the test really needs to specify the path including "${module}

" it should quote the dollar sign character

/export/hudson/workspace/sonia-v31-jms-linux-smon/appserver-sqe/build/pe/i386_apg-sqe2_Linux/\$

{module}

/archive/jms-jmsejbappAppClient.jar -name jms-jmsejbappAppClient mytest

(note the backslash preceding the dollar sign)

or it could single-quote the entire path, which suppresses env. var. substitution. Of course these techniques are specific to non-Windows systems.

I did make some changes recently in how the appclient script processes command-line elements but I don't think those changes would have caused this. I will close the issue. Please re-open it if I have missed something.

Comment by Tim Quinn [ 08/Dec/10 ]

Really "not a bug" but that's not an option so I'm using "won't fix."

Comment by sonialiu [ 09/Dec/10 ]

Tim, Thanks for looking at the issue.
Actually, the $

{module}

in the path was not passed from test scripts. The path is automatically generated when a build.properties of any test doesn't have the module.name property. In the earlier builds, all the tests with the $ in the file path were passing till build 29. This issue caused many test failures in different core modules (jms, security, connector...) in the later builds. So, I have to reopen the bug. BTW, do you recall that we had a similar issue about a smoke test failure (http://java.net/jira/browse/GLASSFISH-11829), you fixed the issue for the $ character in the file path. It might be the same problem. Thanks!

Comment by Tim Quinn [ 09/Dec/10 ]

Sonia,

(The cause of and solution for the other bug (11829) were quite different, even though it also involved a $ sign or any other special character.)

The test script - and build.properties or other files the test script uses - is creating an appclient command that contains a file path that contains $

{module} in it.

I maintain that the behavior we are seeing now is what users would expect. Users will expect the shell to replace ${xxx} on a command line with whatever the environment variable xxx is defined as. If xxx is not defined, then the shell replaces it with the empty string. This is true whether you run the appclient command, or ls, or any other command.

Manually create a directory named ${module}

and place a JAR in it and then try to launch the app client JAR.

  1. Note - To create the dir and copy a JAR to it you must use \ to
  2. prevent the shell from trying to substitute the env. var.

$ mkdir \$

{module}
$ cp (otherplace)/showArgsGUI-client.jar \${module}
  1. The above steps have the same effect as
  2. what ant is doing in the test.

$ find .
.
./$

{module}
./${module}

/showArgsGUI-client.jar

  1. The next command is essentially the command which
  2. the ant test script generates:

$ appclient -client $

{module}/showArgsGUI-client.jar

Unable to access jarfile /showArgsGUI-client.jar

$

The shell has tried to substitute the value for the env. var. "module" and, finding no definition, used the empty string.

Suppose, on the other hand, you created a directory xxx and placed the JAR there:

$ mkdir xxx
$ cp (otherplace)/showArgsGUI-client.jar xxx
$ find .

.
./xxx
./xxx/showArgsGUI-client.jar

Now, suppose you define the env. var. "module" to point to the xxx directory.

$ module=xxx
$ export module

$ appclient -client ${module}

/showArgsGUI-client.jar

    1. this works, launching the JAR xxx/showArgsGUI-client.jar

Users should expect normal shell variable substitution to work, as it does currently, when they run appclient commands.

I will leave this open for now but we do not want shell variable substitution to work differently for the appclient command as compared to every other command.

Comment by sonialiu [ 09/Dec/10 ]

Thanks Tim for the input. I understand your point. The problem is that more than 200+ test cases in different test modules got affected due to this issue. The test scripts were running fine till b30. We are not sure why the appclient accepted the $ in the past but doesn't support it now. Most of the tests were ported from V2.x and they were passed against v2.x also. In this case, is that possible to restore the old behavior back, so we can continue to run the tests?

Comment by Tim Quinn [ 09/Dec/10 ]

Sonia, can you please let me know how I can reproduce a single failure using one (or a small number) of the SQE tests?

I tried running from appserver-sqe/pe/jms/jmsejbapp - guessing which test you had used as an example failure - and the test worked for me. I realize in your example the current directory contains $

{module}. I want to understand how in the course of running the tests the current directory becomes one that contains ${module}

.

Comment by Tim Quinn [ 11/Dec/10 ]

Sonia,

I think I have a solution we will both like.

In appserver-sqe/build-config/sqe-properties.xml, I inserted this line

<property name="module" value="notSpec"/>

just after the two <exec executable="uname"...> elements in the init-common target near the top of the file.

Based on how each individual build.xml invokes the files in build-config, this new property definition essentially provides a default value for the "module" property. If an individual test or group of tests defines the property in its build.properties, then ant processes that definition first. The later declaration in init-common does not override the earlier one from the test.

But if a test does not define the "module" property then the new definition provides a default value.

This one change should, I believe, allow all the tests to operate normally while avoiding the shell environment variable substitution problem I described earlier.

How does this sound?

Comment by sonialiu [ 11/Dec/10 ]

I added the following line in the build-config/sqe-properties.xml
<property name="module" value="notSpec"/>
just after the two <exec executable="uname"...> elements in the init-common target.
Now, many tests failed while deploying. See output below:
deploy-common-pe:
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile /export/hudson/workspace/sonia-v3-jms-linux/appserver-sqe/build-config/adminpassword.txt --interactive=false --echo=true --terse=false deploy --name notSpec-basicApp --force=false --precompilejsp=false --verify=false --retrieve /export/hudson/workspace/sonia-v3-jms-linux/appserver-sqe/build/pe/i386_apg-sqe1_Linux/notSpec/archive --generatermistubs=false --availabilityenabled=false --asyncreplication=true --keepreposdir=false --keepfailedstubs=false --isredeploy=false --logreportederrors=true /export/hudson/workspace/sonia-v3-jms-linux/appserver-sqe/build/pe/i386_apg-sqe1_Linux/notSpec/archive/notSpec-basicApp.ear
[exec] Command deploy failed.
[exec] org.glassfish.api.admin.CommandException: remote failure: Error occurred during deployment: Exception while deploying the app [notSpec-basicApp] : Application [notSpec-basicApp] contains no valid components. Please see server.log for more details.
[exec] Result: 1

Comment by Tim Quinn [ 12/Dec/10 ]

Fix checked in.

Sonia, please try your tests again with the nightly build from Dec. 13.

I am closing this issue as this should resolve the problem Sonia encountered. Please re-open the issue if you see the problem again.

Project: glassfish
Repository: svn
Revision: 43743
Author: tjquinn
Date: 2010-12-12 20:19:09 UTC
Link:

Log Message:
------------
Fix for 15057

The revised approach for computing the java command to use to start the ACC invokes another small Java program first. All command-line options and arguments are passed to CLIBootstrap, and as part of that the shell substitutes any environment variables references. The CLIBootstrap code figures out the java command to be used to launch the ACC. Any command-line data inside CLIBootstrap has already undergone the shell's env. var. substitution. When CLIBootstrap emits such data, for non-WIndows systems it now quotes any $ character because any such character is probably part of an unusual but legal path which the user had quoted originally.

(Prior to this change, the un-quoted $ was being interpreted by the shell when the shell processed the java command that invokes the ACC. We need to suppress that second pass of substitution.)

Tests: QL, deployment and ejb devtests

Revisions:
----------
43743

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java





[GLASSFISH-15053] Downloaded artifacts stored incorrectly if target location is absolute and does not yet exist (as in get-client-stubs or deploy --retrieve) Created: 08/Dec/10  Updated: 09/Dec/10  Resolved: 09/Dec/10

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_b33

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 1 hour
Original Estimate: Not Specified


 Description   

The payload handling does not correctly handle the case in which the target location is absolute and does not yet exist.

The logic to handle non-existent output directories currently is used only for relative paths (for no good reason).



 Comments   
Comment by Tim Quinn [ 09/Dec/10 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 43598
Author: tjquinn
Date: 2010-12-09 01:20:35 UTC
Link:

Log Message:
------------
Fix for 15053

Transfered files would be deposited in the wrong place if the destination was an absolute path that did not yet exist. (Relative non-existent paths were already handled correctly).

Tests: QL, deployment and ejb devtests

Revisions:
----------
43598

Modified Paths:
---------------
trunk/v3/common/common-util/src/main/java/org/glassfish/admin/payload/PayloadFilesManager.java





[GLASSFISH-15028] [Regression] Warning with no further information when deploying to a stopped instance. Created: 07/Dec/10  Updated: 28/Jan/11  Resolved: 10/Dec/10

Status: Closed
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1_b31
Fix Version/s: 3.1_b33

Type: Bug Priority: Major
Reporter: lidiam Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

build: ogs-3.1-b32-12_07_2010.zip


Attachments: File clusterjsp.ear     Text File das.server.log     JPEG File deploy-warning.JPG     Text File sin2.server.log    
Tags: 3-1-regression

 Description   

A generic warning with no further details is displayed in Admin Console when an application is deployed to two instances: one running, one stopped. Steps to reproduce:

1. In Admin Console, create two standalone instances, e.g. sin1 and sin2.
2. Start both instances.
3. Stop the first instance, sin1.
4. In Admin Console, go to second instance, sin2 and click on Applications tab.
5. Click on deploy and add first instance, sin1, as a target to already selected sin2.
6. Deploy an application, e.g. clusterjsp.ear to both instances. The following warning will be displayed:

Warning Deployment succeeded with a warning, please look at the log file for details
Application deployed with name clusterjsp.

When you check server.log for DAS and instances, no warning is logged related to this deployment. The issue is with replication of deployment to the stopped instance. Proper warning is displayed upon undeployment, but not deployment.



 Comments   
Comment by Hong Zhang [ 09/Dec/10 ]

I was able to reproduce this problem (this is not a regression though, the previous test was only with a single offline instance). I will work on a fix for this.

Comment by Hong Zhang [ 10/Dec/10 ]

Have provided property warning for this case now (when deploying to two instances and one of the instances are offline).

Comment by lidiam [ 28/Jan/11 ]

Verified on b39 promoted.





[GLASSFISH-15011] Duplicate INFO messages from logger while creating http listeners Created: 06/Dec/10  Updated: 13/Dec/10  Resolved: 13/Dec/10

Status: Closed
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: 3.1_b33

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   

In WebContainer.createHttpListener, one print the an INFO message as follows:
if (_logger.isLoggable(Level.INFO)) {
_logger.log(Level.INFO, "webContainer.HTTP.listenerAndPort", new Object[]

{listener.getName(), listener.getAddress(), listener.getPort()});
}

This messages will be printed two or three times when we run
asadmin create-http-listener --listeneraddress <ip> --listenerport <port> --defaultvs <vs> <listener>

I confirmed that it is the same logger call by adding an AtomicInteger in message as follows:
svn diff .
Index: web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java
===================================================================
— web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java (revision 43372)
+++ web-glue/src/main/java/com/sun/enterprise/web/WebContainer.java (working copy)
@@ -167,6 +167,7 @@
* The current <code>WebContainer</code> instance used (single).
*/
protected static WebContainer webContainer;
+ private static java.util.concurrent.atomic.AtomicInteger ac = new java.util.concurrent.atomic.AtomicInteger();

/**
* Are we using Tomcat deployment backend or DOL?
@@ -857,7 +858,8 @@
connector.setMapper(mapper);

if (_logger.isLoggable(Level.INFO)) {
- _logger.log(Level.INFO, "webContainer.HTTP.listenerAndPort", new Object[]{listener.getName(), listener.getAddress(), listener.getPort()}

);
+ _logger.log(Level.INFO, "webContainer.HTTP.listenerAndPort", new Object[]

{ac.getAndIncrement() + ":: " + listener.getName(), listener.getAddress(), listener.getPort()}

);
+ Thread.currentThread().dumpStack();
}

connector.setName(listener.getName());



 Comments   
Comment by naman_mehta [ 08/Dec/10 ]

I couldn't understand your diff in the bug description. Can you give me more details on the same? Are you asking me to verify your diff?

Comment by Shing Wai Chan [ 08/Dec/10 ]

The diff in description above put an id in logger message so that one can distinguish different call of the logger in this case.

Comment by naman_mehta [ 10/Dec/10 ]

For this issue logging module is working fine. Logging module logs all messages as per the code.

If you keep debug in WebContainer.java line number 857 which has below code.

if (_logger.isLoggable(Level.INFO)) {
_logger.log(Level.INFO, "webContainer.HTTP.listenerAndPort", new Object[]

{listener.getName(), listener.getAddress(), listener.getPort()}

);
}

Above line is executed multiple times with same data and looks like logging same data in server.log file. In turn it looks like logging issue but it's not logging issue. It's revisiting same code again and again which is causing this issue.

To resolve this, log message only once in the code after whole operation is completed. Keep all log messages in some buffer and add unique data at the last. Your suggested solution works but doesn't look perfect to me.

Comment by Santiago Pericas-Geertsen [ 13/Dec/10 ]

This is not a logging problem. There are two change events received by WebConfigListener.changed:114. The first is for the creation of the new HTTP listener. The second is to update the virtual server with the new list of HTTP listeners.

The first event creates the new HTTP listeners and logs the action. The second event deletes and re-creates all of the listeners, including the one created by the first event. Suppose A and B are listeners in server S. When adding a new listener C, the log shows:

(from first event change)
created C
(from second event change – delete and re-create)
created A
created B
created C

It appears the first event is triggering the second. Perhaps someone can comment on whether this behavior is different from earlier versions of GF.

Comment by Shing Wai Chan [ 13/Dec/10 ]

I do notice multiple call before filing this issue.
The multiple call issue is filed on issue 15012.
It was closed and have the status Santiago described.

But in my debug, I have added an AtomicInteger in the code. In other words, each message is different. The following is a snapshot of previous log from Mac OS 10.5.8:

[#|2010-12-03T14:59:57.185-0800|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=107;_ThreadName=pool-13-thread-1;|WEB0169: Created HTTP listener [4:: http-listener-2] on host/port [0.0.0.0:8181]|#]

[#|2010-12-03T14:59:57.185-0800|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=17;_ThreadName=Thread-1;|WEB0169: Created HTTP listener [4:: http-listener-2] on host/port [0.0.0.0:8181]|#]

Comment by Santiago Pericas-Geertsen [ 13/Dec/10 ]

After further investigation, I was able to reproduce the message duplication problem shown in Shin Wai's comment. There are cases in which the exact same message is logged more than once. It looks like an issue in the logging module, but it's quite hard to debug due the blocking queues, threads, etc. Currently investigating the use of the blocking queue in class GFFileHandler.

Comment by Shing Wai Chan [ 13/Dec/10 ]

Sending src/main/java/com/sun/enterpris/web/WebContainer.java
Sending src/main/java/com/sun/enterprise/web/logger/FileLoggerHandler.java
Transmitting file data ..
Committed revision 43827.





[GLASSFISH-15004] [regression] failed to get connection with OAUTH marshaling failure Created: 06/Dec/10  Updated: 16/Feb/11  Resolved: 07/Dec/10

Status: Resolved
Project: glassfish
Component/s: standalone_client
Affects Version/s: 3.1
Fix Version/s: 3.1_b33

Type: Bug Priority: Critical
Reporter: sherryshen Assignee: Tim Quinn
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHL5


Tags: 3_1-regression, 3_1-verified

 Description   

tx prorogation with appclient tests failed to
get connection to oracle database.

[echo] WARNING: RAR5038:Unexpected exception
while creating resource for pool pooltxp. Exception :
javax.resource.spi.ResourceAllocationException:
Connection could not be allocated because: OAUTH marshaling failure.

The same tests passed on glassfish-3.1-b31.zip promoted on 11_30_2010.

To reproduce the problem:
Please refer to this issue for test setup
http://java.net/jira/browse/GLASSFISH-14918
Run test by doing
do "ant oracle4 all_ac_sql_nodsd" in
appserver-sqe/pe/ejb/ejb30/txpropagation

This failure blocks me to verify the fix of 14918.



 Comments   
Comment by sherryshen [ 06/Dec/10 ]

The stacktrace is near utx.begin() in test client.
[echo] at com.sun.enterprise.transaction.UserTransactionImpl.begin(UserTransactionImpl.java:165)
[echo] at ejb30.txpropagation.client.TestClient.doTest(TestClient.java:80)

appserver-sqe/pe/ejb/ejb30/txpropagation/client/TestClient.java_nodsd
public class TestClient {
private DataSource ds;
public static void main (String[] args) {
private static @EJB Sful sful;
public void doTest(String suite, boolean commit) {
// ...
try {
// ...
UserTransaction utx = (UserTransaction)
(new javax.naming.InitialContext()).lookup("java:comp/UserTransaction");
ds = (DataSource)
(new javax.naming.InitialContext()).lookup("jdbc/txp");
utx.begin(); // line 80 in above stack trace.
connection = ds.getConnection();

runclient-common:
[echo] Executing appclient at /export/hudson/workspace/sherry-ejbdbg-oracle/appserver-sqe/pe/ejb/ejb30/txpropagation
[echo] Dec 5, 2010 9:18:16 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[echo] WARNING: ACC013: The -password option is deprecated and will likely be removed in a future release. Please use -passwordfile or let the app client container prompt for the username and/or password if they are needed to access a remote resource.
[echo] Dec 5, 2010 9:18:18 PM com.sun.logging.LogDomains$1 log
[echo] WARNING: ACC001: Using the only client [ejb30-txpropagation-client] with main class [ejb30.txpropagation.client.TestClient] in file:/export/hudson/workspace/sherry-ejbdbg-oracle/appserver-sqe/build/pe/i386_apg-sqe1_Linux/ejb30-txpropagation/archive/ejb30-txpropagationAppClient.jar even though it does not match the specified main class name null or client name ejb30-txpropagationClient
[echo] Dec 5, 2010 9:18:18 PM com.sun.logging.LogDomains$1 log
[echo] INFO: DTX5019: Using [com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate] as the delegate
[echo] WS HOME appserver-sqe
[echo] testSuiteID=EJB3-TXPropagation_AC_sql_nodsd
[echo] name=mary
[echo] AppClient
[echo] after SC lookup ejb or AC: sful=ejb30.txpropagation._Sful_Wrapper@424288a4
[echo] Dec 5, 2010 9:18:32 PM org.hibernate.validator.util.Version <clinit>
[echo] INFO: Hibernate Validator 4.1.0.Final
[echo] Dec 5, 2010 9:18:32 PM org.hibernate.validator.engine.resolver.DefaultTraversableResolver detectJPA
[echo] INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
[echo] ds=com.sun.gjc.spi.jdbc40.DataSource40@129efd0
[echo] Dec 5, 2010 9:18:33 PM com.sun.logging.LogDomains$1 log
[echo] WARNING: RAR5038:Unexpected exception while creating resource for pool pooltxp. Exception : javax.resource.spi.ResourceAllocationException: Connection could not be allocated because: OAUTH marshaling failure
[echo] Dec 5, 2010 9:18:33 PM com.sun.logging.LogDomains$1 log
[echo] WARNING: RAR5117 : Failed to obtain/create connection from connection pool [ pooltxp ]. Reason : com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: OAUTH marshaling failure
[echo] Dec 5, 2010 9:18:33 PM com.sun.logging.LogDomains$1 log
[echo] WARNING: jdbc.exc_get_conn
[echo] java.sql.SQLException: Error in allocating a connection. Cause: Connection could not be allocated because: OAUTH marshaling failure
[echo] at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:117)
[echo] at ejb30.txpropagation.client.TestClient.doTest(TestClient.java:81)
[echo] at ejb30.txpropagation.client.TestClient.main(TestClient.java:34)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[echo] at java.lang.reflect.Method.invoke(Method.java:597)
[echo] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:432)
[echo] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[echo] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[echo] Caused by: javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: Connection could not be allocated because: OAUTH marshaling failure
[echo] at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:310)
[echo] at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:190)
[echo] at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
[echo] at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
[echo] at com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:110)
[echo] ... 9 more
[echo] Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: OAUTH marshaling failure
[echo] at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:103)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.addResource(ConnectionPool.java:282)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.createResourceAndAddToPool(ConnectionPool.java:1497)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.createResources(ConnectionPool.java:940)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.initPool(ConnectionPool.java:230)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:511)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
[echo] at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:242)
[echo] at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:167)
[echo] at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:335)
[echo] at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:304)
[echo] ... 13 more
[echo] Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: OAUTH marshaling failure
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:920)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1181)
[echo] at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
[echo] ... 23 more
[echo] Caused by: com.sun.appserv.connectors.internal.api.PoolingException: Connection could not be allocated because: OAUTH marshaling failure
[echo] at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:168)
[echo] at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:903)
[echo] ... 25 more
[echo] Caused by: javax.resource.spi.ResourceAllocationException: Connection could not be allocated because: OAUTH marshaling failure
[echo] at com.sun.gjc.spi.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:128)
[echo] at com.sun.enterprise.resource.allocator.ConnectorAllocator.createResource(ConnectorAllocator.java:147)
[echo] ... 26 more
[echo] Caused by: java.sql.SQLException: OAUTH marshaling failure
[echo] at oracle.jdbc.driver.T4CTTIoauthenticate.doOAUTH(T4CTTIoauthenticate.java:663)
[echo] at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:359)
[echo] at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:531)
[echo] at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:221)
[echo] at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)
[echo] at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:503)
[echo] at oracle.jdbc.pool.OracleDataSource.getPhysicalConnection(OracleDataSource.java:280)
[echo] at oracle.jdbc.xa.client.OracleXADataSource.getPooledConnection(OracleXADataSource.java:466)
[echo] at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:154)
[echo] at oracle.jdbc.xa.client.OracleXADataSource.getXAConnection(OracleXADataSource.java:99)
[echo] at com.sun.gjc.spi.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:113)
[echo] ... 27 more
[echo] AppClient
[echo] after SC lookup ejb or AC: sful=ejb30.txpropagation._Sful_Wrapper@424288a4
[echo] ds=com.sun.gjc.spi.jdbc40.DataSource40@115e166
[echo] javax.transaction.NotSupportedException: Nested transaction not supported.
[echo] at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.begin(JavaEETransactionManagerSimplified.java:811)
[echo] at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.begin(JavaEETransactionManagerSimplified.java:799)
[echo] at com.sun.enterprise.transaction.UserTransactionImpl.begin(UserTransactionImpl.java:165)
[echo] at ejb30.txpropagation.client.TestClient.doTest(TestClient.java:80)
[echo] at ejb30.txpropagation.client.TestClient.main(TestClient.java:35)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[echo] at java.lang.reflect.Method.invoke(Method.java:597)
[echo] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:432)
[echo] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)

[echo] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)

Comment by sherryshen [ 06/Dec/10 ]

[regression] failed to get connection with OAUTH
marshaling failure at glassfish-3.1-b31-12_05_2010.zip

Comment by Jagadish [ 06/Dec/10 ]

Seems to be failing from 1st Dec 2010 nightly build.
Seems to be failing only in Appclient container. (Able to acquire connections from same pool/@DSD in an EJB).

Comment by Jagadish [ 07/Dec/10 ]

Further investigation reveals that this behavior is seen from 1st Dec 2010 nightly and related to the appclient script related refactoring changes that were introduced, as revoking them seems to solve the issue.

Comment by Tim Quinn [ 07/Dec/10 ]

Jagadish and I have exchanged several e-mails off-line.

I cannot reproduce this problem using out-of-the-box nightly builds.

I updated my copy of the sqe directory. I followed the steps described in 14918. In step 7 I get a naming exception (not related to the marshaling error reported here). Step 8 succeeds.

I tried with the Dec. 1 and Dec. 2 nightly builds. Same successful results both times.

But, I was able to trigger the problem by moving the sunjce_provider.jar library out of $JAVA_HOME/lib/ext on my system.

Jagadish, in your test run you had JAVA_HOME defined as

/home/jagadish/installations/jdk6

and the appclient uses JAVA_HOME for setting java.ext.dirs to include the GlassFish extension directories and the Java ones at $JAVA_HOME/lib/ext.

Can you please confirm if /home/jagadish/installations/jdk6/lib/ext exists and contains sunjce_provider.jar?

Comment by Tim Quinn [ 07/Dec/10 ]

Additional note:

I plan to change the appclient logic so that JAVA_HOME can be defined to point to either the JDK directory or the JRE directory. With this change in place you should not need to change your JAVA_HOME definition.

I would still like to hear if the test works when you (temporarily) change JAVA_HOME to point to the JRE directory.

Comment by Jagadish [ 07/Dec/10 ]

Transferring to Tim who takes care of ACC. Tim has started investigating the issue.

Comment by Tim Quinn [ 07/Dec/10 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 43549
Author: tjquinn
Date: 2010-12-07 22:59:40 UTC
Link:

Log Message:
------------
Improve and clean up choice of which Java to use, and of finding the JRE home.

Tests: QL, deployment devtests

Revisions:
----------
43549

Modified Paths:
---------------
trunk/v3/appclient/client/acc/src/test/java/org/glassfish/appclient/client/CLIBootstrapTest.java
trunk/v3/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java
trunk/v3/appclient/client/appclient-scripts/src/main/resources/glassfish/bin/appclient.bat

Comment by Jagadish [ 07/Dec/10 ]

Tim :
Sorry, I did not see that you have asked to confirm that pointing to JRE solves the issue.
[somehow emails on issue updates are not delivered]

Yes, I tried pointing to JRE and it solves the issue.





[GLASSFISH-14922] After enable-secure-admin Admin GUI won't run Created: 01/Dec/10  Updated: 03/Jan/11  Resolved: 21/Dec/10

Status: Resolved
Project: glassfish
Component/s: admin_gui
Affects Version/s: None
Fix Version/s: 3.1_b33

Type: Bug Priority: Blocker
Reporter: Byron Nevins Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-14899 Admin Console does not come up after ... Closed

 Description   

Perhaps I'm doing something wrong? Or it has been fixed already - my build is a couple days old.

Here are the steps to reproduce

asadmin delete-domain
asadmin create-domain (take the defaults)
asadmin start-domain
asadmin enable-secure-admin
asadmin restart-domain
asadmin restart-domain (sub bug The first time I accepted the SSL cert and it never called restart!)

go to a browser with https://localhost:4848
== or == use the hostname instead of localhost

same result in either case: KABOOM

[#|2010-12-01T11:48:49.836-0800|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=189;_ThreadName=
admin-thread-pool-4848(4);|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:160)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:11
71)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1298)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1180)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: N
o name matching localhost found
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:611)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:174)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:197)
... 50 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching localhost found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1206)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more
Caused by: java.security.cert.CertificateException: No name matching localhost found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
... 71 more

#]

[#|2010-12-01T11:48:59.976-0800|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=35;_ThreadName=a
dmin-thread-pool-4848(1);|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:160)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:11
71)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1298)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1180)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: N
o name matching localhost found
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:611)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:174)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:197)
... 50 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching localhost found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1206)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more
Caused by: java.security.cert.CertificateException: No name matching localhost found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
... 71 more

#]

[#|2010-12-01T11:54:42.023-0800|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=189;_ThreadName=
admin-thread-pool-4848(4);|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:160)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:11
71)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1298)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1180)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: N
o name matching localhost found
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:611)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:174)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:197)
... 50 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching localhost found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1206)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more
Caused by: java.security.cert.CertificateException: No name matching localhost found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
... 71 more

#]

[#|2010-12-01T11:54:47.133-0800|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=188;_ThreadName=
admin-thread-pool-4848(3);|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:160)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:11
71)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1298)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1180)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: N
o name matching localhost found
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:611)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:174)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:197)
... 50 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching localhost found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1206)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more
Caused by: java.security.cert.CertificateException: No name matching localhost found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
... 71 more

#]

[#|2010-12-01T11:54:52.211-0800|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=138;_ThreadName=
admin-thread-pool-4848(2);|ApplicationDispatcher[] PWC1231: Servlet.service() for servlet FacesServlet threw exception
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event1'.
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:422)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.beforeCreate(LayoutComponent.java:348)
at com.sun.jsftemplating.layout.descriptors.LayoutComponent.getChild(LayoutComponent.java:288)
at com.sun.jsftemplating.layout.LayoutViewHandler.buildUIComponentTree(LayoutViewHandler.java:556)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:255)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:244)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:395)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.glassfish.admingui.common.security.AdminConsoleAuthModule.validateRequest(AdminConsoleAuthModule.java:160)
at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFServerAuthContext.validateRequest(GFServerConfigProvider.java:11
71)
at com.sun.web.security.RealmAdapter.validate(RealmAdapter.java:1298)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1180)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
... 44 more
Caused by: com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: N
o name matching localhost found
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:131)
at com.sun.jersey.api.client.Client.handle(Client.java:629)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:601)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.get(WebResource.java:459)
at org.glassfish.admingui.common.util.RestUtil.get(RestUtil.java:611)
at org.glassfish.admingui.common.util.RestUtil.restRequest(RestUtil.java:174)
at org.glassfish.admingui.common.handlers.RestApiHandlers.restRequest(RestApiHandlers.java:197)
... 50 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching localhost found
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1649)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:241)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:235)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1206)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:136)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:893)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:217)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:129)
... 57 more
Caused by: java.security.cert.CertificateException: No name matching localhost found
at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210)
at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:264)
at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:250)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1185)
... 71 more

#]


 Comments   
Comment by Byron Nevins [ 01/Dec/10 ]

Next Steps:

asadmin disable-secure-admin
asadmin restart-domain

go to browser with http://my-host-name:4848

Admin Console came up just fine.

Comment by Tom Mueller [ 01/Dec/10 ]

Are you using JDK 1.6.0_22?

Without that version, secure admin is known not to work with the symptom that the first restart-domain hangs.

Comment by Byron Nevins [ 01/Dec/10 ]

Bumping up the priority since Tim has verified that it is real.

Comment by Tom Mueller [ 01/Dec/10 ]

This appears to be a problem with running with an older JVM.

Perhaps the enable-secure-admin command should verify that it is on a appropriate JVM before making the configuration change. This doesn't guarantee that it will be on that JVM the next time the domain is started, but it would catch most of the cases.

Comment by Byron Nevins [ 01/Dec/10 ]

i ran into this problem using u22 – I updated a week or two ago because of secure-admin

C:\gf_other\value-add\monitoring\scripting>java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

Comment by Tim Quinn [ 01/Dec/10 ]

I am reassigning this to the admin GUI but I will work with Anissa to help resolve this.

I do not think this is an inherent problem in secure admin because I can access

https://localhost:4848/__asadmin/uptime

from a browser successfully. So the basic secure admin functionality is working.

Mitesh encountered a similar problem getting REST to work from inside the DAS to an instance; REST also uses Jersey. The problem is that the default host name verifier which Jersey uses does not recognize localhost. Mitesh resolved this by telling Jersey to use an alternate host name verifier that we provide.

The admin console will need to do the same thing.

Comment by Anissa Lam [ 02/Dec/10 ]

Byron said:
"Or it has been fixed already - my build is a couple days old. "

Thats probably why.
As long as you are using 1.6.0_22, GUI comes up fine when secure admin enabled.
So far, between Tim, Mitesh, Ludo, myself, we have tested this on Mac and Window and we cannot reproduce the problem listed here.
Closing as works for me.
You can try this with today (12/02) nightly build. (Do not use promoted build 31, there will be an exception when you first try to start GUI, although that still didn't prevent you to bring up GUI. Just want to avoid the confusion).

Please reopen and specify exactly which version you are using if you still see the issue.

Comment by Kim Haase [ 21/Dec/10 ]

I am having this problem using

Solaris 10
JDK 1.6.0_22
GF promoted b33

Comment by Kim Haase [ 21/Dec/10 ]

Having problem on Solaris 10 with JDK 1.6.0_22 and GF b33 after enable-secure-admin.

Is there an Admin Console equivalent for the enable-secure-admin command or can this function be performed only from the command line?

Comment by Tim Quinn [ 21/Dec/10 ]

What happens if you stop and start the domain i separate steps instead of using restart-domain in a single step? Do you see any difference?

Comment by Kim Haase [ 21/Dec/10 ]

I have been running two separate commands (stop-domain and start-domain).

On b34, instead of a totally blank window, I get certificate errors; if I add an exception for localhost:4848 I cannot access the Admin Console at all (I keep getting Page Load Errors). But if I add the exception for <mysystemname>:4848 the Admin Console comes up.

Is this expected behavior??? Or is someone trying to fix this so that localhost:4848 works?

Comment by Tim Quinn [ 21/Dec/10 ]

I downloaded nightly b34 dated Dec. 20.

I ran

asadmin start-domain
asadmin enable-secure-admin
asadmin stop-domain
asadmin start-domain

I was able to start the admin console successfully using both localhost and my host's actual name. Both times, as you mentioned, I was prompted and I added the exception through the browser. My browser, by the way, is Firefox 3.6.12.

So I did not see the problem you referred to.

Comment by Anissa Lam [ 21/Dec/10 ]

I just downloaded today's build 12/21/2010 and tested this as well.
I can get to console by specifying either localhost:4848 and hostname:4848.
As like expected, both time, I need to accept the cert.
I don't see any issue.
Also, regardless how i start it first, I can switch between using localhost and hostname without any problem.

Closing this as Fixed, which was the previous resolution before Kim reopen.

Comment by Ramon Rockx [ 03/Jan/11 ]

I was having the same problems.
For me did modifying restAuthURL from "https://localhost:$

{ADMIN_LISTENER_PORT}/management/sessions" to "https://<hostname>:${ADMIN_LISTENER_PORT}

/management/sessions" the trick. After that, I could access the console succesfully.
This property can be set using "set server.security-service.message-security-config.HttpServlet.provider-config.GFConsoleAuthModule.property.restAuthURL.





[GLASSFISH-14679] Win 2008. The filename, directory name, or volume label syntax is incorrect Created: 12/Nov/10  Updated: 13/Dec/10  Resolved: 13/Dec/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1
Fix Version/s: 3.1_b33

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

Operating System: Windows (generic)
Platform: All


Attachments: File patch_14679.diff    
Issuezilla Id: 14,679

 Description   

Win 2008. Build 30, 11/12. Created a cluster with two instances on the
loacalhost: my-in1, my-in2.

In a loop first deployed an webapps-caching1.war with a name temp:1 to the
cluster, then list-application-refs, enable temp:1

Then did the same steps for temp:2 and webapps-caching2.war. (The difference
between webapps-caching1.war and webapps-caching2.war - on a first page for
first app - Version1, for second Version2: <h4>Delivery Mechanism Version1</h4>
<h4>Delivery Mechanism Version2</h4>)

For the temp:1/webapps-cahing1.war all actions were executed without any
issues.

But during the deployment of webapps-cahing2.war with a name temp:2 to the
second instance my-in2, was seen a problem:

=========================================================

Application deployed with name temp:2.
WARNING : Command _deploy did not complete successfully on server instance my-
in2 : org.glassfish.api.admin.CommandException: remote failure: Failed to load
the application on instance my-in2. The application will not run properly.
Please fix your application and redeploy.

Exception while deploying the app [temp:2]. Please see server.log for more
details.

Application [] contains no valid components
Command deploy completed with warnings.
Application reference temp:1 already exists in target server.
Command create-application-ref executed successfully.
org.glassfish.api.admin.CommandException: remote failure: An error occurred
during replication
Command disable failed on server instance my-in2 :
org.glassfish.api.admin.CommandException: remote failure: Application with name
[temp:2] is not deployed
Command disable failed.
temp:1 (disabled)
temp:2 (disabled)
Command list-application-refs executed successfully.
org.glassfish.api.admin.CommandException: remote failure: An error occurred
during replication
Command enable failed on server instance my-in2 :
org.glassfish.api.admin.CommandException: remote failure: Application with name
[temp:2] is not deployed
Command enable failed.

=========================================

In my-in1 the application was deployed without any issues. In my-in2 server.log
were seen such messages:
===============================================
[#|2010-11-12T16:06:15.713-
0800|INFO|glassfish3.1|null|_ThreadID=17;_ThreadName=Thread-1;|Installed
C:\hudson\workspace\deployment\glassfish3\glassfish\modules\autostart\org.apache
.felix.webconsole.internal.servlet.OsgiManager.cfg|#]

[#|2010-11-12T16:06:19.958-
0800|SEVERE|glassfish3.1|javax.enterprise.system.util.com.sun.enterprise.util.io

_ThreadID=17;_ThreadName=Thread-1; UTIL6549: Some IOException occurred
java.io.IOException: The filename, directory name, or volume label syntax is
incorrect
at java.io.WinNTFileSystem.canonicalize0(Native Method)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:396)
at java.io.File.getCanonicalPath(File.java:559)
at java.io.File.getCanonicalFile(File.java:583)
at com.sun.enterprise.util.io.FileUtils.whack(FileUtils.java:420)
at com.sun.enterprise.util.io.FileUtils.whack(FileUtils.java:400)
at
org.glassfish.deployment.admin.InstanceDeployCommand.execute(InstanceDeployComma
nd.java:162)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:3
54)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:3
69)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1
061)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java
:95)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRu
nnerImpl.java:1257)
at
com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRu
nnerImpl.java:1246)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:396)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:216)
at
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at
com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java
:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:22
5)
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:53
2)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
#]

[#|2010-11-12T16:06:20.564-
0800|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.
security|_ThreadID=17;_ThreadName=Thread-1;|SEC1002: Security Manager is OFF.|#]
====================================================

I've reproduced this issue every time. I did not see this issue on other
platforms.



 Comments   
Comment by Hong Zhang [ 13/Nov/10 ]

assign to romain to take a look

Comment by easarina [ 16/Nov/10 ]

Executed the tests on another Win 2008 machine. This issue was seent on
another machine also.

Comment by Romain Grécourt [ 29/Nov/10 ]

reassign to Herve

Comment by easarina [ 29/Nov/10 ]

Saw this issue for b 31 also.

Comment by herve_souchaud [ 07/Dec/10 ]

Hi easarina,

Could you please attach the test script and the war files ?
I made a modification in InstanceDeployCommand, and now there isn't any error in the in2's server.log. But in the console, no command fails, with nor without my modification, so I am not really sure I correctly fixed this issue.

Comment by easarina [ 07/Dec/10 ]

Do you have an access to CVS, if so I can explain how to checkout the script. Or you can give me a patch and I will verify it.

Thank you,

Elena

Comment by herve_souchaud [ 08/Dec/10 ]

Here is a diff file showing the modifications I did trying to resolve this issue.

Comment by Hong Zhang [ 13/Dec/10 ]

Checked in Herve's patch (seems it should address the issue) and mark the issue fixed.





[GLASSFISH-12954] IndexOutOfBoundsException when persisting timer Created: 11/Aug/10  Updated: 17/Dec/10  Resolved: 17/Dec/10

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 3.1
Fix Version/s: 3.1_b33

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

Operating System: Windows 7
Platform: PC


Attachments: Java Archive File DummyEJB.jar     Zip Archive DummyEJB.zip    
Issuezilla Id: 12,954

 Description   

Please refer to the following forum post for more details:

http://forums.java.net/jive/thread.jspa?messageID=477843

I know that this worked in GF 2. I tried this on GF 3.0.1 and the promoted build
3.1-b13.



 Comments   
Comment by thoedorrichard [ 11/Aug/10 ]

I just tried to manually merge (instead of letting the transaction do it) the
entity that contains the TimerHandle and got the following exception:

WARNING: A system exception occurred during an invocation on EJB
NotificationManager method public void
com.acme.enterpriseapp.notification.NotificationManager.manageNotification(long)
javax.ejb.EJBTransactionRolledbackException
at
com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2277
)
at
com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2077)
at
com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvo
cationHandler.java:199)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalOb
jectInvocationHandlerDelegate.java:84)
at $Proxy128.edit(Unknown Source)
at
com.acme.enterpriseapp.domain.dao._EJB31_GeneratedAlertDaoIntf__Bean_.ed
it(Unknown Source)
at
com.acme.enterpriseapp.notification.NotificationManager.handleAlert(Notification
Manager.java:125)
at
com.acme.enterpriseapp.notification.NotificationManager.manageNotification(Notif
icationManager.java:70)
at
com.acme.enterpriseapp.notification.NotificationManager.manageNotification(Notif
icationManager.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityM
anager.java:1048)
at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityMana
ger.java:1120)
at
com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5331)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(Interceptor
Manager.java:797)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterc
eptorProxy.java:158)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemIn
terceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(Intercepto
rManager.java:858)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(Interceptor
Manager.java:797)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorMana
ger.java:367)
at
com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5303)
at
com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5291)
at com.sun.ejb.containers.EjbAsyncTask.call(EjbAsyncTask.java:97)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:8
86)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.TransactionRolledbackLocalException: Exception thrown from
bean
at
com.sun.ejb.containers.BaseContainer.checkExceptionClientTx(BaseContainer.java:5
014)
at
com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4849)
at
com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2028)
... 34 more
Caused by: Exception [EclipseLink-6168] (Eclipse Persistence Services -
2.1.0.v20100614-r7608): org.eclipse.persistence.exceptions.QueryException
Exception Description: Query failed to prepare, unexpected error occurred:
[java.lang.NullPointerException].
Internal Exception: java.lang.NullPointerException
Query: ReadObjectQuery(referenceClass=TimerHandleImpl )
at
org.eclipse.persistence.exceptions.QueryException.prepareFailed(QueryException.j
ava:1528)
at
org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:52
1)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.checkPrepare(ObjectLevelRea
dQuery.java:818)
at
org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:47
0)
at
org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:706)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuer
y.java:1034)
at
org.eclipse.persistence.queries.ReadObjectQuery.execute(ReadObjectQuery.java:407
)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectL
evelReadQuery.java:1112)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(Un
itOfWorkImpl.java:2909)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractS
ession.java:1291)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractS
ession.java:1273)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractS
ession.java:1233)
at
org.eclipse.persistence.internal.sessions.AbstractSession.readObject(AbstractSes
sion.java:2825)
at
org.eclipse.persistence.internal.sessions.MergeManager.registerObjectForMergeClo
neIntoWorkingCopy(MergeManager.java:829)
at
org.eclipse.persistence.internal.sessions.MergeManager.getTargetVersionOfSourceO
bject(MergeManager.java:194)
at
org.eclipse.persistence.mappings.ObjectReferenceMapping.mergeIntoObject(ObjectRe
ferenceMapping.java:420)
at
org.eclipse.persistence.internal.descriptors.ObjectBuilder.mergeIntoObject(Objec
tBuilder.java:3090)
at
org.eclipse.persistence.internal.sessions.MergeManager.mergeChangesOfCloneIntoWo
rkingCopy(MergeManager.java:489)
at
org.eclipse.persistence.internal.sessions.MergeManager.mergeChanges(MergeManager
.java:250)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.mergeCloneWithReference
s(UnitOfWorkImpl.java:3534)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.mergeCloneWi
thReferences(RepeatableWriteUnitOfWork.java:300)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.mergeCloneWithReference
s(UnitOfWorkImpl.java:3494)
at
org.eclipse.persistence.internal.jpa.EntityManagerImpl.mergeInternal(EntityManag
erImpl.java:430)
at
org.eclipse.persistence.internal.jpa.EntityManagerImpl.merge(EntityManagerImpl.j
ava:407)
at
com.sun.enterprise.container.common.impl.EntityManagerWrapper.merge(EntityManage
rWrapper.java:276)
at
com.acme.enterpriseapp.domain.dao.AbstractDao.edit(AbstractDao.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityM
anager.java:1048)
at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityMana
ger.java:1120)
at
com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5331)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(Interceptor
Manager.java:797)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterc
eptorProxy.java:158)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemIn
terceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav
a:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(Intercepto
rManager.java:858)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(Interceptor
Manager.java:797)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorMana
ger.java:367)
at
com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5303)
at
com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5291)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvo
cationHandler.java:191)
... 32 more
Caused by: java.lang.NullPointerException
at
org.eclipse.persistence.queries.ReadObjectQuery.prepare(ReadObjectQuery.java:634
)
at
org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:50
9)
... 77 more

For some reason, the TimerHandleImpl cannot be persisted.

Comment by marina vatkina [ 11/Aug/10 ]

Is there a known issue in EclipseLink that causes NPE?

Comment by thoedorrichard [ 12/Aug/10 ]

Created an attachment (id=4676)
Test case to reproduce the problem (NetBeans project)

Comment by thoedorrichard [ 12/Aug/10 ]

Created an attachment (id=4677)
Test case to reproduce the problem (ear file)

Comment by thoedorrichard [ 27/Aug/10 ]

Marina, can you reproduce the issue after the provided test case and the discussions in the mailing list?

Comment by Mitesh Meswani [ 03/Sep/10 ]

Hi thoedorrichard,

EclipseLink is defaulting TimerHandle(an interface) to a VariableOneToOne mapping. This
is a bug with EclipseLink(https://bugs.eclipse.org/bugs/show_bug.cgi?id=324471). Please
explicitly annotate the field with @Lob to workaround as shown below


@Entity
public class NewEntity implements Serializable {
private static final long serialVersionUID = 1L;
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;

@Lob
private TimerHandle timerHandle;


Downgrading to P3 as there is a easy workaround.

Comment by Mitesh Meswani [ 05/Oct/10 ]

Targeting MS07

Comment by Mitesh Meswani [ 17/Dec/10 ]

Fixed with current integration of EclipseLink 2.2-M6





[GLASSFISH-4065] Connector configuration lookup not multithread safe Created: 02/Feb/08  Updated: 10/Dec/10  Resolved: 10/Dec/10

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 9.1peur1
Fix Version/s: 9.2, 3.1_b33

Type: Bug Priority: Minor
Reporter: gfuser9999 Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,065

 Description   

Product: AS8.1, AS8.2 , AS9.x, GFv2ur1 (AS911)
OS: Not relevant

Description
------------
Trying to use a standalone client that does a
lookup to a JMS pool fails. This is
like continuation to
https://glassfish.dev.java.net/issues/show_bug.cgi?id=2672
since there is some other parts of the AS8/AS9 common
subsystem that is not multithread safe.

IN short,
Concurrent lookup of
lookup(jmspool) on Thread-1
lookup(jmspool) on Thread-2
may cause problems.

Symptom/Testcase
--------

1. Create a JMS pool with (MUST be this)

<connector-connection-pool associate-with-thread="false" connection-creation
-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connectio
n-definition-name="javax.jms.TopicConnectionFactory" connection-leak-reclaim="fa
lse" connection-leak-timeout-in-seconds="0" fail-all-connections="false" idle-ti
meout-in-seconds="300" is-connection-validation-required="false" lazy-connection
-association="false" lazy-connection-enlistment="false" match-connections="true"
max-connection-usage-count="0" max-pool-size="8" max-wait-time-in-millis="60000
" name="jms/topicpool" pool-resize-quantity="2" resource-adapter-name="jmsra" st
eady-pool-size="1" validate-atmost-once-period-in-seconds="0">
<property name="Password" value="admin"/>
<property name="ReconnectEnabled" value="true"/>
<property name="AddressListBehavior" value="RANDOM"/>
<property name="UserName" value="admin"/>
<property name="ReconnectInterval" value="60000"/>
<property name="AddressList" value="mq://localhost:7676/,"/>
<property name="ReconnectAttempts" value="3"/>
<property name="AddressListIterations" value="3"/>
<property name="AddressListIterations" value="3"/>
</connector-connection-pool>

2. Run the same program

import javax.naming.*;
import java.util.*;

public class genlook extends Thread
{
static String host="localhost";
static String port="3700";
static String name="jms/topicpool";

public void run()
{
try

{ Hashtable props = new Hashtable(); props.put("javax.rmi.CORBA.UtilClass", "com.sun.corba.ee.impl.javax.rmi.CORBA.Util"); props.put("org.omg.CORBA.ORBClass", "com.sun.corba.ee.impl.orb.ORBImpl"); props.put("org.omg.CORBA.ORBSingletonClass", "com.sun.corba.ee.impl.orb.ORBSingleton"); props.put("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); props.put("java.naming.factory.url.pkgs","com.sun.enterprise.naming"); props.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); props.put("org.omg.CORBA.ORBInitialHost", host); props.put("org.omg.CORBA.ORBInitialPort", port); props.put(Context.PROVIDER_URL,"iiop://"+host+":"+port); Context c = new InitialContext(props); c.lookup(name); }

catch (NamingException e)

{ throw new RuntimeException(e); }

}

public static void main(String args[]) throws InterruptedException

{ if (args.length>0) host=args[0]; if (args.length>1) port=args[1]; if (args.length>2) name=args[2]; Thread t1 = new genlook(), t2 = new genlook); t1.start(); t2.start(); t2.join(); t2.join(); }

}

3. Run this (as a few times if needed). You may get this

Caused by: javax.naming.CommunicationException: serial context communication ex
[Root exception is com.sun.enterprise.connectors.ConnectorRuntimeException:
Failed to create MCF]
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:427)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at genlook.run(genlook.java:30)
Caused by: com.sun.enterprise.connectors.ConnectorRuntimeException: Failed to
create MCF
at
com.sun.enterprise.naming.factory.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:116)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
... 2 more

Cause of failure
-----------------
It seems that "com.sun.enterprise.connectors.util.SetMethodAction"
uses com.sun.enterprise.deployment.EnvironmentProperty
and this "EnvironmentProperty.setBoundsChecking(true|false)"
is called every now and then.

The problem is that for the above ManagedConnectionFactory
that take in primitive variable may trigger
"setBoundsChecking(false)" and some thread will call
"setBoundsChecking(true)". The effect is then that
if there is multiple threads trying to lookup
the same pool, the above too make cause the following

java.lang.IllegalArgumentException: Illegal type for environment properties: [nu
ll]
at com.sun.enterprise.deployment.EnvironmentProperty.getObjectFromString
(EnvironmentProperty.java:255)
at com.sun.enterprise.deployment.EnvironmentProperty.getValueObject(Envi
ronmentProperty.java:142)
at com.sun.enterprise.connectors.util.SetMethodAction.run(SetMethodActio
n.java:94)
at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.createMan
agedConnectionFactory(ActiveOutboundResourceAdapter.java:290)
at com.sun.enterprise.connectors.ActiveInboundResourceAdapter.createMana
gedConnectionFactory(ActiveInboundResourceAdapter.java:320)

  • The cause being "EnvironmentProperty" is not a thread safe function
    so that means SetMethodAction is not threadsafe too.


 Comments   
Comment by km [ 10/Feb/08 ]

Redirecting appropriately.

Comment by Jagadish [ 11/Feb/08 ]

I do not see the method call
"at com.sun.enterprise.deployment.EnvironmentProperty.getValueObject(Envi
ronmentProperty.java:142)" from SetMethodAction any time during 9.x

https://glassfish.dev.java.net/source/browse/glassfish/appserv-core/src/java/com/sun/enterprise/connectors/util/SetMethodAction.java?annotate=1.9
does not have a call to getValueObject.

Somehow EnvironmentProperty's type is null. Will investigate further.

Comment by Jagadish [ 21/Feb/08 ]

Transferring this to Hong for further investigation as making
EnvironmentProperty's isBoundsChecking() & setBoundsChecking along with some
minor changes makes it thread safe

Comment by Jagadish [ 21/Feb/08 ]

Corrected Text :
Setting EnvironmentProperty's isBoundsChecking() & setBoundsChecking as
synchronized, along with some minor changes makes it thread safe

Comment by Hong Zhang [ 21/Feb/08 ]

Jagadish, thanks for your investigation on this.

Comment by Hong Zhang [ 21/Feb/08 ]

move under deployment

Comment by harpreet [ 25/Mar/08 ]

Per recommendation of Hong - marking for 9.2.

Comment by sanandal [ 11/Jan/09 ]

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

Comment by Hong Zhang [ 10/Dec/10 ]

I have made the suggested changes by Jagadish in the deployment code to make the boundsChecking thread safe now.





Generated at Sat May 23 01:34:31 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.