[JAVASERVERFACES-3246] default-locale is not used for resolving texts of resource bundles Created: 17/Apr/14  Updated: 30/Jan/15  Resolved: 09/Jan/15

Status: Closed
Project: javaserverfaces
Component/s: configuration
Affects Version/s: 2.1.26, 2.1.28
Fix Version/s: 2.1.29-01

Type: Bug Priority: Minor
Reporter: lutzulrich Assignee: ren.zhijun.oracle
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Text File changebundle.txt     Text File changebundle.txt     File mojarra-default-locale.war     Java Source File MultiViewHandler.java     Zip Archive newfiles.zip    
Tags: 3_1-approved, 3_1-verified, newtestcase

 Description   

Excerpt from faces-config.xml:

<locale-config>
<default-locale>en</default-locale>
<supported-locale>de</supported-locale>
</locale-config>

But the Default locale 'en' seems to be ignored.
If there is some resource bundle with an English and German variant, the resolved texts are always German, no matter what the preferred locale of the HTTP request is.

The Problem can be resolved by adding a <supported-locale> element for the default locale.

There seems to be no such bug in 2.2.6.



 Comments   
Comment by Manfred Riem [ 17/Apr/14 ]

Please send a reproducer to issues@javaserverfaces.java.net. Thanks!

Comment by ren.zhijun.oracle [ 27/Jun/14 ]

Hi lutzulrich,

I tried to reproduce this issue in both glassfish 3.1.2 and glassfish 4, but the behaviours are both correct and aligned with the jsf spec.

In glassfish 3.1.2, I replaced javax.faces.jar with the javax.faces-2.1.28.jar which provided by the bug filer and the behaviour is still correct.

Can you help to provide the detailed reproducing steps?

My test results are:

precondition:
faces-config.xml includes locales: (the default locale can changed in case 2)
<default-locale>de</default-locale>
<supported-locale>en</supported-locale>
<supported-locale>fr</supported-locale>

1. when client browser's locale was set to one of 'de' or 'en' or 'fr', the final display string is determined by the client browser's locale;

2. when client browser's local was set to a different locale such as 'ar' which is not in set of locales supported by jsf, the final display string is determined by the default-locale in faces-config.xml

I will ask the filer to provide the exact reproduce steps.

Comment by ren.zhijun.oracle [ 27/Jun/14 ]

also please confirm your jar file javax.faces-2.1.28.jar is correct one for the reproducing.

Comment by lutzulrich [ 27/Jun/14 ]

I did use the original java.faces-2.1.28.jar as downloaded via maven.
You may binary-compare the JAR which is included in my mojarra-default-locale.war with the official one.

Nevertheless, now I tried glassfish 4 and there is no problem.
Seems to be a problem with Tomcat 7.

Makes me wonder why the problem doesn't show up with Tomcat 7 and java.faces-2.2.6.jar, too.

Or maybe the problem is related to the JVM.
I am new to glassfish and I just installed it, so I do not know which JVM it uses.
Could differ from the JVM my Tomcat uses.

So at least, there is probably a difference in java.faces-2.1.28 and 2.2.6 and you could solve the problem in 2.1.x, too.
But since it is a minor problem, it is alright to me not do anything about it in 2.1.x.

Comment by ren.zhijun.oracle [ 27/Jun/14 ]

you mean you can reproduce the problem in Tomcat 7 with java.faces-2.1.28?

Comment by lutzulrich [ 27/Jun/14 ]

Yes, Tomcat 7.0.53 and a JRE of JDK 1.7.0_05.
The JRE is a bit outdated of course. But since I never discovered any error which seemed to be related to the JRE, I never cared to change it.

Comment by ren.zhijun.oracle [ 28/Jun/14 ]

I just tested with Tomcat7.54 with the file e java.faces-2.1.28.jar you provided and didn't reproduce it.

Comment by ren.zhijun.oracle [ 30/Jun/14 ]

Hi lutzulrich,

Regarding that I can't reproduce the bug in Tomcat with the same jar file you provided, so I don't think the issue you met is related to the jsf, do you think so?

if yes, can I close it?

BR,
Zhijun

Comment by lutzulrich [ 30/Jun/14 ]

As I mentioned above, I do not actually care if the issue is resolved in 2.1.x.

Nevertheless, I am not sure the problem's source is located outside JSF.
I understand your approach of trying to reproduce errors first.

But inspecting the code of 2.1.28 one can see:

  • in com.sun.faces.application.ApplicationImpl: defaultLocale and supportedLocales are kept separatly; the Iterator returned by getSupportedLocales() does not cover the defaultLocale
  • in com.sun.faces.application.view.FaceletViewHandlingStrategy.createView(FacesContext,String), the Locale for the new UIViewRoot is determined via ViewHandler.calculateLocale(FacesContext)
  • com.sun.faces.application.view.MultiViewHandler.calculateLocale(FacesContext) calls calculateLocaleWithLanguageTag(FacesContext), which takes into account the supportedLocales() of the Application, but not the defaultLocale
  • in com.sun.faces.taglib.jsf_core.LoadBundleTag.doStartTab() UIViewRoot.getLocale() is used

Thus, as far as I see things, in 2.1.28 the Locale of UIViewRoot is one of the Application's supportedLocales (which excludes the Application's defaultLocale).
And if UIViewRoot's Locale is used to determine any string resource, the defaultLocale will not be taken into account.

Also note that for reproducing the issue:
I always tested with a preferred browser locale and secondary preferred locales.
So, if the default-locale of the JSF application is 'en' and the supported localues of the JSF application are 'de' and 'fr' (but not 'en'),
and the preferred locales of the browser are 'en' (preferred choice) followed by 'de' or 'fr' (so the 'Accept-Language' header contains 'en,de' or 'en,fr'),
Mojarra will choose 'de' (or 'fr') instead of 'en', because 'en' is not an element of supportedLocales.

Aside from that note, I cannot tell why we cannot always reproduce the problem.
But from experience I can tell, that you cannot always reproduce all problems.
For example, when Maps are used and one iterates over the Map.Entry objects, the order of them depends on hashcodes, as long as you don't decide to use a LinkedHashMap or the like.
If anything depends on the order of Map.Entry objects, one never knows what's going to happen at runtime.

Also note that have been changes in Java 1.7 related to Locale stuff, see https://bugs.openjdk.java.net/browse/JDK-7073906, for example.
So reproducing the issue may be a matter of the Java version as well.
And if there are official Java changes in methods which are used, an application or library should be capable of dealing with different behavior in different Java versions.

Comment by ren.zhijun.oracle [ 30/Jun/14 ]

Hi lutzulrich,

Just as you said, I tested in Tomcat7.54 with the file java.faces-2.1.28.jar and can reproduce what you said when browser has 2 locales.

Mojarra locale:
<default-locale>en</default-locale>
<supported-locale>fr</supported-locale>
<supported-locale>de</supported-locale>

Browser locale:
English [en]
French [ fr ]

And the display locale is 'fr', not the browser first locale and not the jsf default locale.

So that is the problem you really refer to?

BR,
Zhijun

Comment by lutzulrich [ 30/Jun/14 ]

Exactly.
Sorry for all the tests you did without being able to reproduce the problem just because I didn't mention that I used other locales in the browser as well. I always have multiple locales specified in my browser. That's why I didn't get the idea that you don't.

And of course, if there is a default locale in JSF, why shouldn't it be applied if the HTTP request header signals that it should be used in the first place.

Comment by ren.zhijun.oracle [ 30/Jun/14 ]

ok, got you.

So I will fix the issue in the following days.

Comment by ren.zhijun.oracle [ 30/Jun/14 ]

but i can't reproduce in glassfish3.1.2 with the same java and the same jsf

Comment by lutzulrich [ 30/Jun/14 ]

As noted in my comment of 27/Jun I couldn't reproduce the problem with glassfish 4, too.

I cannot tell the difference. Maybe glassfish and Tomcat differ in pre-processing HTTP headers. One may strip redundant whitespace so the HTTP Header value for 'Accept-Language' differs when inspected by JSF.
Also, glassfish 4 seems to come with its own javax.faces.jar. So maybe the JSF classes of that JAR are used instead of the one in the JAR of WEB-INF/lib of the web-application. And the JSF classes integrated in glassfish may not come with the error.
Whatever the problem may be, just because one cannot reproduce it with glassfisg doesn't mean it's a bug in Tomcat.
One has to analyze the problem by debugging.
And as mentioned above, to me it seems the defaultLocale of the JSF Application is not used when determining the Locale of UIViewRoot if any other supported Locale matches one of the elements of the 'Accept-Language' header value.
I rather wonder why it works in glassfish, more than I wonder why it doesn't work in Tomcat.

Comment by ren.zhijun.oracle [ 07/Jul/14 ]

For review and approval.

Comment by Ed Burns [ 10/Jul/14 ]

I added a spec bug: JAVASERVERFACES_SPEC_PUBLIC-1288

Comment by Ed Burns [ 10/Jul/14 ]

Hello Zhijun,

I would like you to try a different approach. Also, a change like this
needs an automated regression test to be contributed along with it as
well. We have made it a bit easier to create such a test with some
maven archetypes. You'll have to look on the Internet for general
instructions on how to use maven archetypes, but for this issue, I'll
walk you through what I did to create one.

First, let's talk about the heart of your change. Your proposal
accomodates the change on the late side, when the information is
requested. I think it's better to handle it on the parsing side. When
the app starts up, the faces-config.xml files are read and the config is
populated, the locale being one of those kinds of configs.

I want you to try it this way:

8<------
Index: jsf-ri/src/main/java/com/sun/faces/config/processor/ApplicationConfigProcessor.java
===================================================================
— jsf-ri/src/main/java/com/sun/faces/config/processor/ApplicationConfigProcessor.java (revision 13412)
+++ jsf-ri/src/main/java/com/sun/faces/config/processor/ApplicationConfigProcessor.java (working copy)
@@ -305,6 +305,7 @@
addVariableResolver(associate, n);
} else if (DEFAULT_LOCALE.equals(n.getLocalName()))

{ setDefaultLocale(app, n); + addSupportedLocale(app, n); }

else if (SUPPORTED_LOCALE.equals(n.getLocalName()))

{ addSupportedLocale(app, n); }

else if (RESOURCE_BUNDLE.equals(n.getLocalName())) {
8<----------

this basically says, "if you come across a <default-locale> element,
also add it to the set of supported locales."

That way when other code asks, "is this locale supported?" the answer
will be yes if it's either <default-locale> or <supported-locale>.

Now, on to the more laborious but equally important part, the test.

We have two archetypes to make a test, one for JSF 2.1 based code
another for JSF 2.2 based code.

Here are my UNIX aliases for them.

alias mvnajt21='mvn archetype:generate -DarchetypeGroupId=com.sun.faces -DarchetypeArtifactId=faces-2.1-test-war-archetype -DarchetypeVersion=0.1 -DarchetypeCatalog=https://maven.java.net/content/repositories/releases/archetype-catalog.xml'
alias mvnajt22='mvn archetype:generate -DarchetypeGroupId=com.sun.faces -DarchetypeArtifactId=faces-2.2-test-war-archetype -DarchetypeVersion=0.2 -DarchetypeCat

Don't ask me questions about proxies! I had to get on the external
Internet to get this to work.

That said, here are the steps I took to arrive at the revised
changebundle, which I am attaching to the issue.

1. Find a place in the existing test system that is the "right" place
for this test.

In the 2.1.x tree, test/agnostic/application is a clear winner.

2. cd to that directory and run the archetype command.

mvnajt21

3. Answer as follows for the groupId, artifactId, and version questions:

com.sun.faces.test.agnostic.application
defaultLocale
2.1.30-SNAPSHOT

answer this to the package question:

com.sun.faces.test.agnostic.application.defaultLocale

4. This creates a new defaultLocale project
as a child of the test/agnostic/application multi-module pom.

5. clean up the generate pom.xml to make it look like the other poms at
the similar level in the tree. I just basically took the
test/agnostic/application/localeConfig/pom.xml as a guide.

Because this test is in the "agnostic" area, you have to remove the
beans.xml that was generated by the archetype. Also delete any other
files not relevant to this test. For example, the genearted UserBean.

6. Apply the content from the mojarra-default-locale.war to this new
project.

I didn't do this step, but basically you need to extract stuff from the
war and make it so maven puts it back in the same place in the new test.
Also you have to take the important stuff from the faces-config.xml and
web.xml in the war and replace the corresponding stuff in the generated
ones. Of course, you have to take the content from the index.xhtml and
put it in the one in the new project.

7. Finally, you have to make the HtmlUnit test exercise the war and make
assertions about its correctness. The archetype creates an HtmlUnit
testcase that gets you started with this.

I think Liang would be able to help.

I'm going to attach a new changebundle that includes the changes I made
above which you can use as a starting point and then post another
changebundle.

Comment by Ed Burns [ 10/Jul/14 ]

new approach, and including required automated test.

Comment by ren.zhijun.oracle [ 15/Jul/14 ]

Hi Ed,

Agree with your solution.

I have done steps 1 ~ 6, currently I am writing the test code for it.

I need some time for it.

Thanks,
Zhijun

Comment by Ed Burns [ 15/Jul/14 ]

Ok, thanks.

Comment by Manfred Riem [ 22/Jul/14 ]

Zhijun,

Please adjust the following:

1. Remove the <dependencies> section, everything should be inherited from the parent POM.
2. Make sure .properties are not committed as svn:executable
3. Remove unnecessary comments from the Test file (only add comments to it if you need to explain the method under test).
4. Please move addSupportedLocale(app, n); below the setDefaultLocale call

Once you have done that
r=mriem

Thanks!

Comment by ren.zhijun.oracle [ 23/Jul/14 ]

committed final content.

Comment by ren.zhijun.oracle [ 23/Jul/14 ]

all comments from Manfred have been fixed and all TCs re-runned. will commit code.

Comment by ren.zhijun.oracle [ 23/Jul/14 ]

code commited:
rzhijun-mac:MOJARRA_2_1X_ROLLING zhijun$ svn commit -m "to fix https://java.net/jira/browse/JAVASERVERFACES-3246" --username ren.zhijun.oracle
Sending jsf-ri/src/main/java/com/sun/faces/config/processor/ApplicationConfigProcessor.java
Sending jsf-ri/test/com/sun/faces/application/TestViewHandlerImpl.java
Adding test/agnostic/application/defaultLocale
Adding test/agnostic/application/defaultLocale/pom.xml
Adding test/agnostic/application/defaultLocale/src
Adding test/agnostic/application/defaultLocale/src/main
Adding test/agnostic/application/defaultLocale/src/main/java
Adding test/agnostic/application/defaultLocale/src/main/webapp
Adding test/agnostic/application/defaultLocale/src/main/webapp/WEB-INF
Adding test/agnostic/application/defaultLocale/src/main/webapp/WEB-INF/classes
Adding test/agnostic/application/defaultLocale/src/main/webapp/WEB-INF/classes/ApplicationStrings_de.properties
Adding test/agnostic/application/defaultLocale/src/main/webapp/WEB-INF/classes/ApplicationStrings_en.properties
Adding test/agnostic/application/defaultLocale/src/main/webapp/WEB-INF/classes/ApplicationStrings_fr.properties
Adding test/agnostic/application/defaultLocale/src/main/webapp/WEB-INF/faces-config.xml
Adding test/agnostic/application/defaultLocale/src/main/webapp/WEB-INF/web.xml
Adding test/agnostic/application/defaultLocale/src/main/webapp/index.xhtml
Adding test/agnostic/application/defaultLocale/src/test
Adding test/agnostic/application/defaultLocale/src/test/java
Adding test/agnostic/application/defaultLocale/src/test/java/com
Adding test/agnostic/application/defaultLocale/src/test/java/com/sun
Adding test/agnostic/application/defaultLocale/src/test/java/com/sun/faces
Adding test/agnostic/application/defaultLocale/src/test/java/com/sun/faces/test
Adding test/agnostic/application/defaultLocale/src/test/java/com/sun/faces/test/agnostic
Adding test/agnostic/application/defaultLocale/src/test/java/com/sun/faces/test/agnostic/application
Adding test/agnostic/application/defaultLocale/src/test/java/com/sun/faces/test/agnostic/application/defaultLocale
Adding test/agnostic/application/defaultLocale/src/test/java/com/sun/faces/test/agnostic/application/defaultLocale/DefaultLocaleIT.java
Sending test/agnostic/application/pom.xml
Transmitting file data ...........
Committed revision 13436.

Comment by Ed Burns [ 04/Aug/14 ]

Re-opening to remove 2.1.20 tag.

Comment by Ed Burns [ 04/Aug/14 ]

Re closing after removing 2.1.20 tag.





[GLASSFISH-16619] Got com.sun.xml.wss.XWSSecurityException when ran some WSS security tests on AIX Created: 12/May/11  Updated: 09/Apr/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 3.1.1
Fix Version/s: not determined

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

AIX, IBM jdk1.6.0


Attachments: File all.log.b07     Text File server.log     Text File server.log    
Tags: 3_1-approved

 Description   

build: V3.1.1 build 4
OS: AIX

Please note that this test only failed on AIX and it passed on all other OS/platforms.

Steps to reproduce the bug:
1.Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT=:pserver:cvsguest@sunsw.us.oracle.com:/m/jws)
cd appserver-sqe
ant -f bootstrap.xml co-security
2. install GF V3.1.1, start domain domain1
3. Set 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>
4. cd appserver-sqe/pe/security/wss/annotations/servletws, run "ant all", test failed with the following error:
[exec] </S:Envelope>==== Received Message End ====
[exec] [exec] May 11, 2011 2:19:20 AM com.sun.xml.wss.impl.SecurityRecipient processMessagePolicy
[exec] SEVERE: WSS0253: Message does not conform to configured policy: No Security Header found in message
[exec] com.sun.xml.wss.XWSSecurityException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.impl.SecurityRecipient.processMessagePolicy(SecurityRecipient.java:818)
[exec] at com.sun.xml.wss.impl.SecurityRecipient.validateMessage(SecurityRecipient.java:261)
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:156)
[exec] at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFClientAuthContext.validateResponse(GFServerConfigProvider.java:1279)
[exec] at com.sun.enterprise.security.webservices.ClientSecurityPipe.processSecureRequest(ClientSecurityPipe.java:211)
[exec] at com.sun.enterprise.security.webservices.ClientSecurityPipe.process(ClientSecurityPipe.java:184)
[exec] at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
[exec] at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
[exec] at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
[exec] at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
[exec] at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
[exec] at com.sun.xml.ws.client.Stub.process(Stub.java:323)
[exec] at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161)
[exec] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:113)
[exec] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
[exec] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144)
[exec] at $Proxy49.getFedTax(Unknown Source)
[exec] at com.sun.appserv.sqe.security.wss.annotations.client.TaxCalClient.callTaxService(TaxCalClient.java:85)
[exec] at com.sun.appserv.sqe.security.wss.annotations.client.TaxCalClient.main(TaxCalClient.java:64)
[exec] javax.xml.ws.WebServiceException: Cannot validate response for

{http://sun.com/appserv/sqe/security/taxws}

TaxPort
[exec] at com.sun.enterprise.security.webservices.ClientSecurityPipe.processSecureRequest(ClientSecurityPipe.java:215)
[exec] at com.sun.enterprise.security.webservices.ClientSecurityPipe.process(ClientSecurityPipe.java:184)
[exec] at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:119)
[exec] at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:641)
[exec] at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:600)
[exec] at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:585)
[exec] at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:482)
[exec] at com.sun.xml.ws.client.Stub.process(Stub.java:323)
[exec] at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:161)
[exec] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:113)
[exec] at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:93)
[exec] at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:144)
[exec] at $Proxy49.getFedTax(Unknown Source)
[exec] at com.sun.appserv.sqe.security.wss.annotations.client.TaxCalClient.callTaxService(TaxCalClient.java:85)
[exec] at com.sun.appserv.sqe.security.wss.annotations.client.TaxCalClient.main(TaxCalClient.java:64)
[exec] Caused by: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:161)
[exec] at com.sun.enterprise.security.jmac.config.GFServerConfigProvider$GFClientAuthContext.validateResponse(GFServerConfigProvider.java:1279)
[exec] at com.sun.enterprise.security.webservices.ClientSecurityPipe.processSecureRequest(ClientSecurityPipe.java:211)
[exec] ... 14 more
[exec] TaxCal client failed
[exec] Generating report at /export/hudson/workspace/alex-aix3.1.1gf/appserver-sqe/test_results.xml
[exec] [exec] [exec] -----------------------------------------
[exec] - sec-wss-annotate-servletwsendpoint-getFedTax: FAIL -
[exec] -----------------------------------------
[exec] Total PASS: 0
[exec] Total FAIL: 1
[exec] Total DNR: 0
[exec] ----------------------------------



 Comments   
Comment by kumarjayanti [ 13/May/11 ]

Can you attach the sever.log for the failure.

Comment by sonialiu [ 13/May/11 ]

attached server.log

Comment by kumarjayanti [ 18/May/11 ]

Made a change in Metro which when integrated into 3.1.1 might fix the issue.

Comment by scatari [ 07/Jun/11 ]

Pre-approving for 3.1.1 as this is a test blocker.

Comment by scatari [ 08/Jun/11 ]

Updated Metro integrated into 3.1.1 for B07.

Comment by sonialiu [ 10/Jun/11 ]

I saw some new WSS failures(25+ more) which I did not see in b06, and the exceptions in the client side seems similar as I reported in the bug. To reproduce the new failures:
1. cd appserver-sqe/pe/security/wss/enforcepolicy
2. run "ant all"
The following error displayed:

[exec] Jun 10, 2011 2:17:34 PM com.sun.xml.wss.impl.SecurityRecipient processMessagePolicy
[exec] SEVERE: WSS0253: Message does not conform to configured policy: No Security Header found in message
[exec] com.sun.xml.wss.XWSSecurityException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.impl.SecurityRecipient.processMessagePolicy(SecurityRecipient.java:818)
[exec] at com.sun.xml.wss.impl.SecurityRecipient.validateMessage(SecurityRecipient.java:261)
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:156)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
[exec] at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
[exec] at java.security.AccessController.doPrivileged(AccessController.java:251)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
[exec] at com.sun.enterprise.security.jauth.ConfigFile$ConfigClient.validateResponse(ConfigFile.java:619)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:281)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:263)
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:167)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub._preHandlingHook(TaxIF_Stub.java:436)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub.getStateTax(TaxIF_Stub.java:277)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testStateTax(TaxCalClient.java:114)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:52)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] Jun 10, 2011 2:17:34 PM com.sun.enterprise.security.webservices.WebServiceSecurity validateResponse
[exec] SEVERE: Container-auth: wss: Error validating response
[exec] Throwable occurred: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:161)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
[exec] at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
[exec] at java.security.AccessController.doPrivileged(AccessController.java:251)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
[exec] at com.sun.enterprise.security.jauth.ConfigFile$ConfigClient.validateResponse(ConfigFile.java:619)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:281)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:263)
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:167)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub._preHandlingHook(TaxIF_Stub.java:436)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub.getStateTax(TaxIF_Stub.java:277)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testStateTax(TaxCalClient.java:114)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:52)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] Jun 10, 2011 2:17:34 PM com.sun.enterprise.security.webservices.MessageLayerClientHandler handleResponse
[exec] WARNING: SEC2005: Container-auth: wss: Error validating response
[exec] Throwable occurred: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:161)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
[exec] at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
[exec] at java.security.AccessController.doPrivileged(AccessController.java:251)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
[exec] at com.sun.enterprise.security.jauth.ConfigFile$ConfigClient.validateResponse(ConfigFile.java:619)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:281)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:263)
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:167)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub._preHandlingHook(TaxIF_Stub.java:436)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub.getStateTax(TaxIF_Stub.java:277)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testStateTax(TaxCalClient.java:114)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:52)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] java.rmi.RemoteException: response handler error: ; nested exception is:
[exec] javax.xml.rpc.JAXRPCException: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:812)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub._preHandlingHook(TaxIF_Stub.java:436)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxIF_Stub.getStateTax(TaxIF_Stub.java:277)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testStateTax(TaxCalClient.java:114)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:52)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] Caused by: javax.xml.rpc.JAXRPCException: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:172)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] ... 13 more
[exec] Unknown exception during getStateTax()
[exec] Jun 10, 2011 2:17:35 PM com.sun.xml.wss.impl.filter.DumpFilter process
[exec] INFO: ==== Sending Message Start ====

************************************
In the server.log I saw the following exceptions:
********

[#|2011-06-10T14:17:34.545-0700|SEVERE|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.webservices|_ThreadID=9;_ThreadName=Thread-6;|SEC2003: Container-auth: wss: Error securing response
com.sun.enterprise.security.jauth.AuthException: java.lang.NullPointerException
at com.sun.xml.wss.provider.ServerSecurityAuthModule.secureResponse(ServerSecurityAuthModule.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
at java.security.AccessController.doPrivileged(AccessController.java:251)
at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
at com.sun.enterprise.security.jauth.ConfigFile$ConfigServer.secureResponse(ConfigFile.java:660)
at com.sun.enterprise.security.webservices.WebServiceSecurity.secureResponse(WebServiceSecurity.java:198)
at com.sun.enterprise.security.webservices.WebServiceSecurity.secureResponse(WebServiceSecurity.java:175)
at com.sun.enterprise.security.webservices.ServletSystemHandlerDelegate.processResponse(ServletSystemHandlerDelegate.java:247)
at org.glassfish.webservices.monitoring.JAXRPCEndpointImpl.processResponse(JAXRPCEndpointImpl.java:151)
at com.sun.xml.rpc.server.http.JAXRPCServletDelegate.doPost(JAXRPCServletDelegate.java:468)
at org.glassfish.webservices.JAXRPCServlet.doPost(JAXRPCServlet.java:114)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1539)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
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:330)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:232)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
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:736)

#]
Caused by: com.sun.enterprise.security.jauth.AuthException: java.lang.NullPointerException
at com.sun.xml.wss.provider.ServerSecurityAuthModule.secureResponse(ServerSecurityAuthModule.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
at java.security.AccessController.doPrivileged(AccessController.java:251)
at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
at com.sun.enterprise.security.jauth.ConfigFile$ConfigServer.secureResponse(ConfigFile.java:660)
at com.sun.enterprise.security.webservices.WebServiceSecurity.secureResponse(WebServiceSecurity.java:198)
at com.sun.enterprise.security.webservices.WebServiceSecurity.secureResponse(WebServiceSecurity.java:175)
at com.sun.enterprise.security.webservices.ServletSystemHandlerDelegate.processResponse(ServletSystemHandlerDelegate.java:247)

Here is the list of wss test cases failed in b07.
appserver-sqe/pe/security/wss/annotations/ejbws
appserver-sqe/pe/security/wss/annotations/servletws
appserver-sqe/pe/security/wss/enforcepolicy/servletws
appserver-sqe/pe/security/wss/dynencryptkey/servletws
appserver-sqe/pe/security/wss/ejbws
appserver-sqe/pe/security/wss/ejbclient
appserver-sqe/pe/security/wss/annotations/ejbws
appserver-sqe/pe/security/wss/annotations/servletws
appserver-sqe/pe/security/wss/mesgmethod/ejbws
appserver-sqe/pe/security/wss/mesgmethod/servletws
appserver-sqe/pe/security/wss/mesgoperation/servletws
appserver-sqe/pe/security/wss/mesgoperation/ejbws
appserver-sqe/pe/security/wss/encrypt/servletws
appserver-sqe/pe/security/wss/encrypt/ejbws
appserver-sqe/pe/security/wss/clienthandler/ejbws
appserver-sqe/pe/security/wss/clientmesgoperation/ejbws
appserver-sqe/pe/security/wss/clientmesgoperation/servletws
appserver-sqe/pe/security/wss/transpo/ejbws
appserver-sqe/pe/security/wss/transpo/servletws
appserver-sqe/pe/security/wss/runasubject/servletws
appserver-sqe/pe/security/auditmodule/apps/ejbws
appserver-sqe/pe/security/auditmodule/apps/servletws

– The exceptions in client side and server.log are attached.

Comment by sonialiu [ 10/Jun/11 ]

server.log and client log for b07

Comment by kumarjayanti [ 13/Jun/11 ]

Why fix this issue in 3.1.1?
It is a QE failure that occurs only on AIX

Which is the targeted build of 3.1.1 for this fix?
TBD

Do regression tests exist for this issue?
YES

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The GF Security WebService QE tests.

Comment by sherryshen [ 06/Jul/11 ]

3 runs on b10 are posted for comparing security failure on RunID 55, 56, 57.
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=GF311SQETest
For webservices security failures:
--b07 has more failures than b04.
--b10 has less failures than b07
I looked into one failure as a reference to look at the test client output.
html report gives machine name for hudson execution, and test case location.
To look at server.log, please login the machine as a hudson user.

--The core result page gives the link of summary report

--summary report gives the link to module report

--module html report gives test case info
http://agni-1.us.oracle.com/asqe-logs/export1/3.1.1/Results/build10/core/aix_security/html/test_results_security.html
Sec::wss_servletws-runas-principal-mls-signatureID
1 fail, 1 pass
/export/hudson/workspace/sherry-aix-311-security/appserver-sqe/pe/security/wss/runasubject/servletws/.
Sec::wss_servletws-runas-principal-mls-signatureID pass
Sec::wss_servletws-runas-principal-mls-usernametokenID fail

--The client output privide more info
http://agni-1.us.oracle.com/asqe-logs/export1/3.1.1/Results/build10/core/aix_security/output/security.wss.output

runclient-ssl-pe:
[echo] Test is running on Platform Edition!
[exec] Jul 3, 2011 1:37:36 PM org.glassfish.appclient.client.acc.AppclientCommandArguments warnAboutPasswordUsage
[exec] 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.
[exec] Jul 3, 2011 1:37:39 PM com.sun.enterprise.deployment.node.SaxParserHandler error
[exec] SEVERE: DPL8015: Invalid Deployment Descriptors in Deployment descriptor file META-INF/application-client.xml in archive [wss-taxcal-clientClient.jar].
[exec] Line 13 Column 26 – cvc-complex-type.2.4.b: The content of element 'port-component-ref' is not complete. One of '

{"http://java.sun.com/xml/ns/javaee":service-endpoint-interface}

' is expected.
[exec] Jul 3, 2011 1:37:40 PM com.sun.enterprise.deployment.node.SaxParserHandler error
[exec] SEVERE: DPL8015: Invalid Deployment Descriptors in Deployment descriptor file META-INF/application-client.xml in archive [wss-taxcal-clientClient.jar].
[exec] Line 14 Column 26 – cvc-complex-type.2.4.b: The content of element 'port-component-ref' is not complete. One of '

{"http://java.sun.com/xml/ns/javaee":service-endpoint-interface}

' is expected.
[exec] Jul 3, 2011 1:37:40 PM com.sun.enterprise.deployment.ServiceReferenceDescriptor addRuntimePortInfo
[exec] WARNING: Runtime port info SEI null is not declared in standard service-ref deployment descriptors (under port-component-ref), is this intended ?
[exec] WS HOME appserver-sqe
[exec] Jul 3, 2011 1:37:41 PM com.sun.enterprise.deployment.node.SaxParserHandler error
[exec] SEVERE: DPL8015: Invalid Deployment Descriptors in Deployment descriptor file META-INF/application-client.xml in archive [wss-taxcal-clientClient.jar].
[exec] Line 13 Column 26 – cvc-complex-type.2.4.b: The content of element 'port-component-ref' is not complete. One of '

{"http://java.sun.com/xml/ns/javaee":service-endpoint-interface}

' is expected.
[exec] Jul 3, 2011 1:37:41 PM com.sun.enterprise.deployment.node.SaxParserHandler error
[exec] SEVERE: DPL8015: Invalid Deployment Descriptors in Deployment descriptor file META-INF/application-client.xml in archive [wss-taxcal-clientClient.jar].
[exec] Line 14 Column 26 – cvc-complex-type.2.4.b: The content of element 'port-component-ref' is not complete. One of '

{"http://java.sun.com/xml/ns/javaee":service-endpoint-interface}

' is expected.
[exec] Jul 3, 2011 1:37:41 PM com.sun.enterprise.deployment.ServiceReferenceDescriptor addRuntimePortInfo
[exec] WARNING: Runtime port info SEI null is not declared in standard service-ref deployment descriptors (under port-component-ref), is this intended ?
[exec] 0.CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
[exec] Jul 3, 2011 1:37:45 PM com.sun.xml.wss.impl.filter.DumpFilter process
[exec] INFO: ==== Sending Message Start ====
[exec] <?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
[exec] <env:Header>
[exec] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
[exec] <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1309725462824-777498885">
[exec] <wsu:Created>2011-07-03T20:37:43Z</wsu:Created>
[exec] <wsu:Expires>2011-07-03T20:42:43Z</wsu:Expires>
[exec] </wsu:Timestamp>
[exec] <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-13097254628631565534604">MIICcTCCAdqgAwIBAgIETg6YPzANBgkqhkiG9w0BAQQFADB9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMRIwEAYDVQQDEwlsb
2NhbGhvc3QwHhcNMTEwNzAyMDQwMjA3WhcNMjEwNjI5MDQwMjA3WjB9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMRIwEAYDVQQDEwlsb2NhbGhvc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKZyKmS6CkwBMzuLLNsl42EV5Y+B9H6zUdp9pFhG7UquChF4JVsgmDdj0FNUGrfq/BYrBJFiWna2mRtIPzswOFRLRwomtMuELVyHRfFQhismjX2p85yBTCYr2OOpG6t9lQHZocK8b0SqW65Mur2ZL4Op5zYVITc1f41iva/OlcpHAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAlPP1yvWJhvztwQxKHN4nOABuFz+u2ABQOOhaOkIyAlzfOEQtblaNajKGMIBwSoYVNDqroZ4SFxUNC0PvWVv/A4jnS4CMVSxlnUDEQmIqTrFayYXqv2UzaMso/Axsl14jzyOv6kHEIUebce0L1Lw0lU332JTWAhTZ624/0Ql8Vbc=</wsse:BinarySecurityToken>
[exec] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="XWSSGID-1309725462863-1763461457">
[exec] <ds:SignedInfo>
[exec] <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
[exec] <InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse enc env ns0 xsd xsi"/>
[exec] </ds:CanonicalizationMethod>
[exec] <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
[exec] <ds:Reference URI="#XWSSGID-1309725463553-869309864">
[exec] <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[exec] <ds:DigestValue>aPoqufNjuErl0oonWa9RfrFa0qo=</ds:DigestValue>
[exec] </ds:Reference>
[exec] <ds:Reference URI="#XWSSGID-1309725462824-777498885">
[exec] <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[exec] <ds:DigestValue>3K5jSLAEv0iIX6yhWqWdWU8ZW+U=</ds:DigestValue>
[exec] </ds:Reference>
[exec] </ds:SignedInfo>
[exec] <ds:SignatureValue>kGfwr0TBYbd6uZEYCppdt66iU2N1xNFzQdjt45Aze5OZigX7Itusu4Ad6Ni6DxKIsHr3L0JxS9E/
[exec] r+9JmNvMiMFe8ibzWG8sn7WelzSKKT/M/utxYCgW8fZ768BYgRe18fbY3vmnzD+46eWUqVqY3USY
[exec] 1uiXaOlGsZo0ZXDfw2I=</ds:SignatureValue>
[exec] <ds:KeyInfo>
[exec] <wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1309725463506-332222617">
[exec] <wsse:Reference URI="#XWSSGID-13097254628631565534604" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
[exec] </wsse:SecurityTokenReference>
[exec] </ds:KeyInfo>
[exec] </ds:Signature>
[exec] </wsse:Security>
[exec] </env:Header>
[exec] <env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1309725463553-869309864">
[exec] <ns0:getRunAsPrincipalNameSignature/>
[exec] </env:Body>
[exec] </env:Envelope>==== Sending Message End ====
[exec]
[exec] Jul 3, 2011 1:37:50 PM com.sun.xml.wss.impl.filter.DumpFilter process
[exec] INFO: ==== Received Message Start ====
[exec] <?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
[exec] <env:Header>
[exec] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
[exec] <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1309725465508-1460142292">
[exec] <wsu:Created>2011-07-03T20:37:48Z</wsu:Created>
[exec] <wsu:Expires>2011-07-03T20:42:48Z</wsu:Expires>
[exec] </wsu:Timestamp>
[exec] <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-1309725465508-1386807055">MIICcTCCAdqgAwIBAgIETg6YPzANBgkqhkiG9w0BAQQFADB9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMRIwEAYDVQQDEwls
b2NhbGhvc3QwHhcNMTEwNzAyMDQwMjA3WhcNMjEwNjI5MDQwMjA3WjB9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMRIwEAYDVQQDEwlsb2NhbGhvc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKZyKmS6CkwBMzuLLNsl42EV5Y+B9H6zUdp9pFhG7UquChF4JVsgmDdj0FNUGrfq/BYrBJFiWna2mRtIPzswOFRLRwomtMuELVyHRfFQhismjX2p85yBTCYr2OOpG6t9lQHZocK8b0SqW65Mur2ZL4Op5zYVITc1f41iva/OlcpHAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAlPP1yvWJhvztwQxKHN4nOABuFz+u2ABQOOhaOkIyAlzfOEQtblaNajKGMIBwSoYVNDqroZ4SFxUNC0PvWVv/A4jnS4CMVSxlnUDEQmIqTrFayYXqv2UzaMso/Axsl14jzyOv6kHEIUebce0L1Lw0lU332JTWAhTZ624/0Ql8Vbc=</wsse:BinarySecurityToken>
[exec] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="XWSSGID-1309725465508-1894216289">
[exec] <ds:SignedInfo>
[exec] <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
[exec] <InclusiveNamespaces xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse enc env ns0 xsd xsi"/>
[exec] </ds:CanonicalizationMethod>
[exec] <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
[exec] <ds:Reference URI="#XWSSGID-1309725468822-1878860834">
[exec] <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[exec] <ds:DigestValue>2HQZtBsNSV4PBh8/h6ZqX0w//C0=</ds:DigestValue>
[exec] </ds:Reference>
[exec] <ds:Reference URI="#XWSSGID-1309725465508-1460142292">
[exec] <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[exec] <ds:DigestValue>kc0z/ZcNhkYX++ys1XZbI/HUFdo=</ds:DigestValue>
[exec] </ds:Reference>
[exec] </ds:SignedInfo>
[exec] <ds:SignatureValue>GTwxOYTnZY/T9sQB3i14O1E1p7PYEP3x0GYDaGFvprIgswv5fjqmjs//OqxMCunzN52gboet8tSR
[exec] 9r6eT3zsX8ZjOmDH2Nl/1VEWPhF3nRY6JngwRu6LM8PYiVWdlYgOlLcABMui9VYbLgwOdzP0n3r2
[exec] ztLodWT2m02NZX0MvA4=</ds:SignatureValue>
[exec] <ds:KeyInfo>
[exec] <wsse:SecurityTokenReference xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1309725468814456765725">
[exec] <wsse:Reference URI="#XWSSGID-1309725465508-1386807055" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
[exec] </wsse:SecurityTokenReference>
[exec] </ds:KeyInfo>
[exec] </ds:Signature>
[exec] </wsse:Security>
[exec] </env:Header>
[exec] <env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1309725468822-1878860834">
[exec] <ns0:getRunAsPrincipalNameSignatureResponse>
[exec] <result xsi:type="xsd:string">CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US</result>
[exec] </ns0:getRunAsPrincipalNameSignatureResponse>
[exec] </env:Body>
[exec] </env:Envelope>==== Received Message End ====
[exec]
[exec] Got:CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US;Expected:CN=localhost, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
[exec] Jul 3, 2011 1:37:52 PM com.sun.xml.wss.impl.filter.DumpFilter process
[exec] INFO: ==== Sending Message Start ====
[exec] <?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
[exec] <env:Header>
[exec] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
[exec] <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-1309725462933-674196013">MIICcTCCAdqgAwIBAgIETg6YPzANBgkqhkiG9w0BAQQFADB9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMRIwEAYDVQQDEwlsb
2NhbGhvc3QwHhcNMTEwNzAyMDQwMjA3WhcNMjEwNjI5MDQwMjA3WjB9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEUMBIGA1UEBxMLU2FudGEgQ2xhcmExGzAZBgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjESMBAGA1UECxMJR2xhc3NGaXNoMRIwEAYDVQQDEwlsb2NhbGhvc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKZyKmS6CkwBMzuLLNsl42EV5Y+B9H6zUdp9pFhG7UquChF4JVsgmDdj0FNUGrfq/BYrBJFiWna2mRtIPzswOFRLRwomtMuELVyHRfFQhismjX2p85yBTCYr2OOpG6t9lQHZocK8b0SqW65Mur2ZL4Op5zYVITc1f41iva/OlcpHAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAlPP1yvWJhvztwQxKHN4nOABuFz+u2ABQOOhaOkIyAlzfOEQtblaNajKGMIBwSoYVNDqroZ4SFxUNC0PvWVv/A4jnS4CMVSxlnUDEQmIqTrFayYXqv2UzaMso/Axsl14jzyOv6kHEIUebce0L1Lw0lU332JTWAhTZ624/0Ql8Vbc=</wsse:BinarySecurityToken>
[exec] <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="XWSSGID-1309725470236-1698110210">
[exec] <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
[exec] <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[exec] <wsse:SecurityTokenReference>
[exec] <wsse:Reference URI="#XWSSGID-1309725462933-674196013" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
[exec] </wsse:SecurityTokenReference>
[exec] </ds:KeyInfo>
[exec] <xenc:CipherData>
[exec] <xenc:CipherValue>d8Ga6jzVttFEnrZMNCBIUsYauwmdEBBS/RNIlyDMtGCySSvOUxPUCJju8g18D1bHyl7muuTbQJTt
[exec] pugaj0WSRsogA+WM1mATFBDSHuealO0P5ZxEP/1DdhbXHeErVrXtF6gGdrj7TAxo7JHG6h59K+O4
[exec] rVdbs1pSYd/onfpgqKA=</xenc:CipherValue>
[exec] </xenc:CipherData>
[exec] </xenc:EncryptedKey>
[exec] <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
[exec] <xenc:DataReference URI="#XWSSGID-1309725472383-1556823487"/>
[exec] </xenc:ReferenceList>
[exec] <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1309725462934-1289127666">
[exec] <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="XWSSGID-1309725472383-1556823487" Type="http://www.w3.org/2001/04/xmlenc#Content">
[exec] <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
[exec] <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[exec] <wsse:SecurityTokenReference>
[exec] <wsse:Reference URI="#XWSSGID-1309725470236-1698110210"/>
[exec] </wsse:SecurityTokenReference>
[exec] </ds:KeyInfo>
[exec] <xenc:CipherData>
[exec] <xenc:CipherValue>Q1/dXuJh7GdNU1yzng83YPGS7WdJCPwGyzp5z0eIrvFeR5SZA18ddYNdlssc8OiNn2NJw+coOOji
[exec] QFRZ6xe7K8qGI4LHs1G5Afuq8t5S6R7CWzvgcR7u85UYEVK7/FmEadjT6i5y0iJn3YYkvqe0cAsh
[exec] XhyJ0lIqycHvhEqy6TEhfB18pr9rZcCCWMvoHXi1Y2ymnVfp+kSUSLV8nCUiZ+HIomxN/B1MOXnr
[exec] u48+jVwT3nt1eGZ2SMzBbKf+BElw5OMR+YF6gvbXgfgUK2Dy+9/Hb5FsXn41iaLSHCQ5muo1UcdJ
[exec] zZmeXe6ZizcTjJlx9tzrtBbe336ObYW2k9oHvPlsr2D/GPH6+DVGGOOwNd/J3DzduHze6+c4stJS
[exec] QAky7wR8NOWmDQEY2seWB1IPzIxmA3mMWCF6hPVWOSbjW7PAWOCeiTwg6JBAgI1V1h2kM5rMLrrv
[exec] It1NGf3QnzpsjQ4IEQP09j6CObVN96KwmH0aUPl2YSpjNOMCv2UZJCV4ryraUIXrce/k2kqFlP05
[exec] 4jGYDHdN0kpNguN/4bEi4qhfXMHoOuJ1A0pMYDBqx8wiFuQAYr7V/B7EVBYJYTIH668I7Q+5P5ZX
[exec] qYqDN31mGQoE7hLtaw0hzs4DrOP2gKS4HzFSQWhQzdFEl7EJ+GURBgPuClsOVpKkKpOUgR+ojU3D
[exec] GCnNKqy20VTNTLtlmGQ2MmTkAMKezL8JkyIQxikpVD33fuzf3Rroi+NVbUIItSzalK39aDeQqjAB
[exec] srZLBa4ZrTmDucpXDbdUJjaqvfkHj5NNgcS7iGVWr+6lQeBmUfEpY7JtsYuKNKyWkyatGo2w</xenc:CipherValue>
[exec] </xenc:CipherData>
[exec] </xenc:EncryptedData>
[exec] </wsse:UsernameToken>
[exec] </wsse:Security>
[exec] </env:Header>
[exec] <env:Body>
[exec] <ns0:getRunAsPrincipalNameUsername/>
[exec] </env:Body>
[exec] </env:Envelope>==== Sending Message End ====
[exec]
[exec] Jul 3, 2011 1:37:57 PM com.sun.xml.wss.impl.filter.DumpFilter process
[exec] INFO: ==== Received Message Start ====
[exec] <?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
[exec] <env:Body>
[exec] <env:Fault>
[exec] <faultcode>env:Server</faultcode>
[exec] <faultstring>JAXRPCSERVLET28: Missing port information</faultstring>
[exec] </env:Fault>
[exec] </env:Body>
[exec] </env:Envelope>==== Received Message End ====
[exec]
[exec] Jul 3, 2011 1:37:57 PM com.sun.xml.wss.impl.SecurityRecipient processMessagePolicy
[exec] SEVERE: WSS0253: Message does not conform to configured policy: No Security Header found in message
[exec] com.sun.xml.wss.XWSSecurityException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.impl.SecurityRecipient.processMessagePolicy(SecurityRecipient.java:818)
[exec] at com.sun.xml.wss.impl.SecurityRecipient.validateMessage(SecurityRecipient.java:261)
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:156)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
[exec] at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
[exec] at java.security.AccessController.doPrivileged(AccessController.java:251)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
[exec] at com.sun.enterprise.security.jauth.ConfigFile$ConfigClient.validateResponse(ConfigFile.java:619)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:281)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:263)
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:167)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub._preHandlingHook(StateTaxIF_Stub.java:298)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub.getRunAsPrincipalNameUsername(StateTaxIF_Stub.java:69)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testRunAsPrincipalNameUsername(TaxCalClient.java:101)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:63)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] Jul 3, 2011 1:37:57 PM com.sun.enterprise.security.webservices.WebServiceSecurity validateResponse
[exec] SEVERE: Container-auth: wss: Error validating response
[exec] Throwable occurred: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:161)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
[exec] at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
[exec] at java.security.AccessController.doPrivileged(AccessController.java:251)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
[exec] at com.sun.enterprise.security.jauth.ConfigFile$ConfigClient.validateResponse(ConfigFile.java:619)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:281)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:263)
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:167)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub._preHandlingHook(StateTaxIF_Stub.java:298)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub.getRunAsPrincipalNameUsername(StateTaxIF_Stub.java:69)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testRunAsPrincipalNameUsername(TaxCalClient.java:101)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:63)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] Jul 3, 2011 1:37:57 PM com.sun.enterprise.security.webservices.MessageLayerClientHandler handleResponse
[exec] WARNING: SEC2005: Container-auth: wss: Error validating response
[exec] Throwable occurred: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.wss.provider.ClientSecurityAuthModule.validateResponse(ClientSecurityAuthModule.java:161)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invokePriv(AuthContext.java:143)
[exec] at com.sun.enterprise.security.jauth.AuthContext$1.run(AuthContext.java:93)
[exec] at java.security.AccessController.doPrivileged(AccessController.java:251)
[exec] at com.sun.enterprise.security.jauth.AuthContext.invoke(AuthContext.java:90)
[exec] at com.sun.enterprise.security.jauth.ConfigFile$ConfigClient.validateResponse(ConfigFile.java:619)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:281)
[exec] at com.sun.enterprise.security.webservices.WebServiceSecurity.validateResponse(WebServiceSecurity.java:263)
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:167)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub._preHandlingHook(StateTaxIF_Stub.java:298)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub.getRunAsPrincipalNameUsername(StateTaxIF_Stub.java:69)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testRunAsPrincipalNameUsername(TaxCalClient.java:101)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:63)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] java.rmi.RemoteException: response handler error: ; nested exception is:
[exec] javax.xml.rpc.JAXRPCException: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:812)
[exec] at com.sun.xml.rpc.client.StreamingSender._preHandlingHook(StreamingSender.java:732)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub._preHandlingHook(StateTaxIF_Stub.java:298)
[exec] at com.sun.xml.rpc.client.StreamingSender._send(StreamingSender.java:124)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.StateTaxIF_Stub.getRunAsPrincipalNameUsername(StateTaxIF_Stub.java:69)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.testRunAsPrincipalNameUsername(TaxCalClient.java:101)
[exec] at com.sun.appserv.sqe.security.wss.servletws.taxcal.client.TaxCalClient.main(TaxCalClient.java:63)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[exec] at java.lang.reflect.Method.invoke(Method.java:611)
[exec] at org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:438)
[exec] Checking runas principal for username failed with unknown exception
[exec] at org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:182)
[exec] at org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)
[exec] Caused by: javax.xml.rpc.JAXRPCException: com.sun.enterprise.security.jauth.AuthException: Message does not conform to configured policy [ TimestampPolicy(S) SignaturePolicy(P) ]: No Security Header found
[exec] at com.sun.enterprise.security.webservices.MessageLayerClientHandler.handleResponse(MessageLayerClientHandler.java:172)
[exec] at com.sun.xml.rpc.client.HandlerChainImpl.handleResponse(HandlerChainImpl.java:131)
[exec] at com.sun.xml.rpc.client.StreamingSender._callResponseHandlers(StreamingSender.java:810)
[exec] ... 13 more
[exec] Generating report at /export/hudson/workspace/sherry-aix-311-security/appserver-sqe/test_results.xml
[exec]
[exec]
[exec] -----------------------------------------
[exec] - Sec::wss_servletws-runas-principal-mls-signature: PASS -
[exec] - Sec::wss_servletws-runas-principal-mls-usernametoken: FAIL -
[exec] -----------------------------------------
[exec] Total PASS: 1
[exec] Total FAIL: 1
[exec] Total DNR: 0
[exec] -----------------------------------------

Comment by kumarjayanti [ 07/Jul/11 ]

With latest AIX b10 the error seems to be only in the DUMPING of the messages enabled by the debug property of the SAM.

An AIX specific error is occuring when doing a JAXP Transform.

So the testcase should pass if debug property in the SAM configuration is removed.

Here is the error on the server.log. I have asked the ClassLoader experts on what the problem could be.

-------------------
[#|2011-07-03T14:30:55.536-0700|WARNING|glassfish3.1.1|javax.enterprise.system.cor
e.classloading.com.sun.enterprise.loader|_ThreadID=12;_ThreadName=Thread-9;|Input
stream has been finalized or forced closed without being explicitly closed; stream
instantiation reported in following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.<init>(A
SURLClassLoader.java:1230)
at com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLCla
ssLoader.java:878)
at org.glassfish.web.loader.WebappClassLoader.getResourceAsStream(WebappCl
assLoader.java:1252)
at com.ibm.xtq.xslt.drivers.SecuritySupport$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(AccessController.java:202)
at com.ibm.xtq.xslt.drivers.SecuritySupport.getResourceAsStream(Unknown So
urce)
at com.ibm.xtq.xslt.drivers.XylemRuntimePreCompiler.getResource(Unknown So
urce)
at com.ibm.xtq.xslt.drivers.XylemRuntimePreCompiler.getPrecompiledRuntime(
Unknown Source)
at com.ibm.xtq.xslt.drivers.XSLTCompiler.compileRuntime10(Unknown Source)
at com.ibm.xtq.xslt.drivers.XSLTCompiler.compileRuntime(Unknown Source)
at com.ibm.xtq.xslt.drivers.XSLTCompiler.compile(Unknown Source)
at com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl.createTemplates(U
nknown Source)
at com.ibm.xtq.xslt.jaxp.AbstractTransformerFactory.newTemplates(Unknown S
ource)
at com.sun.xml.wss.impl.filter.TeeFilter.init(TeeFilter.java:164)

This issue should no longer be a release stopper for AIX.

Comment by kumarjayanti [ 08/Jul/11 ]

Adding comments from ClassLoader experts :

Tim Quinn Wrote :
---------------

Sahoo is correct; a stream has been opened but never closed by the code which opened it.

From a quick look at the stack trace, the stream is opened (as a side effect of classLoader.getResourceAsStream) from com.ibm.xtq.xslt.drivers.XylemRuntimePreCompiler, so presumably any fix would need to be there.

  • Tim

On Jul 7, 2011, at 5:45 AM, Sahoo wrote:

Hi Kumar,

That indicates that some of the streams referring to resources returned by this class loader were still open, but there is no reference to those streams in code so finalizer is getting called. It further means there is some bad code somewhere which is not calling InputStream.close(). If this can be isolated, then one has to instrument the code to detect the bad code and fix it. btrace can be excellent option to debug such issues. Copying Tim for any additional input he may have, as he has dealt with such issues in the past and IIRC has introduced this error detection logic in ASURLClassLoader.

HTH,
Sahoo

On Thursday 07 July 2011 12:58 PM, Kumar Jayanti wrote:
Hi Shaoo, Siva,

There is a problem happening on AIX with Metro Security SQE runs. Just wanted to know if you have any idea/hints on what is wrong.

-------------------
[#|2011-07-03T14:30:55.536-0700|WARNING|glassfish3.1.1|javax.enterprise.system.cor
e.classloading.com.sun.enterprise.loader|_ThreadID=12;_ThreadName=Thread-9;|Input
stream has been finalized or forced closed without being explicitly closed; stream
instantiation reported in following stack trace
java.lang.Throwable
at com.sun.enterprise.loader.ASURLClassLoader$SentinelInputStream.<init>(A
SURLClassLoader.java:1230)
at com.sun.enterprise.loader.ASURLClassLoader.getResourceAsStream(ASURLCla
ssLoader.java:878)
at org.glassfish.web.loader.WebappClassLoader.getResourceAsStream(WebappCl
assLoader.java:1252)
at com.ibm.xtq.xslt.drivers.SecuritySupport$6.run(Unknown Source)
at java.security.AccessController.doPrivileged(AccessController.java:202)
at com.ibm.xtq.xslt.drivers.SecuritySupport.getResourceAsStream(Unknown So
urce)
at com.ibm.xtq.xslt.drivers.XylemRuntimePreCompiler.getResource(Unknown So
urce)
at com.ibm.xtq.xslt.drivers.XylemRuntimePreCompiler.getPrecompiledRuntime(
Unknown Source)
at com.ibm.xtq.xslt.drivers.XSLTCompiler.compileRuntime10(Unknown Source)
at com.ibm.xtq.xslt.drivers.XSLTCompiler.compileRuntime(Unknown Source)
at com.ibm.xtq.xslt.drivers.XSLTCompiler.compile(Unknown Source)
at com.ibm.xtq.xslt.jaxp.compiler.TransformerFactoryImpl.createTemplates(U
nknown Source)
at com.ibm.xtq.xslt.jaxp.AbstractTransformerFactory.newTemplates(Unknown S
ource)
at com.sun.xml.wss.impl.filter.TeeFilter.init(TeeFilter.java:164)
----------------------

regards,
kumar

Comment by kumarjayanti [ 08/Jul/11 ]

Dowgrading the bug since it is only an exception during debug. I am also trying to remove some dependence on Apache Xerces which might help remove this exception (need to verify still). The change will require a new Metro Integration

Comment by Alex Pineda [ 14/Jul/11 ]

Are there plans to integrate this fix and a new Metro version in Glassfish (final GF 3.1.1) build? Need to know to plan the testing appropriately.

Comment by kumarjayanti [ 14/Jul/11 ]

Martin G had a discussion with Sathyan and it seems we are not going to integrate now.

Comment by Tom Mueller [ 06/Mar/12 ]

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





[GLASSFISH-16200] Common Tasks: Broken Doc Links Created: 13/Mar/11  Updated: 19/Dec/16  Resolved: 26/Apr/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Major
Reporter: Harald Wellmann Assignee: Paul Davies
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, 3_1-fishcat

 Description   

The Documentation links on the Common Tasks welcome page are broken. They all link or redirect to http://www.oracle.com/pls/topic/error.



 Comments   
Comment by Harald Wellmann [ 13/Mar/11 ]

As I cannot reopen GLASSFISH-15663, I created this clone.

With Glassfish 3.1 (the release, aka b43), the links on the Admin Console start page are broken again.

The URLs listed by Paul Davies in GLASSFISH-15663 seem to have changed again. I get the same error message when directly pointing my browser at these URLs.

Comment by Anissa Lam [ 13/Mar/11 ]

Request Paul to follow up on this.
This was from the latest email from Paul when i requested him to double check the doc link.

==================================
Hi Anissa,

I have cross-checked the URLs that I gave you with the URLs in the svn diff output in the comment that you added to the bug and I can confirm that they are correct.

I have much greater confidence in these URLs as they were generated automatically by our link management system and match the URLs that will be in the Preface of all the books when they're published on OTN.

I only wish that I had had this information when I gave you the original URLs.

Regards,
-Paul

On 01/26/11 23:03, Anissa Lam wrote:
>
> Component: admin_gui
> Issue: http://java.net/jira/browse/GLASSFISH-15663
>
> I have once again updated the doc link in the common task page according to the new info thats provided by the doc team. There is no way to verify the link is correct. Request Paul to review the link again.
>
> thanks
> Anissa.





[GLASSFISH-15963] .reload dynamic reload feature fails and destroys application directory Created: 11/Feb/11  Updated: 19/Dec/16  Due: 11/Feb/11  Resolved: 11/Feb/11

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

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

Tags: 3_1-approved

 Description   

A long-standing feature is that users can place individual updated files of an app directly into the correct location within the deployed applications/(appName) directory and then use

touch applications/(appName)/.reload

to trigger an automatic reload of the app.

This feature is broken in the current 3.1 builds in a way that not only does not work but also deletes the expanded application directory.

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
  • Introduces an incompatibility
  • Likely to generate a customer support call
  • An in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)
any time a user tries to use the "touch .reload" feature

How much effort is required to fix it? (Cost)
one-line change

What is the risk of fixing it? (Risk)
very low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
redeploying the whole application is a poor workaround; the point of the .reload feature is to allow "surgical" updates to selected files rather than redeploying the entire app

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
yes

How long has the bug existed in the product?
rev 36941 (May 13, 2010)

Do regression tests exist for this issue?
no - adding one for this

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
an archive deployment, with and without upload

When will a tested fix be ready for integration?
later today - fix is already implemented and is undergoing tests now



 Comments   
Comment by Tim Quinn [ 11/Feb/11 ]

taking ownership

Comment by Nazrul [ 11/Feb/11 ]

Approved for check in into RC3 pending the following activities:
1) Code review
2) All deployment dev tests pass
3) Dev Test(s) for this feature is added and pass

Comment by Tim Quinn [ 11/Feb/11 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 45067 (3.1 branch) / 45068 (trunk)
Author: tjquinn
Date: 2011-02-11 22:59:25 UTC
Link:

Log Message:
------------
Fix for 15963

Work done earlier to help optimize synchronization of uploaded archives to remote instances introduced a bug which broke the .reload feature. Files uploaded during deployment are placed into a temporary directory under the domain's applications directory. The code at fault incorrectly assumed that a file anywhere under the domain's applications directory was an uploaded file. Deployment expands all archives and, except for the sync feature, the uploaded archive is no longer needed. So the code moved what it thought was the uploaded file to a separate directory for use by synchronization. But when a user touches the .reload file in the applications/(appName) directory for an already-deployed app, that directory is within the applications directory so this logic was moving the expanded directory to this separate directory, causing rather some havoc.

This change repairs the problem by not moving a file under the applications directory if it is itself a directory. This is the lowest-risk fix at this point in 3.1.

Approved: Nazrul
Reviewed: Hong
Tests: QL, deployment devtests including a new test for the .reload feature

Revisions:
----------
45067 (for 3.1 branch)
45068 (for trunk)

Modified Paths:
---------------
branches/3.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java





[GLASSFISH-15961] some l10n man pages are not loaded when the server is running Created: 11/Feb/11  Updated: 19/Dec/16  Due: 13/Feb/11  Resolved: 12/Feb/11

Status: Closed
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved

 Description   

Some of the l10n man pages are not loaded when the server is running like asadmin help list-clusters.
The asadmin client does the lookup correctly. it seems that the logic is missing on the server side.



 Comments   
Comment by Chris Kasso [ 11/Feb/11 ]

Georges - Can you give us an idea of how many commands are afflicted with this issue?

Comment by gmurr [ 11/Feb/11 ]

I don't know how many. The man pages are returned either by the client or the server, I don't know how the logic is implemented to make the distinction. However all l10n man pages are displayed correctly if the server is not running.

Comment by Chris Kasso [ 11/Feb/11 ]

How does the failure manifest itself to the user? Do they see the man page in english or do they get an error?

Comment by gmurr [ 11/Feb/11 ]

They see the EN man page

Comment by Bill Shannon [ 11/Feb/11 ]

The root problem here is that the code to find the localized man pages
doesn't even exist in the server! Ouch! Prior testing of localized man
pages only tested when the server is down, in which case asadmin does all
the work of finding the man page. The fix it to adapt the man-page-finding
code from asadmin so that it can work in the server.

How bad is its impact? (Severity)
Pretty bad. Localized man pages aren't found at all.
Previous 3.x releases haven't provided localized man pages.

How often does it happen? (Frequency)
Even time in non-English locales.

How much effort is required to fix it? (Cost)
It took me several hours to fix it.

What is the risk of fixing it? (Risk)
Moderate. I've isolated the fix to the server code that finds man pages,
even though the asadmin code that does the same should be refactored to
use common code; that will wait for 3.2. The risk is that the fix might
break finding the default man pages in some case that testing won't detect.
Fortunately, the fix is isolated to the man-page-finding code.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
The workaround is to only ask for man pages when the server is down,
or to supply the wrong server coordinates to asadmin so it thinks the
server is down.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Absolutely.

How long has the bug existed in the product?
Since 3.0.

Do regression tests exist for this issue?
Not that I'm aware of.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Any tests that involve finding man pages. I think the risk of
destabilization outside the man page area is extremely small.

When will a tested fix be ready for integration?
Later today.

Comment by Chris Kasso [ 11/Feb/11 ]

Approved for RC3 pending:

1) Code review
2) The obligatory QL testing
2) A better understanding of how to validate the fix. That may just mean poking at a bunch of man pages.

Comment by Bill Shannon [ 12/Feb/11 ]

Fixed.

3.1 revision 45078
trunk revision 45089

Comment by gmurr [ 14/Feb/11 ]

Fix verified in promoted 3.1 b42





[GLASSFISH-15940] Exception printed on screen when accessing custom network listener Created: 10/Feb/11  Updated: 19/Dec/16  Resolved: 11/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

ogs-3.1-web-b41.zip


Attachments: JPEG File protocol-exception.JPG     Text File server.log    
Tags: 3_1-approved, 3_1-verified

 Description   

Steps to reproduce:

1. In Admin Console go to default config.
2. Click on Network Config node, Network Listeners.
3. Create a new network listener with default values, providing only name and an available port number, e.g. http-goofy, 8585. Click Save. Minor issue: the nodes tree on the left is never updated with the new listener (the same is true for custom created virtual servers and protocols).
4. Click on Protocols node.
5. In the table click on http-goofy network listener and the following error is displayed:

An error has occurred
REST: Exception java.lang.NullPointerException at org.glassfish.admin.rest.resources.custom.FindHttpProtocolResource.get(FindHttpProtocolResource.java:86) 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.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:167) at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:70) at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:279) at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule .... msg.seeServerLog

The same listener can be accessed fine from the Network Listeners screen.



 Comments   
Comment by Anissa Lam [ 10/Feb/11 ]

This again is the same issue we faced before. The redirect didn't specify the config name, thus goes to the "server-config" which is the default.
Also notice that the link to the transport in the page also has the same problem. fix that as well.
The fix is trivial and no risk.

1. How bad is its impact? (Severity)
Sometimes you see exception on screen like reported. In times where the server-config also has the same named network listener, the error will not show up, and user may not realize that all of a sudden, they are configuring the DAS instead of the cluster/instance they have been working on.

2. How often does it happen? (Frequency)
100%. Whenever user goes to the Network Listener page by clicking on the links in the protocols table.

3. How much effort is required to fix it? (Cost)
less than an hour. Once i realize the config name showing in the page is wrong, i know whats the problem.

4. What is the risk of fixing it? (Risk)
extremely low.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes, they can get to this network listener from the tree. The issue here is, user may not realize that they are taken to a different configuration.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Not really. If they realize the problem, they don't need to go to release note They can click the correct tree node.

7. How long has the bug existed in the product?
Since we support multiple config in 3.1

8. Do regression tests exist for this issue?
Yes, but the test just uses 'server-config' which didn't catch this. I am going to add one that creates the listener in a different config.

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The usual test they run.

10. When will a tested fix be ready for integration?
It is available now. svn diff included here.

~/Awork/V3/v3.1/3.1/admingui 181) svn diff web
Index: web/src/main/resources/grizzly/networkListenerEdit.jsf
===================================================================
— web/src/main/resources/grizzly/networkListenerEdit.jsf (revision 45009)
+++ web/src/main/resources/grizzly/networkListenerEdit.jsf (working copy)
@@ -162,7 +162,7 @@
</sun:property>

<sun:property id="transport" labelAlign="left" noWrap="#

{true}" overlapLabel="#{false}" label="$resource{i18n_web.grizzly.networkListener.transport}" >
- <sun:hyperlink id="transport" text="#{pageSession.valueMap['transport']}" url="#{request.contextPath}/web/grizzly/transportEdit.jsf?name=#{pageSession.valueMap['transport']}" />
+ <sun:hyperlink id="transport" text="#{pageSession.valueMap['transport']}" url="#{request.contextPath}/web/grizzly/transportEdit.jsf?name=#{pageSession.valueMap['transport']}&configName=#{configName}" />
</sun:property>

<sun:property id="threadpool" labelAlign="left" noWrap="#{true}

" overlapLabel="#

{false}

" label="$resource

{i18n_web.grizzly.networkListener.threadPool}

" helpText="$resource

{i18n_web.grizzly.networkListener.threadPoolHelp}

">
Index: web/src/main/resources/grizzly/protocols.jsf
===================================================================
— web/src/main/resources/grizzly/protocols.jsf (revision 45009)
+++ web/src/main/resources/grizzly/protocols.jsf (working copy)
@@ -158,7 +158,7 @@

<sun:tableColumn headerText="$resource

{i18n_web.grizzly.protocol.listenerNameCol}

" sort="name" rowHeader="$boolean

{true}

" id="colnet">
<foreach key="listenerName" list="#

{td.value.listenerList}

" >

  • <sun:hyperlink text="# {listenerName}" url="#{request.contextPath}/web/grizzly/networkListenerEdit.jsf?name=#{listenerName}

    &cancelTo=protocols.jsf" />"<br>
    + <sun:hyperlink text="#

    {listenerName}" url="#{request.contextPath}/web/grizzly/networkListenerEdit.jsf?name=#{listenerName}

    &cancelTo=protocols.jsf&configName=#

    {configName}

    " />"<br>
    </foreach>
    </sun:tableColumn>

Comment by srinik76 [ 10/Feb/11 ]

Changes looks fine.

Comment by Nazrul [ 10/Feb/11 ]

Approved for checkin into RC3 pending the following activities:
1) Verify that the original issue is fixed
2) Run GUI Dev Tests and make sure there are no regressions
3) Verify that the config pages under server-config are working properly after removal of "server-config" as default
4) Verify that the config pages under default-config or cluster1-config are working properly after these changes

Comment by Anissa Lam [ 11/Feb/11 ]

>3) Verify that the config pages under server-config are working properly after removal of "server-config" as default

Just to clarify,
I am NOT removing 'server-config' as default in any pages. This will be done as code cleanup in 3.2.
I have ran manual testing on server-config, default-config and cluster-config. and run devtest. Also working on adding devtest for this.

fix checked into trunk and 3.1 branch.
3.1 branch: rev# 45056
trunk: rev# 45057

Project: glassfish
Repository: svn
Revision: 45056
Author: anilam
Date: 2011-02-11 16:30:36 UTC
Link:

Log Message:
------------
GLASSFISH-15940. Add configName when redirecting to listener page from the protocols table.

manual testing creating the listener in server-config, default-config and cluster-config. run devtest.

Reviewed by Srini
Approved by Nazrul

Revisions:
----------
45056

Modified Paths:
---------------
branches/3.1/admingui/web/src/main/resources/grizzly/networkListenerEdit.jsf
branches/3.1/admingui/web/src/main/resources/grizzly/protocols.jsf

Comment by lidiam [ 04/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-15931] web profile: New Resource Adapter Config screen shows 'jmsra' and causes error shown on screen Created: 09/Feb/11  Updated: 19/Dec/16  Due: 13/Feb/11  Resolved: 10/Feb/11

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

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

Attachments: JPEG File error.jpg     File jmsra.diff    
Issue Links:
Duplicate
is duplicated by GLASSFISH-15932 Web distribution: 500 error when clic... Resolved
is duplicated by GLASSFISH-15933 Web distribution: error when trying t... Resolved
Tags: 3_1-approved

 Description   

When running in web profile, 'jmsra' is added to the Resource adapter list in the create Resource Adapter Config screen. 'jmsra' is not present in web profile, thus causing an error msg on screen when first get there.

User can still use the screen to create the RA Config for the adapter they have deployed.
No lost in functionality.
If i can't find a trivial fix tomorrow, we will have to exclude this and release note it.



 Comments   
Comment by Anissa Lam [ 10/Feb/11 ]

The web profile doesn't have the buildin resource adapter "jmsra", thus resulting in exception when trying to get more info about this resource adapter.

The following screen is affected because of this bug: Admin Object Resource, Work Security Maps and Resource Adapter Config. There should be API for GUI to obtain the system resources adapter, instead of always adding "jmsra" since GUI will not know if it is running in web profile or glassfish profile.

And then the already existed command _get-system-rars-allowing-pool-creation() returns the wrong info. It returns "jmsra" and "jaxr-ra" even in web profile, thus causing the problem in Connector Connection Pool.

As a 'quick' fix for this, we can add a session attribute "_jms_plugin_exist" in the JMS tree node, so all the affected screen can check this value and decide if "jmsra" should be added or not.

This fix is very low risk and local to these 4 screens.

Comment by Anissa Lam [ 10/Feb/11 ]

considering the # of pages affected by this, raising this to critical.

Comment by Anissa Lam [ 10/Feb/11 ]

1. How bad is its impact? (Severity)
The impact is pretty bad. There are 4 resources page affected by this which are pretty common functions that GUI user performs.

2. How often does it happen? (Frequency)
100%

3. How much effort is required to fix it? (Cost)
Take me sometimes to track down the issue, and then figuring out how to fix this with min. code change. There are better fix available, but those require additional hidden command from Jagadish, and then REST needs to expose it. Too late at this point.
The fix now is to 'blockcast' to the world that 'I exist' from the JMS plugin, and then let those screens to decide whether to include "jmsra" and "jaxr-ra" in the resource adapter dropdown list or not.

4. What is the risk of fixing it? (Risk)
The risk is pretty low.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
For RA config, work security map and connector connection pool, user has to ignore the error when they first visit the screen. For Admin Object Resource, there is no workaround. The page just doesn't function with exception shown on screen.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Definitely.

7. How long has the bug existed in the product?
Since we support web profile.

8. Do regression tests exist for this issue?
Yes, but we don't run those test in web profile. Should start setting up hudson job for this profile.

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The usual test they run. If this change causes any regression, it can be caught right away.

10. When will a tested fix be ready for integration?
I am testing my changes now. Should be available for review in a couple hours.

Comment by Anissa Lam [ 10/Feb/11 ]

Patch attached.
I have tested the following cases manually.

  • web profile
    No RAR deployed. – There will not be any Resource Adapter available on the screens to select from, there won't be any error on screen. User can't create any Connector Connection Pool, Admin Object Resource, Connector Security Map and Resource Adapter Config.
    With RAR deployed. – This deployed rar will show up as expected, and user can create all the above objects with the deployed RAR. (except for Admin Object Resource, refer to GLASSFISH-15949)/
  • glassfish profile
    NO RAR deployed – the default 'jmsra' shows up correctly. for Connector Connection Pool, both 'jmsra' and 'jasx-ra' shows up correctly.

with RAR deployed – shows up besides the default build in one (jmsra).

I am running the dev test for the glassfish profile to make sure no regression. I cannot run the devtest on web profile yet, because lots of the test is using 'jmsra' as the adapter. This all needs to be cleaned up.

Comment by Chris Kasso [ 10/Feb/11 ]

Approved for RC3.

Comment by Jason Lee [ 10/Feb/11 ]

Changes look fine.

Comment by Anissa Lam [ 10/Feb/11 ]

Fix checked into both trunk & 3.1 branch.

3.1 branch: rev# 45053
trunk: rev# 45054

Project: glassfish
Repository: svn
Revision: 45053
Author: anilam
Date: 2011-02-11 05:18:03 UTC
Link:

Log Message:
------------
GLASSFISH-15931. Fixes for web profile NOT to refer to jmsra and jaxs-ra which is not available in web profile. This is by setting a session attribute in the JMS plugin and all screens should check that attribute before showing these 2 build-in adapter.

Reviewed by Jason
Approved by Chris

Revisions:
----------
45053

Modified Paths:
---------------
branches/3.1/admingui/jms-plugin/src/main/resources/resourcesNodes.jsf
branches/3.1/admingui/jca/src/main/resources/resourceAdapterConfigAttr.inc
branches/3.1/admingui/jca/src/main/resources/adminObjectAttr.inc
branches/3.1/admingui/jca/src/main/java/org/glassfish/jca/admingui/handlers/ConnectorsHandlers.java
branches/3.1/admingui/jca/src/main/resources/adminObjectNew.jsf
branches/3.1/admingui/jca/src/main/resources/resourceAdapterConfigNew.jsf
branches/3.1/admingui/jca/src/main/resources/workSecurityMapAttr.inc
branches/3.1/admingui/jca/src/main/resources/connectorConnectionPoolNew1.jsf
branches/3.1/admingui/jca/src/main/resources/connectorConnectionPoolEdit.jsf





[GLASSFISH-15929] man-page-review umbrella issue Created: 09/Feb/11  Updated: 19/Dec/16  Due: 13/Feb/11  Resolved: 16/Feb/11

Status: Resolved
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

Type: Bug Priority: Blocker
Reporter: Jagadish Assignee: Paul Davies
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-15958 man page: webtier CLIs Resolved
depends on GLASSFISH-15877 man-page-review : remove the section ... Resolved
depends on GLASSFISH-15878 man-page-review : create-jdbc-connect... Resolved
depends on GLASSFISH-15879 man-page-review : note about resource... Resolved
depends on GLASSFISH-15962 Man page for update-node-config is wr... Resolved
depends on GLASSFISH-3198 Synopsis for asadmin help create-cust... Resolved
depends on GLASSFISH-15485 Error in man pages for restart-local-... Resolved
depends on GLASSFISH-15564 create-http-health-checker man page e... Resolved
depends on GLASSFISH-15566 change-master-password --help has wro... Resolved
depends on GLASSFISH-15867 documentation of create-system-proper... Resolved
depends on GLASSFISH-15872 man-page : flush-connection-pool, pin... Resolved
depends on GLASSFISH-15873 man-page-review : delete-resource-ada... Resolved
depends on GLASSFISH-15874 man-page-review : delete-connector-re... Resolved
depends on GLASSFISH-15875 man-page-review : list-admin-objects,... Resolved
depends on GLASSFISH-15876 man-page-review : list-connector-reso... Resolved
depends on GLASSFISH-15919 man-page-review: jms CLIs Resolved
depends on GLASSFISH-15956 man page: remove --upgrade option fro... Closed
depends on GLASSFISH-15947 Remove --upgrade from start-local-ins... Resolved
Tags: 3_1-approved, 3_1-release-note-added, 3_1-release-notes

 Description   

Raising an umbrella issue for the man pages of various commands for Bugswat review. Please refer the "depends on" issues list.



 Comments   
Comment by Paul Davies [ 11/Feb/11 ]

This bug is the umbrella bug for all man page fixes for the RC 3 build. I have increased the priority to ensure that it is approved for integration in RC 3.

Comment by Paul Davies [ 11/Feb/11 ]

How bad is its impact? (Severity)
The fix needs to occur now because the issue:

  • Is likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature
  • Is an in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)
Every time a user requests help on an affected subcommand.

How much effort is required to fix it? (Cost)
Approx 4 writer days (3 writers working 1 day each on the fixes, + 1 day for integration and testing)

What is the risk of fixing it? (Risk)
Low.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes - deliver the fixes only in the version that is published on the web.The workaround could be employed by an end user but only if the user is aware of the workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

How long has the bug existed in the product?
The errors were introduced in this release.

Do regression tests exist for this issue?
N/A

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
QuickLook would be sufficient for this purpose.

When will a tested fix be ready for integration?
Before the RC 3 build is started.

Comment by Chris Kasso [ 11/Feb/11 ]

Approved for RC3.

Comment by Chris Kasso [ 11/Feb/11 ]

These changes will not be localized for 3.1 thus users in non-EN locales will continue to see the incorrect man pages. The release notes should direct these users to the unbundled versions of the man pages for the corrections.

Comment by Paul Davies [ 13/Feb/11 ]

For the 3.1 branch, change is committed in revision 45101.

Comment by Paul Davies [ 16/Feb/11 ]

For the trunk, the fix is committed in revision 45163.

Comment by Scott Fordin [ 24/Mar/11 ]

Added topic to 3.1 Release Notes. Added "3_1-release-note-added" tag.





[GLASSFISH-15923] A monitoring module was added in 3.1, "deployment" - but enable-monitoring doesn't support it Created: 09/Feb/11  Updated: 15/Mar/11  Resolved: 09/Feb/11

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

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

Tags: 3_1-approved, added-devtest

 Description   

I added 360 new Monitoring Dev Tests and this problem was detected.

org.glassfish.api.monitoring.ContainerMonitoring has a hard-coded list of all Monitoring modules. enable-monitoring uses this list.

Sometime during 3.1 a new module was added – "deployment". But that file was not updated. As a result if you try something like the following you will get an error:

asadmin enable-monitoring --modules deployment:LOW

com.sun.enterprise.config.serverbeans.ModuleMonitoringLevels has a getter/setter added for the new module.

I don't know if other areas are also affected.

======

The fix would be trivial – add a test and call to the getter.



 Comments   
Comment by Byron Nevins [ 09/Feb/11 ]

========================
1. How bad is its impact? (Severity)
The impact is pretty bad. The fix is trivial and has no risk.

  • Identify why the fix needs to occur now:
    o Likely to generate a customer support call

2. How often does it happen? (Frequency)
100%

3. How much effort is required to fix it? (Cost)
Zero cost – I have a fix ready to go. It is easy.

4. What is the risk of fixing it? (Risk)
Very Low risk.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes and yes. It is the usual answer for any fouled-up command that exclusively sets config – the work-around is to use the low-level "set" command.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Definitely.

7. How long has the bug existed in the product?
Since whenever the "deployment" module was added. It might be in 3.0

8. Do regression tests exist for this issue?
Yes. Monitoring DevTests detected the problem today!

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

It's not that sort of issue. It is self-contained. To be very safe I would add a tiny minimal change in 3.1 branch and do the full change (change to ContainerMonitoring in the api package) to the trunk.

QA never tested it – it would have failed instantly.

10. When will a tested fix be ready for integration?
Code changes – a few minutes. Code review and red-tape – a few hours

Comment by Byron Nevins [ 09/Feb/11 ]

DETAILS:

existing pseudo-code:

if(moduleName.equals(ContainerMonitoring.HTTP_SERVICE)
obj.setHttpService(level);
// 14 similar else blocks for the other 14 modules.

What I need to do is add one else clause exactly like this:

else if(moduleName.equals("deployment"))
obj.setDeployment(level);

Simple! setDeployment() already exists – there just is no corresponding constant in ContainerMonitoring.

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

Comment by Byron Nevins [ 09/Feb/11 ]

A better solution needs to be Engineered for 3.2 so new modules can be added w/o having to remember to update code in different modules. It's a classic use-case of the Java Bean API and reflection. I'll open a new bug for 3.2 and point it to this one...

Index: src/main/java/org/glassfish/flashlight/cli/MonitoringConfig.java
===================================================================
— src/main/java/org/glassfish/flashlight/cli/MonitoringConfig.java (revision 45009)
+++ src/main/java/org/glassfish/flashlight/cli/MonitoringConfig.java (working copy)
@@ -166,6 +166,8 @@
param.setJpa(level);
} else if (moduleName.equals(ContainerMonitoring.JERSEY))

{ param.setJersey(level); + }

else if (moduleName.equals("deployment"))

{ + param.setDeployment(level); }

else

{ valueUpdated.set(false); }

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

I've also turned back on the Monitoring DevTests that identified this bug in the first place...

Comment by Byron Nevins [ 09/Feb/11 ]

Sorry – tons of comments but we are at that phase of the project!

Output of the Monitoring DevTests:

dev-report:
[java] **********************
[java] * PASSED 375 *
[java] * FAILED 0 *
[java] * DID NOT RUN 0 *
[java] * TOTAL 375 *
[java] **********************
[java]
[echo] Detailed results available under d:/gf/v2/appserv-tests/test_results.html

BUILD SUCCESSFUL
Total time: 4 minutes 2 seconds

Comment by Byron Nevins [ 09/Feb/11 ]

D:\gf\v3\flashlight\framework\foo\framework>svn commit
Sending src\main\java\org\glassfish\flashlight\cli\MonitoringConfig.java
Transmitting file data .
Committed revision 45032.

This fix is only for the 3.1 Branch.

Comment by Byron Nevins [ 09/Feb/11 ]

here is the commit to the trunk

D:\gf\v3>svn commit flashlight\framework\src\main\java\org\glassfish\flashlight\cli\MonitoringConfig.java common\glassfish-api\src\main\java\org\glass
fish\api\monitoring\ContainerMonitoring.java
Sending common\glassfish-api\src\main\java\org\glassfish\api\monitoring\ContainerMonitoring.java
Sending flashlight\framework\src\main\java\org\glassfish\flashlight\cli\MonitoringConfig.java
Transmitting file data ..
Committed revision 45033.

Comment by Byron Nevins [ 15/Mar/11 ]

Added a devtest 3/15/2011

note that the command is

asadmin enable-monitoring --modules deployment=LOW
not
asadmin enable-monitoring --modules deployment:LOW

!!!!





[GLASSFISH-15911] Integrate EclipseLink 2.2 Created: 09/Feb/11  Updated: 09/Feb/11  Resolved: 09/Feb/11

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

Type: Task Priority: Major
Reporter: Mitesh Meswani Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

We are planning to ship EclipseLink 2.2 with GlassFish 3.1. EclipseLink 2.2 was released today. It is bit-by-bit same as RC4. Seeking permission to integrate EclipseLink 2.2



 Comments   
Comment by Nazrul [ 09/Feb/11 ]

Approved for checkin into RC3

Comment by Mitesh Meswani [ 09/Feb/11 ]

Fixed with 45017





[GLASSFISH-15908] [BLOCKING] After Updating from 3.0 to B41 using UC, many exceptions in the server.log while loading the Admin Console Created: 09/Feb/11  Updated: 19/Dec/16  Resolved: 10/Feb/11

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

Type: Bug Priority: Blocker
Reporter: Alex Pineda Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 Professional, JDK 1.6.0_23, Browser Firefox 3.6, glassfish-v3-b74b-windows distribution (v3.0 FCS build), build 41 on UC Publisher dev.glassfish.org (Repository URL http://pkg.glassfish.org/v3/dev)


Attachments: File server.log_2011-02-09T07-03-13     JPEG File update-error.jpg    
Tags: 3_1-approved, 3_1-blocking, 3_1-upgrade

 Description   

While testing the new Update process on my Win7 system (asqe-win7-3.us.oracle.com)with v3.0 installed (build 74b) and no Admin password set, several exceptions are seen in the server log (see attachment) while loading the Admin Console. After a while the Login Admin console page is displayed, but not the Admin Console "Common Tasks" page.

The same configuration was tested on build 38 without the above described problem.

The same procedure works on v3.0.1 installation(glassfish-3.0.1-b22-windows) on the same system. The system is updated properly and the Admin console loads correctly. The sample application is viewable and useable. Have not tried anything further (like instance or cluster creation as of yet).

To reproduce the failure, perform the following steps:
1. Install GF 3.0 build 74b
2. Start the domain
3. Check the server is up and running
4. Make sure Admin Console is accessible
5. Deploy sample app (hello.war)
6. Shut down the domain server
7. Start "Updatetool" (<GF_Directory>/glassfishv3/updatetool/bin/updatetool)
8. Edit the preferred repository to the dev.glassfish.org repository
9. Select "Available Updates" (left side of the screen - Application Images)
10. Update all the pkgs.
11. Check versions of the updates and make sure it matches the latest build
12. Monitor the server log (tail -f server.log)
13. Start the domain with --upgrade. (asadmin start-domain --upgrade --domaindir <GF_Dir>/glassfish/domains domain1)
14. Start the domain (asadmin start-domain)
15. Make sure it's up and running (check localhost:8080)
16. Go to the Admin Console (URL localhost:4848)

In the server log you will see several exceptions (see the attached server log) and the Admin Console login page is displayed (nor the "Common Tasks" page).



 Comments   
Comment by Alex Pineda [ 09/Feb/11 ]

I don't believe "upgrade_tool" is the correct component, so please change to the right component.

Comment by Bobby Bissett [ 09/Feb/11 ]

I see no problems during the upgrade (except expected expired certificate) or initial startup. But when you try to load the admin console and from then on, I see lots of errors with class loading. For instance:

Caused by: java.lang.ClassNotFoundException: com.sun.jersey.multipart.FormDataMultiPart not found by org.glassfish.admin.rest-service [211]
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:787)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 40 more

#]

and a LOT of these:

Caused by: java.lang.LinkageError: loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoaderJava5): attempted duplicate class definition for name: "org/glassfish/admin/rest/resources/generatedASM/DomainAnonymousUserEnabledResource"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
... 30 more

I'm going to assign to update tool for a look since that changes the behavior of the server (and the class loading), but maybe this is an OSGi issue for all I know. It looks like a lot of the server isn't being loaded.

Since I didn't see this with 3.0, it would be nice to know if there was some OSGi change between 3.0 and 3.0.1.

Comment by Alex Pineda [ 09/Feb/11 ]

I can make the system available for debugging (asqe-win7-3.us.oracle.com) if needed. Please send me email directly and I will provide the username and password.

Comment by Bobby Bissett [ 09/Feb/11 ]

Alex, just to be explicit about this: you're seeing the problem with 3.0 but not with 3.0.1. Is that right?

Comment by Anissa Lam [ 09/Feb/11 ]

Just another data point. I tried starting 3.1 by pointing to the 3.0 domain, (ie, not going through updatetool), It works without issue.

%asadmin start-domain --upgrade=true --domaindir /Users/anilam/Sun/v3/3.0/Release/glassfishv3/glassfish/domains domain1
%asadmin start-domain --domaindir /Users/anilam/Sun/v3/3.0/Release/glassfishv3/glassfish/domains domain1

Comment by Alex Pineda [ 09/Feb/11 ]

That is correct. I'm only seeing this issue on 3.0 and not 3.0.1. I checked this morning on this system and the Admin Console came up, and I did not see the exceptions in the server.log.

Comment by Alex Pineda [ 09/Feb/11 ]

Anissa, what is the difference between using --upgrade and --upgrade=true. Please help me understand. Please send me email directly. Thanks.

Comment by Bobby Bissett [ 09/Feb/11 ]

Can someone tell me where to download 3.0? All I can find is 3.0.1. Alex, if you haven't gotten a response yet, there's no difference between --upgrade and --upgrade=true. In both cases, you'll see this in the JVM options that asadmin outputs:

-upgrade
true

If you use --upgrade=false, it's the same as leaving out --upgrade entirely.

Comment by Chris Kasso [ 09/Feb/11 ]

I've updated Bobby with the internal location of v3.

Comment by Snjezana Sevo-Zenzerovic [ 09/Feb/11 ]

I am checking for file differences (other than domain config) between 3.1 b41 and upgraded v3 installation. Stay tuned...

Comment by Bobby Bissett [ 09/Feb/11 ]

Like Anissa, I don't see the issue when I just copy the 3.0 domain over to my 3.1 installation, but I do see the problem after updating my 3.0 install to 3.1. I only see the problem when accessing the admin console though.

In other words, the rest of the server seems ok. I can see the app that was deployed before the upgrade. Using the command line, I can undeploy the app, create and start a cluster, etc. Just can't use the admin console. Maybe that helps narrow down the issue.

Comment by Bobby Bissett [ 09/Feb/11 ]

FWIW, I was using the download from http://glassfish.java.net/downloads/v3-final.html which is " GlassFish v3.0-b74b (build 74.2)"

Comment by Snjezana Sevo-Zenzerovic [ 09/Feb/11 ]

Bobby, that would point to something fishy (no pun intended) going on during the update process itself.

One potential difference between b38 run and b41 run is that in the meantime we pushed out empty glassfish-scripting@3.1 package so glassfish-scripting modules are now removed from the installation during the update. However, I don't think that is the issue since I tested v3 update using that package before it got published.

Comment by Snjezana Sevo-Zenzerovic [ 09/Feb/11 ]

I think I found it... Updated installation seems to be missing mimepull.jar which got moved from jersey to glassfish-common package in 3.1 in order to address duplicate file being packaged in jersey and metro packages.

For some reason, when I use updatetool to apply updates I get "two step" update - in the first pass it seems that everything other than glassfish-scripting and jersey packages get reported as available updates. Once I install those, glassfish-scripting and jersey show up. At that point, jersey package update will effectively wipe out mimepull.jar file since new jersey package does not contain the file anymore. Running 'pkg fix glassfish-common' brings back lost file and at that point things seem to behave more or less normally.

Note that jersey content has been the same for couple of months and so far image update was handling this correctly. Not sure what's going on right now, but will talk to Joe.

Bobby, could you please check your installation and see if mimepull.jar is missing?

Comment by Anissa Lam [ 09/Feb/11 ]

I have no luck running the update tool to try updating from 3.0 ( GlassFish v3, build 74.2) to 3.1
I also set "dev.glassfish.org" as the preferred publisher.
But i get lots of constraint violation error. I am attaching a couple here.
This is on Mac, is Mac supported ?

Comment by Snjezana Sevo-Zenzerovic [ 09/Feb/11 ]

Yes, MacOS is supported - I know that you can get constraint violation errors if you don't select to install all available updates from the list. Another thing you can try is to run 'pkg image-update' instead of updating through updatetool.

Comment by Bobby Bissett [ 09/Feb/11 ]

It's also a 2 step process for me. After the first pass, I still have the file:

hostname% pwd
/Users/bobby/eraseme/glassfishv3
hostname% find . -name mimepull.jar
./glassfish/modules/mimepull.jar

But I still have Jersey Core and GF Scripting to update. After I update those, no jar:

hostname% find . -name mimepull.jar
hostname%

I made a copy of it before the update. When I copy it back to the gf modules dir before starting the server, I can then access the admin console with no problems.

Comment by Snjezana Sevo-Zenzerovic [ 09/Feb/11 ]

OK, at least we have consistent behavior and know the culprit. Joe has some ideas on metapackage dependency definitions that may fix this, I'll try them out...

Comment by Snjezana Sevo-Zenzerovic [ 09/Feb/11 ]

Tentative fix would consist of following:

  • adding 'incorporate' dependency on glassfish-scripting@3.1 package to glassfish-web-incorporation package
  • modify 'require' dependency on jersey package in glassfish-web-profile metapackage to specify dependency on jersey@1.5
Comment by Snjezana Sevo-Zenzerovic [ 09/Feb/11 ]

How bad is its impact? (Severity)
Direct update from v3 FCS installation to 3.1 FCS produces corrupted installation image. This qualifies as both potential support call generator and an in-your-face usability issue.

How often does it happen? (Frequency)
For all updates where the starting point is v3 FCS installation.

How much effort is required to fix it? (Cost)
Minimal effort for workspace fix (requires only adjustment of package dependencies for two packager modules). Moderate effort to test the fix since it requires setting up a private copy of stable repository and publishing updated packages to it.

What is the risk of fixing it? (Risk)
Minimal risk. 3.0.1 update path will be tested for regressions.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Workaround is to run 'pkg fix glassfish-common' command on affected installation but it is far from obvious for the end user.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

How long has the bug existed in the product?
Jersey package content which indirectly causes the issue has been in place for more than two months. Updated glassfish-scripting package became available in the dev repository in the last week. It is unclear at which point repository content triggered faulty image update behavior.

Do regression tests exist for this issue?
No automated regression test. Manual v3 and 3.0.1 update test plan will be used to check for regressions.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
v3 and 3.0.1 updates to 3.1.

When will a tested fix be ready for integration?
By 02/10 COB (tentatively).

Comment by Chris Kasso [ 09/Feb/11 ]

Approved for RC3.

Comment by Snjezana Sevo-Zenzerovic [ 10/Feb/11 ]

Fix checked in as revision 45044 (3.1 branch) and 45046 (trunk).

Before the integration I run full update test scenarios using v3 FCS and 3.0.1 FCS installations as starting point. Repository used for that testing was replica of current stable.glassfish.org repository plus set of 3.1 IPS packages built from current workspace. Instead of switching preferred repository to dev.glassfish.org as in original QA test scenario, the URL of stable.glassfish.org publisher was being set to private test repo URL. This should very closely resemble the update scenario for an actual 3.1 FCS end user.

Comment by Alex Pineda [ 15/Feb/11 ]

Verified the fix in build 42. Tested it on the same configuration that I found the issue and everything is working now.





[GLASSFISH-15903] ConcurrentModificationException observed in the MQ logs during a 24x7 Stress Test RichAccess run Created: 08/Feb/11  Updated: 19/Dec/16  Resolved: 10/Feb/11

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: v3.0.1, 3.1_dev
Fix Version/s: 3.1_dev

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

Attachments: HTML File instance-mq-log    
Tags: 3_1-approved

 Description   

GF Build: Observed with Builds 37 and 40
Platform: OEL (b37) and Windows 2008 (b40)

  • Observed with RichAccess run (b37) and a RichAccess + SSL run (b40)

The following Exception appears in the MQ logs on a few instances on each of these runs:
******
[05/Feb/2011:19:32:55 IST] ERROR [B3100]: Unexpected Broker Internal Error : [TransactionLogManager: Checkpoint runnerFailed to synchronize persistence store for transaction log checkpoint]:^M
java.util.ConcurrentModificationException^M
at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)^M
at com.sun.messaging.jmq.jmsserver.persist.file.BaseTransactionManager.writePreparedTransactionsToPreparedTxnStoreOnCheckpoint(BaseTransactionManager.java:244)^M
at com.sun.messaging.jmq.jmsserver.persist.file.TransactionLogManager.doCheckpoint(TransactionLogManager.java:828)^M
at com.sun.messaging.jmq.jmsserver.persist.file.CheckpointManager.run(CheckpointManager.java:74)^M
at java.lang.Thread.run(Thread.java:662)^M
*****

The Exception does not seem to cause any harm to the test.



 Comments   
Comment by Satish Kumar [ 09/Feb/11 ]

From the exception in the log, it appears to be MQ broker issue. Requestion Amy to investigate...

Comment by amyk [ 09/Feb/11 ]

add 3_1-review tag

Comment by Nazrul [ 09/Feb/11 ]

How bad is its impact? (Severity)
Show stopper - The exception causes txnlog grow infinitely

How often does it happen? (Frequency)
Expect to happen under load

How much effort is required to fix it? (Cost)
Minimal. Code changes as following, which is a safe fix with perf consideration based on MQ 4.5 code analysis
— a/src/share/java/com/sun/messaging/jmq/jmsserver/persist/file/BaseTransactionManager.java Mon Jan 31 12:57:40 2011 -0800
+++ b/src/share/java/com/sun/messaging/jmq/jmsserver/persist/file/BaseTransactionManager.java Wed Feb 09 19:03:39 2011 -0800
@@ -239,9 +239,16 @@
+ " num incompleteUnstored=" + incompleteUnstored.size();
logger.log(Logger.DEBUG, msg);
}

  • Iterator<BaseTransaction> iter = incompleteUnstored.values().iterator();
    +
    + ArrayList<TransactionUID> incmps = null;
    + synchronized(incompleteUnstored) { + incmps = new ArrayList<TransactionUID>(incompleteUnstored.keySet()); + }

    + TransactionUID tid = null;
    + BaseTransaction baseTxn = null;
    + Iterator<TransactionUID> iter = incmps.iterator();
    while (iter.hasNext()) {

  • BaseTransaction baseTxn = iter.next();
    + tid = iter.next();
    if (!preparedTxnStore.containsTransaction(tid)) {
    + baseTxn = (BaseTransaction)incompleteUnstored.get(tid);
    + if (baseTxn == null) { + continue; + }

What is the risk of fixing it? (Risk)
Very low to none

Does a work aroundfor the issue exist? Can the workaround be reasonably employed by the end user?
No

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes but no workaround to prevent the bug happen

Howlong has the bug existed in the product?
Since 4.4u2 when the newTxnLog feature was added

Do regression tests existfor this issue?
Yes

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
GlassFish richAccess

When will a tested fix be readyfor integration?
The fix is ready and a MQ build has been started

Comment by varunrupela [ 09/Feb/11 ]

Of the ~8 runs of the RichAccess Stress Test, MQ logs were collected for 5 of them. Of those 5 this stack trace appears in 2 of those runs.
1. With Build 37 - on one instance on OEL
2. With Build 40 - on 2 instances on Windows-2008

Now, a similar but different stack trace seems to have been fixed by Amy in http://java.net/jira/browse/MQ-73 on 5th Jan and build 37 came out on 11th Jan. So its likely that it may not have been possible to obtain the latest stack trace prior to build 37 ?

Comment by amyk [ 10/Feb/11 ]

Varun, please provide the stacktrace for the one "on 5th Jan" you mentioned above and its complete broker log

The stacktrace for MQ-73 and the tacktrace for GLASSFISH-15903 are on different variables in MQ newTxnLog code and both were introduced in MQ4.4u2 and can occur in the stress test runs depending on runtime timing.

MQ-73 on variable "completeStored" - same exception should not occur on this variable after MQ build24
at com.sun.messaging.jmq.jmsserver.persist.file.BaseTransactionManager.removeCompleteTransactionsAfterCheckpoint(BaseTransactionManager.java:283)

GLASSFISH-15903 on variable "incompleteUnstored"
at com.sun.messaging.jmq.jmsserver.persist.file.BaseTransactionManager.writePreparedTransactionsToPreparedTxnStoreOnCheckpoint(BaseTransactionManager.java:244)

Comment by varunrupela [ 10/Feb/11 ]

Amy: The one on 5th Jan is MQ-73 and not one that we found through our testing. Are you looking for logs for MQ-72 ? I am afraid we do not have logs for those as we modified our framework to collect MQ logs only after we hit issue MQ-72.

Comment by amyk [ 10/Feb/11 ]

So your previous comment "a similar but different stack trace seems to have been fixed by Amy in http://java.net/jira/browse/MQ-73 on 5th Jan" was really referring to the one from broker log for MQ-72 which was created on Jan 03 using a MQ build before build24. Then that's the same one that has been fixed by MQ-73 (MQ build24-c).

Comment by Chris Kasso [ 10/Feb/11 ]

Approved for RC3.

Comment by varunrupela [ 10/Feb/11 ]

Answer is Yes to Amy's Comment.

Comment by amyk [ 10/Feb/11 ]

fixed in MQ build29-b (7018423) and integrated to GlassFish 3.1 for RC3 build (b42)

Comment by amyk [ 10/Feb/11 ]

updated Affects Versions





[GLASSFISH-15897] CLONE -Result data is not displayed in Application Monitoring Created: 08/Feb/11  Updated: 19/Dec/16  Due: 13/Feb/11  Resolved: 11/Feb/11

Status: Resolved
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1
Fix Version/s: 3.1_dev

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

Operating System: All
Platform: All


Attachments: PNG File screen3.png     Zip Archive testmodule.zip    
Issuezilla Id: 11,859
Tags: 3_1-approved, added-devtest-cant

 Description   

Issue:
Result data is not displayed in the Application Monitoring.

Steps:
1. Start glassfish.
3. Open Administration Console. Select "Configuration" > "Monitoring" to open
the "Monitoring Services". Set all items as "HIGH" and click on "Save".
4. Restart glassfish to enable the new settings.
5. Run run.bat contained in the zip file.
6. Open Administration Console.
Select "Enterprise Server" from the tree.
Click on "Monitor" tab then select "Resources". (Refer to the screenshot)
Select "MDBQueueConnectionFactory" from the drop-down menu.
The result is not displayed in the Monitor table.

Windows XP
Glassfish version: 3.1
glassfish-v3_1-b01-04_18_2010.zip



 Comments   
Comment by tak09 [ 08/Feb/11 ]

I checked case 11859, but it seems that it is not fixed yet.
I used glassfish-3.1-b38.zip to verify if this is fixed.

Comment by Anissa Lam [ 08/Feb/11 ]

I tried with the latest build and don't see any monitoring data either.

However, the data is available through CLI.

~/Desktop/BUG 1111) v3admin get -m server.resources.*
server.resources.jms/MDBQueueConnectionFactory.averageconnwaittime-count = 0
server.resources.jms/MDBQueueConnectionFactory.averageconnwaittime-description = Average wait-time-duration per successful connection request
server.resources.jms/MDBQueueConnectionFactory.averageconnwaittime-lastsampletime = 1297225888141
...
...

REST is able to show data under web request,
http://localhost:4848/monitoring/domain/server/web/request

but there is no data shown for this resource.
http://localhost:4848/monitoring/domain/server/resources/jms/MDBQueueConnectionFactory

I believe it has to do with the slash in the resource name.

I tried duplicating the __TimerPool and call it "my/timerpool". I ping both __TimerPool and my/timerpool ,
I can see statistics if i go to http://localhost:4848/monitoring/domain/server/resources/__TimerPool
but no stats for my/timerpool.

I also looked at GUI code and see that we have encoded the "/" to %2F in the endpoint before sending, we don't see any result either.

Transfer to Mitesh for investigation.

Comment by Anissa Lam [ 08/Feb/11 ]

Just to want to clarify one thing.
The current GUI code didn't encode the resource name, "/" to "%2F" before passing in. I tried encoding it to %2F first before sending, still didn't get any stats.

Comment by Nazrul [ 09/Feb/11 ]

Update from Mitesh:

A resource with '/' in its name is not accessible from REST. Here is what seems to be happening.

The REST url http://localhost:4848/monitoring/domain/server/resources/jms%2FMDBQueueConnectionFactory ultimately results in call to org.glassfish.flashlight.datatree.impl.AbstractTreeNode.findNodeInTree(String[] tokens) with token as "

{ "jms", "MDBQueueConnectionFactory"}

Where as the children of these tree nodes contain "jms/MDBQueueConnectionFactory". Obviously the data is not found.

Comment by Harshad Vilekar [ 09/Feb/11 ]

Open issues related to '/' in the resource name:
http://java.net/jira/browse/GLASSFISH-14132
http://java.net/jira/browse/GLASSFISH-13038

Comment by Jennifer Chou [ 10/Feb/11 ]

Regarding the update from Mitesh about the token issue:

In MonitoringResource at line 171
String dottedName = path.replace('/', '.');

where

path = "server/resources/jms/MDBQueueConnectionFactory"
dottedName = "server.resources.jms.MDBQueueConnectionFactory"

this replaces all the '/' including the one in the jndi name: jms/MDBQueueConnectionFactory.
Doesn't REST need to preserve the '/' in jms/MDBQueueConnectionFactory ?
Otherwise, the monitoring infra will be looking for a node jms.

Comment by Byron Nevins [ 10/Feb/11 ]

This appears to be an easy bug to fix.

1) Putting %2F in a URL is a Grizzly thing. REST will not see it. REST will see what Grizzly correctly turns it into – a slash. At that point it is too late.

2) You want the *displayed* link to look normal with the slash but you want the URL itself to be encoded with __SLASH__

3) This fixes it

ex: src/main/java/org/glassfish/admin/rest/resources/MonitoringResource.java
===================================================================
— src/main/java/org/glassfish/admin/rest/resources/MonitoringResource.java (revision 45009)
+++ src/main/java/org/glassfish/admin/rest/resources/MonitoringResource.java (working copy)
@@ -259,8 +259,10 @@
if (node.hasChildNodes())

{ String name = node.getName(); // Grizzly will barf if it sees backslash + name = name.replace("\\.", "."); - links.put(name, getElementLink(uriInfo, name)); + String encodedName = name.replace("/", "___SLASH___"); + links.put(name, getElementLink(uriInfo, encodedName)); }

}

Comment by Byron Nevins [ 10/Feb/11 ]

Note from the bugfix that we would use the constant in common – not the actual "__SLASH__" string...

Comment by Jennifer Chou [ 10/Feb/11 ]

How bad is its impact? (Severity)
Medium - Not able to view monitoring statistics through Admin Console/REST if the JNDI of the resource contains a '/' - which is the normal case.

Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
    Regression from v2.x Admin Console.
  • An in-your-face issue that will touch the majority of users
    Not sure how many users use this.

How often does it happen? (Frequency)

  • All the time when the JNDI name of a resource has a '/' - which is the normal case

How much effort is required to fix it? (Cost)

  • minimal effort

What is the risk of fixing it? (Risk)

  • some risk ?

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • Use asadmin get -m "server.resources." or asadmin get -m "server.resources.jms*MDBQueue"
  • Use AMX mbean

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • Yes

How long has the bug existed in the product?

  • Probably when the encode slash was introduced in monitoring infra - 2 mts?

Do regression tests exist for this issue?

  • There are REST devtests in admin/rest/src/test/java

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • REST tests

When will a tested fix be ready for integration?

  • today or tomorrow
Comment by Byron Nevins [ 10/Feb/11 ]

Notes:

1) Needs testing of things with embedded dots [1] and embedded slashes [2] via REST, Admin GUI, asadmin

2) Impact is VERY BAD! If you use JMS with the usual accepted naming scheme you will never see your monitoring data.

3) This bug has almost certainly been in here since V3.0

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

[1] easy --> "asadmin deploy --name foo.goo hello.war"
[2] also easy using the procedure and zip file in this bug

Comment by Chris Kasso [ 10/Feb/11 ]

Approved for RC3.

Comment by Nazrul [ 10/Feb/11 ]

Please do the following before committing this change:
0) Code review
1) Run the REST Dev Tests (request REST team)
2) Run the Admin Console Dev Tests (request GUI team)
3) Add REST Dev Test to check for dots and forward slash in the name
4) Verify that the original reported issue is fixed
5) Do some manual testing of the GUI (request GUI team)

Overall, please make sure there are no regression in REST or GUI due to this checkin

Comment by Byron Nevins [ 11/Feb/11 ]

TRUNK:
Sending monitor\src\main\java\org\glassfish\flashlight\datatree\impl\AbstractTreeNode.java
Transmitting file data .
Committed revision 45060.

3.1 Branch:
Sending main\java\org\glassfish\flashlight\datatree\impl\AbstractTreeNode.java
Transmitting file data .
Committed revision 45062.





[GLASSFISH-15895] enable-monitoring command is broken for clusters and instances Created: 08/Feb/11  Updated: 19/Dec/16  Resolved: 09/Feb/11

Status: Closed
Project: glassfish
Component/s: monitoring
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Attachments: Text File diffs.txt     Java Archive File flashlight-framework.jar    
Tags: 3_1-approved, 3_1-verified, added-devtest

 Description   

No resource monitoring data is displayed on Admin GUI - when the JMS connection Factory is created with target = cluster. Same issue with CLI.

Steps:

  • create and start three instance cluster:

$ asadmin list-instances --long
NAME HOST PORT PID CLUSTER STATE
in2 localhost 8363 11368 c1 running
in1 localhost 58077 11367 c1 running
in3 localhost 8619 11369 c1 running
Command list-instances executed successfully.

  • Enable Monitoring for the cluster
  • asadmin create-jms-resource --target c1 --restype javax.jms.QueueConnectionFactory jms_QCF
  • asadmin list-jms-resources c1 | grep jms_QCF
    jms_QCF
  • create new physics destination: myQ (target = c1)
  • asadmin list-jmsdest c1

mq.sys.dmq
myQ
Command list-jmsdest executed successfully.

  • asadmin get -m "in1.*" | grep jms_QCF

Newly created JMS resource is not listed.

Also see earlier reported issue: http://java.net/jira/browse/GLASSFISH-14132



 Comments   
Comment by Harshad Vilekar [ 08/Feb/11 ]

This works fine for target = server. Use these additional steps on Admin Console:

1. Resources - JMS Resources - Connection Factories - jms_QCF - Target - Manage Targets - server - Add- Save

2. Resources - Connection Connection Pool - jmsQCF - Ping (not sure if this is needed)

3. Enable Monitoring: server-config - Monitoring - Level - High (for all) - Change Level - Save

4. Server - Monitor - Resources - View - jms_QF

Comment by Nazrul [ 08/Feb/11 ]

If enable-monitoring (and disable-monitoring) is broken for target=cluster, we will need a fix for this.

Comment by Byron Nevins [ 08/Feb/11 ]

Lots of misleading and complicated info on this Issue including the summary.

I'm changing it to reflect the real problem which is that enable-monitoring is not working correctly for clusters and instances.

Comment by Byron Nevins [ 08/Feb/11 ]

Work-around

Example for Windows

call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.connector-connection-pool=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.connector-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.ejb-container=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jms-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.orb=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.thread-pool=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.transaction-service=HIGH
call asadmin set configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=HIGH

call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.connector-connection-pool=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.connector-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.ejb-container=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.http-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.jms-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.jvm=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.orb=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.thread-pool=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.transaction-service=HIGH
call asadmin set configs.config.c1-config.monitoring-service.module-monitoring-levels.web-container=HIGH

Comment by Byron Nevins [ 08/Feb/11 ]

Very simple & easy problem and fix. Here is another example of how not having devtests is expensive!!

Final Analysis:
It was always using the MonitoringService of DAS

Fix:
Use the correct MonitoringService!

The way it works is you, say, call DAS and tell it to turn on dtrace for cluster c1. DAS writes the change to the c1-config. Then DAS calls all the instances in the cluster. If any of them happen to be running then they do precisely the same thing that DAS just did on their own personal copy of domain.xml. If they are not running then they will get the change the next time they sync up.

I'll attach the diffs...

Comment by Byron Nevins [ 08/Feb/11 ]

These are the diffs for the fix

Comment by Byron Nevins [ 09/Feb/11 ]

Summary:
It's really a minor gaff. The problem is that it wasn't detected until now. When you run the command – DAS will ALWAYS change its own config exclusively and completely ignore the target. If the instance(s) happen to be running - they will adjust their own config correctly. As soon as the instances restart they will sync and lose the correct config. Meantime DAS has incorrect monitoring config.

This results in a very puzzling situation for the user – just look at the original description and comments on this bug to see what I mean.

========================
1. How bad is its impact? (Severity)
The impact is bad. Very bad. The fix is trivial and has no risk at all.

  • Identify why the fix needs to occur now:
    o Likely to generate a customer support call
    o Significantly impacts the operation of a primary release driver feature (clustering)

2. How often does it happen? (Frequency)
100%

3. How much effort is required to fix it? (Cost)
Zero cost – I have a fix ready to go. It is trivial and the diffs are attached to this issue.

4. What is the risk of fixing it? (Risk)
No risk. It is already 100% broken. It would be difficult to make it worse.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes and yes. It is the usual answer for any fouled-up command that exclusively sets config – the work-around is to use the low-level "set" command.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Definitely. But that would be a lot more work than fixing it. The bug is 100% contained. This is a pretty simple command that simply changes config. None of the business-end of the code is touched. All I had to change is to get the MonitoringService config object based on the target – rather than always injecting the one in the DAS config. Literally a few lines of code.

7. How long has the bug existed in the product?
At all times post 3.0

8. Do regression tests exist for this issue?
No. Monitoring DevTests are being developed furiously right now. This issue can be added right away.

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Probably not necessary. Unfortunately there must have been no tests at all otherwise this would have been immediately detected.
Simple manual tests are all that is required. Namely, enable-monitoring for DAS, then for a cluster then a stand-alone cluster. Examine domain.xml for correct changes. Do this before and after the changes. I've already done this methodically.

Direct answer: It can't possibly destabilize GlassFish – it is 100% broken now.

10. When will a tested fix be ready for integration?
Within moments of its approval and review.

Comment by Byron Nevins [ 09/Feb/11 ]

Note to code reviewers –

In the code before the change, the MonitoringService object is injected. It is not checked. It could conceivably be null.

The fix does this:

ms = targetService.getConfig(target).getMonitoringService();

target is GUARANTEED to be a valid target by CommandRunner. Could that config have a null MonitoringService? Yes – but that would mean the user edited out of domain.xml himself and is asking for trouble. Our infrastructure can handle the NPE that would result in that unlikely case.

We could make the error detection and handling more explicit and obvious but I avoided it to make the smallest possible change.

Adding code to produce error messages is to be avoided – this code is already trying to load strings from a localstrings file that does not exist. But I can do it at the cost of a few hours.

Comment by Jennifer Chou [ 09/Feb/11 ]

Question for the JMS folks....

.....unrelated to the bug in enable-monitoring....assume you have turned on monitoring successfully using either asadmin set or Admin Console (not enable-monitoring), when you Ping the jms_QCF (jmsra and javax.jms.QueueConnectionFactory) that is enabled on c1, should this display the JMS monitoring statistics for c1? If not, how can we see the JMS statistics on c1?

Currently, aftering pinging jms_QCF on DAS (server), the JMS monitoring statistics are displayed.
But, after pinging jms_QCF on c1, the JMS monitoring statistics are not displayed.

Comment by Jagadish [ 09/Feb/11 ]

Jennifer has sent me an email about this issue.

In order to see the monitoring statistics for a pool, the pool need to be initialized.
In DAS, ping-connection-pool will start showing the statistics.
Note : ping-connection-pool is applicable only for DAS.

For non-DAS instances, application need to access the pool once so that the pool is initialized which in-turn will register to monitoring registry to start collecting monitoring statistics. I have sent the steps to Jennifer that shows the monitoring statistics of a connector-connection-pool in a clustered instance.

Comment by Nazrul [ 09/Feb/11 ]

Approved for checkin pending the following activities:

  • Code review
  • Validate that the original reported issues is fixed
  • We have Dev Test(s) for this
  • disable-monitoring with target=cluster is also working
  • Validate that there are no regressions due to this checkin
Comment by Jennifer Chou [ 09/Feb/11 ]

Harshad,

Can you please verify that the original reported issue (without using enable-monitoring) is working with the additional step of accessing the pool as Jagadish had described above? I will send you the the steps for connector-connection-pool.

Comment by Harshad Vilekar [ 09/Feb/11 ]

> For non-DAS instances, application need to access the pool once so that the pool is initialized

Monitoring data looks good after the addition steps (similar to the steps suggested by Jagadish) are executed.

Comment by Byron Nevins [ 09/Feb/11 ]

D:\gf\v3\flashlight\framework\foo\framework>svn commit
Sending src\main\java\org\glassfish\flashlight\cli\DisableMonitoring.java
Sending src\main\java\org\glassfish\flashlight\cli\EnableMonitoring.java
Transmitting file data ..
Committed revision 45029.

==============
45028 was the same but checked into the trunk
==============

List of prerequisites from Nazrul and my answers:

  • Code review
    • Jennifer and Tom
  • Validate that the original reported issues is fixed
    • done by Jennifer
  • We have Dev Test(s) for this
    • 360 new tests
  • disable-monitoring with target=cluster is also working
    • Yes – also fixed and tested
  • Validate that there are no regressions due to this checkin
    • I did a lot of automated and manual testing. Homer reports that the 2 commands are not used by any QA tests.
Comment by Harshad Vilekar [ 21/Feb/11 ]

Original issue was verified on B42.





[GLASSFISH-15894] admin gui throws exception after configuring the admin with ldap using configure-ldap-for-admin command. Created: 08/Feb/11  Updated: 19/Dec/16  Resolved: 10/Feb/11

Status: Resolved
Project: glassfish
Component/s: rest-interface
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Attachments: XML File domain.xml     File ldap.diff     Text File server.log    
Tags: 3_1-approved

 Description   

Testcase:
---------
1. Configure admin with ldap credentials.
./asadmin configure-ldap-for-admin -basedn "dc=us,dc=oracle,dc=com"-url ldap://hostname:3060 --ldap-group sqestaticgroup
./asadmin configure-ldap-for-admin --basedn "dc=us,dc=oracle,dc=com" --url ldap://interop-oel54-2.us.oracle.com:3060 --ldap-group sqestaticgroup
LDAP server at ldap://interop-oel54-2.us.oracle.com:3060 is accessible.
...
The LDAP Auth Realm admin-realm was configured correctly in admin server's configuration.

Command configure-ldap-for-admin executed successfully.

2. Restart the domain.
3. Login into admin gui with ldap credentials.
4. Admin gui throws following exception when click on server-config->Security->Realms

java.lang.RuntimeException: com.sun.enterprise.security.auth.realm.BadRealmException: Operation not supported.

5. This error doesn't clear up when click on other links.(eg. Applications).

-Sarada.



 Comments   
Comment by Anissa Lam [ 08/Feb/11 ]

Can you attach server.log and domain.xml ?
You mentioned that the error doesn't clear up when click on other links afterward. Were you able to use GUI before going to the Realms page ? and then after that, it doesn't work anymore ?

Does the GUI works in other pages BEFORE you go to server-config > Security> Realms ?

Have you tried other CLI command, eg, create and start a cluster with 2 instances on remote machine, does it work for you ?

Comment by saradak [ 08/Feb/11 ]

The error seems to be appearing by clicking any link before going to the Realms page.

Even though the error appeared on top of the Applications page, I was able to deploy the application successfully.

Attached the server.log & domain.xml.

-Sarada.

Comment by Anissa Lam [ 08/Feb/11 ]

The realm is created and configured using CLI.
The exception is coming from the backend.

[#|2011-02-08T16:58:55.224-0800|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.com.sun.enterprise.v3.admin|_ThreadID=91;_ThreadName=Thread-1;|Exception in command execution : java.lang.RuntimeException: com.sun.enterprise.security.auth.realm.BadRealmException: Operation not supported.
java.lang.RuntimeException: com.sun.enterprise.security.auth.realm.BadRealmException: Operation not supported.
at org.glassfish.admin.rest.cli.SecurityUtil.getUserNames(SecurityUtil.java:238)
at org.glassfish.admin.rest.cli.SecurityUtil.getAnonymousUser(SecurityUtil.java:344)

Transfer to security for evaluation.

Comment by kumara [ 09/Feb/11 ]

User management is supported only for file realm. For LDAP realm, users have to be managed externally using tools relevant for the LDAP server.

The root cause of exception is that admin console authentication is doing "anonymous" user check on LDAP realm. The code needs to be modified to do the check only when file realm is being used.

Comment by Anissa Lam [ 09/Feb/11 ]

Should this checking be done in GUI or should getUserNames() be smart enough to handle this correctly ?
If in the GUI, I need to see how to detect whether file realm or ldap realm is used.

Comment by Anissa Lam [ 09/Feb/11 ]

Assign to REST.
Jason looked into this and have found the issue.
SecurityUtil.getAnonymousUser() loops through the configs until it finds an AuthRealm named "admin-realm", which happens to be 'default-config', instead of 'server-config'.
more testing and will request to fix in 3.1

Comment by Jason Lee [ 10/Feb/11 ]

How bad is its impact? (Severity)
This strikes me as a fairly major issue. Larger installations would be fairly likely to implement security through LDAP, in which case this becomes a constant and daily issue.

How often does it happen? (Frequency)
Every time where the DAS is configured to use LDAP for the admin realm

How much effort is required to fix it? (Cost)
Very little.

What is the risk of fixing it? (Risk)
The change occurs on the REST side where we determine if the anonymous user is enabled, so there's a risk that this functionality may be compromised. After implementing the fix, though, I ran the Console and REST dev test suites with no failure, so I'm pretty confident we haven't introduced a new bug here.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Not that I know of.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
N/A

How long has the bug existed in the product?
Since the anonymous user check was implemented.

Do regression tests exist for this issue?
Not specifically, no. To test this fully, the DAS must be configured to use LDAP for the admin realm, which requires a running LDAP server (the CLI to convert the admin realm fails if the LDAP server is unreachable). The non-LDAP case is still covered by existing tests, though, so we can be confident that the anon-user check works in that situation

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Console and REST dev tests.

When will a tested fix be ready for integration?
Diff attached.

Comment by Chris Kasso [ 10/Feb/11 ]

Approved for RC3.

Comment by Jason Lee [ 10/Feb/11 ]

Fix committed (branch r45039, trunk r45040)





[GLASSFISH-15893] Error while adding password for Domain in Domain/New Administrator Password page. Created: 08/Feb/11  Updated: 19/Dec/16  Resolved: 08/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Critical
Reporter: shaline Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: Windows 2008 Server
Browser firefox 3.6, IE8.


Attachments: PNG File admin-password-error.png    
Issue Links:
Duplicate
is duplicated by GLASSFISH-15988 Admin password in console gives an error Resolved
Tags: 3_1-approved, 3_1-regression, 3_1-verified

 Description   

Build used : GF v3.1 promoted b41. ( latest-ogs-windows.exe)

In the Admin Console Domain/Administrator Password tab, try to add a new password and click Save. Below Error is displayed:
An error has occurred
'CreateNew' is required for handler 'saveUser'!

In the Server.log there are no Exceptions, but the below message is displayed:

[#|2011-02-08T12:13:05.992-0800|INFO|oracle-glassfish3.1|org.glassfish.admingui|
_ThreadID=17;_ThreadName=Thread-1;|Exception Occurred :'CreateNew' is required f
or handler 'saveUser'!|#]

Attached screenshot.



 Comments   
Comment by Anissa Lam [ 08/Feb/11 ]

-How bad is its impact? (Severity)
medium high. user will not be able to use this screen to change admin password. Although there is workaround, this is in your face issue and commonly used function.

-How often does it happen? (Frequency)
Whenever user goes to domain page -> Admin Password page to change password. Given that we ship with no password as default, there may be many user using this feature.

-How much effort is required to fix it? (Cost)
1 hour.

-What is the risk of fixing it? (Risk)
extremely small. It only affects this one page.

-Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes, user can select server-config -> Security -> Realm ->admin-realm and Manage User from there.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes. I believe this is in the release note already, since we have to tell user who upgrade from v2 that this option is not supported. (someone better confirm thats this is in the release note)

-How long has the bug existed in the product?
Introduced recently.

-Do regression tests exist for this issue?
We probably didn't have dev test for this page. Otherwise we will catch that. I will add devtest for this.

-Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The usual test they run and the GUI dev test.
I have also tested this again by 'adding new user in other realm' , 'edit user i other realm' since this is calling the same java handler.

-When will a tested fix be ready for integration?
Ready now, svn diff attached.

~/Awork/V3/v3 1046) svn diff admingui/common
Index: admingui/common/src/main/resources/appServer/serverInstAdminPassword.jsf
===================================================================
— admingui/common/src/main/resources/appServer/serverInstAdminPassword.jsf (revision 44919)
+++ admingui/common/src/main/resources/appServer/serverInstAdminPassword.jsf (working copy)
@@ -69,7 +69,7 @@
onClick=" if ( checkPSW() ){ return submitAndDisable(this, '$resource

{i18n.button.Processing}

'); } return false; " >
<!command
prepareSuccessfulMsg();

  • saveUser( Realm="# {pageSession.authRealm}" configName="#{pageSession.configName}" UserId="#{sessionScope.userName}" GroupList="#{pageSession.group}" Password="#{pageSession.password}" );
    + saveUser( Realm="#{pageSession.authRealm}

    " configName="#

    {pageSession.configName}

    " UserId="#

    {sessionScope.userName}

    " GroupList="#

    {pageSession.group}

    " Password="#

    {pageSession.password}

    " CreateNew="false");
    />
    </sun:button>
    </sun:panelGroup>

Comment by Jason Lee [ 08/Feb/11 ]

Change looks good to me.

Comment by Chris Kasso [ 08/Feb/11 ]

Approved for RC3.

Comment by Anissa Lam [ 08/Feb/11 ]

Fix checked into trunk & 3.1 branch.
trunk: rev# 44997
3.1 branch: rev# 44998
========================

Log Message:
------------
GLASSFISH-15893. Add the required param for saveUser() in the Admin Password page.
fix is in trunk as well.
Reviewed by Jason
Approved by Chris.

Revisions:
----------
44998

Modified Paths:
---------------
branches/3.1/admingui/common/src/main/resources/appServer/serverInstAdminPassword.jsf

Comment by shaline [ 09/Feb/11 ]

Verified in Nightly GF build dated b42-02-09-2011.





[GLASSFISH-15881] [Intermittent] appclient hangs during dynamic cluster issue Created: 07/Feb/11  Updated: 19/Dec/16  Due: 13/Feb/11  Resolved: 15/Feb/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Blocker
Reporter: gopaljorapur Assignee: oleksiys
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File kernel-15881.patch     Java Archive File kernel.jar     Java Archive File kernel.jar     GZip Archive threaddump.tar.gz    
Tags: 3_1-approved, 3_1-verified

 Description   

This issue is seen intermittently

Since its a serious issue, I am filing a Blocker

This happens only on Solaris sparc platform

Scenario:
This issue happens when we run appclient with endpoints specified

I am reproducing the issue and providing environment to Tim Quinn for debugging



 Comments   
Comment by Tim Quinn [ 07/Feb/11 ]

Gopal,

Can you now reproduce this at will?

Have you been able to get a thread dump? This will be critical for us to progress on this.

Comment by gopaljorapur [ 07/Feb/11 ]

I can not reproduce this issue at will.

Though, occurances of hang is very high, we have seen it many times in our environment, I am trying to reproduce now, will give you the setup once I do

Comment by Chris Kasso [ 08/Feb/11 ]

It would be useful to capture in the issue which version of Solaris the problem has been seen on as well as specifics around how the cluster was changed. How many instances did you start with and how many did you add?

Can you also better characterize how often the issue is seen?

Once you start seeing the problem does each successive run of the appclient see the problem or does it remain intermittent?

Comment by gopaljorapur [ 08/Feb/11 ]

Its Solaris 10 Niagara SunFire T2000 machine

To start with we have 8 instances in the cluster, I add two instances later

Can you also better characterize how often the issue is seen?

  • The issue is seen 4-5 times

Now I am trying to reproduce, its not happening since 1-2 hrs

Once you start seeing the problem does each successive run of the appclient see the problem or does it remain intermittent?

  • It remains intermittent
Comment by Nazrul [ 08/Feb/11 ]

Spoke to Gopal today. He is unable to re-produce the issue (he is trying). I am excluding the issue for now from 3.1. If we can re-produce it, we will take a look.

Comment by gopaljorapur [ 08/Feb/11 ]

Finally, I am able to reproduce the issue

appclient is in hang state, I will send system info to Tim to check process state

I am trying to get thread dump, but its throwing following error

jstack -l 15269
15269: Unable to open door: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
root@bigapp-niagara-1 # jstack -F 15269
Attaching to process ID 15269, please wait...
Error attaching to process: Did not find libthread in target process/core!

Please remove 3_1-exclude tag

Comment by gopaljorapur [ 09/Feb/11 ]

Thread dump

Comment by Ken Cavanaugh [ 09/Feb/11 ]

From the ORB viewpoint, the only CORBA activity in any of the dumps is a waiting getClusterInstanceInfo
request in the appclient. This request is apparently for the first InitialContext creation, which happens
through a long chain of hk2 startup code triggered from app client initialization. It's apparent (since
there is no corba activity at all in any of the instances) that this request is not being handled, but it
also did not get an error. I think lazy init is used by defaujlt, because otherwise the getClusterInstanceInfo
would have failed with a connection error (since there is no sign of a CORBA selector thread that would be
listening for new ACCEPT events). Therefore the lightweight listener is active each server instance
and at least allowed the client to make a connection to a server instance.

Is it possible that somehow the lightweight listener (com.sun.enterprise.v3.service.impl.ServiceInitializerHandler)
lost the request from the client, and failed to start the ORB (clearly there is no ORB running in any
of the servers, since there are not ORB threads present in the thread dumps)? We may need help from
someone on the Grizzly team with this.

Comment by Tim Quinn [ 10/Feb/11 ]

[from Alexey's e-mail]

Hi guys,

Ken, absolutely agree with your comments, looks like the problem is in ServiceInitializerHandler... though as connection is getting accepted (not refused) - it means it's running, but the question is what happens then? Why Corba container is not getting started?

Is there any way to reproduce the issue? Some machine(s) + instructions available?

Thanks.

WBR,
Alexey.

Comment by Tim Quinn [ 10/Feb/11 ]

Because Alexey is currently investigating this problem further, I've transferred this issue to him.

Comment by Tim Quinn [ 10/Feb/11 ]

[From e-mail with Ken]

Tim: IIRC, the client ORB will randomize which endpoint it will use for bootstrapping.

Ken: That's correct.

Tim: And then once bootstrapped a given request for an EJB will be randomized among the currently-active server-side ORBs? (but is sticky once a given EJB is accessed from a given client)

Ken:Correct.

Tim: ...at some point the client is trying to bootstrap to an ORB or, having successfully bootstrapped, is trying to communicate with an EJB on a server but one or the other pathway is non-responsive.

ken: Yes, but from the stack trace, it is the first call from the client to the ORB, and unfortunately, the request neither
succeeds nor fails: it gets lost in limbo. The client will timeout in 30 minutes (which may as well be forever).

Tim: Is there client ORB logging he should turn on so we can tell which ORB is used for bootstrapping, whether bootstrapping succeeds, which ORB is used for the EJB, etc.?

Ken: Yes: turn on FINE logging for the javax.enterprise.system.core.naming logger. That will spit out various
somewhat obscure messages, but I think it will tell you what you want to know.

Comment by oleksiys [ 11/Feb/11 ]

hopefully the fix

Comment by oleksiys [ 11/Feb/11 ]

better fix

Comment by oleksiys [ 11/Feb/11 ]

diff patch

Comment by oleksiys [ 11/Feb/11 ]

The attached diff contains the fix for the lazy service initialization block.

The problem was that even though the lazy service initialization was running inside synchronized block, the reference to the service became available before the actual targetInitializer.initializeService() was called.
So there was a possibility for the newly accepted connection to be passed to the not initialized service, which might lead to unexpected issues depending on timing.

Comment by oleksiys [ 11/Feb/11 ]

diff

Comment by Ryan Lubke [ 11/Feb/11 ]

Alexey and I were talking about the attached changes prior to the meeting.
I'm OK with the changes. They are relatively minor.

Comment by Ryan Lubke [ 11/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature

How often does it happen? (Frequency)
issue is intermittent - depends on timing

How much effort is required to fix it? (Cost)
minimal (see attached patch)

What is the risk of fixing it? (Risk)
minimal - fix is straight forward.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

How long has the bug existed in the product?
Since 3.0 - but the issue surfaced during HA testing which wasn't done in 3.0.

Do regression tests exist for this issue?
No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
HA testing.

When will a tested fix be ready for integration?
2/11/2011

Comment by Ken Cavanaugh [ 11/Feb/11 ]

One thing I don't understand here: why is targetInitializer present at all (as a data member rather
than a local)?
This looks like an attempt to cache the targetInitializer, so that subsequent
calls to onAccept would run faster. But that seems to be incorrect: subsequent
calls to onAccept could be for different services.

Comment by Chris Kasso [ 11/Feb/11 ]

Approved for RC3 pending:

1) Resolving all code review comments. See Ken's comment in the issue.
2) I would like Gopal to confirm the patch fixes 15881.
3) A better understanding of where QA should focus testing. MQ/IIOP?
4) What tests have development performed to verify the fix does not introduce any regressions?

Comment by Ryan Lubke [ 11/Feb/11 ]

I believe it's currently designed such that there will be one ServiceInitializerThread/ServiceInitializerHandler per listener/service.

Comment by Ryan Lubke [ 11/Feb/11 ]

Patched kernel.jar

Comment by Ken Cavanaugh [ 11/Feb/11 ]

Ryan's comment makes sense to me. I thought of the same thing later,
after I made my previous comment.

Comment by Ryan Lubke [ 11/Feb/11 ]

Alexey's patch has been applied (r45070).

Will wait for Gopal's confirmation on his end before marking this as resolved.

Comment by Ryan Lubke [ 14/Feb/11 ]

Update from Gopal on 2/13/2011:

Hi Chris/Ryan,

The full HA run on the patch is not complete, yet

But, with whatever results we have, I dont see a hang (2 times full IIOP run is completed), also I dont see any regression issues (so far)

Comment by gopaljorapur [ 14/Feb/11 ]

We are using RC2 + Patch for verification of patch on a 4 machine 10 instance cluster

Since we are doing thorough verification of the issue, it is taking time to complete verification

Complete IIOP suite was run for 3 times to make sure hang is gone and no other regression is introduced, this happened till saturday evening (13th Feb)

From night of Feb 13, we have started the whole HA Suite , the run is still going on, 90% of the run is complete, so far, so good, no regressions, no hang seen

Comment by gopaljorapur [ 15/Feb/11 ]

hang is not seen, No regression seen with the patch, the issue can be marked as fixed





[GLASSFISH-15880] man pages not loaded for some locales Created: 07/Feb/11  Updated: 19/Dec/16  Resolved: 07/Feb/11

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

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

Tags: 3_1-approved

 Description   

The localized man pages are not loaded for some locales. The l10n man pages are provided in the following directory structure:
<top level dir>/lang_country_variant
the function getLocaleLocations in CLIManFinder.java is using "/" instead of "_" in the lookup



 Comments   
Comment by Tom Mueller [ 07/Feb/11 ]

Fixed on the trunk in revision 44964.
Waiting to mark this resolved until it is determined whether this needs to be fixed in 3.1.

Comment by Tom Mueller [ 07/Feb/11 ]

1. How bad is its impact? (Severity)

Is a regression of functionality or performance available in a prior release
Likely to generate a customer support call

2. How often does it happen? (Frequency)
This would happen for users that retrieve manual pages from asadmin in the following locales:
zh_TW, zh_CH, and pt_BR

3. How much effort is required to fix it? (Cost)
Very low. The change is already checked into the trunk. It just needs to be reviewed by another developer
and checked into the 3.1 branch.
4. What is the risk of fixing it? (Risk)
Very low.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No, short of the user extracting the manual page from the JAR file using the jar command.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No

7. How long has the bug existed in the product?
At least since July 2009 when this file was introduced to SVN. I expect it has always existed in 3.0. However, since manual pages were not translated before, the bug didn't show up.

8. Do regression tests exist for this issue?
No.

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Use asadmin to retrieve manual pages for default locale and the effected locales.

10. When will a tested fix be ready for integration?
Afternoon of Feb 7.

Comment by Nazrul [ 07/Feb/11 ]

Approved for checkin into RC3.

Comment by Tom Mueller [ 07/Feb/11 ]

Fixed in 3.1 branch revision 44968.





[GLASSFISH-15852] when duplicate network listener is added, Error is displayed for a protocol. Created: 04/Feb/11  Updated: 19/Dec/16  Resolved: 07/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

OS; Windows 2008
browser firefox. 3.6


Attachments: File web.diff    
Tags: 3_1-approved, 3_1-verified

 Description   

GF build used : promoted b40.

When we try to add a duplicate network listener, the error displayed is for the protocol. as below:
An error has occurred

{0}

protocol already exists. Cannot add duplicate protocol.

The Error should be displayed for the network listener.

Even when we leave the "Name" field in the "New Network Listener" screen empty, then the Pop UP window asks to "Enter Name for the Protocol". It should be for the network listener.



 Comments   
Comment by Anissa Lam [ 04/Feb/11 ]

negative testing. No function problem, we fix the error msg in 3.2

This kind of testing shouldn't be wait till 12 hours before RC2. code freeze

Comment by Anissa Lam [ 06/Feb/11 ]

I looked at this, this is a error msg from the backend.
If you do CLI create-protocol, you will see the

{0}

%asadmin create-protocol --target test AAA-protocol
remote failure: {0}

protocol already exists. Cannot add duplicate protocol.
Command create-protocol failed.

I have filed GLASSFISH-15871 for this.

When you create a network listener, you need to create a protocol first, and then the network listener. GUI lets you specify both in one screen. But still need to create the protocol first.

Since the protocol already exist, backend gives the above error and so GUI shows that to user.
It is correct that this protocol already exist, but because of the bug GLASSFISH-15871, it is confusing.
If you change the protocol name, this protocol will be created.
Then the next step is to create the network listener.
Now, if the listener exists, you will get the error that the listener already exist.

So, GUI is doing the correct thing. Change your protocol name to an non-existent one and you will see the error about duplicate network listener name.

Closing as Will not fix since this is expected behavior.

Comment by Anissa Lam [ 06/Feb/11 ]

GUI and backend is doing the correct thing. The protocol that needs to be created first for this listener is indeed duplicate. Once user change the name of the dup. protocol, he will get the error of dup. listener.

I am about to close this as will not fix, since this is expected.
However, for better user experience, I am going to add the check for dup. listener first, and inform user of that. But even if i add this check but try to use an existing protocol, they will still get the dup. protocol error msg. This will be expected.

Comment by Anissa Lam [ 06/Feb/11 ]

-How bad is its impact? (Severity)
GUI is doing the correct thing. But with GLASSFISH-15871 this is pretty confusing to user.

How often does it happen? (Frequency)
Whenever user wants to create a network listener, but also specify to create a new protocol that has already exist.

-How much effort is required to fix it? (Cost)
2 hours. The change of code is pretty trivial.

-What is the risk of fixing it? (Risk)
very small. Just add the test if network listener and protocol exist and inform user in that order. Instead of depending on backend.

-Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Doesn't need any work around, whatever GUI doing now is technically correct.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No.

How long has the bug existed in the product?
Probably since the beginning.

Do regression tests exist for this issue?
There are some devtest for realm, will need to add more for this case.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The usual test they run and the GUI dev test.

When will a tested fix be ready for integration?
Ready now, svn diff attached.

Comment by sirajg [ 07/Feb/11 ]

Changes look fine.

Comment by Anissa Lam [ 07/Feb/11 ]

Fix checked into both trunk and 3.1 branch.

Trunk: rev# 44965
Branch: rev# 44966

Project: glassfish
Repository: svn
Revision: 44966
Author: anilam
Date: 2011-02-07 19:45:30 UTC
Link:

Log Message:
------------
GLASSFISH-15852. Provide correct error msg to user when creating network listener. GUI checks if listener exists first before calling backend to create the protocol.
Fix checked into the trunk as rev# 44965

Reviewed by Siraj, Chris
Approved by Chris.

Revisions:
----------
44966

Modified Paths:
---------------
branches/3.1/admingui/web/src/main/resources/grizzly/protocolNewButtons.inc
branches/3.1/admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties
branches/3.1/admingui/web/src/main/resources/grizzly/networkListenerNew.jsf

Comment by shaline [ 09/Feb/11 ]

Verified in GF nightly build dated b42-02-09-2011





[GLASSFISH-15851] remove --upgrade option from start-local-instance Created: 04/Feb/11  Updated: 10/Feb/11  Resolved: 04/Feb/11

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

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

Issue Links:
Dependency
blocks GLASSFISH-15947 Remove --upgrade from start-local-ins... Resolved
Tags: 3_1-approved, 3_1-upgrade

 Description   

We seem to have --upgrade option in start-local-instance in the usage. Please get rid of it.

Usage: asadmin [asadmin-utility-options] start-local-instance
[--verbose[=<verbose(default:false)>]]
[--debug[=<debug(default:false)>]]
[--upgrade[=<upgrade(default:false)>]] [--sync <sync(default:normal)>]
[--nodedir <nodedir>] [--node <node>]
[?|-help[=<help(default:false)>]] [instance_name]



 Comments   
Comment by Byron Nevins [ 04/Feb/11 ]

I have the following proposed fix out for code review:
Index: src/main/java/com/sun/enterprise/admin/cli/cluster/StartLocalInstanceCommand.java
===================================================================
— src/main/java/com/sun/enterprise/admin/cli/cluster/StartLocalInstanceCommand.java (revision 44883)
+++ src/main/java/com/sun/enterprise/admin/cli/cluster/StartLocalInstanceCommand.java (working copy)
@@ -74,9 +74,6 @@
@Param(optional = true, defaultValue = "false")
private boolean debug;

  • @Param(optional = true, defaultValue = "false")
  • private boolean upgrade;
    -
    // handled by superclass
    //@Param(name = "instance_name", primary = true, optional = false)
    //private String instanceName0;
    @@ -147,7 +144,7 @@

launcher.launch();

  • if (verbose || upgrade) { // we can potentially loop forever here...
    + if (verbose) { // we can potentially loop forever here...
    while (true) {
    int returnValue = launcher.getExitValue();

@@ -197,10 +194,8 @@
info = launcher.getInfo();
info.setInstanceName(instanceName);
info.setInstanceRootDir(instanceDir);

  • info.setVerbose(verbose || upgrade);
    + info.setVerbose(verbose);
    info.setDebug(debug);
  • info.setUpgrade(upgrade);
    -
    info.setRespawnInfo(programOpts.getClassName(),
    programOpts.getClassPath(),
    respawnArgs());
Comment by Byron Nevins [ 04/Feb/11 ]

Reviewer: Tom Mueller
Approver: Nazrul Islam
Ran QL tests for completeness

========================
trunk:
D:\gf\v3\cluster\cli>svn commit
Sending cli\src\main\java\com\sun\enterprise\admin\cli\cluster\StartLocalInstanceCommand.java
Transmitting file data .
Committed revision 44909.

========================
3.1 branch:

D:\gf\v3\cluster\cli\3.1\cli>svn commit -F commit.txt
Sending src\main\java\com\sun\enterprise\admin\cli\cluster\StartLocalInstanceCommand.java
Transmitting file data .
Committed revision 44910.

Comment by Nazrul [ 04/Feb/11 ]

%asadmin start-local-instance --help shows --upgrade option. Please release note that this is incorrect.





[GLASSFISH-15850] Admin console: time-based session frequency need to be removed Created: 04/Feb/11  Updated: 19/Dec/16  Resolved: 08/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Attachments: JPEG File web-availability.jpg    
Tags: 3_1-approved, 3_1-verified

 Description   

We dont support time-based session frequency in 3.1, currently its available as an option in console, need to be removed

Steps to reproduce:

1. Install GlasFish 3.1
2. Create a cluster
3. Go to Admin console
Configurations->cluster-config->Availability Service > WebContainer Availability> Persistent Frequency

You will see time-based, this option is not supported in 3.1



 Comments   
Comment by Anissa Lam [ 04/Feb/11 ]

not showstopper, downgrade to P4.
I will request Rebecca to comment on this as well.

Comment by Nazrul [ 06/Feb/11 ]

Quality team requested to have a fix for this assuming this is low risk.

Comment by Anissa Lam [ 06/Feb/11 ]

It is not clear to me what exactly is the acceptable value for Persistence Frequency in the Wab Container Availability tab based on the comment from Rajiv:

>> In 3.1 we don't have support for time-based. So yes we should either default or only have
>> web-method for now. We may support time based in a future release.
>>
>> - Rajiv

What is the 'default' ? and what is acceptable value ?
Currently, GUI shows this as a drop down with 2 choices: "time-based" and "web-method".
(refer to attached screen).
If 'time-based' is not supported, and only "web-method" is, there is no point of providing this dropdown, I will just remove that, won't even pass in this value, unless there are other possible values.

I looked at the config-api comment, it doesn't seem to be correct and confusing. Is "web-event" supported now ?

Please let me know clearly what is the options and what is default.

/**

  • Gets the value of the persistenceFrequency property.
    *
  • The persistence frequency used by the session persistence framework,
  • when persistence-type = "ha". Values may be "time-based" or "web-event"
  • If it is missing, then the persistence-type will revert to "memory".
  • @return possible object is
  • {@link String }

    */
    @Attribute (defaultValue="web-method")
    public String getPersistenceFrequency();

Comment by Nazrul [ 07/Feb/11 ]

The drop down will have one value after we remove time-based.

Comment by Mahesh Kannan [ 07/Feb/11 ]

Looks like the javadoc should be:

/**

  • Gets the value of the persistenceFrequency property.
  • The persistence frequency used by the session persistence framework,
  • when persistence-type = "ha". Values may be "time-based" or "web-method"
  • If it is missing, then the persistence-type will revert to "memory".
  • @return possible object is
  • {@link String }

    */

So, The drop down box should just have "web-method".

Comment by Chris Kasso [ 07/Feb/11 ]

Was time-based session frequency available in prior versions (v2.1 or 3.0.1)? If so what's the story for users upgrading from those releases?

I agree with Anissa it makes no sense to have a drop down with one item. Is this something that can be enabled or disabled (e.g. via a check box) if not then does it need any representation in the Console?

Comment by Nazrul [ 07/Feb/11 ]

time-based policy was supported in 2.x. 3.1 does not have this support. So, this is a functionality issue.

re: converting to a check box, etc. ... may lead to more code changes at this point

Comment by Anissa Lam [ 08/Feb/11 ]

I have decided to just remove the 'time-based' option from the dropdown, even though it means there is only one selection left, instead of hiding Session Frequency completely.
1. If user upgrade from v2, they can see that it has been changed to 'web-method' and this gives them the chance to save it back to 'web-method'.
2. Too late to change the context-sensitive OLH, which talks about time-based and web-method. Remove this dropdown will cause more confusion. With this, I added one more sentence in the help underneath saying only web-method is supported for 3.1

-How bad is its impact? (Severity)
minimal. Even if user sets to 'time-based', backend probably just ignore that.

How often does it happen? (Frequency)
Every time when user goes to the Web Container Availability page

-How much effort is required to fix it? (Cost)
1 hour.

-What is the risk of fixing it? (Risk)
extremely small.

-Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
I guess backend probably just ignore this 'time-based' option.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes. I believe this is in the release note already, since we have to tell user who upgrade from v2 that this option is not supported. (someone better confirm thats this is in the release note)

How long has the bug existed in the product?
Ever since we add availability configuration support in 3.1

Do regression tests exist for this issue?
Yes, there are dev tests written for this.

I have manually tested:

  • config that has 'time-based' set (upgrade case) and can be saved to 'web-method' properly.
  • out-of-box config that doesn't have this attribute specified in domain.xml (ie, defaulting to web-method), can be saved properly.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The usual test they run and the GUI dev test.

When will a tested fix be ready for integration?
Ready now, svn diff attached.

~/Awork/V3/v3 1005) svn diff admingui/web
Index: admingui/web/src/main/resources/configuration/webAvailabilityService.jsf
===================================================================
— admingui/web/src/main/resources/configuration/webAvailabilityService.jsf (revision 44890)
+++ admingui/web/src/main/resources/configuration/webAvailabilityService.jsf (working copy)
@@ -96,7 +96,7 @@
</sun:dropDown>
</sun:property>
<sun:property id="PersistenceFrequencyProp" labelAlign="left" noWrap="#

{true}" overlapLabel="#{false}" label="$resource{i18n_web.availability.persistenceFreq}" helpText="$resource{i18n_web.availability.persistenceFreqHelp}">
- <sun:dropDown id="PersistenceFrequency" selected="#{pageSession.valueMap['persistenceFrequency']}" labels={"time-based", "web-method"} />
+ <sun:dropDown id="PersistenceFrequency" selected="#{pageSession.valueMap['persistenceFrequency']}" labels={"web-method"} />
</sun:property>
<sun:property id="PersistenceScopeProp" labelAlign="left" noWrap="#{true}

" overlapLabel="#

{false}

" label="$resource

{i18n_web.availability.persistenceScope}

" helpText="$resource

{i18n_web.availability.persistenceScopeHelp}

">
<sun:dropDown id="PersistenceScope" selected="#

{pageSession.valueMap['persistenceScope']}

" labels=

{"session", "modified-session", "modified-attribute"}

/>
Index: admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties
===================================================================
— admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties (revision 44965)
+++ admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties (working copy)
@@ -430,7 +430,7 @@
availability.persistenceType=Persistence Type:
availability.persistenceTypeHelp=HTTP session persistence mechanism.
availability.persistenceFreq=Persistence Frequency:
-availability.persistenceFreqHelp=Frequency at which the HTTP session is stored.
+availability.persistenceFreqHelp=Frequency at which the HTTP session is stored. Only 'web-method' is supported for 3.1
availability.persistenceScope=Persistence Scope:
availability.persistenceScopeHelp=Scope of HTTP session changes required for storage to occur.
availability.singleSignOn=Single-Sign-On State:

Comment by sirajg [ 08/Feb/11 ]

Is it possible to have an "empty" value for Session Frequency? If yes, changes look fine. If not, we could just make it a read-only (Static Text) field?

Comment by Anissa Lam [ 08/Feb/11 ]

One cannot set an attribute to "" , there was previous discussion in the admin alias about this.
This attribute has the default value "web-method" when not specified. I prefer not to change that to text field for min. code change.
A static text field will not be saved when submitting the page, which means i need to add more logic/code to save this back to 'web-method' if using a static text field.

Comment by Chris Kasso [ 08/Feb/11 ]

Approved for RC3.

Comment by Anissa Lam [ 08/Feb/11 ]

Fixed in trunk & 3.1 branch
trunk: rev# 44995
3.1 branch: rev# 44996

===========

Project: glassfish
Repository: svn
Revision: 44995
Author: anilam
Date: 2011-02-08 19:21:39 UTC
Link:

Log Message:
------------
GLASSFISH-15850. Remove 'time-based' option from Session Frequency in the Web Container Availability page.

Reviewed by Siraj
Approved by Chris.

Revisions:
----------
44995

Modified Paths:
---------------
trunk/v3/admingui/web/src/main/resources/org/glassfish/web/admingui/Strings.properties
trunk/v3/admingui/web/src/main/resources/configuration/webAvailabilityService.jsf





[GLASSFISH-15848] Cannot add another target to application when primary target deleted Created: 04/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 04/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Attachments: JPEG File error-cannot-add-target.JPG     JPEG File error-when-target-deleted.JPG     Text File server.log    
Tags: 3_1-approved, 3_1-verified

 Description   

This is a P3 scenario and thus has not been tested yet. Steps to reproduce:

1. Create a standalone instance and start it.
2. Deploy an application to this instance, e.g. clusterjsp.ear
3. Stop instance and delete it.
4. Go to Applications page, and click on clusterjsp application. Issue 1: the following error is displayed:

An error has occurred
REST Request 'http://localhost:4848/management/domain/servers/server/server/application-ref/clusterjsp' failed with response code '404'.

5. On the same page select "server" in Virtual Servers box and click Save in an attempt to add server as a target for this application. Issue 2: the following error is displayed:

An error has occurred
Could not apply changesNo configuration found for servers.server.server.application-ref.clusterjsp

Workaround for the above is to undeploy the application and deploy it again, thus I'm ok with excluding this for 3.1 release, but I'll leave it for you to decide.



 Comments   
Comment by Anissa Lam [ 04/Feb/11 ]

This is an issue that kind of make sense out of the many ones that has been filed today.
For a DAS only system, application-ref for the DAS is ALWAYS expected. But for the case where the application is deployed to an instance only, and then the instance is deleted, application-ref doesn't exist for this app.
Even though i don't think this is a production environment use case, would like to fix this for 3.1, otherwise domain.xml is in a less-than expected state.

-How bad is its impact? (Severity)
medium. Cannot edit an application that was 'left over' from deleted instance.

How often does it happen? (Frequency)
whenever the app is deployed to some target, and then the system changed to a DAS only system.

-How much effort is required to fix it? (Cost)
3 hours.

-What is the risk of fixing it? (Risk)
should be low. We are not writing any new code. Just have to call some existing method to add back the application-ref element for DAS when it is a DAS only system.

-Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
yes. user should be able to undeploy this application and redeploy to DAS.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No.

How long has the bug existed in the product?
Probably since we support targets for deployment.

Do regression tests exist for this issue?
No. We have problem in adding devtest to the deploy screen, Jason has it in his task list.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The usual test they run and the GUI dev test.

When will a tested fix be ready for integration?
Ready now, svn diff included here.

~/Awork/V3/v3/admingui 775) svn diff common
Index: common/src/main/java/org/glassfish/admingui/common/util/DeployUtil.java
===================================================================
— common/src/main/java/org/glassfish/admingui/common/util/DeployUtil.java (revision 44894)
+++ common/src/main/java/org/glassfish/admingui/common/util/DeployUtil.java (working copy)
@@ -256,6 +256,12 @@
if (clusters.isEmpty() && standalone.isEmpty()){
//just return Enabled or not.
enabled = (String)RestUtil.getAttributesMap(prefix "/servers/server/server/"+ref"/"+appName).get("enabled");
+ //for DAS only system, there should always be application-ref created for DAS. However, for the case where the application is
+ //deploye ONLY to a cluster/instance, and then that instance is deleted. The system becomes 'DAS' only, but then the application-ref
+ //for DAS will not exist. For this case, we just look at the application itself
+ if (enabled == null)

{ + enabled = (String)RestUtil.getAttributesMap(prefix +"/applications/application/" + appName).get("enabled"); + }

if (useImage)

{ return (Boolean.parseBoolean(enabled))? "/resource/images/enabled.png" : "/resource/images/disabled.png"; }

else{
Index: common/src/main/resources/applications/appEdit.layout
===================================================================
— common/src/main/resources/applications/appEdit.layout (revision 44894)
+++ common/src/main/resources/applications/appEdit.layout (working copy)
@@ -60,8 +60,14 @@
setPageSessionAttribute(key="appRefUrl" value="#

{sessionScope.REST_URL}

/servers/server/server/application-ref/#

{pageSession.encodedAppName}

");
gf.onlyDASExist(onlyDAS="#

{pageSession.onlyDASExist}");
gf.getEntityAttrs(endpoint="#{pageSession.selfUrl}", valueMap="#{pageSession.valueMap}");
- gf.getTargetEnableInfo(appName="#{pageSession.appName}" status="#{pageSession.status}")
if (#{pageSession.onlyDASExist}

){
+
+ gf.checkIfEndPointExist(endpoint="#

{pageSession.appRefUrl}" exists="#{requestScope.exist}");
+ if (! #{requestScope.exist}){
+ convertListToArray(list={"server"} array="#{requestScope.target}" );
+ gf.changeAppTargets(appName="#{pageSession.appName}" targets="#{requestScope.target}" status="true");
+ setPageSessionAttribute(key="status" value="true");
+ }
gf.getEntityAttrs(endpoint="#{pageSession.appRefUrl}

" valueMap="#

{pageSession.valueMap2}");
mapPut(map="#{pageSession.valueMap2}

" key="enabled" value="#

{pageSession.status}");
setPageSessionAttribute(key="origState" value="#{pageSession.status}

");
@@ -70,6 +76,7 @@
}

if (!#

{pageSession.onlyDASExist}

){
+ gf.getTargetEnableInfo(appName="#

{pageSession.appName}

" status="#

{pageSession.status}

")
setPageSessionAttribute(key="finalShowVS" value="#

{false}

");
setPageSessionAttribute(key="finalShowAvail" value="#

{pageSession.showAvailability}

");
}

Comment by sirajg [ 04/Feb/11 ]

Changes look fine.

Comment by Chris Kasso [ 04/Feb/11 ]

Approved for RC2.

Comment by Anissa Lam [ 04/Feb/11 ]

Fix checked into both trunk & 3.1 branch.
trunk: rev# 44920
3.1 branch: rev# 44921

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

Project: glassfish
Repository: svn
Revision: 44920
Author: anilam
Date: 2011-02-05 00:33:22 UTC
Link:

Log Message:
------------
GLASSFISH-15848. Add application-ref to "server" for any application that doesn't have this ref when the system is a DAS only system.

Reviewed by Siraj
Approved by Chris

Revisions:
----------
44920

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/util/DeployUtil.java
trunk/v3/admingui/common/src/main/resources/applications/appEdit.layout

Comment by lidiam [ 04/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-15844] need to integrate l10n packages Created: 04/Feb/11  Updated: 19/Dec/16  Resolved: 04/Feb/11

Status: Resolved
Project: glassfish
Component/s: l10n
Affects Version/s: None
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved

 Description   

Fix for bug GLASSFISH-15781 introduced new message that need translation. Need to integrate l10n packages for the new translations.

How bad is its impact? Critical

How often does it happen? always

How much effort is required to fix it? 1/2 day

What is the risk of fixing it? low

Does a work aroundfor the issue exist? no

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes? no

Howlong has the bug existed in the product? since build 39

Do regression tests existfor this issue? yes

Which tests should QA (re)run to verify the fix did not destabilize GlassFish? l10n testing

When will a tested fix be readyfor integration? Feb-04-2011



 Comments   
Comment by Nazrul [ 04/Feb/11 ]

Approved for checkin in RC2.

Comment by gmurr [ 04/Feb/11 ]

integrated packages with new transaltions





[GLASSFISH-15831] Regression: Exception printed on screen when deploying scrumtoys application second time Created: 03/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 08/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Minor
Reporter: lidiam Assignee: Anissa Lam
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ogs-3.1-b40.zip


Attachments: JPEG File deploy-exception.JPG     File scrumtoys.war     Text File server.log     JPEG File warning.jpg    
Tags: 3_1-approved, 3_1-regression

 Description   

The scrumtoys application requires derby database running and a jdbc resource created. When the application is deployed to DAS and the resource does not exist, an exception is printed on the GUI page.

Steps to reproduce:
1. Start database.
2. In Admin Console, deploy scrumtoys application (you can access it to see that it works).
3. Undeploy the application.
4. Deploy it again and the following exception is displayed on the screen:

HTTP Status 500 -

type Exception report

message

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

exception

javax.servlet.ServletException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'uploadButton'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'command' event for 'uploadButton'.

root cause

java.lang.reflect.InvocationTargetException

root cause

java.lang.UnsupportedOperationException

I have reinstalled Glassfish a couple times to verify that this exception happens on the clean install.

While the application may be invalid (I'll check with JSF team if I have the latest version, since there some issues with this app in the past, e.g. see a related http://java.net/jira/browse/GLASSFISH-14942 issue), Admin Console should not throw an exception on the screen.



 Comments   
Comment by lidiam [ 03/Feb/11 ]

I've checked that I'm using the latest scrumtoys application.

Also, this is definitely a regression, though I am unable to point to a specific build when this worked. Judging by other issues (e.g. http://java.net/jira/browse/GLASSFISH-14741), it must have been before build b30, since DAS deployment was tested before standalone instances.

Comment by Anissa Lam [ 04/Feb/11 ]

You mention this is a regression, do you remember about what time this particular case is working ? I don't think thats the case.

I agree that we shouldn't show exception on screen, however, this is the only application that have this effect. Somehow, during deployment of this app, we even lost the context of the request, which should never happen. This is failing in a util method that was used in all pages, to store the warning message to the request scope attribute map.

Here is what happens: Deployment succeed with WARNING. when we try to save this WARNING to the request scope, this line
Map attrMap = FacesContext.getCurrentInstance().getExternalContext().getRequestMap();
returns an abstract map. This should never happen.

Also, if you deploy this to any other cluster/instance, this strange situation won't happen, and the WARNING will be displayed correctly. (see attached)

So, only when you deploy this app to DAS that you encounter such strange situation.

Work around: deploy to other target, then add "server" as the target, it will be fine.
Also, once you see this exception, most likely you will click the Applications tree node again. This will show you the application is deployed.

The best I can do now is to catch the Exception thrown that is caused by writing to an Abstract Map. This means GUI will get back to the Applications table and show the user the app is deployed. But we won't be able to show the warnings.

User will still see all those exception in server.log, thrown by the backend relating to the database connection etc.

This will fix the exception shown on the screen issue, and we will downgrade this to a P4.

Comment by Anissa Lam [ 04/Feb/11 ]

Discussed this in the bug swat meeting.
For this bug, I will add the catch to this 'completely unexpected' exception, so the stack trace will not be printed on screen.
When deploy to any other target, the warning will show up as expected.
When deploy to DAS, user won't see the warning. Application table will show up and the app is indeed deployed.

Comment by Anissa Lam [ 04/Feb/11 ]

How bad is its impact? (Severity)
kind of low. We were able to deploy this app which causes all kinds of exceptions in the backend, but we showed a stack trace on screen which is a no-no.

How often does it happen? (Frequency)
ONLY when deploy this application, and ONLY when this is deployed to DAS. If deploy to other target, the warning shows up fine.

How much effort is required to fix it? (Cost)
Spent lots of time in trying to see why GUI cannot even get the context request map after this application is deployed, in vein. Decided to catch this very unexpected exception. Adding this catch statement is easy

What is the risk of fixing it? (Risk)
extremely low.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
There isn't really a work around for not showing the exception on screen.
However, once the user see this exception, the next thing they probably do is click the applications tree node again, or reload the GUI. Any action will clean up the screen and the applications table shows this app has been deployed.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No.

How long has the bug existed in the product?
I have no idea. Whatever GUI does shouldn't result in not getting the context request map.

Do regression tests exist for this issue?
No. We have problem in adding devtest to the deploy screen, Jason has it in his task list.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The usual test they run and the GUI dev test. But the code change is just catching an exception. It really shouldn't cause any harm.

When will a tested fix be ready for integration?
Ready now, svn diff included here.

Index: src/main/java/org/glassfish/admingui/common/util/GuiUtil.java
===================================================================
— src/main/java/org/glassfish/admingui/common/util/GuiUtil.java (revision 44894)
+++ src/main/java/org/glassfish/admingui/common/util/GuiUtil.java (working copy)
@@ -426,6 +426,8 @@

  • If type is not specified, it will be "information" by default.
    */
    public static void prepareAlert(String type, String summary, String detail) {
    +
    + try {
    Map attrMap = FacesContext.getCurrentInstance().getExternalContext().getRequestMap();
    if (isEmpty(type)) {
    attrMap.put("alertType", "information");
    @@ -438,11 +440,11 @@
    if (detail != null && detail.length() > 1000) { detail = detail.substring(0, 1000) + " .... " + GuiUtil.getMessage("msg.seeServerLog"); }
  • try { + attrMap.put("alertDetail", isEmpty(detail) ? "" : URLEncoder.encode(detail, "UTF-8")); attrMap.put("alertSummary", isEmpty(summary) ? "" : URLEncoder.encode(summary, "UTF-8")); - }

    catch (UnsupportedEncodingException ex)

    { - //we'll never get here. + }

    catch (Exception ex) {
    + //we'll never get here. , well except for GLASSFISH-15831
    GuiUtil.getLogger().info(GuiUtil.getCommonMessage("log.error.prepareAlert") + ex.getLocalizedMessage());
    if (GuiUtil.getLogger().isLoggable(Level.FINE)){
    ex.printStackTrace();

Comment by sirajg [ 04/Feb/11 ]

Changes look fine. For 3.2, may be we can take another look at exception handling.

Comment by Chris Kasso [ 04/Feb/11 ]

Approved for RC2.

Comment by lidiam [ 04/Feb/11 ]

Anissa, the warning you got (in the attached screenshot) means that the database was most likely not started before deploying the app. In my case database is running and I see the following warning (from the attached server.log files):

java.sql.SQLException: Table/View 'PROJECTS' already exists in Schema 'APP'

So the issue is that the application tries to create tables that already exist from previous deployment. I'm not sure if it's supposed to be part of undeployment to clear those tables.

Comment by Anissa Lam [ 04/Feb/11 ]

I have checked in the fix to catch any unexpected exception, so no stack trace shown on screen.
I am going to downgrade this to P4, and when we have more cycle to get to the bottom of this context request issue, we will revisit.

Fix checked into both trunk and 3.1 branch.
trunk: rev# 44903
3.1 branch: rev# 44904.

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

Project: glassfish
Repository: svn
Revision: 44904
Author: anilam
Date: 2011-02-04 19:19:19 UTC
Link:

Log Message:
------------
GLASSFISH-15831. Catch unexpected exception to ensure stack trace won't show on screen.

Fix checked into the trunk as rev# 44903

Reviewed by Siraj
Approved by Chris

Revisions:
----------
44904

Modified Paths:
---------------
branches/3.1/admingui/common/src/main/java/org/glassfish/admingui/common/util/GuiUtil.java

Comment by marina vatkina [ 04/Feb/11 ]

The app is set not to drop tables on undeploy:
<property name="eclipselink.ddl-generation" value="create-tables"/>

Comment by lidiam [ 08/Feb/11 ]

verified in promoted build b41





[GLASSFISH-15823] Executed create-file-user, then in Admin GUI tried to change password of this user, saw an error and a user was deleted Created: 03/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 04/Feb/11

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

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

Attachments: File common.diff     File NileBookStore.war     Java Archive File ojdbc14.jar    
Tags: 3_1-approved

 Description   

Build 41 02/03. OEL machines. Created a cluster (c1) with three instances on three machines.

Was used FireFox browser: 3.6.13

Created using a CLI file-user, i.e. executed: asadmin create-file-user --target c1 --groups user test. Entered password test.

In admin GUI opened: c1-config/Security/Realms/file. Then clicked Manage Users and saw this user test. Clicked on test. In Edit File Realm User saw
New Password:
Confirm New Password:

Both these fields were empty, I believe dots have to be there, because a password was created. I've typed new password in these fields and clicked save. But then saw a message on the screen:

An error has occurred
DELETE https://localhost:4848/management/domain/configs/config/c1-config/security-service/auth-realm/file/delete-user?target=c1-config&username=test returned a response status of 500

In domain server.log I saw such messages:

[#|2011-02-03T17:37:38.636-0800|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=240;_ThreadName=Thread-1;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

[#|2011-02-03T17:37:38.644-0800|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=271;_ThreadName=Thread-1;|SEC1117: Realm [file] successfully updated.|#]

[#|2011-02-03T17:37:41.177-0800|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=52;_ThreadName=Thread-1;|Exception Occurred :DELETE https://localhost:4848/management/domain/configs/config/c1-config/security-service/auth-realm/file/delete-user?target=c1-config&username=test returned a response status of 500|#

When I clicked again on file, I did not see this user in a list. I've executed asadmin list-file-users c1 and this user was not listed. So the user was just deleted.



 Comments   
Comment by Anissa Lam [ 03/Feb/11 ]

#1. regarding displaying *** for the password field during edit. GUI has no way of knowing if the user has password or not. Maybe file an RFE to security to provide an API for GUI to know if pswd exists.

#2. I looked at the code, for edit, the code is deleting the user first, and then re-create it with the new info. I don't know why it is like this. I think we should use the 'update-file-user' command for this. Will look into this.
This brings out another question, why deleting the use returns FAILURE when the user is actually deleted. Still looking.

Comment by easarina [ 03/Feb/11 ]

Opened RFE: http://java.net/jira/browse/GLASSFISH-15824

Regarding empty password field.

Comment by Anissa Lam [ 03/Feb/11 ]

How bad is its impact? (Severity)
medium. Not able to edit any file realm user of remote machine.

How often does it happen? (Frequency)
Everytime trying to edit existing user.

How much effort is required to fix it? (Cost)
6 hours

What is the risk of fixing it? (Risk)
pretty low. localized to create/edit file user.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Use CLI

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

How long has the bug existed in the product?
Probably for a long time, ever since we change to REST and support multi-config.

Do regression tests exist for this issue?
Probably not, otherwise this would have been caught. I will make sure devtest will be added, either by me or Srini.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
GUI Dev Tests.

When will a tested fix be ready for integration?
Ready now, the diff is attached.

Summary of what has been changed:
1. For editing, use update-file-user command instead of deleting it first then recreate. To fix this, the following change is made:

  • change CreateNew to String and make that a required input to the handler. This makes it clear and avoid false assumption.
  • change the call to post() to restRequest(), this will ensure if there is any WARNING, like saving when the instance is not running, be shown to screen. Using post() directly will not have this info to user.

2. while testing, the edit user screen doesn't interpret multi-groups retrieved from backend correctly. It just takes/shows the first group. Fix this issue as well.

svn diff is attached.

Comment by Chris Kasso [ 04/Feb/11 ]

Approved for RC2.

Comment by Jason Lee [ 04/Feb/11 ]

Diff looks fine.

Comment by easarina [ 04/Feb/11 ]

Attached the app and ojdbc14.jar

Comment by easarina [ 04/Feb/11 ]

The comment here is intended for GLASSFISH-15832.
I moved the comment there to avoid confusion.

Comment by Anissa Lam [ 04/Feb/11 ]

Fix checked into both trunk and branch 3.1
trunk rev#44900
3.1 branch: rev# 44901

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

Project: glassfish
Repository: svn
Revision: 44901
Author: anilam
Date: 2011-02-04 17:37:16 UTC
Link:

Log Message:
------------
GLASSFISH-15823

Summary of what has been changed:
1. For editing, use update-file-user command instead of deleting it first then recreate. To fix this, the following change is made:

  • change CreateNew to String and make that a required input to the handler. This makes it clear and avoid false assumption.
  • change the call to post() to restRequest(), this will ensure if there is any WARNING, like saving when the instance is not running, be shown to screen. Using post() directly will not have this info to user.

2. while testing, the edit user screen doesn't interpret multi-groups retrieved from backend correctly. It just takes/shows the first group. Fix this issue as well.

Checked into the trunk already as rev#44900

Reviewed by Srini, Jason
Approved by Chris Kaaso

Revisions:
----------
44901

Modified Paths:
---------------
branches/3.1/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java
branches/3.1/admingui/common/src/main/resources/security/realms/manageUserEdit.jsf
branches/3.1/admingui/common/src/main/java/org/glassfish/admingui/common/util/RestUtil.java
branches/3.1/admingui/common/src/main/resources/security/realms/manageUserNew.jsf





[GLASSFISH-15820] start-local-instance prompts for master password even though save-master-password is used Created: 03/Feb/11  Updated: 04/Feb/11  Resolved: 04/Feb/11

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

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

Tags: 3_1-approved

 Description   

Carla was trying to verify one of her bugs 14850 and ran into this issue.
Here is the gist of the issue from Carla's email.
"
On DAS machine:

create a domain with the master-password set to "welcome1" using the command
asadmin create-domain --savemasterpassword true --passwordfile ~/passfile3 domain2

create an ssh node using
asadmin create-node-ssh --nodehost adc2190111 --installdir /scratch/gf/cmott/glassfish3 node2

create an instance (on instance machine). This works fine

asadmin create-instance --node node2 ins2

If I try to start ins2 I get an error which I expected.

On the instance machine I try to set the master password.
asadmin change-master-password --savemasterpassword true --nodedir /scratch/gf/cmott/glassfish3/glassfish/nodes node2

This seems to set the master-password and creates a file called master-password in the agent dir of the node node2

Now I see the following:

on the DAS if I try to start the instance using

asadmin start-instance ins2
I get a failure

on the instance machine if I try to start the instance using

asadmin start-local-instance ins2

I am prompted for the master password and it will start once that is supplied.

If I create a new instance on the instance machine using

asadmin create-local-instance --usemasterpassword true --host dhcp-santaclara22-1fl-west-10-132-181-59.usdhcp.oraclecorp.com --node node2 ins3

I am prompted for the master password and the instance is created.

If I try to start the instance using start-local-instance I am also prompted for the master password. asadmin start-local-instance ins3

I can't seem to start the instance without providing the master password as the instance is starting. This means that the user will not be able to administer the instances from a central location.
I thought that we should be able to start the instances without prompting if the master passwords were the same on both instance and the DAS. What am I missing?"



 Comments   
Comment by Bhakti Mehta [ 03/Feb/11 ]

How bad is its impact? (Severity)

This is an in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)
This will happen all the time when master password is used with start-local-instance

How much effort is required to fix it? (Cost)
Less effort I have a patch and am trying all cases right now

What is the risk of fixing it? (Risk)
Minor risk.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
There is no workaround other than entering the master password when instance is starting. If possible I would really like to fix this regression I introduced with my commit 44449

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
It would be preferable to fix this issue

How long has the bug existed in the product?
From Jan 12 2011

Do regression tests exist for this issue?
Yes I will run my tests and also have requested Carla to verify my fix

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
I dont think QA runs tests with master password. Will check with them

When will a tested fix be ready for integration?
Feb4

Comment by Nazrul [ 03/Feb/11 ]

Approved for checkin pending review from Tom/Joe.

Comment by Bhakti Mehta [ 04/Feb/11 ]

Committed on trunk and branch

Sending admin/cli/src/main/java/com/sun/enterprise/admin/cli/LocalServerCommand.java
Sending cluster/cli/src/main/java/com/sun/enterprise/admin/cli/cluster/LocalInstanceCommand.java
Transmitting file data ..
Committed revision 44908.

Sending admin/cli/src/main/java/com/sun/enterprise/admin/cli/LocalServerCommand.java
Sending cluster/cli/src/main/java/com/sun/enterprise/admin/cli/cluster/LocalInstanceCommand.java
Transmitting file data ..
Committed revision 44907.





[GLASSFISH-15808] Log Viewer: cannot delete instance once launched log viewer Created: 02/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 05/Feb/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_dev
Fix Version/s: None

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

two windows machines with ssh enabled, build promoted b40


Attachments: XML File domain.xml     JPEG File logviewer-cannot-delete-instance.JPG     JPEG File logviewer-files-after-delete.JPG     Text File server.log    
Tags: 3_1-approved

 Description   

Steps to reproduce:

1. Create a remote, SSH node on a windows system, specifying a custom install dir, e.g. C:\as\v31 (probably not necessary).
2. Create an instance under this node and start it.
3. Launch Log Viewer for this instance and close it.
4. Stop intance and attempt to delete it. The following error is displayed:

Command succeeded with Warning
Successfully removed instance om2 from the DAS configuration, but failed to remove the instance files from node 42 (jed-asqe-42.us.oracle.com). Command failed on node 42 (jed-asqe-42.us.oracle.com): UTIL6046: Attempt to rename C:\as\v31\glassfish3\glassfish\nodes\42\om2 to C:\as\v31\glassfish3\glassfish\nodes\42\oldinst6160770375853316950.tmp failed after 6 retries Unable to delete the instance directory: C:\as\v31\glassfish3\glassfish\nodes\42\om2 The directory still exists after trying to delete it., whackee=C:\as\v31\glassfish3\glassfish\nodes\42\om2, files in parent:C:\as\v31\glassfish3\glassfish\nodes\42\agent, C:\as\v31\glassfish3\glassfish\nodes\42\om2, , new wackee.exists=true Command _delete-instance-filesystem failed. To complete this operation run the following command locally on host jed-asqe-42.us.oracle.com from the GlassFish install location C:\as\v31\glassfish3: asadmin delete-local-instance --node 42 om2



 Comments   
Comment by lidiam [ 02/Feb/11 ]

If I manually try to delete the instance directory on the remote windows host, I get permission denied error. However, I can delete server.log and then can manually delete the instance directory on the remote machine. If the Log Viewer window remains open, neither the server.log file nor the instance directory can be deleted.

Also, if I follow the same steps creating node and instance, start it but do not launch Log Viewer, I can delete the instance from Admin Console just fine.

Comment by Anissa Lam [ 02/Feb/11 ]

Sounds like file locking issue.
GUI doesn't open/close any logging file. And you also mentioned that
" 3. Launch Log Viewer for this instance and close it.
4. Stop intance and attempt to delete it. The following error is displayed: "
which again confirm that it is not the log viewer problem.

Transfer to logging for evaluation.

If i read this correctly, once you try to view the logs through the log viewer, then you can never able to delete the instance. This sounds more than a P3. upgrade to P2.

Comment by naman_mehta [ 04/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Introduces an incompatibility
  • Likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature
  • An in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)

  • Regular

How much effort is required to fix it? (Cost)

  • Fix is very minor. But testing required much effort.

What is the risk of fixing it? (Risk)

  • No Risk. I have not closed connection so need to close the connection for the same. Attached file diff for the same.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • No

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • N/A

How long has the bug existed in the product?

  • It is from initial stage.

Do regression tests exist for this issue?

  • This issue reproduces with use of GUI only. When Log Viewer opens remote instance log file. So no test is here for the same.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • No simple test is available to do the same. Needs two machines. Issue only reproducible on windows machine.
    1. Create a remote, SSH node on a windows system, specifying a custom install dir, e.g. C:\as\v31.
    2. Create an instance under this node and start it.
    3. Launch Log Viewer for this instance and close it.
    4. Stop instance and attempt to delete it.

When will a tested fix be ready for integration?

  • immediately after approval

File diff:
Index: src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilterForInstance.java
===================================================================
— src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilterForInstance.java (revision 44805)
+++ src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilterForInstance.java (working copy)
@@ -107,6 +107,8 @@
}
out.flush();

+ sftpClient.close();
+
return instanceLogFile;

Comment by Chris Kasso [ 04/Feb/11 ]

Approved for RC2.

Comment by naman_mehta [ 05/Feb/11 ]

Sending logging/src/main/java/com/sun/enterprise/server/logging/logviewer/backend/LogFilterForInstance.java
Transmitting file data .
Committed revision 44945.





[GLASSFISH-15805] Log Viewer: stale log file displayed after rotating server.log with SSH node Created: 02/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 04/Feb/11

Status: Closed
Project: glassfish
Component/s: logging
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved, 3_1-verified

 Description   

Steps to reproduce:

1. Create a remote SSH node and an instance underneath.
2. Start the instance.
3. Launch the Log Viewer from instance's page and note the last record; close it.
4. Click on Rotate Log button for the instance.
5. Launch the Log Viewer again and note that the same log file is displayed, with the same records and time stamps. You will see that the rotated log file can also be viewed and is exactly the same. Close the viewer.

I also tried the following to see if the view would refresh:
6. Deploy an application to the instance.
7. Launch the Log Viewer - still the stale entries are displayed for server.log and the new message about deployment is not visible. Even after clicking "next" (Records after ?? button), no new records are displayed.

Tried the above on two different setups, windows and solaris, with the same results. Restarting server instance did not refresh the view either.



 Comments   
Comment by Anissa Lam [ 02/Feb/11 ]

You mentioned this is a regression, do you remember what version was tested before with the exact same test case ?

Comment by lidiam [ 02/Feb/11 ]

This issue is not present with an instance created under the built in localhost node.

Comment by lidiam [ 02/Feb/11 ]

I'm not sure I tested with an SSH node before, so this may not be a regression.

Comment by sirajg [ 03/Feb/11 ]

This issue can be reproduced on a remote instance, but not on DAS or on an instance on the same machine as DAS. For example, the URL :
http://localhost:4848/management/domain/view-log/details.json?instanceName=server&logFileName=server.log
will give current log entries for DAS. Say DAS has a rotated log file named rotated-DAS. The URL
http://localhost:4848/management/domain/view-log/details.json?instanceName=server&logFileName=rotated-DAS
will give log entries from the rotated log file for DAS.

In the case of a remote instance, say R1, URL :
http://localhost:4848/management/domain/view-log/details.json?instanceName=R1&logFileName=server.log
gives correct result. Now rotate logs for R1, resulting in a rotated log file, say rotated-R1. The URL
http://localhost:4848/management/domain/view-log/details.json?instanceName=R1&logFileName=server.log
AND
http://localhost:4848/management/domain/view-log/details.json?instanceName=R1&logFileName=rotated-R1
give the same result, which is the entries in the rotated file. Hence the result from
http://localhost:4848/management/domain/view-log/details.json?instanceName=R1&logFileName=server.log

is not correct, after rotation. Transferring to logging.

Comment by naman_mehta [ 03/Feb/11 ]

I verified the same. It's reproducible.

I am using SCP to download files from remote machine. So first time it's downloading server.log to DAS machine with all content there. Now user clicks on Rotate button. So on remote machine it rotates server.log file with new name server-timestamp.log. And on remoter machine there are two files now

1. server.log with no data
2. server-timestamp.log with data because it's created from original server.log.

This behavior is correct.

Now when user opens log viewer it download new server-timestamp.log file which has old server.log data and it displays the same. But now when user clicks on file drop down and selects server.log it's not downloading again that file from remote machine so both file is showing same data.

As per the original requirement, on log viewer screen log refresh check box is needed. If user click on the same then I need to download new file but it's not captured by log viewer screen. So my code is not downloading file from remote machine because of log file refresh flag value is coming as false every time.

To resolve this issue GUI must have to pass logFileRefresh flag value as true. Right now it's coming as false.

In below function, I need last argument 'logFileRefresh' as true.
public AttributeList getLogRecordsUsingQuery(
String logFileName, Long fromRecord, Boolean next, Boolean forward,
Integer requestedCount, Date fromDate, Date toDate,
String logLevel, Boolean onlyLevel, List listOfModules,
Properties nameValueMap, String anySearch, String instanceName, boolean logFileRefresh) {

Assigning to Siraj to make this change. Let me know if you have any question.

Comment by Anissa Lam [ 04/Feb/11 ]

Siraj made the following comment in email when JIRA was down.
Assign to Naman.

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

I agree with Siraj here. When i read the comment from Naman, I cannot figure out as an user, when I need to click on the checkbox. User doesn't need to do this in v2, so this is considered as a regression. Please implement the fix in the backend.

thanks
Anissa.

On 2/4/11 7:19 AM, Siraj Ghaffar wrote:
> Hi Naman,
> The logging backend knows that the log file has been rotated. It should be able to figure out that the server.log needs to be downloaded again. What you are describing is an implementation issue, and are asking the user to click on a checkbox, so we can figure out whether the download the file or not, even though the logging backend should be able to do so on its own. The user has already specified the file to view and the instance to view it for. That is sufficient information. The user would have no idea when to click on this checkbox and when not to. We should fix this in the backend, IMO.
>
> JIRA is down so I cannot transfer this bug.
>
> Thanks
> --Siraj

Comment by Nazrul [ 04/Feb/11 ]

From GUI, please call logging backend with refresh=true.

Comment by sirajg [ 04/Feb/11 ]

How bad is its impact? (Severity)
Moderate

How often does it happen? (Frequency)
When viewing log files for a remote instance.

How much effort is required to fix it? (Cost)
Minimal

What is the risk of fixing it? (Risk)
Minor

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

Diffs :

— src/main/java/org/glassfish/admingui/common/handlers/LogViewHandlers.java (revision 44796)
+++ src/main/java/org/glassfish/admingui/common/handlers/LogViewHandlers.java (working copy)
@@ -228,6 +228,7 @@
notNullStringPut(attMap, "anySearch", anySearch);
notNullStringPut(attMap, "logLevel", logLevel);
notNullStringPut(attMap, "instanceName", instanceName);
+ notNullStringPut(attMap, "logFileRefresh", "true");
if (moduleList != null)

{ attMap.put("listOfModules", moduleList); }

The above change will make logging backend refresh log file every time. This is not an ideal fix. For 3.2, issue http://java.net/jira/browse/GLASSFISH-15849 has been filed to make logging backend smarter.

Comment by Anissa Lam [ 04/Feb/11 ]

change looks fine. thanks.

Comment by Chris Kasso [ 04/Feb/11 ]

Approved for RC2.

Comment by sirajg [ 04/Feb/11 ]

Revision on branch : 44914
Revision on trunk : 44916

Comment by lidiam [ 04/Mar/11 ]

Verified in promoted build b43.





[GLASSFISH-15801] create-file-user is missing --target in the usage message Created: 02/Feb/11  Updated: 19/Dec/16  Resolved: 03/Feb/11

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Tom Mueller Assignee: kumarjayanti
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

Here is the usage message from create-file-user:

$ asadmin create-file-user -x
Invalid option: -x
Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username
Command create-file-user failed.

Note that the --target option is missing even though the command does actually accept a --target option.



 Comments   
Comment by kumarjayanti [ 02/Feb/11 ]

there was another bug filed for this. I cannot recollect the bug number though. Should i mark this for release-notes ?.

Comment by Tom Mueller [ 03/Feb/11 ]

I would recommend "no" since the man page is correct.

Comment by Nazrul [ 03/Feb/11 ]

Assuming this is a one line change, please fix this.

Comment by kumarjayanti [ 03/Feb/11 ]

Trunk :
-------
Sending Users/vbkumarjayanti/Documents/workspace/glassfish/v3/v3/security/core/src/main/java/com/sun/enterprise/security/cli/LocalStrings.properties
Transmitting file data .
Committed revision 44893.

Revision: 44893
Author : kumarjayanti
Date : Feb 4, 2011 11:48:56 AM
Fix for 15801

V3.1 Branch
-----------
Sending Users/vbkumarjayanti/Documents/workspace/glassfish/v3.1/3.1/security/core/src/main/java/com/sun/enterprise/security/cli/LocalStrings.properties
Transmitting file data .
Committed revision 44894.

Revision: 44894
Author : kumarjayanti
Date : Feb 4, 2011 11:52:56 AM
Fix for 15801, approved by nazrul, output after fix :

./asadmin create-file-user -x
Invalid option: -x
Usage: asadmin [asadmin-utility-options] create-file-user
[--authrealmname <authrealm_name>] [--target target]
[--groups user_groups[:user_groups]*]
[?|-help[=<help(default:false)>]] username

SVN diff of the Fix :
---------------

Index: LocalStrings.properties
===================================================================
— LocalStrings.properties (revision 44845)
+++ LocalStrings.properties (working copy)
@@ -39,7 +39,7 @@
#

file.realm.keyfilenonexistent=The specified physical file

{0} associated with the file realm {1} does not exist.
create.file.user.usagetext=create-file-user\n\t[groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]\n\t[?|--help[=<help(default:false)>]] username
+create.file.user.usagetext=create-file-user\n\t[--authrealmname <authrealm_name>] [--target target] \n\t[-groups user_groups[:user_groups]*] \n\t[?|--help[=<help(default:false)>]] username
create.file.user.filerealmnotfound=File realm {0}

does not exist
create.file.user.keyfilenotfound=No physical file is associated with file realm

{0}

.

Comment by kumarjayanti [ 03/Feb/11 ]

fixed





[GLASSFISH-15799] StackOverflowError in web container during instance startup. Created: 02/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 03/Feb/11

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

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

SuSE + iWS


Attachments: File server.log_2011-02-02T05-48-56    
Tags: 3_1-approved

 Description   

During instance startup in of the http failover tests, web container startup fails with StackOverflowError. After this, the instance is unresponsive to any asadmin commands and there are a lot of grizzly exceptions.

From the error message it looks like there was some request right at the time of web container initialization.

[#|2011-02-02T05:48:55.302-0800|INFO|glassfish3.1|ShoalLogger|_ThreadID=12;_ThreadName=Thread-1;|GMS1024: Adding Join member: instance105 group: st-cluster StartupState: INSTANCE_STARTUP |#]

[#|2011-02-02T05:48:55.672-0800|INFO|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=1;_ThreadName=Thread-1;|WEB0172: Virtual server [server] loaded default web module []|#]

[#|2011-02-02T05:48:56.120-0800|SEVERE|glassfish3.1|org.apache.catalina.connector.CoyoteAdapter|_ThreadID=17;_ThreadName=Thread-1;|PWC3989: An exception or error occurred in the container during the request processing
java.lang.StackOverflowError
at java.lang.String.indexOf(String.java:1521)
at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:127)
at java.net.URL.<init>(URL.java:596)
at java.net.URL.<init>(URL.java:464)
at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:458)
at sun.misc.URLClassPath.findResource(URLClassPath.java:146)
at java.net.URLClassLoader$2.run(URLClassLoader.java:385)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:382)
at java.lang.ClassLoader.getResource(ClassLoader.java:1003)
at org.apache.felix.framework.ModuleImpl.doImplicitBootDelegation(ModuleImpl.java:1535)
at org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1472)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:734)
at org.apache.felix.framework.ModuleImpl.getResourceByDelegation(ModuleImpl.java:652)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.getResource(ModuleImpl.java:2020)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1193)
at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2324)
at java.util.ResourceBundle$Control$1.run(ResourceBundle.java:2309)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2308)
at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1364)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1328)
at java.util.ResourceBundle.findBundle(ResourceBundle.java:1282)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1224)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:952)
at org.apache.catalina.util.StringManager.getStringInternal(StringManager.java:181)
at org.apache.catalina.util.StringManager.getString(StringManager.java:156)
at org.apache.catalina.util.StringManager.getString(StringManager.java:150)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:508)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:508)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:508)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:508)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:508)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)

Grizzly errors after the stackoverflow. :
[#|2011-02-02T05:48:56.329-0800|WARNING|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=17;_ThreadName=Thread-1;|afterService unexpected exception:
java.lang.StackOverflowError
at java.lang.LinkageError.<init>(LinkageError.java:36)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1907)
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:727)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:71)
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1768)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at com.sun.grizzly.tcp.StaticResourcesAdapter.afterService(StaticResourcesAdapter.java:301)
at com.sun.enterprise.v3.services.impl.ContainerMapper.afterService(ContainerMapper.java:356)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:509)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:508)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:267)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at org.apache.catalina.connector.CoyoteAdapter.postParseRequest(CoyoteAdapter.java:508)



 Comments   
Comment by Shing Wai Chan [ 02/Feb/11 ]

Can you provide more information/steps on how to reproduce the issue?

Comment by sonymanuel [ 02/Feb/11 ]

This issue happened during a Full HA run on Hudson.

The specific test where instance startup failed is in http module with modified-session attribute : com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeNewTest1

See test logs :
http://bigapp-oblade-10.us.oracle.com:1080/job/GF-HA-Functional-tests/38/artifact/results/http-modified-session/com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeNewTest1/html/index.html

Can you please check with Gopal how to re-run this scenario.

I don't think the issue is specific to this test. Most of the tests after this started failing.

http://bigapp-oblade-10.us.oracle.com:1080/job/GF-HA-Functional-tests/38/artifact/results/summary/overall-summary.html

Comment by Shing Wai Chan [ 03/Feb/11 ]

The circular logic is from CoyoteAdapter as follows:
if (context instanceof ContextRootInfo)

{ // this block of code will be invoked when an AJP request is intended // for an Adapter other than the CoyoteAdapter final Adapter toInvoke = ((ContextRootInfo) context).getAdapter(); toInvoke.service(req, res); toInvoke.afterService(req, res); return false; }

This is added in r40454 for fixing issue https://glassfish.dev.java.net/issues/show_bug.cgi?id=12458

Comment by Ryan Lubke [ 03/Feb/11 ]

When the ContainerMapper is initialized, it adds itself as the Adapter:

protected synchronized void configureMapper() {
mapper.setDefaultHostName(defaultHostName);
mapper.addHost(defaultHostName,new String[]{},null);
mapper.addContext(defaultHostName,ROOT,
new ContextRootInfo(this,null),
new String[]

{"index.html","index.htm"}

,null);
// Container deployed have the right to override the default setting.
Mapper.setAllowReplacement(true);
}

Based on the stacktrace, at the time the request is being serviced, there is only one
Adapter present (the CoyoteAdapter), so we remove any MappingData accumulated
at this point and invoke the adapter directly.

Because there isn't any mapping data, the CoyoteAdapter will attempt to map the request
itself, which ends up returning the ContentRootInfo with the ContainerMapper as the adapter.

The code Shing-Wai referenced at that point will invoke the ContainerMapper again, and then we
cycle until we blow the stack.

Since we shouldn't be re-invoking the ContainerMapper at all, we can fix this condition by
checking the Adapter before invoking it.

Comment by Ryan Lubke [ 03/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature

How often does it happen? (Frequency)

  • the code that triggered this has been in place for several months.

How much effort is required to fix it? (Cost)

  • minimal (single line check to prevent recursion)

What is the risk of fixing it? (Risk)

  • minimal

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • no

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • n/a

How long has the bug existed in the product?

  • several months

Do regression tests exist for this issue?

  • Once the fix is in place the HA test shouldn't have issues going forward

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • com.sun.dft.glassfish.http.failover.runtime.HttpFailoverRuntimeNewTest1

When will a tested fix be ready for integration?

  • 2/3/2011
Comment by Chris Kasso [ 03/Feb/11 ]

Approved for RC2.

Comment by Ryan Lubke [ 03/Feb/11 ]

Changes applied:

Revisions:
----------
44884

Modified Paths:
---------------
branches/3.1/web/web-core/src/main/java/org/apache/catalina/connector/CoyoteAdapter.java

Comment by Ryan Lubke [ 03/Feb/11 ]

Changes applied to trunk: revision 44885.





[GLASSFISH-15796] Connector runtime tries to locate the DTDs always from the installRoot/lib/dtds Created: 02/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 03/Feb/11

Status: Resolved
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Critical
Reporter: Bhavanishankar Assignee: Jagadish
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved

 Description   

When using embedded glassfish with uber jar, if the application has WEB-INF/glassfish-resources.xml, the deployment of the application fails with the following error :

org.glassfish.deployment.common.DeploymentException: Failue while processing glassfish-resources.xml(s) in the archive – /tmp/gfembed999554825950448723tmp/lib/dtds/glassfish-resources_1_5.dtd (No such file or directory)

This is not the case for other DTDs/schemas. All other DTD resolutions are embedded aware and they locate them by different machanism without relying on installRoot/lib/dtds (nor they will go online to get the DTD). I think the same thing should be done in the connector runtime as well.

Please note that this is a non issue when the application is run with glassfish-embedded-static-shell.jar, in which case there is an installation of GlassFish, and the dtds are available under installRoot/lib/dtds



 Comments   
Comment by Bhavanishankar [ 02/Feb/11 ]

This is critical for the embedded plugin users who use uber jar always.

Comment by Jagadish [ 02/Feb/11 ]

How bad is its impact? (Severity)

  • Limited to embedded uber jar use-case and application having glassfish-resources.xml

Identify why the fix needs to occur now:

  • Likely to generate a customer support call
  • An in-your-face issue that will touch the majority of users trying to use "glassfish-resources.xml"

How often does it happen? (Frequency)

  • Using embedded Uber jar, having an application that bundles glassfish-resources.xml to define the resources.

How much effort is required to fix it? (Cost)

  • Minor, introduce a fallback mechanism to look at the current class's jar for the DTDs (embedded uber jar will have it)

What is the risk of fixing it? (Risk)

  • none
  • made sure that QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (web, classic), resources-admin-cli, connector-sqe pass
  • made sure that the reported use-case passes
  • Bhavani will make sure that embedded tests pass.
    Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
  • Workaround is to use "installRoot" property to point to a GlassFish installation location, which will not work if the user does not have an installation and depends only on GlassFish uber jar.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • no workaround if the user does not have a classic profile installation of GlassFish.
    How long has the bug existed in the product?
  • since 3.1

Do regression tests exist for this issue?

  • Bhavani is planning to automate the reported test-case in embedded dev-tests

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • NA

When will a tested fix be ready for integration?

  • Ready
Comment by Jagadish [ 03/Feb/11 ]

Hong and Bhavani has added new test :
trunk/v3/tests/embedded/glassfish_resources_xml

Comment by Chris Kasso [ 03/Feb/11 ]

Approved for RC2.

Comment by Jagadish [ 03/Feb/11 ]

svn log -v -r 44869
Modified Paths:
---------------
trunk/v3/admin/util/src/main/java/org/glassfish/admin/cli/resources/ResourcesXMLParser.java

svn log -v -r 44867
Modified Paths:
---------------
branches/3.1/admin/util/src/main/java/org/glassfish/admin/cli/resources/ResourcesXMLParser.java





[GLASSFISH-15791] Alternatives, Interceptors and Decorators broken for archives that contain Extensions Created: 02/Feb/11  Updated: 19/Dec/16  Resolved: 05/Feb/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Jozef Hartinger Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JDK6U23


Attachments: File GLASSFISH-15791.diff     File test.war    
Tags: 3_1-approved

 Description   

Assume a java library (.jar) bundled inside a web archive.

The .jar contains an enabled alternative. The alternative works correctly unless the .jar also bundles a javax.enterprise.inject.spi.Extension implementation. In that situation the deployment fails with the following exception. This also impacts Interceptors and Decorators.

[#|2011-02-02T13:17:00.636+0100|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=79;_ThreadName=Thread-1;|Exception while loading the app : WELD-001423 Cannot enable the same alternative bean class [<class>org.jboss.seam.solder.test.compat.alternative.BarAlternative</class> in file:/home/jharting/jboss/appservers/glassfish-3.1-b37/glassfish3/glassfish/domains/domain1/generated/jsp/test/loader_975262726/META-INF/beans.xml@6, <class>org.jboss.seam.solder.test.compat.alternative.BarAlternative</class> in file:/home/jharting/jboss/appservers/glassfish-3.1-b37/glassfish3/glassfish/domains/domain1/generated/jsp/test/loader_975262726/META-INF/beans.xml@6] in beans.xml
org.jboss.weld.exceptions.DeploymentException: WELD-001423 Cannot enable the same alternative bean class [<class>org.jboss.seam.solder.test.compat.alternative.BarAlternative</class> in file:/home/jharting/jboss/appservers/glassfish-3.1-b37/glassfish3/glassfish/domains/domain1/generated/jsp/test/loader_975262726/META-INF/beans.xml@6, <class>org.jboss.seam.solder.test.compat.alternative.BarAlternative</class> in file:/home/jharting/jboss/appservers/glassfish-3.1-b37/glassfish3/glassfish/domains/domain1/generated/jsp/test/loader_975262726/META-INF/beans.xml@6] in beans.xml



 Comments   
Comment by Jozef Hartinger [ 02/Feb/11 ]

Test sources https://github.com/jharting/seam-solder/tree/GLASSFISH-15791/impl/src/test/java/org/jboss/seam/solder/test/compat/alternative

Comment by Sivakumar Thyagarajan [ 03/Feb/11 ]

Thanks for filing this issue and providing a simple way to reproduce the issue. With the attached patch I see the war deploying and the test passing.

Running org.jboss.seam.solder.test.compat.alternative.AlternativeTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec

Comment by Sivakumar Thyagarajan [ 03/Feb/11 ]

Proposed patch for this issue

Comment by Sivakumar Thyagarajan [ 03/Feb/11 ]

3.1 Change Control questionnaire:

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Introduces an incompatibility

This scenario (Use of a bundled library [WEB-INF/lib/*jar]) as a Bean archive and an Extension archive is a valid scenario.

How often does it happen? (Frequency)

Rarely. Only scenarios where a bundled library in a WAR (a jar under WEB-INF/lib) is a Bean archive and is an Extension and includes enabled Alternatives would face this scenario. Workaround would be to move the extension, Beans/Alternatives in the bundled library into WEB-INF/classes.

How much effort is required to fix it? (Cost)

Fix available and attached with the issue.

What is the risk of fixing it? (Risk)

Not much. I have run CDI devtests. Will also run CDI TCK before commiting.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

Yes. Workaround exists. Workaround would be to move the extension, Beans/Alternatives in the bundled library into WEB-INF/classes.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

Yes.

How long has the bug existed in the product?

Since b39.

Do regression tests exist for this issue?

I will add a developer test.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

SQE's CDI tests.

When will a tested fix be ready for integration?

By tomorrow(Feb 4th) end of day IST.

Comment by Sivakumar Thyagarajan [ 03/Feb/11 ]

Analysis: When a bundled library (WEB-INF/lib/*jar) in a WAR is a Bean archive(includes beans.xml) and also bundles a javax.enterprise.inject.spi.Extension implementation, GF BDA processing logic was adding the beans.xml in the bundled library resource twice to its list. Hence an enabled Alternative/Interceptor/Decorator in the bundled library was reported to exist twice during metadata processing in Weld.

Fix involved ensuring that only once a unique location of beans.xml is added to the BDA's beans.xml URL list.

Comment by Sivakumar Thyagarajan [ 05/Feb/11 ]

Resolved through svn commits:
trunk: Committed revision 44935.
3.1 branch: Committed revision 44936.

Comment by Sivakumar Thyagarajan [ 07/Feb/11 ]

Following commits were made to fix a FindBugs error introduced as part of the earlier commits:

trunk: svn commit id 44959
3.1 branch: svn commit id 44960

Comment by rhorn [ 18/Aug/11 ]

Sorry for the newbie question, but can you tell me where I can get the patch for this and how I can install it? I don't see the patch attached. Thanks much.





[GLASSFISH-15790] deleting an administered resource does not cause removal of corresponding osgi service Created: 02/Feb/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 03/Feb/11

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved

 Description   

When I delete a jdbc or jms resource, I don't see the corresponding osgi service getting unregistered. This is a regression. The fix has been discussed with Jagadish and it is trivial with zero side effect. So, we should fix this in 3.1 release itself.



 Comments   
Comment by Jagadish [ 02/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
  • An in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)

  • We expose jdbc, jms resources as OSGi service references and when the underlying resource is deleted in GlassFish, they are not removed from OSGi service references. So, any OSGi bundle that uses these service references will face stale resource issue.

How much effort is required to fix it? (Cost)

  • Minor, made sure that only one instance of resource-manager per type (jdbc, jms) is available at runtime.

What is the risk of fixing it? (Risk)

  • Very minimal, fix is localized to OSGi-ee-resources module (does not affect GlassFish's core container modules)
  • Will make sure that QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (Web, Classic), resources-admin-cli, connector-sqe-tests pass.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • No.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • NA

How long has the bug existed in the product?

  • 3-4 months (a regression).

Do regression tests exist for this issue?

  • Yes, will be adding a new test-case for this use-case.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • NA

When will a tested fix be ready for integration?

  • < 1 day's time.
Comment by Sanjeeb Sahoo [ 02/Feb/11 ]

Jagadish had sent me the patch for review and I do agree with him that this is a very very simple and localised fix and won't affect any part of Java EE container. It only addresses the bug found in osgi-ee-resources module.

Comment by Jagadish [ 03/Feb/11 ]

Added the following test-case to test jdbc and jms resources :
trunk/v2/appserv-tests/devtests/connector/v3/osgi-resources-test

http://java.net/projects/glassfish/sources/svn/show/trunk/v2/appserv-tests/devtests/connector/v3/osgi-resources-test?rev=44855

Comment by Chris Kasso [ 03/Feb/11 ]

Approved for RC2.

Comment by Jagadish [ 03/Feb/11 ]

svn log -v -r 44868
Modified Paths:
---------------
branches/3.1/osgi-javaee/osgi-ee-resources/src/main/java/org/glassfish/osgi/ee/resources/ResourceProviderService.java

svn log -v -r 44870
Modified Paths:
---------------
trunk/v3/osgi-javaee/osgi-ee-resources/src/main/java/org/glassfish/osgi/ee/resources/ResourceProviderService.java





[GLASSFISH-15789] Grizzly 1.9.31 integration required Created: 02/Feb/11  Updated: 19/Dec/16  Due: 03/Feb/11  Resolved: 03/Feb/11

Status: Closed
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved

 Description   

In order to fix issues:

1)
http://java.net/jira/browse/GLASSFISH-15741
"Servlet 3.0 doesn't work when Comet or Websocket are enabled"

2)
http://java.net/jira/browse/GRIZZLY-963
"Lazy SSL initialization is not synchronized well, which may cause unexpected side effects"

we need another Grizzly integration



 Comments   
Comment by oleksiys [ 02/Feb/11 ]

1. How bad is its impact? (Severity)

a)
http://java.net/jira/browse/GLASSFISH-15741

  • Significantly impacts the operation of a primary release driver feature

b)
http://java.net/jira/browse/GRIZZLY-963

  • Likely to generate a customer support call

2. How often does it happen? (Frequency)

a)
http://java.net/jira/browse/GLASSFISH-15741
all the time

b)
http://java.net/jira/browse/GRIZZLY-963
thread-racing, so it may vary.

3. How much effort is required to fix it? (Cost)

pretty small/easy fixes.

4. What is the risk of fixing it? (Risk)

a)
Very low. Limited by comet/websockets usecase.

b)
Very low.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

a)
yes

b)
no

How long has the bug existed in the product?
from the beginning.

7. Do regression tests exist for this issue?
No.

8. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
a)
comet/websockets related (webtier devtests), will be run before the integration

b)
no.

9. When will a tested fix be ready for integration?
2.2.2011

Comment by Chris Kasso [ 02/Feb/11 ]

Approved for RC2.

Comment by Ryan Lubke [ 03/Feb/11 ]

Integration complete:

Revisions:
----------
44834

Modified Paths:
---------------
branches/3.1/packager/resources/pkg_conf.py
branches/3.1/pom.xml

Comment by Ryan Lubke [ 03/Feb/11 ]

Changes applied to trunk: revision 44885.





[GLASSFISH-15786] IOP00410016: Remote access of appclient over webstart not possible Created: 01/Feb/11  Updated: 19/Dec/16  Resolved: 04/Feb/11

Status: Resolved
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Critical
Reporter: dbieri Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

ubuntu 10.04, sun_jdk_1.6.0_22, glassfish 3.1_b30 - b40


Attachments: File TestEJB.ear    
Tags: 3_1-approved

 Description   

I deploy an ear with an appclient inside, which gets started over the automatic webstart generator. This appclient opens as expected, when it is opened on the server (localhost). But when it gets opened over the network, the initial IIOP connection fails with the following error. The same ear works fine on glassfish 3.0.1.

As you can see in the error message, it tries to open port 192.168.0.25, which in fact is the IP address of the server.

SCHWERWIEGEND: IOP00410016: Unable to create IIOP listener on the specified port: 192.168.0.25
org.omg.CORBA.COMM_FAILURE: SCHWERWIEGEND: IOP00410016: Unable to create IIOP listener on the specified port: 192.168.0.25 vmcid: OMG minor code: 16 completed: No
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:248)
at com.sun.corba.ee.spi.orbutil.logex.corba.CorbaExtension.makeException(CorbaExtension.java:95)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.handleFullLogging(WrapperGenerator.java:387)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator.access$400(WrapperGenerator.java:107)
at com.sun.corba.ee.spi.orbutil.logex.WrapperGenerator$2.invoke(WrapperGenerator.java:511)
at com.sun.corba.ee.spi.orbutil.proxy.CompositeInvocationHandlerImpl.invoke(CompositeInvocationHandlerImpl.java:99)
at $Proxy34.createListenerFailed(Unknown Source)
at com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:98)
at com.sun.corba.ee.impl.transport.CorbaTransportManagerImpl.getAcceptors(CorbaTransportManagerImpl.java:243)
at com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.getAcceptorIterator(LegacyServerSocketManagerImpl.java:163)
at com.sun.corba.ee.impl.legacy.connection.LegacyServerSocketManagerImpl.legacyIsLocalServerPort(LegacyServerSocketManagerImpl.java:130)
at com.sun.corba.ee.impl.ior.iiop.IIOPProfileImpl.isLocal(IIOPProfileImpl.java:341)
at com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setLocalSubcontract(CorbaContactInfoListImpl.java:444)
at com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setEffectiveTargetIOR(CorbaContactInfoListImpl.java:277)
at com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.setTargetIOR(CorbaContactInfoListImpl.java:219)
at com.sun.corba.ee.impl.transport.CorbaContactInfoListImpl.<init>(CorbaContactInfoListImpl.java:183)
at com.sun.corba.ee.spi.transport.TransportDefault$1.create(TransportDefault.java:70)
at com.sun.corba.ee.impl.orbutil.ORBUtility.makeClientDelegate(ORBUtility.java:803)
at com.sun.corba.ee.impl.resolver.BootstrapResolverImpl.<init>(BootstrapResolverImpl.java:83)
at com.sun.corba.ee.spi.resolver.ResolverDefault.makeBootstrapResolver(ResolverDefault.java:89)
at com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.initializeNaming(ORBConfiguratorImpl.java:363)
at com.sun.corba.ee.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:152)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:625)
at com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:704)
at com.sun.corba.ee.impl.orb.ORBImpl.setParameters(ORBImpl.java:691)
at com.sun.corba.ee.spi.osgi.ORBFactory.initialize(ORBFactory.java:107)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.initORB(GlassFishORBManager.java:581)
at org.glassfish.enterprise.iiop.impl.GlassFishORBManager.getORB(GlassFishORBManager.java:263)
at org.glassfish.enterprise.iiop.impl.GlassFishORBFactoryImpl.createORB(GlassFishORBFactoryImpl.java:93)
at org.glassfish.enterprise.iiop.api.GlassFishORBHelper.getORB(GlassFishORBHelper.java:120)
at com.sun.enterprise.naming.impl.SerialContext.getORB(SerialContext.java:365)
at com.sun.enterprise.naming.impl.SerialContext.getProviderCacheKey(SerialContext.java:372)
at com.sun.enterprise.naming.impl.SerialContext.getRemoteProvider(SerialContext.java:402)
at com.sun.enterprise.naming.impl.SerialContext.getProvider(SerialContext.java:347)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:508)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.sun.ejb.EjbNamingReferenceManagerImpl.resolveEjbReference(EjbNamingReferenceManagerImpl.java:173)
at com.sun.enterprise.container.common.impl.ComponentEnvManagerImpl$EjbReferenceProxy.create(ComponentEnvManagerImpl.java:1097)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:771)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:740)
at com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:166)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:502)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl._inject(InjectionManagerImpl.java:597)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.inject(InjectionManagerImpl.java:468)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectClass(InjectionManagerImpl.java:215)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.injectClass(InjectionManagerImpl.java:207)
at org.glassfish.appclient.client.acc.AppClientContainer$ClientMainClassSetting.getClientMainClass(AppClientContainer.java:619)
at org.glassfish.appclient.client.acc.AppClientContainer.getMainMethod(AppClientContainer.java:511)
at org.glassfish.appclient.client.acc.AppClientContainer.completePreparation(AppClientContainer.java:405)
at org.glassfish.appclient.client.acc.AppClientContainer.prepare(AppClientContainer.java:319)
at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:278)
at org.glassfish.appclient.client.JWSAppClientContainerMain$ClientRunner.run(JWSAppClientContainerMain.java:167)
at org.glassfish.appclient.client.JWSAppClientContainerMain.main(JWSAppClientContainerMain.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.BindException: Cannot assign requested address: bind
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at sun.nio.ch.ServerSocketAdaptor.bind(Unknown Source)
at org.glassfish.enterprise.iiop.impl.IIOPSSLSocketFactory.createServerSocket(IIOPSSLSocketFactory.java:293)
at com.sun.corba.ee.impl.transport.SocketOrChannelAcceptorImpl.initialize(SocketOrChannelAcceptorImpl.java:91)
... 57 more



 Comments   
Comment by Tim Quinn [ 02/Feb/11 ]

Thanks for reporting this.

This is not related to Java Web Start only. The same error occurs launching the app client using the appclient script.

This might be an ORB issue. I am still investigating.

Comment by Tim Quinn [ 02/Feb/11 ]

I am reassigning this to the ORB team.

As I mentioned earlier this problem occurs with any app client launch, not just with Java Web Start.

I will attach a very simple app with one EJB and one app client. To reproduce the problem you will want to run asadmin and appclient on one system and the DAS on another. The easiest is just to unzip the glassfish.zip on both systems.

On DAS system (suppose it's named DAShost):
1. asadmin start-domain
2. asadmin enable-secure-admin
3. asadmin restart-domain

On other system:
4. asadmin --host DAShost deploy --retrieve localdir TestEJB.ear
5. appclient -targetserver DAShost:3700 localdir/TestEJBClient.jar

You will see the error the original poster reported.

Still on the client system:
6. appclient -targetserver DAShost:3700,DAShost:3700 localdir/TestEJBClient.jar

You will see a single-line of output showing the current date and time.

Internally, the ACC (at appclient/client/acc AppClientContainerBuilder:233) does this:

if (targetServers.length == 1)

{ defineIfNotDefined(GlassFishORBHelper.OMG_ORB_INIT_HOST_PROPERTY, targetServers[0].getAddress()); defineIfNotDefined(GlassFishORBHelper.OMG_ORB_INIT_PORT_PROPERTY, Integer.toString(targetServers[0].getPort())); }

else

{ /* * Currently, set a system property to specify multiple endpoints. */ defineIfNotDefined(ENDPOINTS_PROPERTY_NAME, sb.toString()); }

So it seems that the ORB is not correctly handling the case when
1. the client is remote from the server and
2. only one endpoint is specified using the org.omg.CORBA.ORBInitialHost and org.omg.CORBA.ORBInitialPort properties.

Comment by Tim Quinn [ 02/Feb/11 ]

Attached TestEJB.ear containing a very simple EJB and a very simple app client.

Comment by Tim Quinn [ 02/Feb/11 ]

Forgot to reassign the owner.

Comment by Ken Cavanaugh [ 03/Feb/11 ]

I tried to run the test case, but I have a problem:

ken@apollo% glassfish3/glassfish/bin/appclient -targetserver minas:3700 /tmp/tim/TestEJBClient.jar
java.lang.ClassNotFoundException: /tmp/tim/TestEJBClient.jar
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.glassfish.appclient.client.AppClientFacade.createContainerForClassName(AppClientFacade.java:518)
at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:470)
at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:269)
at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:76)
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 sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:323)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:338)

What do I need to do?

Comment by Tim Quinn [ 03/Feb/11 ]

I should have written

5. appclient -targetserver DAShost:3700 -jar localdir/TestEJBClient.jar

and

6. appclient -targetserver DAShost:3700,DAShost:3700 -jar localdir/TestEJBClient.jar

Apologies for the typos.

Comment by Ken Cavanaugh [ 04/Feb/11 ]

OK, with that fix, I can reproduce this now. I'll investigate.

Comment by Ken Cavanaugh [ 04/Feb/11 ]

How bad is its impact? (Severity)
Regression in in webstart from GF 2.1.

How often does it happen? (Frequency)
Happens all the time with the given test.
I think this one is a sever defect that would break most non-FOLB appclients.

How much effort is required to fix it?
There is old, incorrect code in the GlassFishORBManager that sets the ORB server host
to the ORB initial host. This should never be done, so the fix is to remote the two
lines of code.

What is the risk of fixing it? (Risk)
Low: small change, good test coverage

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
User could probably do something like -targerserver host:3700,host:3700 to avoid this (as in the test),
but that seems like a poor workaround.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
yes, but I'd recommend fixing this.

How long has the bug existed in the product?
Since the beginning of GF 3.1 FOLB development (roughly 6 months)

Do regression tests exist for this issue?
Not sure. There should be coverage in EJB dev, but those tests do not fail.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Test case is in this issue.

When will a tested fix be ready for integration?
Probably later today (2/4/11)

Comment by Chris Kasso [ 04/Feb/11 ]

Approved for RC2.

Comment by Ken Cavanaugh [ 04/Feb/11 ]

Fixed in rev 44924.

Comment by dbieri [ 07/Feb/11 ]

tested with 3.1_b41. This fix solved my problem. Thanks a lot!

Cheers,
Dani





[GLASSFISH-15784] [PERF] ConnectorObjectFactor.getObjectInstance performance has regressed Created: 01/Feb/11  Updated: 19/Dec/16  Resolved: 02/Feb/11

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: None
Fix Version/s: 3.1_dev

Type: Bug Priority: Critical
Reporter: Scott Oaks Assignee: Jagadish
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, PSRBUG

 Description   

Performance of ConnectorObjectFactor.getObjectInstance has regressed in V3.1 due to the section of code added for dynamic reconfiguration. In particular, continually calling resources.getResourceByName(ResourcePool.class, poolInfo.getName()) is a performance drain because it depends on expensive JNDI lookups.



 Comments   
Comment by Jagadish [ 02/Feb/11 ]

Refer the issues
http://java.net/jira/browse/GLASSFISH-14454
http://java.net/jira/browse/GLASSFISH-14731
for more background w.r.t config bean calls (resources.getResources() or resources.getResourceByName() or resource.getEnabled() ) related performance issues.

Config bean calls seem to be expensive.

I am working on a fix which will avoid the reported config-bean call in the above block of code by default. Only when the pool is enabled with transparent dynamic reconfiguration flag, config-bean related calls will be made.

Following might be a more appropriate (complete solution) solution which should be evaluated for 3.2 :

Eventually, we need a fix in Config layer to make these calls (atleast the read-only calls) less expensive so that every module benefits from it.
or
We may have to back the config bean for all resources and pools

Comment by Jagadish [ 02/Feb/11 ]

How bad is its impact? (Severity)

  • Affects Performance tests
    Identify why the fix needs to occur now:
  • Is a regression of performance available in a prior release

How often does it happen? (Frequency)

  • Every time application tries to acquire a "datasource".

How much effort is required to fix it? (Cost)

  • Minor, fix is to avoid this expensive call by caching the attribute.

What is the risk of fixing it? (Risk)

  • Minor, made sure that all of the tests pass (QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (web, classic), resources-admin-cli, connector-sqe)

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • No, as it affects performance tests.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • NA

How long has the bug existed in the product?

  • Performance team has revealed it today.

Do regression tests exist for this issue?

  • Since this is a performance issue, no feature is being tested here.
  • Also, sent the patch to Scott, Amit for verification.
  • Made sure that the reported call does not happen by default.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • NA

When will a tested fix be ready for integration?

  • Fix is available, waiting for Scott/Amits confirmation.
Comment by Nazrul [ 02/Feb/11 ]

Approved for checkin pending confirmation from Performance team. Please run the Dev Tests to make sure that this is not causing any regression. Also, please do a code review before committing the changes.

Comment by Scott Oaks [ 02/Feb/11 ]

Perf tests show a 1% improvement with the patch.

Comment by Jagadish [ 02/Feb/11 ]

Made sure that all of the tests pass (QL (Web, Classic), connector-dev, jdbc-dev, connector-standalone-cts (web, classic), resources-admin-cli, connector-sqe)

Fixed in trunk:
svn log -v -r 44853
Modified Paths:
---------------
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/JdbcConnectionPoolDeployer.java
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/naming/ConnectorObjectFactory.java
trunk/v3/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/ConnectorRegistry.java

Fixed in 3.1 branch :
svn log -v -r 44847
Modified Paths:
---------------
branches/3.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/connectors/ConnectorRegistry.java
branches/3.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/naming/ConnectorObjectFactory.java
branches/3.1/connectors/connectors-runtime/src/main/java/com/sun/enterprise/resource/deployer/JdbcConnectionPoolDeployer.java





[GLASSFISH-15783] change-admin-password command changes password with any dummy value. Created: 01/Feb/11  Updated: 19/Dec/16  Due: 03/Feb/11  Resolved: 02/Feb/11

Status: Closed
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

OS: Solaris Sparc 10


Tags: 3_1-approved, 3_1-verified

 Description   

GF build used: promoted b40.

Create a domain with user name and password. Using asadmin change-admin-password command we can change the adminpassword just by proving a dummy password value.

steps:
Create a domainby proving username/password .
Start domain1

Issue some CLI, like list-jdbc-connection-pools where in username/password should be provided.
command succeeds and lists the pools.

bash-3.00# ./asadmin change-admin-password

Enter admin user name [default: admin]> admin
Enter admin password> [ENTER any dummy value (dummypass)]
Enter new admin password> [Enter the value we want ( adminadmin)]
Enter new admin password again> [adminadmin]
Command change-admin-password executed successfully.

bash-3.00# ./asadmin list-jdbc-connection-pools
Enter admin user name> admin
Enter admin password for user "admin"> [adminadmin]
__TimerPool
DerbyPool
Command list-jdbc-connection-pools executed successfully.



 Comments   
Comment by Chris Kasso [ 01/Feb/11 ]

Updating to P1 given this is a security issue.

Comment by Tom Mueller [ 02/Feb/11 ]

Tim, can you please take a look at this? There is a local change-admin-password command that prompts for the username, the old password, and the new password. This command then uses the ServerRemoteAdminCommand class to run a remote change-admin-password command on the DAS that saves the admin password. The remote command doesn't look at the old password at all, even though it is passed in.

The ServerRemoteAdminCommand constructor accepts a password argument (the old password), but that argument is ignored.

So the bottom line is that in the change-admin-password command, the old password value that is entered by the user is ignored completely. However,the command works and the password is changed. Should the local change-admin-password command not be using the ServerRemoteAdminCommand class?

Comment by Tim Quinn [ 02/Feb/11 ]

In an earlier change (long ago) I incorrectly changed the use of RemoteAdminCommand to ServerRemoteAdminCommand thinking that this class ran inside the DAS.

Changing it to use RemoteAdminCommand fixes this.

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Impacts product security
  • Is a regression of functionality or performance available in a prior release
  • Likely to generate a customer support call

How often does it happen? (Frequency)
any time a user changes the admin password; the actual password is not needed

How much effort is required to fix it? (Cost)
minimal

What is the risk of fixing it? (Risk)
very low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
no workaround

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

How long has the bug existed in the product?
since Oct. 27, 2010

Do regression tests exist for this issue?
might be included in Shaline's tests

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
some that depend on non-default admin user/passwords

When will a tested fix be ready for integration?
upon approval (ready in my workspace)

Comment by Chris Kasso [ 02/Feb/11 ]

Approved for RC2.

Comment by Tim Quinn [ 02/Feb/11 ]

Fix checked in to trunk and 3.1 branch.

Project: glassfish
Repository: svn
Revision: 44833
Author: tjquinn
Date: 2011-02-02 23:15:16 UTC
Link:

Log Message:
------------
Fix for 15783

Because this class runs in asadmin (and not in the DAS), it should use RemoteAdminCommand instead of ServerRemoteAdminCommand.

Approved: Chris
Reviewed: Tom
Tests: test of the failure case; now no longer accepts a password change with any random current password; works only if correct current password is provided; QL

Revisions:
----------
44833 (for trunk)
44837 (for 3.1 branch)

Modified Paths:
---------------
trunk/v3/admin/cli/src/main/java/com/sun/enterprise/admin/cli/ChangeAdminPasswordCommand.java

Comment by shaline [ 10/Feb/11 ]

Verified in GF b42 nightly dated 02-09-2011





[GLASSFISH-15782] Install summary HTML file shows many broken links Created: 01/Feb/11  Updated: 19/Dec/16  Due: 03/Feb/11  Resolved: 02/Feb/11

Status: Resolved
Project: glassfish
Component/s: installation
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved

 Description   

This was discussed in GLASSFISH-15663 which has been resolved and not related to installation summary HTML file.

Opening this to better keep track of the issue.

From stephanj:
>>The glassfish install summary HTML file shows many links to http://docs.sun.com/doc/820-7690 which are broken.

From scatari:
>>Paul,
>> Can u provide us with the updated URL for Install Guide(online)? Are we not setting redirects for these links?



 Comments   
Comment by scatari [ 01/Feb/11 ]

If the URL forwarding is setup appropriately, then no code changes are required.

Comment by Paul Davies [ 01/Feb/11 ]

URL forwarding is set up to re-direct all URLs to docs.sun.com to the main Oracle documentation page, which is why all such URLs now appear broken.

The URL to the Installation Guide is:
http://www.oracle.com/pls/topic/lookup?ctx=821-2427&id=sjsaseeig

This link will return error 404 until the product ships.

Comment by scatari [ 02/Feb/11 ]

How bad is its impact? (Severity)

Bad user experience as the user is not directed to the correct installation guide.

How often does it happen? (Frequency)
Every time

How much effort is required to fix it? (Cost)
0.5 engineering day.

What is the risk of fixing it? (Risk)
Nothing

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No workaround exists, but users could always be instructed to navigate to the correct URL documented
in the Release Notes.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes, please see above.

How long has the bug existed in the product?
From the beginning of 3.1 Release.

Do regression tests exist for this issue?
No, but the changes are very local.Also please see below.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
A successful installation followed by start/stop server and uninstallation.

When will a tested fix be ready for integration?
02/02/2010.

Comment by Chris Kasso [ 02/Feb/11 ]

Approved for RC2.

Comment by scatari [ 02/Feb/11 ]

Reviewed by: Snjezana
Approved by: Chris

Checkin info for Trunk
------------------------------
Sending src/GlassFishV3Preview/resources/view/Summary.xml
Sending src/GlassFishV3WebProfilePreview/resources/view/Summary.xml
Sending src/main/java/org/openinstaller/provider/conf/InstallationConfigurator.java
Transmitting file data ...
Committed revision 44839.

Checkin info for Branch
--------------------------------
Sending src/GlassFishV3Preview/resources/view/Summary.xml
Sending src/GlassFishV3WebProfilePreview/resources/view/Summary.xml
Sending src/main/java/org/openinstaller/provider/conf/InstallationConfigurator.java
Transmitting file data ...
Committed revision 44844.





[GLASSFISH-15781] [Update] Need for upgrading from 3.0.x to 3.1 is not detected Created: 01/Feb/11  Updated: 19/Dec/16  Resolved: 04/Feb/11

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

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

Tags: 3_1-approved, 3_1-upgrade

 Description   

When a system is updated from 3.0 or 3.0.1 to 3.1, there is nothing that detects that an upgrade is actually needed in order to perform various changes (add default-config, delete osgi-cache, clean up session data, etc.).

Suggested fix:
Implement a new <domain> element version field. If it is not there and the domain is started, then print a message saying that the domain must be started with --upgrade and exit.



 Comments   
Comment by Tom Mueller [ 01/Feb/11 ]

1. How bad is its impact? (Severity)

This problem is a regression of functionality for users that upgrade from 3.0.x and it is likely to generate a customer support call. It is also an in-your-face issue that will touch users that upgrade from 3.0.x.

2. How often does it happen? (Frequency)

The problem of starting a 3.0.x domain with the 3.1 software will happen for all users that update from 3.0.x who don't read and follow the release notes.

3. How much effort is required to fix it? (Cost)
1 day

4. What is the risk of fixing it? (Risk)

Since this effects DAS startup, it could impact the developer scenario startup time.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

A work-around for the issue is to start the domain with --upgrade after applying the 3.1 update. This is expected to be documented in the release notes. This fix is for catching the situation for people that don't do this.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

The need to run --upgrade after a 3.0.x -> 3.1 upgrade should be documentation in the release notes even if this is implemented.

7. How long has the bug existed in the product?

For all of the 3.1 release development. It actually exists in 3.0.1 too.

8. Do regression tests exist for this issue?
No.

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

3.0.1 to 3.1 upgrade. 3.0 to 3.1 upgrade.

10. When will a tested fix be ready for integration?
2/2/2011.

Comment by Nazrul [ 01/Feb/11 ]

Please hand off the i18n string to George when ready

Comment by Tom Mueller [ 01/Feb/11 ]

Here is the message that will be generated when an incorrect version is detected.

The configuration data for this domain must be upgraded to run with this version of the software. To upgrade the data, run "asadmin start-domain --upgrade". Then start the domain normally.

Comment by Tom Mueller [ 04/Feb/11 ]

Fixed in:
trunk (revision 44929)
3.1 branch (revision 44930)





[GLASSFISH-15780] Need to integrate l10n packages Created: 01/Feb/11  Updated: 19/Dec/16  Resolved: 01/Feb/11

Status: Resolved
Project: glassfish
Component/s: l10n
Affects Version/s: 3.1_dev
Fix Version/s: None

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

Tags: 3_1-approved

 Description   

Need to integrate l10n packages In order to include latest translations.



 Comments   
Comment by Nazrul [ 01/Feb/11 ]

How bad is its impact? Critical

How often does it happen? always

How much effort is required to fix it? 1/2 day

What is the risk of fixing it? low

Does a work aroundfor the issue exist? no

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes? no

Howlong has the bug existed in the product? since build 36

Do regression tests existfor this issue? yes

Which tests should QA (re)run to verify the fix did not destabilize GlassFish? l10n testing

When will a tested fix be readyfor integration? Feb-01-2011

Comment by gmurr [ 01/Feb/11 ]

Integrated latest l10n packages





[GLASSFISH-15778] Endorsed bundles don't get updated properly while upgrading from 3.0.x Created: 01/Feb/11  Updated: 19/Dec/16  Resolved: 01/Feb/11

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

Attachments: Text File patch.txt    
Issue Links:
Dependency
blocks GLASSFISH-15772 3.0.1 to 3.1 update requires removal ... Resolved
Tags: 3_1-approved

 Description   

Refer to GLASSFISH-15772. We need to fix the location string used to install endorsed bundles to make sure that endorsed bundles are updated during upgrade. See attached patch. Either we fix the issue now or never.

How bad is its impact? (Severity)
Identify why the fix needs to occur now:
See GLASSFISH-15772 for justification. If that does not have to be fixed, then this issue is also needed to be fixed.

How often does it happen? (Frequency)
While updating existing 3.0.x installation

How much effort is required to fix it? (Cost)
Very Low

What is the risk of fixing it? (Risk)
None

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes, the work around is to remove $

{domain_dir}

/osgi-cache/ after updating the installation. I won't judge whether it is acceptable or not.
If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.
How long has the bug existed in the product?
It existed for some weeks now.

Do regression tests exist for this issue?
Manual test exist

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
QuickLook
When will a tested fix be ready for integration?
Already available. See patch



 Comments   
Comment by Sanjeeb Sahoo [ 01/Feb/11 ]

This issue needs to be fixed only if we need 15772 to be fixed.

Comment by Sanjeeb Sahoo [ 01/Feb/11 ]

3.1-branch:
----------
Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ..
Committed revision 44816.

trunk:
------
Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ..
Committed revision 44817.





[GLASSFISH-15774] [Update] default-config is missing Created: 31/Jan/11  Updated: 19/Dec/16  Due: 04/Feb/11  Resolved: 04/Feb/11

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

Type: Bug Priority: Critical
Reporter: Nazrul Assignee: Jennifer Chou
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File 3.0.1-domain-after-upgrade.xml     Text File default-config-diff.patch     Java Source File DefaultConfigUpgrade.java     Text File diffs.txt    
Issue Links:
Duplicate
duplicates GLASSFISH-15751 [Regression] Have to manually reload ... Closed
duplicates GLASSFISH-15689 [Regression] Unable to bring Admin Co... Closed
duplicates GLASSFISH-15755 list-nodes failed after updating fr... Closed
Tags: 3_1-approved, 3_1-upgrade

 Description   

[Tracking Bug]

When you update from 3.0.1 to 3.1, default-config is not created in domain.xml after the start-up. default-config is not created even if we do %asadmin start-domain --upgrade

Without default-config, user is not able to create clusters, etc. in 3.1.



 Comments   
Comment by Nazrul [ 01/Feb/11 ]

Getting help from Tom.

Comment from Bobby:
Maybe better, at least for users: the miniparser could check that default-config is missing in the domain and just do the upgrade before starting the server. Then the users wouldn't have to do a separate step, and it would satisfy my sense of balance that the server acts the same way for 2.X and 3.X.

Comment by Bobby Bissett [ 01/Feb/11 ]

Here's a followup to my comment about having the upgrade happen automatically (note that the upgrade code to actually add the default-config needs to be written separately from this question).

The server already checks for a network-config element in com.sun.enterprise.universal.xml.MiniXmlParser#parseConfig in order to detect 2.X domains:

else if ("network-config".equals(name))

{ sawNetworkConfig = true; // etc }

So it should be simple to add another check here for the default-config element and would not noticeably impact startup. Later, after the config has been parsed, com.sun.enterprise.admin.launcher.GFLauncher#setup does this check to see if we need to upgrade:

needsUpgrade = !parser.hasNetworkConfig();

So we'd only need to add a field to MiniXmlParser along with a getter. The rest of the code is already in place. I'll give this a try in my workspace in case we want to implement it, but it should probably be brought up in the admin iteam meeting since we've discussed it there before.

Comment by Tom Mueller [ 01/Feb/11 ]

Another option might be to modify the Configs bean so that getConfig and getConfigsByName always include the default-config even if it isn't really there in the domain.xml file. Sort of like a default value for an element in the list. Not quite sure how to implement this though.

Comment by Bobby Bissett [ 01/Feb/11 ]

Tom: I like that idea, as long as it solves Shing Wai's issue about the old session data so that we don't need an upgrade when starting with a 3.0.1 domain. Doing this would have the fewest unknowns since we're only changing one piece. It might be a pain though to keep the default values in sync with any future changes in the domain.xml template though. Also, I don't know how to implement it either.

Comment by Bobby Bissett [ 01/Feb/11 ]

Looking at MiniXmlParser further, this wouldn't be as simple as a quick check like the example I gave above. The code above is called while already parsing server-config, and after that's parsed the server exits. The code would need to change a bit more to continue looking for other configs after server-config is parsed.

Comment by Tom Mueller [ 01/Feb/11 ]

Another issue to resolve is where to obtain the initial value for default-config. It isn't obvious that this should come from the domain.xml template, although maybe it could. If it comes from there, then token substitution would need to be done and this complicates matters.

Comment by Nazrul [ 01/Feb/11 ]

Based on v2.x history, default-config came from domain.xml template.

Comment by Tom Mueller [ 01/Feb/11 ]

From the admin iteam discussion, the decision is to move forward with an implementation that depends on starting the domain with --upgrade to get the default-config inserted into the domain.xml. A new ConfigurationUpgrade module will extract the default-config from the domain.xml template and insert it into the domain.xml for the domain.

A separate bug will be filed to detect the need to upgrade and prevent the domain from starting if it is not upgraded.

Comment by Bobby Bissett [ 01/Feb/11 ]

In case it helps, here's a template for the upgrade module:

import com.sun.enterprise.config.serverbeans.Config;
import com.sun.enterprise.config.serverbeans.Configs;
import org.glassfish.api.admin.config.ConfigurationUpgrade;
import org.jvnet.hk2.annotations.Inject;
import org.jvnet.hk2.annotations.Service;
import org.jvnet.hk2.component.PostConstruct;

@Service
public class DefaultConfigUpgrade implements ConfigurationUpgrade, PostConstruct {

@Inject
private Configs configs;

public void postConstruct() {
Config defaultConfig = configs.getConfigByName("default-config");
if (defaultConfig == null)

{ // minor details :) }

}
}

Comment by Jennifer Chou [ 01/Feb/11 ]

Thanks for the starting point! That helps. Do you know where we should put the new DefaultConfigUpgrade?

Comment by Bobby Bissett [ 01/Feb/11 ]

You can put the code anywhere and it will be picked up. If you can't think of a better place for it, maybe it should be in admin/config-api module? I think there are already a few other upgrade classes there in the org.glassfish.config.support package.

I haven't seen Tom's new issue yet about the "3.1" attribute on the domain, but I imagine the class you're going to write may as well add that in during the upgrade. Unless you or Tom have another idea.

Comment by Jennifer Chou [ 04/Feb/11 ]

How bad is its impact? (Severity)

  • Bad
    Identify why the fix needs to occur now:
  • An in-your-face issue that will touch the majority of users

How often does it happen? (Frequency)

  • Trying to update from 3.0.1 to 3.1
  • Trying to upgrade from v2.x developer profile to 3.1

How much effort is required to fix it? (Cost)

  • few days

What is the risk of fixing it? (Risk)

  • risk is limited since this a new DefaultConfigUpgrade class that is run during asadmin start-domain --upgrade

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • manually copy default-config from template to you domain.xml

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • Yes

How long has the bug existed in the product?

  • Since the beginning. This is a missed requirement to be able to update from a domain.xml that doesn't have a default-config, like from 3.0.1 to 3.1.

Do regression tests exist for this issue?

  • No

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • Run asadmin start-domain --upgrade on a 3.0.1 domain.xml. Then run tests as usual on the newly upgraded domain.xml

When will a tested fix be ready for integration?

  • Planning by end of Friday Feb 4.
Comment by Chris Kasso [ 04/Feb/11 ]

Approved for RC2.

Comment by Jennifer Chou [ 04/Feb/11 ]

New DefaultConfigUpgrade.java and diffs for localStrings.properties.

Comment by Jennifer Chou [ 04/Feb/11 ]

Attaching "normalized" (I reordered the elements so they're in the same order) default-config diff between 3.0.1 domain.xml after upgrade and 3.1 domain.xml.

Comment by Jennifer Chou [ 04/Feb/11 ]

Checked-in to the Trunk

Adding C:/gf/v3/admin/config-api/src/main/java/org/glassfish/config/support/DefaultConfigUpgrade.java
Sending C:/gf/v3/admin/config-api/src/main/java/org/glassfish/config/support/LocalStrings.properties
Transmitting file data ...
Committed revision 44927.
Revision: 44927
Author : jc129909
Date : Feb 4, 2011 10:34:31 PM
GLASSFISH-15774 default-config is missing after 3.0.1 update to 3.1

Added a new DefaultConfigUpgrade service that is run during asadmin start-domain --upgrade to create a default-config using data from the domain.xml template

Approved By: Chris Kasso
Reviewed By: Bobby Bissett

Comment by Jennifer Chou [ 04/Feb/11 ]

Checked-in to 3.1 Branch:

Adding C:/gf/3.1/admin/config-api/src/main/java/org/glassfish/config/support/DefaultConfigUpgrade.java
Sending C:/gf/3.1/admin/config-api/src/main/java/org/glassfish/config/support/LocalStrings.properties
Transmitting file data ...
Committed revision 44928.
Revision: 44928
Author : jc129909
Date : Feb 4, 2011 10:49:35 PM
GLASSFISH-15774 default-config is missing after 3.0.1 update to 3.1

Added a new DefaultConfigUpgrade service that is run during asadmin start-domain --upgrade to create a default-config using data from the domain.xml template

Approved By: Chris Kasso
Reviewed By: Bobby Bissett





[GLASSFISH-15773] cannot remote deploy large wars Created: 31/Jan/11  Updated: 19/Dec/16  Resolved: 02/Feb/11

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

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

Attachments: Text File 15733Diffs-A.txt     Text File 15733Diffs.txt    
Tags: 3_1-approved, 3_1-next_release-note-added, 3_1-next_release-notes

 Description   

Initially, I was thinking of a NetBeans or Eclipse bug in trying to remote deploy web apps that has few jars in the lib dir.
For me, a 3.5Mb war fails, for Vince 7 and 33mb as well.

But the same error is happening from asadmin CLI...

From Mac (jdk22, old SSL) or Solaris (jdk23 and new SSL?) and Ubuntu Latest.

Basically:
./asadmin --host=pigalle.us.oracle.com --port=4848 deploy /Users/ludo/acvs/WebApplication3/dist/WebApplication3.war
...
Do you trust the above certificate [y|N] -->y
Enter admin user name> admin
Enter admin password for user "admin">
I/O Error: Error writing request body to server
Command deploy failed.
dhcp-santaclara22-1fl-west-10-132-178-158:bin ludo$

From Eclipse, I have this error: (As if the server fails while receiving the bytestream of the zipped payload...)?

INFO: Error writing request body to server
java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2802)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2785)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:161)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:196)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:301)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:146)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:321)
at com.sun.enterprise.jst.server.sunappsrv.commands.CommandRunner.handleSend(CommandRunner.java:667)

So I guess it is a generic bug in either asadmin client or possibly the remote server, maybe due to SSL? In v3, we did not enforce SSL for remote access, and the code in NetBeans used to work..

The server log in this situation only shows:
SEVERE: The log message is null.

To create such a monster war, just create a simple web app project in NetBeans, and using the project properties, just add random jars in it.
Do no pick GlassFish jar, I picked Eclipse or NetBeans jars, any jars would work, as long as they are in the lib of the web app.
Depending on the machine, you might want to add/remove jars to trigger the bug.
I would start with 100Mb jar, to see if you can reproduce the bug if medium size wars work for you.

We tried a combination of Client and Server Machines with JDK 22 or 23
mac-linux
mac-solaris
solaris-linux.
Same effect.



 Comments   
Comment by Hong Zhang [ 31/Jan/11 ]

Chris has written to the Grizzly team as Ludo thinks this might be a grizzly issue.
While we are waiting to hear back from Grizzly team, I am reassigning this issue to Tim to see if he has any insights on this (he is more familiar with upload and SSL).

Comment by Tim Quinn [ 31/Jan/11 ]

(also wrote to Ludo via e-mail before I knew this issue was open)

Do you see this problem only if secure admin is enabled? Or does it also happen with http?

Comment by ludo [ 31/Jan/11 ]

did not try without SSL.
Anyway, for remote access via CLI we require SSL, right?

Comment by Tim Quinn [ 31/Jan/11 ]

After making sure secure admin is disabled (and restarting the DAS if needed), run this command from the same system as the DAS:

asadmin --upload=true large.jar

Comment by Ryan Lubke [ 31/Jan/11 ]

This is trying a remote deploy after enabling secure admin, correct? If so, i'm not sure this is a Grizzly issue.

I was debugging the cli code and noticed that RemoteAdminCommand:502 was calling HttpURLConnection.getInputStream() to write content before the logic in RemoteAdminCommand:652 and beyond had a chance to verify if redirection to the secure port is necessary

urlConnection.connect();
/*

  • We must handle redirection from http to https explicitly
  • because, even if the HttpURLConnection's followRedirect is
  • set to true, the Java SE implementation does not do so if the
  • procotols are different.
    */
    String redirection = checkConnect(urlConnection);

It would seem that the redirect status would need to be taken into account before streaming any content?

Note, I can reproduce this problem using a local server only: asadmin deploy --upload=true <war>

Comment by ludo [ 31/Jan/11 ]

Well, we have also different logic in NetBeans client where it fails as well.
It works for GlassFish v3 with same client code.. which there did not handle redirect...

Comment by Tim Quinn [ 31/Jan/11 ]

I had understood that the whole request needed to be composed and sent for http before we could be sure the receiver would receive any data. Then if redirection was called for the whole request resent following the redirect. We knew this would be inefficient (uploading twice) but thought that was unavoidable.

Is this incorrect? Can the first response to http - which specifies redirect - be returned before the client has completely sent the request?

Comment by ludo [ 31/Jan/11 ]

So far, cannot reproduce without SSL.

Comment by ludo [ 31/Jan/11 ]

In Netbeans, we detect early if https is needed, and if it is, we use it in the url we use to connect, so I guess we do not need the redirect logic asadmin is using.?

Comment by Ryan Lubke [ 31/Jan/11 ]

Made some changes to RemoteAdminCommand to make sure we're sending the proper request, but there are some other issues I"m looking into.

I did see the "SEVERE: The log message is null. " message in my log and tracked it to:
CommandRunnerImpl:1130: logger.severe(ex.getMessage());

Will report further findings.

Comment by Ryan Lubke [ 31/Jan/11 ]

Stacktrace of the exception triggering the null log message:

[#|2011-01-31T21:55:30.921-0800|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=70;_ThreadName=admin-thread-pool-4848(4);|java.io.IOException
at org.glassfish.admin.payload.PayloadFilesManager.extractFile(PayloadFilesManager.java:565)
at org.glassfish.admin.payload.PayloadFilesManager.access$600(PayloadFilesManager.java:95)
at org.glassfish.admin.payload.PayloadFilesManager$DataRequestType$1.processPart(PayloadFilesManager.java:745)
at org.glassfish.admin.payload.PayloadFilesManager.processPartsExtended(PayloadFilesManager.java:605)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.extractFiles(CommandRunnerImpl.java:1434)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.<init>(CommandRunnerImpl.java:1407)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$UploadedFilesManager.<init>(CommandRunnerImpl.java:1385)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:834)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
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:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
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:680)
Caused by: java.io.EOFException: Unexpected end of ZLIB input stream
at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:223)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141)
at java.util.zip.ZipInputStream.read(ZipInputStream.java:154)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at org.glassfish.admin.payload.ZipPayloadImpl$Inbound$ZipEntryInputStream.read(ZipPayloadImpl.java:219)
at org.glassfish.admin.payload.PayloadFilesManager.extractFile(PayloadFilesManager.java:540)
... 29 more

Comment by Ryan Lubke [ 31/Jan/11 ]

Eliminated port unification from the equation. Deployment streaming of the archive fails fairly early on with the exception above.

Comment by Tim Quinn [ 01/Feb/11 ]

RemoteAdminCommand (which runs inside asadmin and actually sends the http/https request to the DAS) does not currently – but could and should – avoid uploading to http if the server redirects to https.

I created a fix for that in my workspace.

The earlier error Ryan mentioned - the "log message is null" message - is annoying but not the root cause of the problem. I change some error reporting, so now instead of that "log message is null" the server.log contains the stack trace Ryan reported in his earlier comment.

This exception is thrown - and the deployment fails - only with secure admin enabled, and therefore only over SSL. I disabled secure admin and the large JAR uploaded successfully and deployment succeeded. (I used asadmin deploy --upload=true from the same system as the DAS to force an upload with secure admin disabled.)

Comment by Ryan Lubke [ 01/Feb/11 ]

Ok, I think I see what the next issue is.

A renegotiation is triggered on the server side while the client is streaming bytes. The SSL renegotiation logic is reading from the client, but we're reading the upload bytes being streamed to us. We start resizing the buffer until we hit the max buffer size at this point we trigger an exception which causes the upload to fall apart.

Comment by Tim Quinn [ 01/Feb/11 ]

Offline, Ryan indicated that to fix this in Grizzly will be fairly extensive.

A user workaround for this would be to manually copy a large archive to the DAS system (or a system which can see the same file system as the DAS) and deploy it without uploading during the deployment operation itself.

Ryan, do we know the maximum size of an archive that will not trigger the problem?

I have also created some workarounds in GlassFish code (in my workspace at the moment) which seem to be working. They involve small changes to a few classes and some more substantial changes to one class.

We need to weigh the risk of these changes vs. the risk of the Grizzly changes vs. the awkwardness of the manual workaround.

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

Moderate changes required as part of the workaround:

core/kernel AdminAdapter
------------------------
Dump the http/https incoming payload to a temporary file, then have the command read from a payload wrapping the temp file instead of directly from the request's input stream. This hurts deployment performance if the archive is uploaded, especially a large archive, but Ryan's analysis shows that this is necessary to allow uploading over SSL to work for large uploads.

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

Very minor changes required as part of the workaround:

admin/util RemoteAdminCommand
-----------------------------
Remember if the metadata retrieval http request was redirected to https so we can avoid redirection of the real request (which included the uploaded data) by sending it directly to https. (This will help performance when secure admin is enabled as well as avoid the error scenario.)

common/common-util ZipPayloadImpl
---------------------------------
Fix an error in iterator implementation

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

Very minor changes NOT required for the workaround but which would help diagnosing other problems:

common/common-util PayloadFilesManager
--------------------------------------
Add msg to IOException thrown if there is an error extracting a file (currently just creates an IOException without a msg).

core/kernel CommandRunnerImpl
-----------------------------
Log the whole exception instead of just the msg from the exception (which could be null) if an error occurs during command execution.

Comment by Ryan Lubke [ 01/Feb/11 ]

> Ryan, do we know the maximum size of an archive that will not trigger the problem?

Currently, 196608 bytes (non configurable at the moment)

Alexey and I have discussed this and we're not 100% sure this can be fixed on the Grizzly side.
I had an idea of a callback that could be invoked if the buffer is exceeded to allow the developer
to decided how they wish to handle that situation, but that's getting into new feature territory.

My opinion at this point is that these changes seem like the best approach.

Comment by super_glassfish [ 01/Feb/11 ]

A user workaround for this would be to manually copy a large archive to the DAS system (or a system which can see the same file system as the DAS) and deploy it without uploading during the deployment operation itself.

--->If recommended and selected, why do we need the other code changes?
---> How do I implement this workaround as a NetBeans or Eclipse user? As a JRVE user? As an Amazon cloud user?

Ryan, do we know the maximum size of an archive that will not trigger the problem?

---?It is very small, i.e for every web app using a framework of apache jars, you are doomed.

I have also created some workarounds in GlassFish code (in my workspace at the moment) which seem to be working. They involve small changes to a few classes and some more substantial changes to one class.

--->Workarounds to which issues? Not clear if this solve or not the issue of this bug.

We need to weigh the risk of these changes vs. the risk of the Grizzly changes vs. the awkwardness of the manual workaround.

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

Moderate changes required as part of the workaround:

core/kernel AdminAdapter
------------------------
Dump the http/https incoming payload to a temporary file, then have the command read from a payload wrapping the temp file instead of directly from the request's input stream. This hurts deployment performance if the archive is uploaded, especially a large archive, but Ryan's analysis shows that this is necessary to allow uploading over SSL to work for large uploads.

----->Would that entirely fix the issue? It is not clear for this...

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

Very minor changes required as part of the workaround:

admin/util RemoteAdminCommand
-----------------------------
Remember if the metadata retrieval http request was redirected to https so we can avoid redirection of the real request (which included the uploaded data) by sending it directly to https. (This will help performance when secure admin is enabled as well as avoid the error scenario.)

----> This is of course needed to avoid copying twice large data (MegaBytes!)

common/common-util ZipPayloadImpl
---------------------------------
Fix an error in iterator implementation

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

Very minor changes NOT required for the workaround but which would help diagnosing other problems:

common/common-util PayloadFilesManager
--------------------------------------
Add msg to IOException thrown if there is an error extracting a file (currently just creates an IOException without a msg).

core/kernel CommandRunnerImpl
-----------------------------
Log the whole exception instead of just the msg from the exception (which could be null) if an error occurs during command execution.

Comment by Tim Quinn [ 01/Feb/11 ]

Responding to "super-glassfish"...

A user workaround for this would be to manually copy a large archive to the DAS system (or a system which can see the same file system as the DAS) and deploy it without uploading during the deployment operation itself.

--->If recommended and selected, why do we need the other code changes?

>> Code changes are not needed if we adopt the manual user workaround. This is an "either-or" situation. Either we rely on a manual user workaround or build a code workaround into GlassFish.

---> How do I implement this workaround as a NetBeans or Eclipse user? As a JRVE user? As an Amazon cloud user?

>> All good questions. Part of the decision making process must weigh how often such use cases arise vs. the risk of coding changes.

I have also created some workarounds in GlassFish code (in my workspace at the moment) which seem to be working. They involve small changes to a few classes and some more substantial changes to one class.

--->Workarounds to which issues? Not clear if this solve or not the issue of this bug.

>> This issue. The coding workarounds in my workspace allow large uploads to work over https.

Comment by ludo [ 01/Feb/11 ]

when available. please attach the diff that I can test from the IDEs.

Comment by Tim Quinn [ 01/Feb/11 ]

I have attached svn diffs for the altered classes, for Ludo's experimentation and for code review.

Comment by ludo [ 01/Feb/11 ]

tempFile.deleteOnExit();

might be an issue for iterative deployments to a server running in a small system (Amazon, JRVE VM where disk space is limited) when the archive is big...
I would prefer a cleanup after each deployment

Comment by Tim Quinn [ 01/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
  • Likely to generate a customer support call
  • Significantly impacts the operation of a primary release driver feature
  • An in-your-face issue that will touch the majority of users
    Uploading large archives during deployment will not work.

How often does it happen? (Frequency)
Any time a large archive is uploaded during deployment.

How much effort is required to fix it? (Cost)
Fix already in place and undergoing testing.

What is the risk of fixing it? (Risk)

There are several classes affected. Most are minimal, in many cases one-line changes. The largest change is to AdminAdapter. This class receives and acts on every asadmin request. The changes deal with the payload that might be included in the incoming http/https request. I am successfully (so far) running deployment devtests with secure admin enabled and using upload=true. The same code is used by remote instances to handle asadmin requests which the DAS sends to them. Next test will be to make sure deployment to remote instances works correctly.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

The workaround (described earlier) requires the user to manually copy a large archive to the DAS system, then deploy it from there. This is cumbersome and probably not workable from IDEs.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
yes

How long has the bug existed in the product?
Not clear. Probably for much of 3.1.

Do regression tests exist for this issue?
Not yet. If the changes are approved an admin test can be added relatively simply.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
Tests involving deployment (ideally with upload) to remote instances.

When will a tested fix be ready for integration?
By 2/3 if approved.

Comment by ludo [ 01/Feb/11 ]

patch seems to fail for other commands.

For example, the hidden __locations command

http://10.132.178.158:4848/__asadmin/__locations

gives this error back:

<?xml version="1.0" encoding="UTF-8" standalone="no"?><action-report description="" exit-code="FAILURE"><message-part message="Exception while processing command: java.util.zip.ZipException: ZIP file must have at least one entry"/></action-report>

Comment by ludo [ 01/Feb/11 ]

same for localhost as well, via the __asadmin adapter:

See:
view-source:http://localhost:4848/__asadmin/__locations
This worked before the patch

Comment by Tim Quinn [ 02/Feb/11 ]

ludo commented about deleteOnExit.

I guess you did not see the explicit delete in the close() method of AdminAdapter.PayloadBuffer. It will normally be cleaned up as part of the deployment. The deleteOnExit is there as an extra safeguard.

Comment by ludo [ 02/Feb/11 ]

Yep, noticed that after.
But if payloadInputStream.close(); fails, the explicit call to file detete would not be done. Corner case, but at this level of code stability, we'd better 100% safe.
I still cannot test the fix since the IDEs use the __location call at init time, and if it fails, we cannot deploy later.

Comment by Tim Quinn [ 02/Feb/11 ]

I have sent Ludo an updated patch for AdminAdapter which addresses his latest concerns: skipping the tempFile.delete if the close fails and the ZipException.

Comment by Tim Quinn [ 02/Feb/11 ]

I need to hear back from the Grizzly team on this, but there might be a much simpler workaround.

We would still need the change in RemoteAdminCommannd, but the change in AdminAdapter would be far less intrusive.

Tom made a comment yesterday that deploying a large app to a remote instance was working so long as the archive was not uploaded from the asadmin host to the DAS (meaning asadmin and the DAS both had access to the file system where the archive exists).

Inspired by that, I tried that with an unchanged nightly b41 and the same scenario worked for me.

The archive is uploaded from the DAS to the remote instance using the same mechanism as the upload from asadmin to the DAS. The key difference seems to be that with the DAS-to-instance upload the SSL cert is provided, while with the asadmin-to-DAS upload there is no SSL cert.

As an experiment, I reverted the AdminAdapter changes and made one minor change: AdminAdapter invokes request.getUserPrincipal (which seems to cause the problems) only if the current system is NOT the DAS.

This experiment worked for me. The sacrifice we make is that it's conceivable that a user might have configured an admin client to provide an SSL client cert for authentication. With the experimental change we cannot support that. But the scope and complexity of changes are far less severe and we do not have to copy the payload to a temp file so performance is not degraded.

I have written to the Grizzly team about this already to see if the error scenario is always avoided with a large upload if the cert is in fact present in the arriving request. More later.

Comment by Ryan Lubke [ 02/Feb/11 ]

If a certificate is provided during the initial ssl handshake, then when getUserPrincipal is called, there is no need for a session renegotiation which means no buffering issues.

So based on the above, this is another option (one with fewer overall side effects it seems).

Comment by ludo [ 02/Feb/11 ]

How do we decide?
We have only 1 patch so far (and private since the attached one is not enough).
Can we have the 2 other patchs and pro and con for a discussion? Who is doing extensive testing, i.e with cli, NetBeans, Eclipse, etc?

Comment by Tim Quinn [ 02/Feb/11 ]

15733Diffs-A.txt are the diffs for the solution adopted in the bug swat meeting today (2 Feb 2011). The DAS will, normally, not check for a client SSL cert in admin requests. The user can override this by setting a property for the DAS.

Comment by Tim Quinn [ 02/Feb/11 ]

Fix/workaround checked in.

Repository: svn
Revision: 44842
Author: tjquinn
Date: 2011-02-03 00:48:50 UTC
Link:

Log Message:
------------
Workaround/fix for 15773

Large archive uploads during deployment with secure admin enabled cause problems in Grizzly buffering of the request's input stream if there is no client cert in the message when the server invokes request.getUserPrincipal. In by far the most cases, user admin messages to the DAS (whether from asadmin, IDEs, or other admin clients) do not use client SSL authentication.

So as a workaround/fix, these changes accomplish two basic things:

1. The AdminAdapter does not invoke request.getUserPrincipal if it is running on the DAS. (The user can override this by setting org.glassfish.admin.DASCheckAdminCert for the DAS.)

2. The RemoteAdminCommand now records if the first request it sends (to retrieve the command metadata) is redirected to https. If so, the second request (to submit the actual command) is sent via https. This avoids redirection of the actual command request, which carries with it the uploaded archive.

Approved: Chris
Reviewed: Tom
Tests: QL, upload of large archives succeeded with the property undefined, failed with the property defined - as expected

Revisions:
----------
44842 (for trunk)
44843 (for 3.1 branch)

Modified Paths:
---------------
trunk/v3/common/common-util/src/main/java/org/glassfish/admin/payload/PayloadFilesManager.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/admin/AdminAdapter.java
trunk/v3/core/kernel/src/main/java/com/sun/enterprise/v3/admin/CommandRunnerImpl.java
trunk/v3/admin/util/src/main/java/com/sun/enterprise/admin/remote/RemoteAdminCommand.java
trunk/v3/common/common-util/src/main/java/org/glassfish/admin/payload/ZipPayloadImpl.java

Comment by Rebecca Parks [ 07/Jul/11 ]

I'm not sure what needs to be stated in the Release Notes in all of this. Does a user who is deploying a large WAR have to deploy it to the DAS first and then use create-application-ref to deploy it elsewhere?

Comment by Tim Quinn [ 07/Jul/11 ]

Proposed release note for 15773. Rebecca, please edit as needed for clarity, voice, etc.

Note: this discussion applies only to administrative clients sending admin messages to the domain admin server (DAS). It does not apply to end-user clients sending messages to applications.

By default, when you enable secure admin the GlassFish DAS does not use SSL client certificate authentication to verify the identify of admin clients, such as the asadmin utility or browsers or IDEs. Instead, the admin user typically provides an admin username and password which identify the user and authorize him or her to perform administrative operations.

You can enable admin request SSL client certificate support in the DAS by setting the system property

org.glassfish.admin.DASCheckAdminCert

to true. This does not disable username/password admin authentication; it simply adds client SSL cert-based authentication as another alternative the DAS can use.

If you:

  • enable secure admin for the domain,
  • enable SSL admin client cert support as just described above,
  • upload a moderate or large file as part of deployment, and
  • use an admin client that is not configured to send an SSL client certificate for authentication

then GlassFish might report communication errors related to SSL. This can happen if the upload is in progress when the GlassFish DAS requests certificate information from the admin client. This happens only if the client was not configured to use an SSL cert.

If you want to enable SSL admin client cert support but you also have a large file to deploy, you should first upload the file manually to the system where the DAS is running or store the file in a shared file system that both your system and the DAS system can access. Then do not specify --upload=true when you deploy the application. The DAS will find the file without uploading it, so the certificate negotiation between the DAS and the admin client can complete normally).

Comment by Rebecca Parks [ 12/Jul/11 ]

Thanks Tim! Added the following to the 3.1.1 Release Notes:

cannot remote deploy large wars (15773)

Description

This issue applies only to administrative clients sending administration messages to the domain administration server (DAS). It does not apply to end-user clients sending messages to applications.

By default, when you enable secure admin, the GlassFish Server DAS does not use SSL client certificate authentication to verify the identify of administration clients (such as the asadmin utility, browsers, or IDEs). Instead, the administrative user typically provides a username and password which authorize performance of administrative operations. To enable admin request SSL client certificate support in the DAS, set the following system property to true:

org.glassfish.admin.DASCheckAdminCert

This does not disable username and password authentication. It simply adds client SSL certificate-based authentication as another alternative the DAS can use.

If you perform the following steps, then GlassFish Server might report communication errors related to SSL:

1. Enable secure admin for the domain.

2. Enable admin request SSL client certificate support as just described.

3. Use an administration client that is not configured to send an SSL client certificate for authentication.

4. Upload a moderate or large file as part of deployment.

This can happen if the upload is in progress when the GlassFish Server DAS requests certificate information from the administration client. This happens only if the client was not configured to use an SSL certificate.

Workaround

To enable admin request SSL client certificate support and deploy a large file, first upload the file manually to the system where the DAS is running or store the file in a shared file system that both your system and the DAS system can access. Then do not specify --upload=true when you deploy the application. The DAS finds the file without uploading it, so the certificate negotiation
between the DAS and the administration client can complete normally.





[GLASSFISH-15769] Regression: Weaving attempted in Glassfish embedded even though supposedly disabled Created: 31/Jan/11  Updated: 19/Dec/16  Resolved: 04/Feb/11

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

Type: Bug Priority: Critical
Reporter: ljnelson Assignee: Mitesh Meswani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, 3_1-fishcat

 Description   

Weaving is apparently disabled-or at least that's the intent-in Glassfish embedded.

However, when I use the embeddable Glassfish APIs, documented at http://embedded-glassfish.java.net/nonav/apidocs/, it appears that weaving is attempted.

I have an EJB project set up with a persistence unit in it. So, some classes are EJB interfaces, others are EJB implementations, and others are entity classes. There is a META-INF/persistence.xml file in there. javax.ejb.embeddable.EJBContainer deploys this "archive" fine.

I've recently switched over to using the Glassfish embeddable APIs instead, since they are more robust (they support remote EJBs among other things). I've made no other changes.

At test time, I get the exception message detailed by this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=323403

That is, EclipseLink 2.2.0 is attempting to invoke a weaving-supplied method, even though weaving is disabled.

I suspect that something about the way weaving is "disabled" is not in fact fully disabling it.

In point of fact, I would like weaving to be ON. But I understand that this is an issue with an embedded API.

I can work around this issue if I explicitly set weaving to be off in my persistence.xml file:

<property name="eclipselink.weaving" value="false"/>

...but I'd rather not do that.



 Comments   
Comment by Mitesh Meswani [ 03/Feb/11 ]

Weaving was always disabled in embedded mode to guard against use cases where entity classes are touched (and hence loaded) by the app before transformers get installed. JPADeployer relied on serverEnvironment.isEmbedded() to determine if it is being run in embedded mode. Embedded implementation has recently changed to not answer true for serverEnvironment.isEmbedded() causing the regression. After discussions, it seems instead of always disabling weaving, a more flexible approach would be to enabled it by default and give user an option to explicitly disable it for embedded. Following diffs implements the change

Index: src/main/java/org/glassfish/persistence/jpa/JPADeployer.java
===================================================================
— src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (revision 44872)
+++ src/main/java/org/glassfish/persistence/jpa/JPADeployer.java (working copy)
@@ -42,6 +42,7 @@

import com.sun.appserv.connectors.internal.api.ConnectorRuntime;
import com.sun.enterprise.deployment.*;
+import com.sun.enterprise.module.bootstrap.StartupContext;
import com.sun.logging.LogDomains;
import org.glassfish.api.deployment.DeployCommandParameters;
import org.glassfish.api.event.EventListener;
@@ -84,6 +85,9 @@
private ServerEnvironmentImpl serverEnvironment;

@Inject
+ private volatile StartupContext sc = null;
+
+ @Inject
private Events events;

@Inject
@@ -196,7 +200,13 @@
@Override void visitPUD(PersistenceUnitDescriptor pud, DeploymentContext cont
ext) {
if(referencedPus.contains(pud)) {
boolean isDas = isDas();

  • ProviderContainerContractInfo providerContainerContractInfo = serverEnvironment.isEmbedded() ?
    +
    + // While running in embedded mode, it is not possible to guarantee that entity classes are not loaded by the app classloader before transformers are installed
    + // If that happens, weaving will not take place and EclipseLink will throw up. Provide users an option to disable weaving by passing the flag.
    + // Note that we enable weaving if not explicitly disabled by user
    + boolean weavingEnabled = Boolean.valueOf(sc.getArguments().getProperty("org.glassfish.persistence.embedded.weaving.enabled", "true"));
    +
    + ProviderContainerContractInfo providerContainerContractInfo = weavingEnabled ?
    new EmbeddedProviderContainerContractInfo(context, connectorRuntime, isDas) :
    new ServerProviderContainerContractInfo(context, connectorRuntime, isDas);
    PersistenceUnitLoader puLoader = new PersistenceUnitLoader(pud, providerContainerContractInfo);
Comment by Mitesh Meswani [ 03/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality from prior release.
  • With this issue present, if an app needs to disable weaving for embedded, the app's persistence.xml needs to be changed. This is quite inconvenient for unit test scenarios (The main use case for embedded)

How often does it happen? (Frequency)

  • For any app that needs to disable weaving

How much effort is required to fix it? (Cost)

  • The fix is available and is attached in previous comment

What is the risk of fixing it? (Risk)

  • Minimal to no risk. The fix is localized to embedded use case. I have verified in debugger that nothing is changed for non embedded case.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • Work around is to modify persistence.xml to explicitly disable weaving. This makes using embedded for unit testing inconvenient

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • Yes

How long has the bug existed in the product?

  • Not more than a month

Do regression tests exist for this issue?

  • No.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • The standard QE test suit against derby. I have already run them with these changes.

When will a tested fix be ready for integration?

  • It is available now.
Comment by Mitesh Meswani [ 03/Feb/11 ]

Checked in the code branch rev 44890, trunk rev 44889

Comment by Mitesh Meswani [ 03/Feb/11 ]

Assigning to docs to document the property "org.glassfish.persistence.embedded.weaving.enabled" in Embedded guide

Comment by Sanjeeb Sahoo [ 03/Feb/11 ]

I am not convinced by the change. There seem to be an assumption made about embedded which is not true. Why can't weaving be disabled outside embedded mode? Similarly, what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml? Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?

Comment by Mitesh Meswani [ 03/Feb/11 ]

What do you mean by weaving disabled outside embedded mode?

> what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml?
It will be disabled.

>Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?
No. It is just matter of name. EmbeddedProviderContractInfo currently just provides isWeavingDisabled(). Once the trunk opens up, I am inclined towards removing the class with some refactoring.

Comment by marina vatkina [ 03/Feb/11 ]

I'm confused... ServerEnvironmentImpl.isEmbedded() returns true in static-shell run of the EJB Timer Service...

Comment by marina vatkina [ 04/Feb/11 ]

All JPA tests in embedded ejb devtests failed - see http://hudson-sca.us.oracle.com/job/ejb-devtests-v3/281/

Comment by Mitesh Meswani [ 04/Feb/11 ]

Checked in 44918 in trunk and 44919 in branch.
The check in disables weaving for embedded EJB container case as was before. The status now is:
-Weaving is enabled by default when GlassFish Emedded API is used. It can be disabled by specifying property "org.glassfish.persistence.embedded.weaving.enabled" as "false"
-Weaving is disabled for embedded EJB container use case.

This behavior is not yet stable and can be changed in future versions of GlassFish.

Comment by ljnelson [ 04/Feb/11 ]

Thanks for your hard work.

Comment by Sanjeeb Sahoo [ 04/Feb/11 ]

Replying to Mitesh's response:

> What do you mean by weaving disabled outside embedded mode?
What this means is for whatever reason, someone may like to disable weaving in regular glassfish - e.g., someone wants to measure benefits of weaving, but they don't want to change their persistence.xmls to set the property. In such a case, the new system property can be very handy.

>> what happens when weaving has not disabled in embedded mode using this system property, but it has been explicitly disabled using persistence.xml?
> It will be disabled.
That's the desired behavior.

>> Are we loosing out any functionality by not using EmbeddedProviderContractInfo? Or, is it just a matter of name here?
> No. It is just matter of name. EmbeddedProviderContractInfo currently just provides isWeavingDisabled(). Once the trunk opens up, > I am inclined towards removing the class with some refactoring.

I look forward to this improvement to improve clarity in the code.

Thanks.

Comment by ljnelson [ 10/Feb/11 ]

Please also see http://java.net/jira/browse/GLASSFISH-13688





[GLASSFISH-15768] IIOP Loadbalancing not happening with old styled applications Created: 31/Jan/11  Updated: 19/Dec/16  Resolved: 03/Feb/11

Status: Closed
Project: glassfish
Component/s: rmi_iiop_load_balancer
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

Type: Bug Priority: Critical
Reporter: gopaljorapur Assignee: Ken Cavanaugh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-approved, 3_1-verified

 Description   

IIOP Loadbalancing not happening with old styled application

1. Start Cluster with 5 instances
2. Create 12 InitialContext in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see 12 of them in only one instance (incorrect behavior, load should be loadbalanced across cluster)

The test code is as follows

/// When we run appclient, we provide test id as RMIIIOPFOTC4, this creates 12 ic and 12 sfsb remote ref

if(testid.equals("RMIIIOPFOTC4"))
{
for(int i=0;i<12;i++)

{ client.createContextForACC(); client.createSFSBRemoteRef(); }

System.out.println("Test Passed");
}

//// Here is how ic is created

public void createContextForACC()
{
try

{ Context initial = new InitialContext(); myEnv = (Context)initial.lookup("java:comp/env/ejb"); }

catch(NamingException ne)

{ System.err.println("Caught an unexpected exception!"); ne.printStackTrace(); }

}

///// Here is how sfsb remote ref is
public void createSFSBRemoteRef()
{
try

{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }
catch(Exception exc)
{ exc.printStackTrace(); }
}




*******************************************************************************************************************************************************

The scenario that works:

The variation of the test, RMIIOPFOTC4A

1. Start Cluster with 5 instances
2. Create 12 InitialContext with endpoint properties in the argument in a loop, create SFSB reference by looking ejb
3. grep for "SFSB Bean!" in server.log of all instances, you will see load distributed across all instances in the cluster (correct behavior)

Test code is as follows


/// When we run appclient, we provide test id as RMIIIOPFOTC4A, this creates 12 ic and 12 sfsb remote ref
if(testid.equals("RMIIIOPFOTC4A"))
{
for(int i=0;i<12;i++)
{ client.createContextForStandalone(); client.createSFSBRemoteRef(); }
System.out.println("Test Passed");
}

//// This is how createContextForStandalone

public void createContextForStandalone()
{
try
{ myEnv = new InitialContext(properties); }
catch(Exception exc)
{ System.err.println("Caught an unexpected exception!"); exc.printStackTrace(); }
}



///// This is how createSFSBRemoteRef is done ( its same as scenario when test fails)

public void createSFSBRemoteRef()
{
try
{ Object sfsbobjref = myEnv.lookup("TestSFSB"); sfsbhomeref = (SFSBRemoteHomeRef)PortableRemoteObject.narrow(sfsbobjref, SFSBRemoteHomeRef.class); sfsbref = sfsbhomeref.create("SFSB Bean!"); System.out.println(sfsbref.validate()); }

catch(Exception exc)

{ exc.printStackTrace(); }

}

Here is how to deploy
asadmin --user admin deploy --retrieve /export/DecCVS/agentrepo//appclient --availabilityenabled=true --target st-cluster --force=true RMIIIOPFailover.ear

appclient execution
/export/DecCVS/glassfish3/glassfish/bin/appclient -Dcom.sun.appserv.iiop.endpoints=hat2k1.us.oracle.com:23700,hat2k1.us.oracle.com:23701,hat2k2.us.oracle.com:23700,hat2k2.us.oracle.com:23701,hat2k2.us.oracle.com:23702 -client /export/DecCVS/agentrepo/appclient/RMIIIOPFailoverClient/rmi-iiop-client2Client.jar -mainclass samples.rmiiiopclient.client.ACC_Standalone_Client



 Comments   
Comment by gopaljorapur [ 01/Feb/11 ]

This is important and should be fixed for 3.1

Comment by Ken Cavanaugh [ 03/Feb/11 ]

How bad is its impact? (Severity)
Regression in IIOP FOLB from GF 2.1.

How often does it happen? (Frequency)
Happens all the time in Gopal's test scenario.
It fails because LB happens to only one instance.

How much effort is required to fix it?
I have a proposed fix in the GF naming code (still discussing this with Mahesh and Marina).
The fix is to make sure that the JavaURLContext for java:comp/env/ejb has the correct
SerialContext.

What is the risk of fixing it? (Risk)
Low. Only FOLB is affected.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
The end user can avoid using java:comp/env/ejb. I'm not sure whether that is reasonable.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
yes

How long has the bug existed in the product?
Since the beginning of GF 3.1 FOLB development (roughly 6 months)

Do regression tests exist for this issue?
No FOLB dev test (I haven't been able to set this up), but there is an SQE test.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
IIOP FOLB SQE tests

When will a tested fix be ready for integration?
Probably later today (2/3/11)

Comment by Ken Cavanaugh [ 03/Feb/11 ]

Fixed in rev 44898.





[GLASSFISH-15767] java.lang.NullPointerException while creating Message Security Config in configs other than server-config. Created: 31/Jan/11  Updated: 19/Dec/16  Due: 03/Feb/11  Resolved: 10/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

OS: Windows 2008 server
browser : IE 7


Attachments: File message-security.bmp     Text File msgSecurity.patch    
Tags: 3_1-approved, 3_1-regression, 3_1-verified

 Description   

GF Build Used: Promoted b40.

In a different config (cluster,instance etc), other than server-config, Under the Message Security Configurations --only SOAP shows up and HttpServlet is not listed. When we try to create a HttpServlet Configuration providing all values , I see the below Exception in the Console and server.log.

Here is the Exception in the server.log:

[#|2011-01-31T12:06:23.360-0800|SEVERE|oracle-glassfish3.1|com.sun.jersey.spi.co
ntainer.ContainerResponse|_ThreadID=43;_ThreadName=Thread-1;|The RuntimeException could not be mapped to a response, re-throwing to the HTTP container
java.lang.NullPointerException
at org.glassfish.admin.rest.resources.PropertiesBagResource.setParentAndTagName(PropertiesBagResource.java:279)
at org.glassfish.admin.rest.resources.generatedASM.ProviderConfigResource.getPropertiesBagResource(Unknown Source)
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.jersey.server.impl.uri.rules.SubLocatorRule.invokeSubLocator(SubLocatorRule.java:157)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:97)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:121)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:86)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:136)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:74)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1347)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1279)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1229)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1219)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:180)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:145)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:177)
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:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
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)

#]


 Comments   
Comment by Anissa Lam [ 01/Feb/11 ]

1. How bad is its impact? (Severity)
Cannot create message security config (HttpServlet) layer.

2. How often does it happen? (Frequency)
whenever user wants to do this for any config that doesn't already have both SOAP and HttpServlet auth layer created.

3. How much effort is required to fix it? (Cost)
1.5 days

4. What is the risk of fixing it? (Risk)
low.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Use the CLI create-security-message-provider which will create the msg security config AND the provider. No work around in GUI.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes

7. How long has the bug existed in the product?
When we move to use REST

8. Do regression tests exist for this issue?
No, but i will add dev test for this when checking in the code.

9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
The GUI dev test.

10. When will a tested fix be ready for integration?
2/2/2011.

Comment by Chris Kasso [ 01/Feb/11 ]

Approved for RC2.

Comment by Anissa Lam [ 01/Feb/11 ]

Attached is the patch. Looks like lots of change, when most is just white space re-formatingthe code.
Changes include:

  • Fix endpoint in msgSecurityNew.jsf to create a new msg. security config with a Provider.
  • Add back the checkbox during creation to indicate this provider should be the default.
  • Add inline help text for this checkbox.
  • Define the Delete button in the Providers table so that provider can be deleted.
Comment by Jason Lee [ 02/Feb/11 ]

Changes look fine, though I'd like to see a test added for this scenario.

Comment by Anissa Lam [ 02/Feb/11 ]

Committed to both Trunk & 3.1 Branch.
Trunk: rev# 44846 ( The comment has Anissa as approval, when it should be Nazrul/Chris).
3.1 Branch: rev# 44849

==============================
Project: glassfish
Repository: svn
Revision: 44846
Author: anilam
Date: 2011-02-03 04:59:34 UTC
Link:

Log Message:
------------
Issue GLASSFISH-15767. Fix creating MsgSecurityConfig issue.

  • Fix endpoint in msgSecurityNew.jsf to create a new msg. security config with a Provider.
  • Add back the checkbox during creation to indicate this provider should be the default.
  • Add inline help text for this checkbox.
  • Define the Delete button in the Providers table so that provider can be deleted.
  • Added a new MsgSecurityTest.java that contains 5 dev test in this area.

Approve: Anissa
Reviewer: Jason.

Revisions:
----------
44846

Modified Paths:
---------------
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/providerAttr.inc
trunk/v3/admingui/common/src/main/resources/org/glassfish/common/admingui/Strings.properties
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/providers.jsf
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/msgSecurityNew.jsf
trunk/v3/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/providerTableButtons.inc
trunk/v3/admingui/common/src/main/resources/security/msgSecurity/providerEdit.jsf

Added Paths:
------------
trunk/v3/admingui/devtests/src/test/java/org/glassfish/admingui/devtests/MsgSecurityTest.java

============================
Project: glassfish
Repository: svn
Revision: 44849
Author: anilam
Date: 2011-02-03 05:07:14 UTC
Link:

Log Message:
------------
Issue GLASSFISH-15767. Fix creating MsgSecurityConfig issue.

  • Fix endpoint in msgSecurityNew.jsf to create a new msg. security config with a Provider.
  • Add back the checkbox during creation to indicate this provider should be the default.
  • Add inline help text for this checkbox.
  • Define the Delete button in the Providers table so that provider can be deleted.
  • Added a new MsgSecurityTest.java that contains 5 dev test in this area.

Fix has been committed to Trunk as rev# 44846

Approve: Nazrul, Chris Kasso
Reviewer: Jason.

Revisions:
----------
44849

Modified Paths:
---------------
branches/3.1/admingui/common/src/main/java/org/glassfish/admingui/common/handlers/SecurityHandler.java
branches/3.1/admingui/common/src/main/resources/security/msgSecurity/providerTableButtons.inc
branches/3.1/admingui/common/src/main/resources/security/msgSecurity/providerEdit.jsf
branches/3.1/admingui/common/src/main/resources/security/msgSecurity/providers.jsf
branches/3.1/admingui/common/src/main/resources/org/glassfish/common/admingui/Strings.properties
branches/3.1/admingui/common/src/main/resources/security/msgSecurity/providerAttr.inc
branches/3.1/admingui/common/src/main/resources/security/msgSecurity/msgSecurityNew.jsf

Added Paths:
------------
branches/3.1/admingui/devtests/src/test/java/org/glassfish/admingui/devtests/MsgSecurityTest.java

Comment by shaline [ 10/Feb/11 ]

On nightly build 42, dated 02-09-11, when we add the HttpServlet message Security configuration, The below Error is displayed in the Console:
"An error has occurred
An error occurred during replication"

server.log has the below message:
[#|2011-02-10T12:45:52.718-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingu
i|_ThreadID=34;_ThreadName=Thread-3;|RestResponse.getResponse() gives FAILURE.
endpoint = 'http://localhost:4848/management/domain/configs/config/remote-ins1-c
onfig/security-service/message-security-config'; attrs = '

{providername=Client, classname=com.sun.xml.wss.provider.ClientSecurityAuthModule, providertype=client , target=remote-ins1-config, isdefaultprovider=true, layer=HttpServlet}

'|#]

Attached screenshot

Comment by shaline [ 10/Feb/11 ]

Attached Screen shot.

Comment by Anissa Lam [ 10/Feb/11 ]

I cannot reproduce this problem. I added at least 5 more dev test to this screen when i fix this, and they are all passing also.

I tried creating a cluster, C1 and then go to C1-config to create this HttpServlet MS config, no error.
I tried creating a cluster, C3, start that and then stop it. then create, no error.
I copied a config from default-config and create this, no error.

Please give step by step instruction on how to reproduce this.
When looking at the screen, the error is coming from backend, and the endpoint and info that is passing in are correct. Please attach server.log, this may give more idea of what is going on.

Ok, I see when this error occurs, that is when the cluster is running.
This is completely different than what this bug was opened.

Let me try this with CLI and see.

Comment by Anissa Lam [ 10/Feb/11 ]

I am going to reopen the issue so i can mark this fixed.

Comment by Anissa Lam [ 10/Feb/11 ]

What you see here is completely different than the bug you originally filed.
There is NO NPE and the msg security config pages are all working fine.

What you are seeing is from the backend when you try to create the msg Security config HttpServelet layer for a running cluster. I have opened up GLASSFISH-15951 to track that.

This GUI bug has been fixed as indicated.

Comment by shaline [ 28/Feb/11 ]

Verified in promoted b43.





[GLASSFISH-15766] Tree nodes Title page has Sun Logo before the node name. Created: 31/Jan/11  Updated: 19/Dec/16  Due: 02/Feb/11  Resolved: 31/Jan/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

OS: Windows 2008 Server.
Browser: IE 7.


Attachments: File console.bmp     JPEG File Firefox.jpg     JPEG File IE.jpg     JPEG File ogs-chrome.jpg    
Tags: 3_1-approved, 3_1-verified

 Description   

GF build used : promoted b40.

In the adminConsole , when we click on the tree nodes , Common Tasks, Domain, Server etc, the Page Title displayed on the Left Top corner of the browser has the Logo "Sun" before the tree node name .
It shows up for all the tree nodes in the left tree.
and also appears before the URL http://hostname:4848

Attached the screen shot.
Notice the Sun Logo before "Common Tasks", and also in the URL field.



 Comments   
Comment by Anissa Lam [ 31/Jan/11 ]

This is new to me. I have never seen this 'Sun' logo, It doesn't even exist in our workspace.

We have been using the GlassFish favicon for many release, haven't changed that.
I tried Firefox, chrome, IE, Safari, for both the open source brand and the oracle brand. Refer to the attached images. I cannot reproduce this.

This is probably something in your environment. Can you try other browser ? or restart the browser, clear cache etc.

We don't even have such an icon in our workspace. Not much i can do. closing as will not fix.

Comment by Anissa Lam [ 31/Jan/11 ]

Closing as cannot reproduce.

Comment by shaline [ 31/Jan/11 ]

I see the blue Sun Logo on all browsers using promoted b40. (latest-og-windows.exe, and latest-ogs.zip) bundles on Sparc and Windows 2008.

Machines which has these installations can be accessed as below to see the Sun Logo.
http://bigapp-oblade-3.us.oracle.com:4848 (windows 2008)
http://cub-s10-2.us.oracle.com:4848 (Sparc)

Comment by Snjezana Sevo-Zenzerovic [ 31/Jan/11 ]

FWIW, this seems to be admingui/customtheme/src/main/resources/images/favicon.ico from internal workspace...

Comment by Anissa Lam [ 31/Jan/11 ]

Thanks Snjezana, thats correct.

How bad is its impact? (Severity)
Doesn't affect function, but we shouldn't be showing sun icon.

How often does it happen? (Frequency)
On every page.

How much effort is required to fix it? (Cost)
Very little

What is the risk of fixing it? (Risk)
Very little

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No.

  • How long has the bug existed in the product?
    This icon has been used for Sun branded server fore 3.0.1. So, since day 1 for 3.1
  • Do regression tests exist for this issue?
    No.
  • Which tests should QA (re)run to validate the fix did not destabilize GlassFish?
    Just by observing, i guess.
  • When will a tested fix be ready for integration? (We know this)
    It is ready now.
Comment by Chris Kasso [ 31/Jan/11 ]

Approved for RC2.

Comment by Anissa Lam [ 31/Jan/11 ]

The oracle favicon.ico has been checked into both trunk and branch 3.1 in the internal workspace.

Trunk version: # 2159
Branch version: # 2160

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

svn commit
Sending admingui/customtheme/src/main/resources/images/favicon.ico
Transmitting file data .
Committed revision 2160.

Comment by shaline [ 10/Feb/11 ]

Verified in b42 nightly dated 02-09-11





[GLASSFISH-15759] HTTP Status 500 Error when orb-listener-1/SSL tab is clicked Created: 30/Jan/11  Updated: 19/Dec/16  Resolved: 31/Jan/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_dev
Fix Version/s: 3.1_dev

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

OS: SOlaris SParc 10
Browser: firefox 3.6


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

 Description   

Build used : promoted b40.

Click on server-config/ORB/iiop Listeners/orb-listener-1/SSL tab.
The below HTTP Status 500 error is shown in browser.

HTTP Status 500 -

type Exception report

message

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

exception

javax.servlet.ServletException: java.lang.RuntimeException while attempting to process a 'beforeCreate' event for 'event156'.

root cause

java.lang.RuntimeException: java.lang.RuntimeException while attempting to process a 'beforeCreate' event for 'event156'.

root cause

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException while attempting to process a 'beforeCreate' event for 'event156'.

root cause

java.lang.reflect.InvocationTargetException

root cause

java.lang.NullPointerException

note The full stack traces of the exception and its root causes are available in the Oracle GlassFish Server 3.1 logs.
Oracle GlassFish Server 3.1

Attached server.log



 Comments   
Comment by shaline [ 30/Jan/11 ]

Same Error appears for a new iiop listener also, when the SSL tab is clicked for the new iiop listener.
Create a new iiop listener and provide network address and listener port. Check Listener Enabled and Security. Click Save. Select the created Listener and click on SSL tab. we see the above Error.

Comment by srinik76 [ 31/Jan/11 ]

1. How bad is its impact? (Severity)
Cannot access SSL Page

2. How often does it happen? (Frequency)
everytime when trying to access the ssl page

3. How much effort is required to fix it? (Cost)
3 hrs

4. What is the risk of fixing it? (Risk)
Small.

5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
No.

6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
No. don't think it helps just telling user they cannot access the SSL page in GUI, when they have alredy realize that.

7. How long has the bug existed in the product?
Do not know the timeline, when the ssl element under orb-listener was removed to not be available by default and to be available only by accessing create-ssl

8. Do regression tests exist for this issue?
No. SSL Page access need to be added in the IiopListenerTest

9. Which tests should QA (re)run to validate the fix did not destabilize GlassFish?
Need to run IiopListenerTest under admingui/devtests

10. When will a tested fix be ready for integration?
It is ready now.

Comment by srinik76 [ 31/Jan/11 ]

Attaching the diff

Index: corba/src/main/resources/sslEdit.jsf
===================================================================
— corba/src/main/resources/sslEdit.jsf (revision 44793)
+++ corba/src/main/resources/sslEdit.jsf (working copy)
@@ -62,6 +62,10 @@
setPageSessionAttribute(key="childType" value="ssl")
setPageSessionAttribute(key="selfUrl", value="#

{pageSession.parentUrl}/#{pageSession.childType}");
setPageSessionAttribute(key="showCancelButton" value="#{true}" )
+ setPageSessionAttribute(key="createSslUrl", value="#{pageSession.parentUrl}

/create-ssl");
+ createMap(result="#

{pageSession.valueMap}");
+ mapPut(map="#{pageSession.valueMap}

" key="target" value="#

{pageSession.configName}

");
+ mapPut(map="#

{pageSession.valueMap}

" key="certNickname" value="");
#include "/common/shared/sslPrepare.inc"

Comment by Anissa Lam [ 31/Jan/11 ]

The change looks fine. I have also rebuild based on this change and see that it fixes this issue.

Comment by srinik76 [ 31/Jan/11 ]

Checked in into the trunk.

Issue : 15759, HTTP Status 500 Error when orb-listener-1/SSL tab is clicked
Approved by: Nazrul, Reviewed by : Anissa

Sending resources/sslEdit.jsf
Transmitting file data .
Committed revision 44804.

Comment by srinik76 [ 31/Jan/11 ]

Checked into the 3.1 branch

Sending resources/sslEdit.jsf
Transmitting file data .
Committed revision 44805.

Issue : 15759, HTTP Status 500 Error when orb-listener-1/SSL tab is clicked
Approved by: Nazrul, Reviewed by : Anissa

Comment by srinik76 [ 31/Jan/11 ]

Branch 3.1 URL -> branches/3.1/admingui/corba/src/main/resources/sslEdit.jsf

trunk URL -> trunk/v3/admingui/corba/src/main/resources/sslEdit.jsf





[GLASSFISH-15749] [Regression] CDI injection breaks PersistenceContext injection Created: 29/Jan/11  Updated: 19/Dec/16  Resolved: 02/Feb/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_dev
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Harald Wellmann Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File GLASSFISH-15749.diff     File glassfish-15749.war     Zip Archive glassfish-15749.zip    
Tags: 3_1-approved

 Description   

While testing the fix for GLASSFISH-15660 with 3.1-b39, I ran into a new problem. I reused the example with the same project structure from GLASSFISH-15660, and I added an injected persistence context to the picture.

package com.blogspot.hwellmann.cdi;

import javax.annotation.PostConstruct;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import javax.inject.Inject;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

import com.blogspot.hwellmann.cdi.service.InjectedService;

@Singleton
@Startup
public class ClientService {

@PersistenceContext
private EntityManager em;

@Inject
private InjectedService injected;

@PostConstruct
public void execute()

{ System.out.println("accessing injected EntityManager"); em.find(Person.class, 99); System.out.println("accessing injected service"); injected.doSomething(); System.out.println("done"); }

}

Now when deploying may WAR, I get a NullPointerException when accessing the EntityManager. However, the EntityManager works as expected when I comment out the InjectedService and remove the beans.xml file, so the root cause appears to be CDI and not JPA.

Again, this is a regression from 3.1-b33 where the same WAR runs fine.

I'll attach my example WAR and the sources.



 Comments   
Comment by Harald Wellmann [ 29/Jan/11 ]

Note: The persistence unit uses the jdbc/__default data source, so you have to start the Derby Network server delivered with Glassfish to run the test.

Comment by Harald Wellmann [ 29/Jan/11 ]

The same WAR runs on JBoss 6.0.0.Final, so I guess the problem is on the Glassfish side and not in Weld.

Comment by Sivakumar Thyagarajan [ 30/Jan/11 ]

3.1 Change Control questionnaire:

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
  • Introduces an incompatibility

This scenario (Injection of Java EE resources into Beans packaged within WEB-INF/lib) was working in a prior release.

How often does it happen? (Frequency)

Rarely. Only scenarios where a bundled library in a WAR (a jar under WEB-INF/lib) includes a Bean and that Bean performs Java EE style injection of a resource would face this scenario. Workaround would be to use CDI style injection in the bundled library.

How much effort is required to fix it? (Cost)

Fix available and attached with the issue.

What is the risk of fixing it? (Risk)

Not much. I have run CDI devtests. Will also run CDI TCK before commiting.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

Yes. Workaround exists. The Bean in the bundled library could use CDI injection of the resource or could be packaged differently such that the Bean is packaged in the WAR(WEB-INF/classes).

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

Yes.

How long has the bug existed in the product?

Since b39.

Do regression tests exist for this issue?

I will add a developer test.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

SQE's CDI tests.

When will a tested fix be ready for integration?

By today(Jan 31st) end of day IST.

Comment by Sivakumar Thyagarajan [ 30/Jan/11 ]

Proposed fix for this issue

Comment by Sivakumar Thyagarajan [ 30/Jan/11 ]

Analysis: GF wasn't adding InjectionServices Service for the BeanDeploymentArchive of the bundled library and hence Weld wasn't calling GF to perform injection on Beans bundled in the bundled library.

Comment by Sivakumar Thyagarajan [ 30/Jan/11 ]

Marking issue as critical and not a blocker, as a workaround exists for the issue.

Comment by Sivakumar Thyagarajan [ 02/Feb/11 ]

Closed as part of the following commits
Trunk: svn commit 44819
GF3.1 branch: svn commit 44820

Comment by Harald Wellmann [ 08/Feb/11 ]

Tested with b41, but I still see the same bug.

Also tried replacing @PersistenceContext by @Inject, which causes another exception:

Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:744)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:138)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:872)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:884)
at org.jboss.weld.bean.SessionBean$1$1.proceed(SessionBean.java:195)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54)
at org.jboss.weld.bean.SessionBean$1.inject(SessionBean.java:190)
at org.glassfish.weld.services.JCDIServiceImpl.injectEJBInstance(JCDIServiceImpl.java:198)
at com.sun.ejb.containers.BaseContainer.injectEjbInstance(BaseContainer.java:1675)
at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:504)
... 38 more

Is there anything else to do for injecting an EntityManager with CDI?

I could live with this workaround (if it did work) but unpacking all libs into WEB-INF/classes is not really acceptable.

I was going to reopen this bug, but I don't seem to have permission to do so.





[GLASSFISH-15727] osgi-cache/felix dir name change Created: 27/Jan/11  Updated: 19/Dec/16  Resolved: 28/Jan/11

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: None
Fix Version/s: 3.1_dev

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

Tags: 3_1-approved

 Description   

GlassFish 3.1 recent build inadvertantly renamed osgi-cache/Felix. It used to be osgi-cache/felix in 3.0.1. This also breaks the directory naming standard used in rest of GlassFish (used lower case).



 Comments   
Comment by Sanjeeb Sahoo [ 27/Jan/11 ]

It's not a recent change - the name was changed 6-7 months ago... Will revert it back soon. Can you approve the bug?

Comment by Nazrul [ 27/Jan/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Introduces an incompatibility

How often does it happen? (Frequency)
Always.

How much effort is required to fix it? (Cost)
Low

What is the risk of fixing it? (Risk)
Low

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
N/A

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
N/A

Comment by Sanjeeb Sahoo [ 28/Jan/11 ]

Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ..
Committed revision 44769.

Comment by Sanjeeb Sahoo [ 28/Jan/11 ]

Forward ported to trunk:

Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
Transmitting file data ..
Committed revision 44770.





[GLASSFISH-15726] appclient fails on Windows systems using MKS toolkit with java.lang.ClassNotFoundException: org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader Created: 27/Jan/11  Updated: 19/Dec/16  Resolved: 27/Jan/11

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

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

Windows running MKS toolkit


Tags: 3_1-approved

 Description   

Running the appclient script on a Windows system running the MKS toolkit fails with a stack trace beginning with this:

java.lang.Error: java.lang.ClassNotFoundException: org.glassfish.appclient.client.acc.agent.ACCAgentClassLoader
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1357)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1320)

The problem is that Java indicates that the CLIBootstrap class (which builds the java command to actually launch the ACC) is in a Windows environment, and therefore CLIBootstrap generates the java command using the semi-colon for the path separator. An earlier change dealt with this problem with Windows/cygwin systems, but does not handle the Windows/MKS case. As a result, the generated java command uses semi-colons for path separators but the MKS shell expects to see colons for that, and semi-colons as command separators.



 Comments   
Comment by Tim Quinn [ 27/Jan/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
  • Likely to generate a customer support call

How often does it happen? (Frequency)
when a user runs the appclient command on a Windows system from an MKS shell

How much effort is required to fix it? (Cost)
minimal - I have a fix in my workspace already

What is the risk of fixing it? (Risk)
low to moderate - the appclient script is used not only on Windows/MKS and Windows/cygwin systems but also on non-Windows systems. I have already tested the fix on Windows/MKS and Mac OS X as an example of a non-Windows environment. I still need to test on Windows/cygwin.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
There is not a practical workaround. Users could avoid invoking appclient under MKS but that would defeat the purpose of having MKS installed - typically to provide a more uniform environment across multiple platforms.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

Comment by Tim Quinn [ 27/Jan/11 ]

Fixes checked in for the 3.1 branch and the trunk.

Branch check-in:

Project: glassfish
Repository: svn
Revision: 44766
Author: tjquinn
Date: 2011-01-28 05:54:29 UTC
Link:

Log Message:
------------
Fix for 15726

Similarly to cygwin, MKS on Windows expects the path separator to be the Unix-style colon separator. Java, left alone, though, will report the semi-colon as the path separator on Windows even if run under MKS. These changes cause the appclient script (non-Windows version only, which is used by MKS and cygwin shells as well as Unix shells) to set a property which indicates (basically) that a Unix-style invocation is in progress. This way, CLIBootstrap can use the suitable path separator.

Approved: Nazrul
Reviewed: Chris
Tests: appclient tests on Mac OS X, Windows/cygwin, Windows/MKS

Revisions:
----------
44766

Modified Paths:
---------------
branches/3.1/appclient/client/acc/src/main/java/org/glassfish/appclient/client/CLIBootstrap.java
branches/3.1/appclient/client/appclient-scripts/src/main/resources/glassfish/bin/appclient

Trunk check-in:

Project: glassfish
Repository: svn
Revision: 44767
Author: tjquinn
Date: 2011-01-28 05:55:52 UTC
Link:

Log Message:
------------
Fix for 15726

Similarly to cygwin, MKS on Windows expects the path separator to be the Unix-style colon separator. Java, left alone, though, will report the semi-colon as the path separator on Windows even if run under MKS. These changes cause the appclient script (non-Windows version only, which is used by MKS and cygwin shells as well as Unix shells) to set a property which indicates (basically) that a Unix-style invocation is in progress. This way, CLIBootstrap can use the suitable path separator.

Approved: Nazrul
Reviewed: Chris
Tests: appclient tests on Mac OS X, Windows/cygwin, Windows/MKS

Revisions:
----------
44767

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





[GLASSFISH-15720] [regression] jpa failure in trimHavingClause on Microsoft SQL server Created: 27/Jan/11  Updated: 19/Dec/16  Due: 03/Feb/11  Resolved: 02/Feb/11

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

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

solaris and linux


Tags: 3_1-approved, 3_1-regression, 3_1-verified

 Description   

glassfisg-3.1-b39.zip
jpa failure in trimHavingClause on Microsoft SQL server

  • EJB3-EJBQL-EAR-J2DB-test_trimHavingClause_01: FAIL -
    The test passed on Derby with the same build.

To reproduce the failure:
set env with referece of
http://agni-1.us.oracle.com/JSPWiki/Wiki.jsp?page=V31CoreInstruction
in appserver-sqe, do
ant microsoftdd-setup
in appserver-sqe/pe/ejb/ejb30/ejbql, do
ant -f buildJava2DB.xml microsoftdd all



 Comments   
Comment by sherryshen [ 27/Jan/11 ]

public boolean test_trimHavingClause_01() {

/* Test for TRIM BOTH characters(blanks) in the Having Clause
*/

boolean pass=false;
Object result = null;
String expected = " David R. Vincent ";

try {

result = manager.createQuery(
"select c.name FROM Customer c group by c.name HAVING trim(BOTH from c.name) = 'David R. Vincent'")
.getSingleResult();

The same test passed in v3.0. The query in fine log shows the difference in trim.

v3.1:
SELECT NAME FROM CUSTOMER_TABLE GROUP BY NAME HAVING (TRIM(NAME) = ?)
bind => [1 parameter bound]

v3.0:
SELECT NAME FROM CUSTOMER_TABLE GROUP BY NAME HAVING (RTRIM(LTRIM(NAME)) = ?)
bind => [David R. Vincent]|#]

v3.1 b39
EclipseLink, version: Eclipse Persistence Services - 2.2.0.v20110114-r8831|#]
User: dbo
Database: Microsoft SQL Server Version: Microsoft SQL Server 2008 R2 - 10.50.1600.1
Driver: SQLServer Version: 4.2.0.026220 (F044226.U015810)|#]

[#|2011-01-27T14:48:39.619-0800|FINE|glassfish3.1|org.eclipse.persistence.session.file:/space/test1/v3/glassfish/domains/domain1/applications/ejb30-ejbqlApp/lib/ejb30-ejbql-par.jar_em.sql|_ThreadID=20;_ThreadName=Thread-1;ClassName=null;MethodName=null;|
SELECT NAME FROM CUSTOMER_TABLE GROUP BY NAME HAVING (TRIM(NAME) = ?)
bind => [1 parameter bound]|#]

[#|2011-01-27T14:48:39.726-0800|FINE|glassfish3.1|org.eclipse.persistence.session.file:/space/test1/v3/glassfish/domains/domain1/applications/ejb30-ejbqlApp/lib/ejb30-ejbql-par.jar_em.sql|_ThreadID=20;_ThreadName=Thread-1;ClassName=null;MethodName=null;|SELECT 1|#]

[#|2011-01-27T14:48:39.936-0800|WARNING|glassfish3.1|org.eclipse.persistence.session.file:/space/test1/v3/glassfish/domains/domain1/applications/ejb30-ejbqlApp/lib/ejb30-ejbql-par.jar_em|_ThreadID=20;_ThreadName=Thread-1;|
Local Exception Stack:
Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.2.0.v20110114-r8831): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: [DataDirect][SQLServer JDBC Driver][SQLServer]'TRIM' is not a recognized built-in function name.
Error Code: 195
Call: SELECT NAME FROM CUSTOMER_TABLE GROUP BY NAME HAVING (TRIM(NAME) = ?)
bind => [1 parameter bound]
Query: ReportQuery(referenceClass=Customer sql="SELECT NAME FROM CUSTOMER_TABLE GROUP BY NAME HAVING (TRIM(NAME) = ?)")
at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:333)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:684)
at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:526)
at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1729)
at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:566)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:207)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:193)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:264)
at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:647)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2558)
at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllReportQueryRows(ExpressionQueryMechanism.java:2501)
at org.eclipse.persistence.queries.ReportQuery.executeDatabaseQuery(ReportQuery.java:841)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:808)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1040)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:383)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1126)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2842)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1521)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1503)
at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1477)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:484)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.getSingleResult(EJBQueryImpl.java:772)
at pe.ejb.ejb30.ejbql.session.TestSessionBean.test_trimHavingClause_01(TestSessionBean.java:3361)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4155)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5347)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5327)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:206)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy183.test_trimHavingClause_01(Unknown Source)
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.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:144)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:174)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1624)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1486)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:990)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:214)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:742)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.dispatch(CorbaMessageMediatorImpl.java:539)
at com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.doWork(CorbaMessageMediatorImpl.java:2324)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.sql.SQLException: [DataDirect][SQLServer JDBC Driver][SQLServer]'TRIM' is not a recognized built-in function name.
at com.ddtek.jdbc.sqlserverbase.ddb7.b(Unknown Source)

v3.0 b74b

EclipseLink, version: Eclipse Persistence Services - 2.0.0.v20091127-r5931|#]

User: dbo
Database: Microsoft SQL Server Version: Microsoft SQL Server 2008 R2 - 10.50.1600.1
Driver: SQLServer Version: 4.2.0.026220 (F044226.U015810)|#]

[#|2011-01-27T14:15:35.198-0800|FINE|glassfishv3.0|org.eclipse.persistence.session.file:/space/test1/v30b74b/glassfish/domains/domain1/applications/ejb30-ejbqlApp/lib/ejb30-ejbql-par.jar_em.sql|_ThreadID=26;_ThreadName=Thread-1;ClassName=null;MethodName=null;|
SELECT NAME FROM CUSTOMER_TABLE GROUP BY NAME HAVING (RTRIM(LTRIM(NAME)) = ?)
bind => [David R. Vincent]|#]

Comment by sherryshen [ 28/Jan/11 ]

Thank Mitesh for following up this issue at EclipseLink.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=335707
Mitesh Meswani 2011-01-28 12:20:03 EST
SQL Server does not offer TRIM. EclipseLink had a work around in place to use
RTRIM(LTRIM() ) instead. A change in
https://fisheye2.atlassian.com/changelog/eclipselink/?cs=6761 has removed the
work around. This results in JPQL TRIM() not working against SQL Server

Comment by Nazrul [ 01/Feb/11 ]

This requires a fix from EclipseLink

Comment by Mitesh Meswani [ 02/Feb/11 ]

How bad is its impact? (Severity)
Identify why the fix needs to occur now:

  • Is a regression of functionality or performance available in a prior release
  • The basic functionality of JPQL TRIM() will not work against SQL server and any other databases that does not directly support TRIM()

How often does it happen? (Frequency)

  • Always against SQL Server

How much effort is required to fix it? (Cost)

  • The fix is available in EclipseLink RC4

What is the risk of fixing it? (Risk)

  • EclipseLink RC4 also fixes other critical issues found during testing. These changes may introduce regression.
  • They have run their full set of tests against various platforms to ensure against regression.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?

  • No.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?

  • NA

How long has the bug existed in the product?

  • 5-6 months (a regression).

Do regression tests exist for this issue?

  • Yes, EclipseLink has added a regression test for this issue.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

  • The standard QE test suit against SQL Server and one more database

When will a tested fix be ready for integration?

  • It is available now.
Comment by Chris Kasso [ 02/Feb/11 ]

Approved for RC2.

Comment by Mitesh Meswani [ 02/Feb/11 ]

Fixed in branch with rev 44831
Fixed in trunk with rev 44832

Comment by sherryshen [ 17/Feb/11 ]

Verified the fix on glassfish-3.1-b43.zip and microsoftdd.





[GLASSFISH-15716] appclient -help option shows usage output, not help output Created: 27/Jan/11  Updated: 19/Dec/16  Due: 27/Jan/11  Resolved: 27/Jan/11

Status: Resolved
Project: glassfish
Component/s: