[GLASSFISH-20554] SERVERINSTADMINPASSWORD.JSF SHOWS WITH ERROR WHEN CREATE ADMIN PASSWORD Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b87_RC3

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

[ENV]
OS:Windows2008 x64
Server locale: fr
Browser:IE8
Browser locale:en / fr-FR

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b85/archive/bundles/java_ee_sdk-7-b85-jdk7-windows-x64-ml.exe



 Description   

1. Set browser language as en;
2. Login Admin console;
3. Click Domain and switch to Administrator Password tab;
4. Enter a string as password and click Save button;
5. URL turns to "http://localhost:4848/common/appServer/serverInstAdminPassword.jsf" with
error. Pls check picture attached.
6. Set browser language as fr-FR, and the same issue occurs.

This bug is migrated from bugdb 16735152.



 Comments   
Comment by li.wu [ 17/May/13 ]

Fixed in b87.





[GLASSFISH-20553] NLS:ERROR SHOWS IN SERVER ADMINISTRATION PAGE IN FR Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b87_RC3

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

[ENV]
OS:Windows2008 x64
Server locale: fr
Browser:IE8
Browser locale:en / fr-FR

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b85/archive/bundles/java_ee_sdk-7-b85-jdk7-windows-x64-ml.exe



 Description   

1. Set browser language as en;
2. Click Server(Server Administration) from left tree;
3. There is errors related to jsf in the page. Pls check picture attached.
4. Set browser language as fr-FR,and the same issue happens.

In the generated index.jsf, there is "serveur (serveur d'administration)" in
<a>content. Maybe the single quote causes this issue.

This bug is migrated from bugdb 16735184.



 Comments   
Comment by li.wu [ 17/May/13 ]

Fixed in b87.





[GLASSFISH-20548] CREATE A CLUSTERED SERVER INSTANCE FAILED IN CONFIGURATION Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: other
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b87_RC3

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

[ENV]
Windows2008 zh_TW 64bit

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b80/archive/bundles/java_ee_sdk-7-b80-jdk7-windows-x64-ml.exe



 Description   

1.Download shiphome and install it with domain1;
2.Check domain1 is running by running cmd: asadmin list-domains;
3.Click java_ee_sdk-7-b80-jdk7-windows-x64-ml.exe and select Custom
Installation;
4.Select Create a clustered server instance in Configuration step;
5.Click Create Cluster checkbox and keep default value c1 for Cluster Name
and domain1 for Domain Name;
6.Click Next;
7.Config Result is failure due to domain1 is not running. Pls check picture
attached.

This bug is migrated from bugdb 16543515 .



 Comments   
Comment by li.wu [ 17/May/13 ]

Fixed in b87.





[GLASSFISH-20547] EXCEPTION THROWS OUT WHEN STARTING STANDALONE INSTANCE IN ADMIN CONSOLE Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b80_EE7MS6
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Minor
Reporter: li.wu Assignee: michael.y.chen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

[ENV]
Windows2008 zh_TW 64bit
Firefox 11

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b80/archive/bundles/java_ee_sdk-7-b80-jdk7-windows-x64-ml.exe



 Description   

1. Login admin console and click Standalone Instances;
2. Create a new instance named instance1 with default Configuration
instance1-config and Node localhost-domain1;
3. Select instance1 and click Start;
4. An error has occurred:
java.lang.StringIndexOutOfBoundsException: String index out of range: -29

This bug is migrated from bugdb 16543627.



 Comments   
Comment by li.wu [ 17/May/13 ]

Fixed in b87.





[GLASSFISH-20546] ERROR OCCURS WHEN CLICK SSL TAB FOR NETWORK PROTOCOL OF ADMIN-LISTENER Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b81
Fix Version/s: 4.0_b87_RC3

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

[ENV]
Windows2008 zh_TW 64bit
Firefox 11

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b81/archive/bundles/java_ee_sdk-7-b81-jdk7-windows-x64-ml.exe



 Description   

1. Install java_ee bundle and login admin console;
2. Click Configurations->default config>Network Config->Protocols;
3. Click admin-listener and switch to Protocol tab;
4. Click SSL tab, page shows An Error has occurred;
5. Check server.log there is an exception:
[2013-03-29T14:50:21.253+0800] [glassfish 4.0] [INFO] []
[com.sun.enterprise.config.modularity.ConfigModularityUtils] [tid:
_ThreadID=161 _ThreadName=admin-listener(9)] [timeMillis: 1364539821253]
[levelValue: 800] [[
cannot get parent config bean for: default-confi
java.lang.NullPointerException
at
com.sun.enterprise.config.modularity.ConfigModularityUtils.getOwner(ConfigModu
larityUtils.java:371)
at
com.sun.enterprise.config.modularity.ConfigModularityUtils.getOwningObject(Con
figModularityUtils.java:333)
at
org.glassfish.admin.rest.resources.TemplateRestResource.setParentAndTagName(Te
mplateRestResource.java:353)
at
org.glassfish.admin.rest.resources.generatedASM.ProtocolResource.getSslResourc
e(Unknown Source)
at sun.reflect.GeneratedMethodAccessor1656.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.j
ava:43)
at java.lang.reflect.Method.invoke(Method.java:601)

This bug is migrated from bugdb 16572529.



 Comments   
Comment by li.wu [ 17/May/13 ]

Fixed in b87.





[GLASSFISH-20544] NLS:UNLOCALIZED STRINGS IN CONCURENCY PAGES OF ADMIN CONSOLE Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b87_RC3

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

[ENV]
OS:Windows2008 zh_CN
Browser:Firefox 11
Browser locale:zh_CN

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b83/archive/bundles/java_ee_sdk-7-b83-jdk7-windows-x64-ml.exe



 Description   

1. Login Admin console;
2. Click Resources -> Concurrent Resources ->Context Services;
3. "Logical JNDI Name" is not translated in Context services page;
4. Click New button to create new context service;
5. "Shift-click or Control-click for multiple contexts" is not translated in
this page;
6. "Logical JNDI Name" is not translated neither in page of Managed Thread
Factories, Managed Executor Services, Managed Scheduled Executor Services.
This bug is migrated from bugdb 16633436



 Comments   
Comment by li.wu [ 17/May/13 ]

Fixed in b87





[GLASSFISH-20543] NLS:HELP IS NOT TRANSLATED IN ADMIN CONSOLE Created: 17/May/13  Updated: 17/May/13  Resolved: 17/May/13

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b87_RC3

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

[ENV]
OS:Windows2008 zh_CN
Browser:Firefox 11
Browser locale:zh_CN

[SHIPHOME]
http://javaweb.us.oracle.com/java/re/javaeesdk/7.0/promoted/b83/archive/bundles/java_ee_sdk-7-b83-jdk7-windows-x64-ml.exe



 Description   

1. Login Admin console;
2. Click Help on the right top;
3. Help window pops up, but all help information is not translated.
This bug is migrated from bugdb 16633465.



 Comments   
Comment by li.wu [ 17/May/13 ]

Fixed in b87.





[GLASSFISH-20526] NLS: UNLOCALIZED STRINGS IN THE LOGGER SETTINGS -> GENERAL PAGE Created: 14/May/13  Updated: 14/May/13  Resolved: 14/May/13

Status: Closed
Project: glassfish
Component/s: i18n
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: michael.fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: RHEL 5u6 x64
Bundle: java_ee_sdk-7-b82-jdk7-linux-ml.sh
Server Locale: pt_BR.UTF-8
Browser Locale: ko-kr
JDK: 1.7.0_13 x64


Attachments: JPEG File loggerSettings_unloca.jpg    

 Description   

[To reproduce]
1. In the Admin Console page, go to configurations -> default-config -> Logger Settings -> General tab.

There are unlocalized strings. attached screen shot for your reference.



 Comments   
Comment by sunny-gui [ 14/May/13 ]

Verified and fixed with java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh in OEL6 x64 ja_JP.UTF-8.





[GLASSFISH-20525] NLS: UNLOCALIZED STRINGS UNDER THE SSL TAB IN THE IIOP LISTENER PAGE Created: 14/May/13  Updated: 14/May/13  Resolved: 14/May/13

Status: Closed
Project: glassfish
Component/s: i18n
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: michael.fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: RHEL 5u6 x64
Bundle: java_ee_sdk-7-b82-jdk7-linux-ml.sh
Server Locale: pt_BR.UTF-8
Browser Locale: ko-kr
JDK: 1.7.0_13 x64


Attachments: JPEG File SSL_unloca.jpg    

 Description   

[To reproduce]
1. In the Admin Console page, go to configs -> default-config -> ORB -> IIOP Listener
2. Go to SSL tab in the SSL page.

There are unlocalized strings. attached screen shot for your reference.



 Comments   
Comment by sunny-gui [ 14/May/13 ]

Verified and fixed with java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh in OEL6 x64 ja_JP.UTF-8.





[GLASSFISH-20524] NLS: UNLOCALIZED STRINGS IN THE NEW REALMS PAGE IN THE ADMIN CONSOLE PAGE Created: 14/May/13  Updated: 14/May/13  Resolved: 14/May/13

Status: Closed
Project: glassfish
Component/s: i18n
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: michael.fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: RHEL 5u6 x64
Bundle: java_ee_sdk-7-b82-jdk7-linux-ml.sh
Server Locale: pt_BR.UTF-8
Browser Locale: ko-kr
JDK: 1.7.0_13 x64


Attachments: JPEG File newRealm_unloca.jpg    

 Description   

[To reproduce]
1. In the Admin Console page, go to configs -> default-config -> security -> realms.
2. In the Realms page, click on New button.

There are unlocalized strings. attached screen shot for your reference.



 Comments   
Comment by sunny-gui [ 14/May/13 ]

Verified and fixed with java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh in OEL6 x64 ja_JP.UTF-8.





[GLASSFISH-20523] NLS: UNLOCALIZED STRINGS IN THE RESOURCE ADAPTER CONFIGS PAGE IN ADMIN CONSOLE Created: 14/May/13  Updated: 14/May/13  Resolved: 14/May/13

Status: Closed
Project: glassfish
Component/s: i18n
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: michael.fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: RHEL 5u6 x64
Bundle: java_ee_sdk-7-b82-jdk7-linux-ml.sh
Server Locale: pt_BR.UTF-8
Browser Locale: ko-kr
JDK: 1.7.0_13 x64


Attachments: JPEG File ResourceAdapt_unloca.jpg    

 Description   

[To reproduce]
1. In the Admin Console page, go to Resources -> Resource Adapter Configs

Unlocalized strings in the Resource Adapter Configs page in Admin Console.

attached screen shot for your reference.



 Comments   
Comment by sunny-gui [ 14/May/13 ]

Verified and fixed with java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh in OEL6 x64 ja_JP.UTF-8.





[GLASSFISH-20522] NLS: UNLOCALIZED STRINGS IN THE CONNECTOR SERVICE PAGE IN ADMIN CONSOLE Created: 14/May/13  Updated: 14/May/13  Resolved: 14/May/13

Status: Closed
Project: glassfish
Component/s: i18n
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: michael.fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: RHEL 5u6 x64
Bundle: java_ee_sdk-7-b82-jdk7-linux-ml.sh
Server Locale: pt_BR.UTF-8
Browser Locale: ko-kr
JDK: 1.7.0_13 x64


Attachments: JPEG File connectorService_unloca.jpg    

 Description   

[To reproduce]
1. In the Admin Console page, go to Config -> default config -> Connector
Service.

Unlocalized strings in the Connector Service page in Admin Console. attached
screen shot for your reference.



 Comments   
Comment by sunny-gui [ 14/May/13 ]

Verified and fixed with java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh in OEL6 x64 ja_JP.UTF-8.





[GLASSFISH-20521] NLS: UNLOCALIZED STRINGS IN THE EDIT CONTEXT SERVICE PAGE IN ADMIN CONSOLE Created: 14/May/13  Updated: 14/May/13  Resolved: 14/May/13

Status: Closed
Project: glassfish
Component/s: i18n
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: sunny-gui Assignee: michael.fang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server OS: RHEL 5u6 x64
Bundle: java_ee_sdk-7-b82-jdk7-linux-ml.sh
Server Locale: ko_KR.UTF-8
Browser Locale: pt-br
JDK: 1.7.0_13 x64


Attachments: JPEG File concurrent_unloca.jpg    

 Description   

[To reproduce]
1. In the Admin Console page, go to Resources -> Concurrent Resource > Context Service > concurrent_default service.

There are unlocalized strings in the Edit Context Service page. Attached screen shot for your reference.



 Comments   
Comment by sunny-gui [ 14/May/13 ]

Verified and fixed with java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh in OEL6 x64 ja_JP.UTF-8.





[GLASSFISH-20519] NLS: UNLOCALIZED STRINGS UNDER THE BATCH TAB IN THE ADMIN CONSOLE PAGE Created: 14/May/13  Updated: 14/May/13  Resolved: 14/May/13

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b83
Fix Version/s: 4.0_b87_RC3

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

Server OS: RHEL 5u6 x64
Bundle: java_ee_sdk-7-b83-jdk7-linux-ml.sh
Server Locale: ko_KR.UTF-8
Browser Locale: pt-br
JDK: 1.7.0_13 x64


Attachments: JPEG File batch_unloca1.jpg     JPEG File batch_unloca2.jpg    

 Description   

[To reproduce]
1. In the Admin Console page, go to server -> Batch tab.
2. Under Batch tab, click on 'Executions' or 'Configuration' sub tab.

There are unlocalized strings. Attached screen shot for your reference.



 Comments   
Comment by sunny-gui [ 14/May/13 ]

Verified and fixed with java_ee_sdk-7-b87-jdk7-linux-x64-ml.sh in OEL6 x64 ko_KR.UTF-8.





[GLASSFISH-20453] WebPipeline is not invoked Created: 01/May/13  Updated: 01/May/13  Resolved: 01/May/13

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

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

Tags: 4_0-approved

 Description   

The WebPipeline is not invoked in GlassFish 4.0.



 Comments   
Comment by Shing Wai Chan [ 01/May/13 ]
  • What is the impact on the customer of the bug?
    WebPipeline is not invoked. Some functionality may be missing.
  • What is the cost/risk of fixing the bug?
    Add back the WebPipeline as in 3.1.1.
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b87
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A
Comment by Shing Wai Chan [ 01/May/13 ]

Sending web-glue/src/main/java/com/sun/enterprise/web/BasePersistenceStrategyBuilder.java
Transmitting file data .
Committed revision 61790.





[GLASSFISH-20442] restore BeanValidatorNamingProxy to nucleus Created: 30/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Closed
Project: glassfish
Component/s: bean-validator
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

BeanValidatorNamingProxy was recently removed from nucleus, favoring an alternate implementation (in weld-integration) that integrates with CDI (since the Validator/ValidatorFactory needs to be retrieved from CDI when available). This is problematic in appclient distribution where the weld-integration module is not present.

The solution is to restore BeanValidatorNamingProxy and delegate to the weld-integration if available (implemented with @Inject @Optional @Named(...)).. This way, CDI will be interrogated for Validator objects if CDI is available, but the object will be returned either way.



 Comments   
Comment by mtaube [ 30/Apr/13 ]

This bug is causing the following CTS failure: com/sun/ts/tests/ejb30/misc/jndi/earjar/Client.java#beanValidator: Client_beanValidator

Comment by mtaube [ 30/Apr/13 ]

What is the impact on the customer of the bug?
appclients cannot look up Validator/ValidatorFactory from jndi

How likely is it that a customer will see the bug and how serious is the bug?
certain

Is it a regression?
Yes.

Does it meet other bug fix criteria (security, performance, etc.)?
no.

What CTS failures are caused by this bug?
com/sun/ts/tests/ejb30/misc/jndi/earjar/Client.java#beanValidator: Client_beanValidator

What is the cost/risk of fixing the bug?
Low

How risky is the fix? How much work is the fix? Is the fix complicated?
Low – restores previous behavior and adds a delegation model

Is there an impact on documentation or message strings?
no.

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
EJB, EJB cts, bean-validation CTS

Which is the targeted build of 4.0 for this fix?
rc3.

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
No.

Comment by mtaube [ 30/Apr/13 ]

Sending appserver/web/weld-integration/src/main/java/org/glassfish/weld/ValidationNamingProxy.java
Adding nucleus/core/kernel/src/main/java/org/glassfish/kernel/bean_validator/BeanValidatorNamingProxy.java
Transmitting file data ..
Committed revision 61753.





[GLASSFISH-20437] SFSB PreDestroy never commits during undeploy Created: 30/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

SFSB container calls PreDestroy during undeploy, but ContainerSynchronization prevents transaction completion.

  • What is the impact on the customer of the bug?
    PreDestroy behavior is not as described in the EJB spec
  • How likely is it that a customer will see the bug and how serious is the bug?
    If the code expects to flush data to the database, the data will be lost
  • Is it a regression?
    It's a missing part in the new functionality
  • Does it meet other bug fix criteria (security, performance, etc.)?
    no.
  • What CTS failures are caused by this bug?
    None.
  • What is the cost/risk of fixing the bug?
    Low.
  • How risky is the fix? How much work is the fix? Is the fix complicated?
    Minimal.
  • Is there an impact on documentation or message strings?
    no.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB
  • Which is the targeted build of 4.0 for this fix?
    rc3.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    No.


 Comments   
Comment by marina vatkina [ 30/Apr/13 ]

Fixed by accounting for SFSB PreDestroy called in a transaction.
Sending src/main/java/com/sun/ejb/containers/ContainerSynchronization.java
Transmitting file data .
Committed revision 61740.





[GLASSFISH-20435] NullPointer exception in domain log on cluster or instance creation Created: 29/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

gf-transaction-cluster-devtest reports NPEs during "create-cluster" or "create-local-instance --cluster" call (the log reports various actions on different threads, and the instance log starts at 13:15:42.166-0700) for the 'selfrecovery' and 'autorecovery' tests in the transaction/ee suite. It doesn't happen in other tests.

These are the DAS server.log fragments:

1:

[2013-04-29T13:15:36.997-0700] [glassfish 4.0] [INFO] [membership.snapshot.analysis] [ShoalLogger] [tid: _ThreadID=108 _ThreadName=GMS ViewWindowThread Group-c1] [timeMillis: 1367266536997] [levelValue: 800] [[
GMS1016: Analyzing new membership snapshot received as part of event: JOINED_AND_READY_EVENT for member: server of group: c1]]

[2013-04-29T13:15:37.424-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=55 _ThreadName=pool-8-thread-1] [timeMillis: 1367266537424] [levelValue: 1000] [[
Exception while processing config bean changes :
java.lang.NullPointerException
at java.lang.reflect.Proxy.getInvocationHandler(Proxy.java:656)
at org.jvnet.hk2.config.ConfigSupport.getImpl(ConfigSupport.java:246)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener$1.changed(CombinedJavaConfigSystemPropertyListener.java:249)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:288)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener.changed(CombinedJavaConfigSystemPropertyListener.java:195)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:400)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:390)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:280)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:278)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-04-29T13:15:38.233-0700] [glassfish 4.0] [INFO] [NCLS-CLSTR-20001] [javax.enterprise.cluster.gms.bootstrap] [tid: _ThreadID=154 _ThreadName=pool-24-thread-1] [timeMillis: 1367266538233] [levelValue: 800] [[
Adding instance in1 to health history table.]]

2:
[2013-04-29T13:18:07.273-0700] [glassfish 4.0] [INFO] [membership.snapshot.analysis] [ShoalLogger] [tid: _ThreadID=240 _ThreadName=GMS ViewWindowThread Group-c1] [timeMillis: 1367266687273] [levelValue: 800] [[
GMS1016: Analyzing new membership snapshot received as part of event: JOINED_AND_READY_EVENT for member: server of group: c1]]

[2013-04-29T13:18:08.084-0700] [glassfish 4.0] [SEVERE] [] [javax.enterprise.system.core] [tid: _ThreadID=234 _ThreadName=pool-49-thread-1] [timeMillis: 1367266688084] [levelValue: 1000] [[
Exception while processing config bean changes :
java.lang.NullPointerException
at java.lang.reflect.Proxy.getInvocationHandler(Proxy.java:656)
at org.jvnet.hk2.config.ConfigSupport.getImpl(ConfigSupport.java:246)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener$1.changed(CombinedJavaConfigSystemPropertyListener.java:249)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:288)
at com.sun.enterprise.v3.admin.listener.CombinedJavaConfigSystemPropertyListener.changed(CombinedJavaConfigSystemPropertyListener.java:195)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:400)
at org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:390)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:280)
at org.jvnet.hk2.config.Transactions$ConfigListenerNotifier$1$1.call(Transactions.java:278)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
]]

[2013-04-29T13:18:08.784-0700] [glassfish 4.0] [INFO] [NCLS-CLSTR-20001] [javax.enterprise.cluster.gms.bootstrap] [tid: _ThreadID=220 _ThreadName=pool-43-thread-1] [timeMillis: 1367266688784] [levelValue: 800] [[
Adding instance in1 to health history table.]]



 Comments   
Comment by Tom Mueller [ 30/Apr/13 ]

More information is needed on how to reproduce this issue.
I tried running the appserv-tests/devtests/transaction/ee tests by setting S1AS_HOME and APS_HOME and running "ant all", but the build fails. I tried just creating clustered instances and the message doesn't show up.
It would be helpful if the hudson job set "AS_LOGFILE" so that the commands that it executes would be recorded and the timestamps could be aligned with the server.log error messages.

Comment by marina vatkina [ 30/Apr/13 ]

The tests are executed by running 'ant all' (may be the S1AS_HOME and APS_HOME are not set properly?). The tests that report the NPE are 'selfrecovery' and 'autorecovery'

Comment by Tom Mueller [ 30/Apr/13 ]

To recreate the problem easily, do the following on a clean install:

asadmin start-domain
asadmin create-cluster c1
asadmin create-system-properties --cluster c1 a=b

The NullPointerException message is printed in the log during the 3rd command.

Comment by Byron Nevins [ 30/Apr/13 ]

Tom - Nice job turning it into a 3 command scenario. But #3 is wrong:

WRONG:
asadmin create-system-properties --cluster c1 a=b

RIGHT:
asadmin create-system-properties --target c1 a=b

Comment by Tom Mueller [ 30/Apr/13 ]
  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?

If the customer adds a system property to a cluster config, they will see this NPE.

Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
No. This was there in 3.1.2 also.
What CTS failures are caused by this bug?
None.

  • What is the cost/risk of fixing the bug?

How risky is the fix? How much work is the fix? Is the fix complicated?
Low risk. Just add checks for cluster==null in the right places.

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Tests that set system properties.
  • Which is the targeted build of 4.0 for this fix?
    Next one.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A.
Comment by Tom Mueller [ 30/Apr/13 ]

Approved for 4.0.

Comment by Tom Mueller [ 30/Apr/13 ]

Fixed on the trunk in revision 61757.





[GLASSFISH-20432] integrate javax.ejb-api:3.2 javax.transaction-api:1.2 Created: 29/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: glassfish
Component/s: None
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

Integrate final version of ejb-api and transaction-api.
This requires CCP as we re-inlined the jaxrpc that ejb depends on inside the ejb-api jar. Hence we can get rid of javax.xml.rpc-api.jar in the webprofile.

Also, javax.management-j2ee-api had to be relaxed and javax.xml.rpc.jar was not importing its exported package making the OSGi runtime resolving improper wirings. (javax.ejb used instead of javax.xml.rpc jar)

Full diff:

Index: appserver/pom.xml
===================================================================
--- appserver/pom.xml	(revision 61733)
+++ appserver/pom.xml	(working copy)
@@ -70,15 +70,15 @@
         <mojarra.version>2.2.0-m15</mojarra.version>
         <jsf-ext.version>0.2</jsf-ext.version>
         <woodstock.version>4.0.2.10</woodstock.version>
-        <javax.ejb-api.version>3.2-b02</javax.ejb-api.version>
+        <javax.ejb-api.version>3.2</javax.ejb-api.version>
         <javax.interceptor-api.version>1.2</javax.interceptor-api.version>
-        <javax.xml.rpc-api.version>1.1</javax.xml.rpc-api.version>
-        <javax.transaction-api.version>1.2-b03</javax.transaction-api.version>
+        <javax.xml.rpc-api.version>1.1.1</javax.xml.rpc-api.version>
+        <javax.transaction-api.version>1.2</javax.transaction-api.version>
         <jaxws-api.version>2.2.8</jaxws-api.version>
         <javax.faces-api.version>2.2-m12</javax.faces-api.version>
         <cdi-api.version>1.1-PRD</cdi-api.version>
         <javax.inject.version>1</javax.inject.version>
-        <javax.resource-api.version>1.7-b05</javax.resource-api.version>
+        <javax.resource-api.version>1.7</javax.resource-api.version>
         <javax.enterprise.deploy-api.version>1.6</javax.enterprise.deploy-api.version>
         <javax.security.jacc-api.version>1.5</javax.security.jacc-api.version>
         <javax.security.auth.message-api.version>1.1</javax.security.auth.message-api.version>
@@ -129,7 +129,7 @@
         <com.ibm.jbatch-runtime-all.version>1.0-b26</com.ibm.jbatch-runtime-all.version>
         <com.ibm.jbatch-ri-spi.version>1.0-b26</com.ibm.jbatch-ri-spi.version>
 	<javax.xml.soap-api.version>1.3.5</javax.xml.soap-api.version>
-	<javax.management.j2ee-api.version>1.1</javax.management.j2ee-api.version>
+	<javax.management.j2ee-api.version>1.1.1</javax.management.j2ee-api.version>
     </properties>
 
     <modules>
@@ -277,11 +277,10 @@
                                 <artifactId>javax.transaction-api</artifactId>
                                 <version>${javax.transaction-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>     
-                            <specVersion>1.1</specVersion>
-                            <newSpecVersion>1.2</newSpecVersion>
-                            <specBuild>03</specBuild>
+                            <specVersion>${javax.transaction-api.version}</specVersion>
+                            <specImplVersion>${javax.transaction-api.version}</specImplVersion>
                             <apiPackage>javax.transaction</apiPackage>
                         </spec>
                         <spec>
@@ -376,11 +375,10 @@
                                 <artifactId>javax.ejb-api</artifactId>
                                 <version>${javax.ejb-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
-                            <specVersion>3.1</specVersion>
-                            <newSpecVersion>3.2</newSpecVersion>
-                            <specBuild>02</specBuild>
+                            <specVersion>${javax.ejb-api.version}</specVersion>
+			    <specImplVersion>${javax.ejb-api.version}</specImplVersion>
                             <apiPackage>javax.ejb</apiPackage>
                         </spec>
                         <spec>
@@ -401,11 +399,10 @@
                                 <artifactId>javax.resource-api</artifactId>
                                 <version>${javax.resource-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
-                            <specVersion>1.6</specVersion>
-                            <newSpecVersion>1.7</newSpecVersion>
-                            <specBuild>05</specBuild>
+                            <specVersion>${javax.resource-api.version}</specVersion>
+			    <specImplVersion>${javax.resource-api.version}</specImplVersion>
                             <apiPackage>javax.resource</apiPackage>
                         </spec>
                         <spec>
@@ -429,7 +426,7 @@
                             <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
                             <specVersion>1.1</specVersion>
-                            <specImplVersion>1.1</specImplVersion>
+                            <specImplVersion>${javax.xml.rpc-api.version}</specImplVersion>
                             <apiPackage>javax.xml.rpc</apiPackage>
                         </spec>
                         <spec>
@@ -453,7 +450,7 @@
                             <nonFinal>false</nonFinal>
                             <jarType>api</jarType>
                             <specVersion>1.1</specVersion>
-                            <specImplVersion>1.1</specImplVersion>
+                            <specImplVersion>${javax.management.j2ee-api.version}</specImplVersion>
                             <apiPackage>javax.management.j2ee</apiPackage>
                         </spec>
                         <spec>
Index: appserver/packager/glassfish-common-full/pom.xml
===================================================================
--- appserver/packager/glassfish-common-full/pom.xml	(revision 61733)
+++ appserver/packager/glassfish-common-full/pom.xml	(working copy)
@@ -213,7 +213,10 @@
             <groupId>org.glassfish</groupId>
             <artifactId>javax.enterprise.concurrent</artifactId>
         </dependency>
-       
+        <dependency>
+            <groupId>javax.xml.rpc</groupId>
+            <artifactId>javax.xml.rpc-api</artifactId>
+        </dependency>  
     </dependencies>
 </project>
 
Index: appserver/packager/glassfish-common-web/pom.xml
===================================================================
--- appserver/packager/glassfish-common-web/pom.xml	(revision 61733)
+++ appserver/packager/glassfish-common-web/pom.xml	(working copy)
@@ -337,11 +337,7 @@
         <dependency>
             <groupId>javax.transaction</groupId>
             <artifactId>javax.transaction-api</artifactId>
-        </dependency>
-        <dependency>
-            <groupId>javax.xml.rpc</groupId>
-            <artifactId>javax.xml.rpc-api</artifactId>
-        </dependency>        
+        </dependency>      
     </dependencies>
     
     <repositories>


 Comments   
Comment by Romain Grécourt [ 29/Apr/13 ]
  • What is the impact on the customer of the bug?
    No final API used in GF for EJB and Transaction

How likely is it that a customer will see the bug and how serious is the bug?
Quite hidden
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
No.
What CTS failures are caused by this bug?
none.

  • What is the cost/risk of fixing the bug?
    medium, it involves OSGi wiring solving + packaging change to have javax.xml.rpc-api.jar only in Full Profile.

How risky is the fix? How much work is the fix? Is the fix complicated?
Relatively easy.

  • Is there an impact on documentation or message strings?
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    QL wp and GP.
  • Which is the targeted build of 4.0 for this fix?
    RC3.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    osgi metadata, relaxing some imports and making sure bundles are well doing substitutable export.
Comment by Tom Mueller [ 29/Apr/13 ]

Approved for 4.0.

Comment by Romain Grécourt [ 01/May/13 ]

done with svn revision #61754





[GLASSFISH-20426] promoted artifact has wrong url Created: 29/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

org.glassfish.main/glassfish-parent/4.0-b84/glassfish-parent-4.0-b84.pom has following non-existent URL:

https://github.com/sonatype/jvnet-parent/glassfish-nucleus-parent/glassfish-parent/tags/4.0-b84/jvnet-parent/glassfish-nucleus-parent/glassfish-parent

This must be the case for other artifacts as well.



 Comments   
Comment by Romain Grécourt [ 29/Apr/13 ]
  • What is the impact on the customer of the bug?
    Maven pom showing irrelevant information

How likely is it that a customer will see the bug and how serious is the bug?
It's unprofesional, anybody looking at the pom could see the problem.

Is it a regression?
yes.
Does it meet other bug fix criteria (security, performance, etc.)?
no.
What CTS failures are caused by this bug?
None.

  • What is the cost/risk of fixing the bug?
    Trivial.

How risky is the fix? How much work is the fix? Is the fix complicated?
Trivial.

  • Is there an impact on documentation or message strings?
    no.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    none.
  • Which is the targeted build of 4.0 for this fix?
    rc3.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    No.
Comment by Romain Grécourt [ 01/May/13 ]

Index: appserver/pom.xml
===================================================================
— appserver/pom.xml (revision 61761)
+++ appserver/pom.xml (working copy)
@@ -57,6 +57,7 @@
<scm>
<connection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/appserver</connection>
<developerConnection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/appserver</developerConnection>
+ <url>https://svn.java.net/svn/glassfish~svn/trunk/main/appserver</url>
</scm>

<properties>
Index: nucleus/pom.xml
===================================================================
— nucleus/pom.xml (revision 61761)
+++ nucleus/pom.xml (working copy)
@@ -59,6 +59,7 @@
<scm>
<connection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus</connection>
<developerConnection>scm:svn:https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus</developerConnection>
+ <url>https://svn.java.net/svn/glassfish~svn/trunk/main/nucleus</url>
</scm>
<issueManagement>
<system>IssueTracker</system>
romano@dhcp-prague08-third-floor-10-163-25-212:~/workspaces/glassfish/git-ws/all/main$ svn commit -m "fix for GLASSFISH-20426"
Sending appserver/pom.xml
Sending nucleus/pom.xml
Transmitting file data ..
Committed revision 61762.





[GLASSFISH-20412]  WebSocket API 1.0 Tyrus 1.0-rc4 integration Created: 25/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: glassfish
Component/s: web_socket
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved

 Description   

Integration of WebSocket API and Tyrus (RI); both already present in promoted repo: https://maven.java.net/content/groups/promoted/

patch:

Pavels-MacBook-Pro:main pavel$ svn diff
Index: appserver/pom.xml
===================================================================
--- appserver/pom.xml	(revision 61651)
+++ appserver/pom.xml	(working copy)
@@ -120,8 +120,8 @@
         <jaxr.version>JAXR_RA_20091012</jaxr.version>
         <weld.version>2.0.0.CR4</weld.version>
         <wsdl4j.version>1.6.2</wsdl4j.version>
-        <websocket-api.version>1.0-rc5</websocket-api.version>
-        <tyrus.version>1.0-rc3</tyrus.version>
+        <websocket-api.version>1.0</websocket-api.version>
+        <tyrus.version>1.0-rc4</tyrus.version>
         <jsonp.version>1.0-b06</jsonp.version>
         <concurrent-api.version>1.0-b06</concurrent-api.version>
         <concurrent.version>1.0-b08</concurrent.version>
@@ -341,11 +341,10 @@
                                 <artifactId>javax.websocket-api</artifactId>
                                 <version>${websocket-api.version}</version>
                             </artifact>
-                            <nonFinal>true</nonFinal>
+                            <nonFinal>false</nonFinal>
                             <jarType>api</jarType>     
-                            <specVersion>0.0</specVersion>
-                            <newSpecVersion>1.0</newSpecVersion>
-                            <specBuild>18</specBuild>
+                            <specVersion>1.0</specVersion>
+                            <specImplVersion>${websocket-api.version}</specImplVersion>
                             <apiPackage>javax.websocket</apiPackage>
                         </spec>
                         <spec>


 Comments   
Comment by Pavel Bucek [ 26/Apr/13 ]

Committed revision 61691.





[GLASSFISH-20408] glassfish-verifier: bin script don't have execution permissions Created: 25/Apr/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Critical
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: 4_0-approved, packaging, updatecenter, updatetool, verifier

 Description   

glassfish-verifier: bin script don't have execution permissions



 Comments   
Comment by Romain Grécourt [ 25/Apr/13 ]
  • What is the impact on the customer of the bug?
    Direct impact if they try to install glassfish-verifier package, they will have to chmod the bin verify script.

How likely is it that a customer will see the bug and how serious is the bug?
Every person trying to install and use glassfish-verify will see the bug.
Not serious, but unprofessional

Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
Yes.

What CTS failures are caused by this bug?
None.

  • What is the cost/risk of fixing the bug?
    Easy, it should be a change in the pkg prototype to specify the permissions properly.

How risky is the fix? How much work is the fix? Is the fix complicated?
not risky.

  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Install glassfish-verifier and try to start the script after installation.
  • Which is the targeted build of 4.0 for this fix?
    b87
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
Comment by Romain Grécourt [ 01/May/13 ]

Project: glassfish
Repository: svn
Revision: 61763
Author: romain_grecourt
Date: 2013-05-01 09:33:41 UTC
Link:

Log Message:
------------
fix for GLASSFISH-20408, make glassfish-verifier bin scripts executable

Revisions:
----------
61763

Modified Paths:
---------------
trunk/main/appserver/packager/glassfish-verifier/pom.xml

Added Paths:
------------
trunk/main/appserver/packager/glassfish-verifier/src/main/assembly
trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml

Diffs:
------
Index: trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml
===================================================================
— trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml (revision 0)
+++ trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml (revision 61763)
@@ -0,0 +1,68 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+
+ DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
+
+ Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved.
+
+ The contents of this file are subject to the terms of either the GNU
+ General Public License Version 2 only ("GPL") or the Common Development
+ and Distribution License("CDDL") (collectively, the "License"). You
+ may not use this file except in compliance with the License. You can
+ obtain a copy of the License at
+ https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
+ or packager/legal/LICENSE.txt. See the License for the specific
+ language governing permissions and limitations under the License.
+
+ When distributing the software, include this License Header Notice in each
+ file and include the License file at packager/legal/LICENSE.txt.
+
+ GPL Classpath Exception:
+ Oracle designates this particular file as subject to the "Classpath"
+ exception as provided by Oracle in the GPL Version 2 section of the License
+ file that accompanied this code.
+
+ Modifications:
+ If applicable, add the following below the License Header, with the fields
+ enclosed by brackets [] replaced by your own identifying information:
+ "Portions Copyright [year] [name of copyright owner]"
+
+ Contributor(s):
+ If you wish your version of this file to be governed by only the CDDL or
+ only the GPL Version 2, indicate your decision by adding "[Contributor]
+ elects to include this software in this distribution under the [CDDL or GPL
+ Version 2] license." If you don't indicate a single choice of license, a
+ recipient has the option to distribute your version of this file under
+ either the CDDL, the GPL Version 2 or to extend the choice of license to
+ its licensees as provided above. However, if you add GPL Version 2 code
+ and therefore, elected the GPL Version 2 license, then the option applies
+ only if the new code is made subject to such option by the copyright
+ holder.
+
+-->
+
+<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
+
+ <id>stage-package</id>
+ <formats>
+ <format>dir</format>
+ </formats>
+
+ <includeBaseDirectory>false</includeBaseDirectory>
+ <fileSets>
+ <fileSet>
+ <directory>$

{temp.dir}/glassfish/bin</directory>
+ <outputDirectory>${install.dir.name}/glassfish/bin</outputDirectory>
+ <fileMode>755</fileMode>
+ </fileSet>
+ <fileSet>
+ <directory>${temp.dir}

</directory>
+ <excludes>
+ <exclude>glassfish/bin/*</exclude>
+ <exclude>pkg_proto.py</exclude>
+ </excludes>
+ <outputDirectory>$

{install.dir.name}

</outputDirectory>
+ </fileSet>
+ </fileSets>
+</assembly>

Property changes on: trunk/main/appserver/packager/glassfish-verifier/src/main/assembly/glassfish-verifier.xml
___________________________________________________________________
Added: svn:eol-style

    1. -0,0 +1 ##
      +native
      \ No newline at end of property
      Index: trunk/main/appserver/packager/glassfish-verifier/pom.xml
      ===================================================================
      • trunk/main/appserver/packager/glassfish-verifier/pom.xml (revision 61762)
        +++ trunk/main/appserver/packager/glassfish-verifier/pom.xml (revision 61763)
        @@ -52,6 +52,10 @@
        <name>Verifier Package</name>
        <packaging>distribution-fragment</packaging>
        <description>This pom describes how to assemble the Verifier package</description>
        +
        + <properties>
        + <temp.dir>$ {project.build.directory}

        /dependency</temp.dir>
        + </properties>

<build>
<plugins>





[GLASSFISH-20407] GlassFish "client without the ACC" mode incorrectly returns a value for java:comp/InAppClientContainer Created: 25/Apr/13  Updated: 28/Apr/13  Resolved: 28/Apr/13

Status: Resolved
Project: glassfish
Component/s: naming
Affects Version/s: 4.0_b86_RC2
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: guojun.shan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This issue relates to the GlassFish Java SE client, as documented in
http://docs.oracle.com/cd/E18930_01/html/821-2418/gkusn.html#scrolltoc

If my application creates an InitialContext and does a JNDI lookup of java:comp/InAppClientContainer then I get a value of false.

This is incorrect. There should only be a value bound at this location if the application is running in a Java EE container. However this is not a Java EE container. It's (obviously) not a web or EJB container, and the product documentation describes this as "without the ACC" and so this is not an application client container either. So by returning a value at this location GlassFish is returning misleading information, since clients cannot use it to find out which container they are running in.



 Comments   
Comment by guojun.shan [ 27/Apr/13 ]

it seems this is a clarification for GLASSFISH-19052.

Comment by guojun.shan [ 28/Apr/13 ]

fixed At revision: 61695





[GLASSFISH-20396] Incorrect Implementation of NoBodyResponse#setContentLengthLong in HttpServlet.java Created: 24/Apr/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

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

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

Tags: 4_0-approved

 Description   

An issue has been filed about the incorrect implementation of NoBodyResponse#setContentLengthLong in https://java.net/jira/browse/SERVLET_SPEC-69

Since this is an implementation issue, per request, a GlassFish issue is filed for this.



 Comments   
Comment by Shing Wai Chan [ 24/Apr/13 ]
  • What is the impact on the customer of the bug?
    Incorrect implementation of content length in case of HEAD in HttpServlet
  • What is the cost/risk of fixing the bug?
    low
  • Is there an impact on documentation or message strings?
    No.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    SQE web tests
  • Which is the targeted build of 4.0 for this fix?
    4.0_b87
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    Yes. https://java.net/jira/browse/SERVLET_SPEC-69
Comment by Shing Wai Chan [ 24/Apr/13 ]

Sending javax.servlet/src/main/java/javax/servlet/http/HttpServlet.java
Sending javax.servlet/src/main/java/javax/servlet/http/LocalStrings.properties
Transmitting file data ..
Committed revision 61607.

Comment by Shing Wai Chan [ 24/Apr/13 ]

Sending pom.xml
Transmitting file data .
Committed revision 61626.





[GLASSFISH-20390] Possible concurrency issue in AsyncClientShutdownTask.run() in the MDB container Created: 23/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Closed
Project: glassfish
Component/s: jca
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: marina vatkina
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

While trying to verify GLASSFISH-20296, we found that endpointDeactivation may not be called during application undeployment intermittently.

We (Jagadish and I) think this could be due to a concurrency issue in AsynClientShutdownTask in
https://svn.java.net/svn/glassfish~svn/trunk/main/appserver/ejb/ejb-full-container/src/main/java/org/glassfish/ejb/mdb/MessageBeanContainer.java.

To reproduce:

  • In a multi-core laptop (Dell XPS) run the following
    Uncomment the lookup logic in endpointDeactivation in ra/src/connector/SimpleResourceAdapterImpl.java of https://svn.java.net/svn/glassfish~svn/trunk/v2/appserv-tests/devtests/connector/v3/connector1.6, and run the test "ant all".
  • observe that the endpointDeactivation is not called.
    [actually you should be able to use any MDB test that uses a resource adapter to deliver messages. Undeploy the application that uses the RA, and check if endpointDeactivation is called.]

If you set a breakpoint in AsyncClientShutdownTask.run() you can observe that the MessageBeanCllient.close() – which would actually call the RA's endpointDeactivation in the connector's code – is not called intermittently.

Making the "done" local variable in AsyncClientShutdownTask "volatile" appears to fix the issue.

If you can't seem to reproduce the issue, and would like to have us (Jagadish/I) verify your fixes, please let us know. We can reproduce this issue fairly reguarly.



 Comments   
Comment by marina vatkina [ 23/Apr/13 ]

It's not called on undeploy on my mac as well

Comment by marina vatkina [ 23/Apr/13 ]

The endpoint is not called because activeRar in ConnectorMessageBeanClient.close is null. Is it the same as GLASSFISH-20389?

Comment by marina vatkina [ 24/Apr/13 ]

activeRar is also null when undeploying ejb/ejb32/mdb test

Comment by Sivakumar Thyagarajan [ 24/Apr/13 ]

Marina: This issue is not related to GLASSFISH-20389. Infact that issue is now fixed with rev 61615, but you should still be able to reproduce this issue. If you can't reproduce and want us to run a diagnostic patch, please provide us a patch.

Transferring this to you.

Comment by marina vatkina [ 25/Apr/13 ]
  • What is the impact on the customer of the bug?
    It is reported to be seen on a multi-core device
  • How likely is it that a customer will see the bug and how serious is the bug?
    Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
    What CTS failures are caused by this bug?
    Not a regression, but the endpoint remains active until the server shutdown. May cause problems with redeployment.
  • What is the cost/risk of fixing the bug?
    Very low

How risky is the fix? How much work is the fix? Is the fix complicated?
Very low

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Connector, EJB
  • Which is the targeted build of 4.0 for this fix?
    Next
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    No.
Comment by Sivakumar Thyagarajan [ 26/Apr/13 ]

Marking this issue as closed, as we couldn't reproduce it anymore on trunk.





[GLASSFISH-20356] JPA remote SLSB tests failed with CDI enabled Created: 19/Apr/13  Updated: 03/May/13  Resolved: 26/Apr/13

Status: Resolved
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 4.0_b85
Fix Version/s: 4.0_b87_RC3

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

OEL6, JDK1.7.0_10


Tags: 4_0-approved

 Description   

JPA remote SLSB tests failed with CDI enabled
glassfish-4.0-b85.zip
appserver-sqe/pe/ejb/ejb30/issue/1153/basic
Testing EJB3 Issue 1153
appserver-sqe/pe/ejb/ejb30/issue/1251
Testing EJB 3.0 Issue 1251 Multiple PUs

Tests failed on b85 promoted, but passed on b84 promoted.

Thanks Mitesh for the initial analysis:
Injection of EntityManager not happening into a remote SLSB.
The tests started to fail with nightly of Apr 12 and pass
after disabling implicit-cdi (using asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false).



 Comments   
Comment by Mitesh Meswani [ 19/Apr/13 ]

Assigning to JJ since this issue is due to enable-implicit-cdi

Comment by tlcksnyder [ 19/Apr/13 ]

Exception from 1153 log ftp://adc2120166.us.oracle.com/pub/tmp/appserver-sqe_130418_EJB3_six_test_failure/issue_1153_basic.server.log.txt:
java.lang.NullPointerException
at SessionBean.findPerson(SessionBean.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4695)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:630)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:582)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4667)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:79)
at $Proxy400.findPerson(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie.dispatchToMethod(ReflectiveTie.java:143)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:173)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatchToServant(ServerRequestDispatcherImpl.java:528)
at com.sun.corba.ee.impl.protocol.ServerRequestDispatcherImpl.dispatch(ServerRequestDispatcherImpl.java:199)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequestRequest(MessageMediatorImpl.java:1549)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:1425)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleInput(MessageMediatorImpl.java:930)
at com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:213)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.handleRequest(MessageMediatorImpl.java:694)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.dispatch(MessageMediatorImpl.java:496)
at com.sun.corba.ee.impl.protocol.MessageMediatorImpl.doWork(MessageMediatorImpl.java:2222)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)]]

Exception for 1251 ftp://adc2120166.us.oracle.com/pub/tmp/appserver-sqe_130418_EJB3_six_test_failure/issue_1251_server_log.txt

Comment by jjsnyder83 [ 19/Apr/13 ]

Can you provide info on how to download and execute the tests?

Comment by sherryshen [ 19/Apr/13 ]

1) To set up test env, please reference the instruction section I, IIa
http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/4.0+Core+Test+Instructions
(use co-ejb instead of co-core to save check out time).

After check out, do

$ ant start-domain
$ ant startDerby

in $SPS_HOME to start glassfish and derby.

2) To run test suite, do "ant all" in test suite dir, e.g.
appserver-sqe/pe/ejb/ejb30/issue/1153/basic
appserver-sqe/pe/ejb/ejb30/issue/1251

Comment by jjsnyder83 [ 25/Apr/13 ]

What is the impact on the customer of the bug?
EJB's won't work.

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?
The tests listed in this jira.

What is the cost/risk of fixing the bug?
N/A

How risky is the fix? How much work is the fix? Is the fix complicated?
N/A

Is there an impact on documentation or message strings?
No

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

Which is the targeted build of 4.0 for this fix?
4.0_b86_RC2

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.
N/A

Comment by jjsnyder83 [ 26/Apr/13 ]

Committed revision 61664.

Comment by sherryshen [ 03/May/13 ]

Verified the fix on build 87 promoted on May 1, 2013.





Loading of HK2 cache data slows down server initialization (GLASSFISH-20298)

[GLASSFISH-20350] Make DescriptorImpl Externalizable instead of Serializable Created: 19/Apr/13  Updated: 19/Apr/13  Resolved: 19/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

Type: Sub-task Priority: Major
Reporter: mtaube Assignee: mtaube
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved

 Description   

From parent task:

I've measured the time required for loadCachedData in both 4.0 and 3.1.2. This is for a subsequent restart, and is an average of 5 runs on a MBP:

4.0: 424 ms ("Felix" start time is 2726 ms), inhabitants size = 516415
3.1.2: 194 ms ("Felix start time is 1615 ms), inhabitants size = 371748

loadCachedData is approximately 20-25% faster if DescriptorImpl implements Externalizable (using the string-based representation of a Descriptor) instead of Serializable.

  • What is the impact on the customer of the bug?

Startup performance on a 'warm boot' is slowed down by serialization

  • What is the cost/risk of fixing the bug?

Low risk

  • Is there an impact on documentation or message strings?

no

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

quicklook

  • Which is the targeted build of 4.0 for this fix?

4.0_b87

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.


 Comments   
Comment by Tom Mueller [ 19/Apr/13 ]

Approved for 4.0

Comment by mtaube [ 19/Apr/13 ]

Committed revision 61562.





[GLASSFISH-20342] [REGRESSION] Remote SFSB.remove fails with IllegalStateException: Transaction exists on current thread. Created: 17/Apr/13  Updated: 30/Apr/13  Resolved: 30/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b87_RC3

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

linux


Tags: 4_0-approved, ian

 Description   

build: promoted build84

This is a Regression bug since the same tests passed against build83. I am not sure which component this bug belongs to and I just assign it to JMS module, please feel free to assign it to other component owner if it's not a JMS bug. Thanks.

Steps to reproduce the bug:

1. Install GF4.0, start domain
2. Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT: :pserver:<your cvs user>@sunsw.us.oracle.com:/m/jws
cd appserver-sqe
ant -f bootstrap.xml co-bat
3.set following env. variables
S1AS_HOME <GF install dir>, for example: /export/test/v4/glassfish4/glassfish
SPS_HOME <appserver-sqe>, for example: /export/test/appserver-sqe
ANT_HOME <ant location>, for example: /export/test/ant-1.7.1
JAVA_HOME <java location>, for example: /export/test/jdk1.7.0_11
4. cd <workspace dir>/appserver-sqe/, run "ant startDerby" to start derby database
5. cd <workspace dir>/appserver-sqe/pe/integrated-apps/bank, run "ant all".

3 test cases failed and the following errors displayed in the client side:

[echo] JMS1.1:JMS-P2P,UnifiedAPI:StatefulSession-CMT,ReceiveMap,CallStatefulSession:#8 : FAIL
[echo] Error : RemoteException : java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
[echo] java.rmi.RemoteException: null; nested exception is:
[echo] javax.ejb.EJBException
[echo]
[echo]
[echo]
[echo] Wrong type of message received
[echo]
[echo] JMS1.1:JMS-PubSub,UnifiedAPI:AppClient-DurableSubscription,ReceiveText:StatefulSession-CMT,SendText:#9 : FAIL
[echo] Error : Did not receive expected message
[...]
[echo] - SyncControllerJNDI:Lookup:JMS_Destination:Queue:CreatedWith-j2eeadmin:#6: PASS -
[echo] - SyncControllerJMS1.1:JMS-P2P,UnifiedAPI:StatefulSession-CMT,ReceiveMap,CallStatefulSession:#8: FAIL -
[echo] - SyncControllerJNDI:Lookup:JMS_Destination:Topic:CreatedWith-j2eeadmin:#5: PASS -
[echo] - SyncControllerJNDI:Lookup:SessionBean:Stateful:#2: PASS -
[echo] - SyncControllerJMS1.1:JMS-PubSub,UnifiedAPI:AppClient-DurableSubscription,ReceiveText:StatefulSession-CMT,SendText:#9: FAIL -
[echo] - SyncControllerJMS1.1:JMS-P2P,UnifiedAPI:AppClient-SendMap:StatefulSession-CMT,ReceiveMap:#7: PASS -
[echo] - SyncControllerJNDI:Lookup:SessionBean:Stateful:#1: PASS -
[echo] - SyncControllerCMP2.0:UnpopulateDatabase:#11: PASS -
[echo] - SyncControllerJNDI:Lookup:JMS_ConnectionFactory:Topic:CreatedWith-j2eeadmin:#4: PASS -
[echo] - SyncControllerJMS1.1:JMS-UnifiedAPI:AppClient-CloseJMSConnection:#10: PASS -
[echo] - SyncControllerCMP2.0:PopulateDatabase:#3: PASS -
[echo] -----------------------------------------
[echo] Total PASS: 9
[echo] Total FAIL: 2

----------- ------------------------
6. There are some exceptions in server.log
------------------------------------

EJB5184:A system exception occurred during an invocation on EJB ContentControllerEjb, method: null]]

[2013-04-17T14:09:51.546-0700] [glassfish 4.0] [WARNING] [] [javax.enterprise.system.container.ejb.com.sun.ejb.containers] [tid: _ThreadID=117 _ThreadName=p: thread-pool-1; w: 4] [timeMillis: 1366232991546] [levelValue: 900] [[

javax.ejb.EJBException: java.lang.IllegalStateException: Transaction exists on current thread.
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2016)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1979)
at com.sun.ejb.containers.StatefulSessionContainer.removeBean(StatefulSessionContainer.java:1185)
at com.sun.ejb.containers.EJBObjectImpl.remove(EJBObjectImpl.java:198)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invokeEJBObjectMethod(EJBObjectInvocationHandler.java:283)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:170)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:123)
at $Proxy245.remove(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:239)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:150)
at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:226)
at com.sun.ejte.j2ee.bank.contentcontroller.ejb._ContentController_DynamicStub.remove(com/sun/ejte/j2ee/bank/contentcontroller/ejb/_ContentController_DynamicStub.java)
at com.sun.ejte.j2ee.bank.jmsasynccontroller.ejb.DepositMdb.onMessage(DepositMdb.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1057)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1129)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:4118)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4675)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4655)
at org.glassfish.ejb.mdb.MessageBeanContainer.deliverMessage(MessageBeanContainer.java:1197)
at org.glassfish.ejb.mdb.MessageBeanListenerImpl.deliverMessage(MessageBeanListenerImpl.java:81)
at com.sun.enterprise.connectors.inbound.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:171)
at $Proxy278.onMessage(Unknown Source)
at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:283)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.IllegalStateException: Transaction exists on current thread.
at com.sun.enterprise.transaction.JavaEETransactionManagerSimplified.resume(JavaEETransactionManagerSimplified.java:990)
at com.sun.ejb.containers.EJBContainerTransactionManager.postInvokeTx(EJBContainerTransactionManager.java:441)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:4475)

at com.sun.ejb.containers.StatefulSessionContainer.postInvokeTx(StatefulSessionContainer.java:1852)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2009)
... 33 more
]]



 Comments   
Comment by marina vatkina [ 17/Apr/13 ]

What is the date of build 84? Does this test fail on the latest nightly? A fix for a similar issue was committed on Apr 9th.

Comment by sonialiu [ 17/Apr/13 ]

Promoted build84-RC1 was promoted on 04/10
Apr 10 10:18 glassfish-4.0-b84.zip

Comment by sonialiu [ 17/Apr/13 ]

I just ran the tests against latest nightly build (04/17 nightly) and it also failed.

Comment by ethan.wang [ 18/Apr/13 ]

Already reproduced the exception with latest GF build, will look further into it for the cause.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Any further update on this bug? Is this to be fixed for 4.0 release?
We need to ensure we have the fixes for 4.0 wrapped up ASAP.

Comment by ethan.wang [ 24/Apr/13 ]

By far this looks like a concurrent issue to me. In preInvokeTx() we suspend the tx before invoking removeBean() against a SFSB, I checked and the current tx was set to null as expected. Then in postInvokeTx () we try to resume the tx but we find the current tx is not null anymore, so an IllegalStateException is raised saying "Transaction exists on current thread".

Current tx is saved in a TreadLocal object by TransactionManager and the failed cases are in relevant with JMS asynchronous messaging,so it seems like a concurrent issue. I'm looking further into it for the root cause.

Comment by ethan.wang [ 26/Apr/13 ]

The root cause is clear now. For SFSB using BMT, when remove() is being called upon it, postInvokeTx() would be invoked twice, the 1st one is for the PreDestroy callback and another is for remove() method itself, so when tx is suspended for remove(), the second attempt of resuming the tx would fail because it's already resumed. I discussed with Marina about this and I'm working on a fix now.

Comment by marina vatkina [ 30/Apr/13 ]
  • What is the impact on the customer of the bug?
    BMT bean remove fails when called in a transaction
  • How likely is it that a customer will see the bug and how serious is the bug?
    BMT bean remove fails when called in a transaction
  • Is it a regression?
    Yes.
  • Does it meet other bug fix criteria (security, performance, etc.)?
    no.
  • What CTS failures are caused by this bug?
    None.
  • What is the cost/risk of fixing the bug?
    Low so far - testing
  • How risky is the fix? How much work is the fix? Is the fix complicated?
    Minimal so far - testing
  • Is there an impact on documentation or message strings?
    no.
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    EJB
  • Which is the targeted build of 4.0 for this fix?
    rc3.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    No.
Comment by marina vatkina [ 30/Apr/13 ]

Fixed by bypassing tx if it's a BMT SFSB.
Sending ejb-container/src/main/java/com/sun/ejb/containers/StatefulSessionContainer.java
Transmitting file data .
Committed revision 61741.





[GLASSFISH-20340] [regression] Make HK2 cache io buffer size is not configurable Created: 17/Apr/13  Updated: 18/Apr/13  Resolved: 18/Apr/13

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: 4.0_b84_RC1
Fix Version/s: 4.0_b87_RC3

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

Tags: 4_0-approved, performance

 Description   

It used to be configurable earlier, but during hk2 2.x, it has been changed to become a fixed value. Fix it so that perf team can use it to tune the system.



 Comments   
Comment by mtaube [ 18/Apr/13 ]

What is the impact on the customer of the bug?

They will see a performance improvement during startup when io buffer size is optimized for the machine running glassfish

What is the cost/risk of fixing the bug?

This particular change is not risky, will only take effect if a property is specified in osgi.properties

Is there an impact on documentation or message strings?

No

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

quicklook

Which is the targeted build of 4.0 for this fix?

b88

If this an integration of a new version of a component from another project,
what are the changes that are being brought in? This might be list of
Jira issues from that project or a list of revision messages.

n/a

Comment by Tom Mueller [ 18/Apr/13 ]

I hesitate in approving this in that I don't completely agree that this should even be tunable (or should have ever been tunable). More knobs are not necessarily better, and there isn't any proof that different values are needed for different systems. And even if different values were beneficial, is there actually going to be documentation on how users could actually tune this value or is there a performance tuner that sets the value. IMHO, it would be better to just determine a single value that is reasonable for the systems that we target and put that value in the code.

Approved for 4.0.





[GLASSFISH-20296] Make endpoint component naming context available during call to endpointDeactivation Created: 12/Apr/13  Updated: 30/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

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

Tags: connectors

 Description   

To handle CONNECTOR_SPEC-4, the Connectors 1.7 spec says the following in Section Para #3 of Section 13.4.4:
– snip –
The application server must make the application component environment
namespace of the endpoint (that is being activated), available to the resource adapter
during the call to the endpointActivation and endpointDeactivation
methods. The resource adapter may use this JNDI context to access other resources.
– snip –

Though GLASSFISH-19452 provides the naming context during endpointActivation, GF doesn't provide the endpoint naming context to the resource adapter during the call to endpointDeactivation. Please fix this.



 Comments   
Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Hi Guojun
Can you please take a look into this issue ASAP?

Need your eval for this issue for inclusion into or exclusion from 4.0.

Comment by guojun.shan [ 22/Apr/13 ]

Amy Yang said GLASSFISH-19452 should has covered this issue.
Could you please verify it?
thanks.

Comment by Sivakumar Thyagarajan [ 23/Apr/13 ]

We still observe this issue. Please find our observations while running a test RA that performs a lookup of a resource defined in a MDB's component context in endpointDeactivation.

— snip —
[2013-04-23T15:27:33.604+0530] [glassfish 4.0] [INFO] [] [] [tid:
_ThreadID=133 _ThreadName=Thread-7] [timeMillis: 1366711053604]
[levelValue: 800] [[
[SimpleResourceAdapterImpl] ==> endpointDeactivation called...]]

[2013-04-23T15:27:33.605+0530] [glassfish 4.0] [SEVERE] [] [] [tid:
_ThreadID=133 _ThreadName=Thread-8] [timeMillis: 1366711053605]
[levelValue: 1000] [[
javax.naming.NamingException: Lookup failed for 'java:comp/env/MyDB'
in
SerialContext[myEnv=

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

[Root exception is javax.naming.NamingException: Invocation exception: Got null ComponentInvocation ]
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at
connector.SimpleResourceAdapterImpl.endpointDeactivation(SimpleResourceAdapterImpl.java:91)
at
com.sun.enterprise.connectors.inbound.ConnectorMessageBeanClient.close(ConnectorMessageBeanClient.java:364)
at org.glassfish.ejb.mdb.MessageBeanContainer
$ASyncClientShutdownTask.run(MessageBeanContainer.java:1020)
at java.util.concurrent.Executors
$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask
$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.naming.NamingException: Invocation exception: Got null
ComponentInvocation
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.getComponentId(GlassfishNamingManagerImpl.java:842)
at
com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.lookup(GlassfishNamingManagerImpl.java:714)
at
com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:161)
at
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
... 12 more]]

[2013-04-23T15:27:33.605+0530] [glassfish 4.0] [SEVERE] [] [] [tid:
_ThreadID=133 _ThreadName=Thread-8] [timeMillis: 1366711053605]
[levelValue: 1000] [[
java.lang.Exception
at org.glassfish.ejb.mdb.MessageBeanContainer
$ASyncClientShutdownTask.setDone(MessageBeanContainer.java:1051)
at org.glassfish.ejb.mdb.MessageBeanContainer
$ASyncClientShutdownTask.run(MessageBeanContainer.java:1030)
at java.util.concurrent.Executors
$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask
$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)]]

[2013-04-23T15:27:33.610+0530] [glassfish 4.0] [INFO] [] [] [tid:
_ThreadID=46 _ThreadName=Thread-7] [timeMillis: 1366711053610]
[levelValue: 800] [[
bean removed]]
— snip —

Reproducing this should be easy:

  • Take an existing test that uses resource adapters to deliver to MDBs
  • In the RA's endpointDeactivation, lookup a resource defined in the MDB's component context.

It appears that the ComponentInvocation is null because the endpointDeactivation is called in an asynchronous task execution through the threadpoolexecutor, and the invocation context is maintained in an inheritablethreadlocal that is not carried forward to the async thread.

Comment by guojun.shan [ 24/Apr/13 ]

re-assign to Amy yang.

Comment by amy.yang [ 28/Apr/13 ]

i've sent the patch to Marina and will be on vacation for 3 days.

Comment by marina vatkina [ 29/Apr/13 ]

Fixed with
Sending ejb-full-container/src/main/java/org/glassfish/ejb/mdb/MessageBeanContainer.java
Transmitting file data .
Committed revision 61699.

Note1: the test 'unsetup' target needs the order of undeploy and unsetJdbc reversed so that the XAPointbase is still available during undeploy.

Note2: endpointDeactivation during shutdown is still broken - there is no EJB container in the picture:
[2013-04-29T01:06:06.247-0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=129 _ThreadName=Thread-4] [timeMillis: 1367222766247] [levelValue: 1000] [[
javax.naming.NamingException: Lookup failed for 'java:comp/env/MyDB' in SerialContext[myEnv=

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

[Root exception is javax.naming.NamingException: Invocation exception: Got null ComponentInvocation ]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at javax.naming.InitialContext.lookup(InitialContext.java:411)
at connector.SimpleResourceAdapterImpl.endpointDeactivation(SimpleResourceAdapterImpl.java:100)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.deactivateEndPoints(ActiveInboundResourceAdapterImpl.java:113)
at com.sun.enterprise.connectors.inbound.ActiveInboundResourceAdapterImpl.destroy(ActiveInboundResourceAdapterImpl.java:102)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl$RAShutdownTask.run(ResourceAdapterAdminServiceImpl.java:624)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.naming.NamingException: Invocation exception: Got null ComponentInvocation

Comment by Sivakumar Thyagarajan [ 29/Apr/13 ]

Thanks Marina for the fix. I was able to verify the fix and this works. I have fixed the test through
$ svn commit .
Sending connector1.6/build.xml
Sending connector1.6/ra/src/connector/SimpleResourceAdapterImpl.java
Transmitting file data ..
Committed revision 61712.

I will follow up with you about the shutdown Exception. I am not able to reproduce that. Are you able to reproduce that using the latest build? There was a undeployment ordering issue that was fixed through GLASSFISH-20403 that may have caused this issue, but that has been fixed. When I try to reproduce this using the steps below, I don't see the issue:

  • run "ant init-common build setup runtest" under appserv-tests/devtests/connector/v3/connector1.6
  • stop-domain
  • check server.log. I see the correct order (MDB being deactivated first, and then the RA.stop)

– server.log snippet –
[2013-04-29T20:39:44.057+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=124 _ThreadName=Thread-3] [timeMillis: 1367248184057] [levelValue: 800] [[
bean removed]]

[2013-04-29T20:39:44.062+0530] [glassfish 4.0] [INFO] [] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.inbound] [tid: _ThreadID=125 _ThreadName=__ejb-thread-pool1] [timeMillis: 1367248184062] [levelValue: 800] [[
No resource-adapter-mid specified, defaulting to the resource-adapter [ generic-ra ] that supports the requested message-listener [ connector.MyMessageListener ]]]

[2013-04-29T20:39:44.063+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=125 _ThreadName=Thread-3] [timeMillis: 1367248184063] [levelValue: 800] [[
[SimpleResourceAdapterImpl] ==> endpointDeactivation called...]]

[2013-04-29T20:39:44.065+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=125 _ThreadName=Thread-3] [timeMillis: 1367248184065] [levelValue: 800] [[
lookedup in RA endpointDeactivation:com.sun.gjc.spi.jdbc40.DataSource40@1eecd5d]]

[2013-04-29T20:39:44.089+0530] [glassfish 4.0] [INFO] [] [] [tid: _ThreadID=126 _ThreadName=Thread-3] [timeMillis: 1367248184089] [levelValue: 800] [[
[SimpleResourceAdapterImpl] ==> 999. Simple RA stop...]]

[2013-04-29T20:39:44.089+0530] [glassfish 4.0] [INFO] [ra.stop-successful] [javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service] [tid: _ThreadID=124 _ThreadName=Thread-34] [timeMillis: 1367248184089] [levelValue: 800] [[
RAR7094: generic-ra shutdown successful.]]

– server.log snippet –

Comment by Sivakumar Thyagarajan [ 30/Apr/13 ]

Heard from Marina that this may be due to the reordering bug. The shutdown issue is not valid anymore.

Comment by marina vatkina [ 30/Apr/13 ]

Siva, the 'Got null ComponentInvocation' exception on shutdown is there if undeploy fails - try reverting the order of unsetup operations in the test. Something gets into an inconsistent state in that case.

The regular shutdown is fine, and I do see the log message 'lookedup in RA endpointDeactivation:com.sun.gjc.spi.jdbc40.DataSource40@1eceee8d'





[GLASSFISH-20250] [SDK]Java EE 7 sample-Cargo configuration Created: 09/Apr/13  Updated: 29/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: glassfish
Component/s: sample_apps
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b87_RC3

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

ee7 b82 sdk bundle



 Description   

For most of the samples, we are using Cargo framework. For cargo info, it is still using GF3 shown below:

[INFO] [talledLocalContainer] GlassFish 3.x starting...
[INFO] [talledLocalContainer] Waiting for cargo-domain to start ......
[INFO] [talledLocalContainer] Successfully started the domain : cargo-domain
[INFO] [talledLocalContainer] domain Location: /home/daniel/glassfish4-b82/samples/servlet/multipart-war/target/cargo/installs/glassfish/glassfish/domains/cargo-domain
[INFO] [talledLocalContainer] Log File: /home/daniel/glassfish4-b82/samples/servlet/multipart-war/target/cargo/installs/glassfish/glassfish/domains/cargo-domain/logs/server.log
[INFO] [talledLocalContainer] Admin Port: 4848
[INFO] [talledLocalContainer] Command start-domain executed successfully.
[INFO] [talledLocalContainer] Application deployed with name multipart-war.
[INFO] [talledLocalContainer] Command deploy executed successfully.
[INFO] [talledLocalContainer] Application deployed with name cargocpc.
[INFO] [talledLocalContainer] Command deploy executed successfully.
[INFO] [talledLocalContainer] GlassFish 3.x started on port [8080]
[INFO] Press Ctrl-C to stop the container...



 Comments   
Comment by michael.y.chen [ 25/Apr/13 ]

daniel, can you double check. I assume this is fixed now.

Comment by Daniel [ 25/Apr/13 ]

@Michael
I still got the glassfish3.x related info when running cargo from svn repository which contains the latest sample code

[INFO] [talledLocalContainer] GlassFish 3.x starting...
[INFO] [talledLocalContainer] Waiting for cargo-domain to start ........
[INFO] [talledLocalContainer] Successfully started the domain : cargo-domain
[INFO] [talledLocalContainer] domain Location: /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/servlet/annotation-war/target/cargo/installs/glassfish/glassfish/domains/cargo-domain
[INFO] [talledLocalContainer] Log File: /home/daniel/Oracle_Project/glassfish-samples~svn/trunk/ws/javaee7/servlet/annotation-war/target/cargo/installs/glassfish/glassfish/domains/cargo-domain/logs/server.log
[INFO] [talledLocalContainer] Admin Port: 4848
[INFO] [talledLocalContainer] Command start-domain executed successfully.
[INFO] [talledLocalContainer] Application deployed with name annotation-war.
[INFO] [talledLocalContainer] Command deploy executed successfully.
[INFO] [talledLocalContainer] Application deployed with name cargocpc.
[INFO] [talledLocalContainer] Command deploy executed successfully.
[INFO] [talledLocalContainer] GlassFish 3.x started on port [8080]

Comment by Tom Mueller [ 29/Apr/13 ]

Updated in the glassfish-samples project in revision 1137.
This will be fixed in GlassFish when the next glassfish-samples drop is brought in.





[GLASSFISH-20102] Samples: Inspect projects with <packaging>pom</packaging> so their <modules> accurately reflects the intent Created: 29/Mar/13  Updated: 02/May/13  Resolved: 02/May/13

Status: Resolved
Project: glassfish
Component/s: sample_apps
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Snjezana Sevo-Zenzerovic
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have discovered one case where the <packaging>pom<packaging> that directs the flow of the build is missing entries in its <modules> section that apparently should be included.

This one instance is the jsf/pom.xml. I'll work with the engineers who contributed those samples to ensure they are wired up and do not break the build, but this brings to my attention the possibility for other instances of this problem.

I think a manual inspection is in order.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 02/Apr/13 ]

This is more of a task than a bug, but I'll leave it as is so that it stays on the current dashboard. We do need to review sample application pom files, both for the correct module list and also for dependencies.

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Hi Snjezana, Ed
Was there any further progress on this task?
Hopefully this is limited only to the jsf and no other modules.

Comment by Snjezana Sevo-Zenzerovic [ 24/Apr/13 ]

I am planning to use this bug to cover overall review and sanity check on Java EE 7 samples workspace pom files. This will cover items such as dependency usage, hard-coded plugin and dependency versions and module list check.

Comment by Snjezana Sevo-Zenzerovic [ 02/May/13 ]

POM review has been completed. I checked in all trivial changes:

  • Fixed all pom.xml files to use consistent EOLs (quite a few contained the mix of Windows and Unix style EOL characters).
  • Removed references to java.net repository definition which is now consolidated in top level pom.xml
  • Removed explicit versions for managed plugin references.
  • Introduced glassfish.version property which can be used to reference GlassFish promoted build artifacts.
  • Removed javaee7/rest/tictactoe sample from the default reactor since it requires manual installation of JavaFX dependency prior to building.

I also filed following issue to resolve questionable EJB sample gf-client dependency: GLASSFISH-20454.





[GLASSFISH-19945] java.lang.IllegalStateException thrown while running some security WSS tests Created: 19/Mar/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: glassfish
Component/s: security
Affects Version/s: None
Fix Version/s: 4.0_b87_RC3

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

OS: oel5.8
build: promoted build 80


Tags: 4_0-approved

 Description   

There are 6 test cases failed in security/wss test module with the same exceptions. The list of the failed tests:
appserver-sqe/pe/security/wss/sslwss/clientcerto/ejbws
appserver-sqe/pe/security/wss/sslwss/clientcerto/servletws
appserver-sqe/pe/security/wss/sslwss/transpo/ejbws
appserver-sqe/pe/security/wss/sslwss/transpo/servletws
appserver-sqe/pe/security/wss/dynencryptkey/servletws

These tests passed for GF3.x and failed for GF4.0. No test code changes made.
Steps to reproduce the bug:

1. Install GF4.0, start domain
2. Checkout SQE workspace:
cvs co appserver-sqe/bootstrap.xml
(CVSROOT: :pserver:<your cvs user>@sunsw.us.oracle.com:/m/jws
cd appserver-sqe
ant -f bootstrap.xml co-security
3.set following env. variables
S1AS_HOME <GF install dir>, for example: /export/sonia/v4/glassfish4/glassfish
SPS_HOME <appserver-sqe>, for example: /export/sonia/appserver-sqe
ANT_HOME <ant location>, for example: /export/sonia/ant-1.7.1
JAVA_HOME <java location>, for example: /export/sonia/jdk1.7.0_04
4. cd <workspace dir>/appserver-sqe/pe/security/wss, run "ant enable-wss-log"
5. cd <workspace dir>/appserver-sqe/pe/security/wss/dynencryptkey, run "ant all". The test failed and following exceptions displayed in the client side:

runclient-ssl-pe:
[echo] Test is running on Platform Edition!
[exec] Mar 19, 2013 12:38:26 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] Mar 19, 2013 12:38:29 PM com.sun.enterprise.deployment.node.SaxParserHandler error
[exec] SEVERE: enterprise.deployment.backend.invalidDescriptorFailure
[exec] Mar 19, 2013 12:38:29 PM com.sun.enterprise.deployment.node.SaxParserHandler error
[exec] SEVERE: enterprise.deployment.backend.invalidDescriptorFailure
[exec] Mar 19, 2013 12:38:29 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] MultiException stack 1 of 12
[exec] java.lang.IllegalStateException: java.io.IOException: Keystore was tampered with, or password was incorrect
[exec] at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:217)
[exec] at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.initJKS(SecuritySupportImpl.java:150)
[exec] at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.<init>(SecuritySupportImpl.java:122)
[exec] at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.<init>(SecuritySupportImpl.java:117)
[exec] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[exec] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[exec] at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
[exec] at org.glassfish.hk2.utilities.reflection.ReflectionHelper.makeMe(ReflectionHelper.java:1087)
[exec] at org.jvnet.hk2.internal.ClazzCreator.createMe(ClazzCreator.java:245)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:320)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect
[exec] at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772)
[exec] at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
[exec] at java.security.KeyStore.load(KeyStore.java:1214)
[exec] at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadKS(SecuritySupportImpl.java:254)
[exec] at com.sun.enterprise.security.ssl.impl.SecuritySupportImpl.loadStores(SecuritySupportImpl.java:208)
[exec] ... 68 more
[exec] Caused by: java.security.UnrecoverableKeyException: Password verification failed
[exec] at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770)
[exec] ... 72 more
[exec] MultiException stack 2 of 12
[exec] java.lang.IllegalStateException: Unable to perform operation: create on com.sun.enterprise.security.ssl.impl.SecuritySupportImpl
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:347)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 3 of 12
[exec] java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.security.ssl.SSLUtils errors were found
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:227)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 4 of 12
[exec] java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.security.ssl.SSLUtils
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:341)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 5 of 12
[exec] java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.iiop.security.IIOPSSLUtilImpl errors were found
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:227)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 6 of 12
[exec] java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.iiop.security.IIOPSSLUtilImpl
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:341)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 7 of 12
[exec] java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.security.appclient.AppClientSecurityInfoImpl errors were found
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:227)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 8 of 12
[exec] java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.security.appclient.AppClientSecurityInfoImpl
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:341)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:107)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 9 of 12
[exec] java.lang.IllegalArgumentException: While attempting to resolve the dependencies of org.glassfish.appclient.client.acc.AppClientContainerSecurityHelper errors were found
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:227)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 10 of 12
[exec] java.lang.IllegalStateException: Unable to perform operation: resolve on org.glassfish.appclient.client.acc.AppClientContainerSecurityHelper
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:341)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:543)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:192)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:215)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 11 of 12
[exec] java.lang.IllegalArgumentException: While attempting to resolve the dependencies of org.glassfish.appclient.client.acc.AppClientContainer errors were found
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:227)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:312)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)
[exec] MultiException stack 12 of 12
[exec] java.lang.IllegalStateException: Unable to perform operation: resolve on org.glassfish.appclient.client.acc.AppClientContainer
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:341)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2203)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:573)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:560)
[exec] at org.glassfish.appclient.client.acc.ACCModulesManager.getService(ACCModulesManager.java:158)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.createContainer(AppClientContainerBuilder.java:183)
[exec] at org.glassfish.appclient.client.acc.AppClientContainerBuilder.newContainer(AppClientContainerBuilder.java:171)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainerForAppClientArchiveOrDir(AppClientFacade.java:456)
[exec] at org.glassfish.appclient.client.AppClientFacade.createContainer(AppClientFacade.java:415)
[exec] at org.glassfish.appclient.client.AppClientFacade.prepareACC(AppClientFacade.java:270)
[exec] at org.glassfish.appclient.client.acc.agent.AppClientContainerAgent.premain(AppClientContainerAgent.java:83)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[exec] at java.lang.reflect.Method.invoke(Method.java:601)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:382)
[exec] at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:397)

— I checked server.log and no exceptions there.



 Comments   
Comment by Tim Quinn [ 03/Apr/13 ]

Fix checked in:

Project: glassfish
Repository: svn
Revision: 61118
Author: tjquinn
Date: 2013-04-03 04:18:21 UTC
Link:

Log Message:
------------
Fix for GLASSFISH-19945 - java.lang.IllegalStateException thrown while running some security WSS tests

Formerly, the SecuritySupportImpl class would get the passwords to use for the keystore and the truststore from the MasterPasswordHelper. Only if the keystore password was null would it check the standard system properties for the passwords.

If an appclient command specified a keystore or truststore password using a system property settingon the command line, SecuritySupportImpl would ignore them (if the master pw helper returned non-null ones, which it would: the defaults.)

This change causes the SecuritySupportImpl to check for and use the system property settings either if the passwords from the master password helper are null or if the current environment is the ACC.

Tests: QL, SQE test (appserver-sqe/pe/security/wss/dynencryptkey/servletws)

Revisions:
----------
61118

Modified Paths:
---------------
trunk/main/nucleus/security/ssl-impl/src/main/java/com/sun/enterprise/security/ssl/impl/SecuritySupportImpl.java

Comment by sonialiu [ 25/Apr/13 ]

Thanks Tim for the fix. However, I am still seeing the same failures with the same exceptions when I ran appserver-sqe/pe/security/wss/dynencryptkey/servletws test against latest nightly build (04/25 nightly), could you please double check if the fix is in? Thanks.

Comment by Tim Quinn [ 26/Apr/13 ]

Looks as if some changes in hk2 or run levels have changed when SecuritySupportImpl is instantiated relative to services it injects.

As a result, the logic that used to work to detect if the class is running in the ACC no longer works.

  • What is the impact on the customer of the bug?
    SQE regression. User-specified keystore and truststore passwords are ignored when launching a client.
  • What is the cost/risk of fixing the bug?
    Minimal cost and risk. If injected fields are null when they are needed then just use the default habitat to look them up explicitly.
  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    QL (and the SQE test Sonia has identified to verify the fix)
  • Which is the targeted build of 4.0 for this fix?
    4.0-b87
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in?
    n/a
Comment by Tim Quinn [ 26/Apr/13 ]

Fix checked in.

Project: glassfish
Repository: svn
Revision: 61684
Author: tjquinn
Date: 2013-04-26 18:33:43 UTC
Link:

Log Message:
------------
Fix for GLASSFISH-19945 - java.lang.IllegalStateException thrown while running some security WSS tests

This problem seems to have returned with some changes in hk2 or run levels. Fields that used to be injected in the ACC case are no longer.

These changes check all injected fields before use and, if null, try to load them from the service locator explicitly.

Approved: Michael C
Reviewed: Tom M

Revisions:
----------
61684

Modified Paths:
---------------
trunk/main/nucleus/security/ssl-impl/src/main/java/com/sun/enterprise/security/ssl/impl/SecuritySupportImpl.java





[GLASSFISH-19893] performance hotspot in org.glassfish.jersey.server.ApplicationHandler.initialize Created: 15/Mar/13  Updated: 29/Apr/13  Resolved: 29/Apr/13

Status: Resolved
Project: glassfish
Component/s: jax-rs
Affects Version/s: 4.0_b79
Fix Version/s: 4.0_b87_RC3

Type: Bug Priority: Critical
Reporter: Tom Mueller Assignee: martin.mares
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0-approved, devx_web

 Description   

During a profiling run, the Jersey service startup in GF takes 8763 ms, and 6165 ms of that is in one method:

18.1% - 6,165 ms - 1 inv. org.glassfish.jersey.server.ApplicationHandler.initialize

Is it expected that this method would take quite a bit a time?

None of the methods that are called by that method take nearly that much time:

  • validate takes 1491ms
  • 37 invocations of org.glassfish.jersey.server.model.Resource.from take 1302 ms

Nothing else takes more than 1000 ms.

Note: the times are distorted because of the profiling so just compare the relative times. The 18% is the total CPU time of the process.



 Comments   
Comment by Tom Mueller [ 15/Mar/13 ]

This issue has been created as JERSEY-1795.

This issue will be kept open until there is a resolution in GlassFish for JERSEY-1795.

Comment by Marek Potociar [ 26/Mar/13 ]

Targeting for a fix after 4.0 release.

Comment by Tom Mueller [ 01/Apr/13 ]

Marking the fix for 4.0 until we determine that a fix in this area is not necessary to meeting the developer scenario benchmark requirement for 4.0.

Comment by Hong Zhang [ 03/Apr/13 ]

(Update the issue with the information from email exchanges on loading weld-integration module)

This initialization has triggered the loading of the weld-integration jar (stack trace below). We need to look into whether we can avoid loading CDI related things in the initialization.

Module [44] started org.glassfish.main.web.weld-integration

-----------------------------------
Inhabitants / stack combination
-----------------------------------

---------------------------
Complete thread stack Trace
---------------------------
java.lang.Thread.getStackTrace(Thread.java:1567)
com.sun.enterprise.module.common_impl.TracingUtilities.traceState(TracingUtilities.java:96)
com.sun.enterprise.module.common_impl.TracingUtilities.traceStarted(TracingUtilities.java:85)
org.jvnet.hk2.osgiadapter.HK2Main$1.bundleChanged(HK2Main.java:195)
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)
org.apache.felix.framework.Felix.startBundle(Felix.java:2092)
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)
org.jvnet.hk2.osgiadapter.OsgiPopulatorPostProcessor$1.loadClass(OsgiPopulatorPostProcessor.java:77)
org.jvnet.hk2.internal.ServiceLocatorImpl.loadClass(ServiceLocatorImpl.java:1639)
org.jvnet.hk2.internal.ServiceLocatorImpl.reifyDescriptor(ServiceLocatorImpl.java:362)
org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2135)
org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:93)
com.sun.enterprise.naming.impl.NamedNamingObjectManager.tryNamedProxies(NamedNamingObjectManager.java:126)
com.sun.enterprise.naming.impl.JavaURLContext.lookup(JavaURLContext.java:166)
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:471)
com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
javax.naming.InitialContext.lookup(InitialContext.java:411)
javax.naming.InitialContext.lookup(InitialContext.java:411)
org.glassfish.jersey.gf.cdi.CdiComponentProvider.beanManagerFromJndi(CdiComponentProvider.java:222)
org.glassfish.jersey.gf.cdi.CdiComponentProvider.initialize(CdiComponentProvider.java:133)
org.glassfish.jersey.server.ApplicationHandler.initialize(ApplicationHandler.java:353)
org.glassfish.jersey.server.ApplicationHandler.access$500(ApplicationHandler.java:147)
org.glassfish.jersey.server.ApplicationHandler$3.run(ApplicationHandler.java:270)
org.glassfish.jersey.internal.Errors$2.call(Errors.java:249)
org.glassfish.jersey.internal.Errors$2.call(Errors.java:246)
org.glassfish.jersey.internal.Errors.process(Errors.java:275)
org.glassfish.jersey.internal.Errors.process(Errors.java:257)
org.glassfish.jersey.internal.Errors.processWithException(Errors.java:246)
org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:267)
org.glassfish.jersey.server.ContainerFactory.createContainer(ContainerFactory.java:79)
org.glassfish.admin.rest.adapter.JerseyContainerCommandService.getJerseyContainer(JerseyContainerCommandService.java:157)
org.glassfish.admin.rest.adapter.JerseyContainerCommandService.exposeContext(JerseyContainerCommandService.java:150)
org.glassfish.admin.rest.adapter.JerseyContainerCommandService.access$000(JerseyContainerCommandService.java:84)
org.glassfish.admin.rest.adapter.JerseyContainerCommandService$1.call(JerseyContainerCommandService.java:100)
org.glassfish.admin.rest.adapter.JerseyContainerCommandService$1.call(JerseyContainerCommandService.java:97)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
java.util.concurrent.FutureTask.run(FutureTask.java:166)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
java.lang.Thread.run(Thread.java:722)

Comment by Tom Mueller [ 09/Apr/13 ]

Reassigning to Martin since he is looking into this.

Comment by martin.mares [ 11/Apr/13 ]

FROM MAIL CONVERSATION:

I made several different measurements:
A) visualvm CPU profiling: Resource.from average CPU duration is 1.5 ms and 18 resp. 37 iterations
B) Overal Jersey initialisation on my environment with lazy loading (loads for first command call) takes 850 - 950 ms => 30ms is under standard deviation and is hardly seen able.
C) I add logging into Resource.from method of Jersey. In most cases it takes 0-2ms. Only one exception is main resource it takes 55 ms on my environment and 77 ms on my Oracle virtual development environment.
D) I start official performance test on GF with reduced JAX-RS resources (from 37 to 18) and without. There is no difference.

Result. I can not reproduce issue with Resource.from() and I will stop
work on this point.

Comment by martin.mares [ 11/Apr/13 ]

TOM:
How much did the validation time go down when the number of resources was reduced?

MARTIN:
Validation, more exactly: ApplicationHandler.validate() method duration is aprox. 125ms for original resource set and 105ms for reduced resource set. While whole init time for Jersey oscillates between 900-960ms on my environment.

Comment by martin.mares [ 11/Apr/13 ]

TOM:
What is the rough break down of the 900 ms the way you see it?

Comment by Tom Mueller [ 11/Apr/13 ]

Martin, please continue to work on evaluating what takes more than 900 ms to initialize. This is huge relative to the rest of the server initialization time. I also suspect that this initialization time is effecting the overall devx_web test run.

Here's a simple test that would seem to demonstrate this. I ran two versions of a script. The first is like the devx_web test:

asadmin start-domain
time asadmin deploy helloworld.war
asadmin undeploy helloworld
asadmin stop-domain

The second is similar, except it adds a sleep 3 after the start-domain:

asadmin start-domain
sleep 3
time asadmin deploy helloworld.war
asadmin undeploy helloworld
asadmin stop-domain

In the second test, the server is given time to finish the Jersey/command framework initialization before the deploy starts. If this initialization is not effecting the benchmark time, then this test should show deploy times that are the same in both versions. Here are the results:

no sleep: 3.34 sec (average of 10 runs)
with sleep: 2.77 sec (average of 10 runs)

This shows that the initial deployment of an application could be over a half a second faster if the server was really ready to process a command after the domain is started.

Comment by martin.mares [ 11/Apr/13 ]

Tom:
Today I was back in this task. Trying determine what we can do and what initialization is consist of. I found following possibilities - topics for future investigation (overal init is 900ms):

  1. install of base set of Jersey Binders (about 20 binders) takes 240ms. - TODO: Investigate these binders
  2. Validation: 120ms - TODO: Ask Jersey to be possible switch it off. As I wrote before reduction of resources does not help much
  3. Resources introspection: 100ms - TODO: Try to use programmatic API. But I am expecting that it helps just tens of milis.
  4. Stage building 110ms - TODO: Just try to understand this process. But I don't thing that it will be place to reduce init time
  5. Initialisation of component providers 90ms - TODO: Check if we need it and what is it.
Comment by martin.mares [ 12/Apr/13 ]

Currently I have two major ideas:
a) Reflect older idea from Marek and ask Jersey to make validation optional based some configuration variable. Validation takes 120ms on my environment.
b) Currently working on Jersey's plugin to ServiceFinder implementation. It is already plug-able but I want to ask for revision or maybe small API improvement from Jersey team. I don't want to destroy something. If my measurements are OK my plugin can improve performance for aprox 200ms.
Overal initialization takes 900ms these two improvements can change it to 600ms. It looks good - so, cross fingers.

Comment by martin.mares [ 25/Apr/13 ]
  • What is the impact on the customer of the bug?

Solution improves performance of Jersey initialization in metter of time and footprint. Jersey initialization is part of start sequence but running in parallel with other staff.

  • What is the cost/risk of fixing the bug?

This fix has 3 parts:

  1. switch of deployed Jersey application model validation - reduce init duration by 120 ms on my laptop - low risk
  2. reduce number of deployed Jersey providers - reduce init duration by 20 ms and reduce footprint - middle risk
  3. remove non necessary resource auto discovery in Jersey initialization by providing own custom provider - reduce init duration about 100ms - middle risk
  • Is there an impact on documentation or message strings?

No

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

CLI tests

  • Which is the targeted build of 4.0 for this fix?

neerest

  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.

N/A

Comment by martin.mares [ 29/Apr/13 ]

svn 61705





[GLASSFISH-19672] Race Condition when stopping server causes false negative Created: 14/Feb/13  Updated: 24/Apr/13  Due: 24/Apr/13  Resolved: 24/Apr/13

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

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

Issue Links:
Related
is related to GLASSFISH-20110 RARE Restart Server|Domain client-sid... Resolved
Tags: 4_0-approved

 Description   

Problem -

Occasionally a stop-local-instance command will return failure like so:

~/dev/bg/main/nucleus/common/glassfish-api> asadmin stop-instance i1
remote failure: Error trying to stop the instance named i1 : Remote server does not listen for requests on [localhost:24848]. Is the server up?
Command stop-instance failed.

even though the server was successfully stopped.

======



 Comments   
Comment by Byron Nevins [ 14/Feb/13 ]

Tom Mueller originally found this issue (Admin DevTests on Windows only).
It looked as if there was a race –

(1) the server dies – taking down all IO channels of course
(2) ReST client waits for the return status – which is ALWAYS success because it is an asynchronous command.

Now if (1) happens before (2) finishes (like on Windows sometimes), then ReST throws an exception because its pipe broke. That's no problem at all but this is new behavior when we moved to the ReST client.

The solution is simple. Ignore the Exception that ReST throws. This is a special case. It is a non-error to not be able to communicate with the server after the command completes.

I made this happen 100% of the time on all OS by adding a 10 second pause in the AsyncImpl class – jst after firing off the kill order on the server. This makes the bug appear every time.

Comment by Byron Nevins [ 14/Feb/13 ]

Fixed for instances:
Sending cluster/cli/src/main/java/com/sun/enterprise/admin/cli/cluster/StopLocalInstanceCommand.java
Transmitting file data .
Committed revision 59481.

Now it needs to be fixed for stop-domain. It "fails" 100% of the time with the 10 second sleep in place.

Comment by Byron Nevins [ 14/Feb/13 ]

stop-domain fixed

Sending server-mgmt/src/main/java/com/sun/enterprise/admin/servermgmt/cli/StopDomainCommand.java
Transmitting file data .
Committed revision 59482.

Comment by Byron Nevins [ 14/Feb/13 ]

The automated tests all pass now.

Comment by Byron Nevins [ 24/Apr/13 ]

This was fixed for everything EXCEPT for stop-instance command (stop-local-instance works)

Comment by Byron Nevins [ 24/Apr/13 ]

The problem is this:

1) ReST makes a HTTP connection from DAS to an instance server
2) The command that it runs, StopInstanceInstanceCommand is asynchronous – the server commits suicide
3) which, naturally, breaks the HTTP connedfction
4) The actual lowest level place is (currently) line 1288 of RemoteRestAdminCommand – like so ==>

RemoteRestAdminCommand
Line 1288: int code = urlConnection.getResponseCode();

Set a breakpoint there. On my Mac it will throw a ConnectException

The server is running BEFORE 1288
The server is stopped IMMEDIATELY AFTER 1288 (in the catch block)

===============
This is trivially weasy to reproduce in a debugger since time grinds to a halt in a debugger. In DevTests it happens occasionally when a server dies really fast.

The fix is very very simple – ignore ALL EXCEPTIONS! It doesn't matter! Really! The client code (in this case DAS itself) is going to verify that the instance really died. The return value is garbage from asynchronous commands – they just always return success.

Hold on there – am I SURE this is 100% safe to do?
Yes! Because:

(1) before making the call to server we absolutely positively verify that the server is alive and responsive
(2) We ask the server to kill itself
(3) we ignore any exceptions thrown in (2)
(4) we absolutely positively verify that the server is dead and gone before returning

Yes - we also handle failure OK.

Comment by Byron Nevins [ 24/Apr/13 ]

The fix is so tiny I'm adding it here:

ndex: src/main/java/com/sun/enterprise/v3/admin/cluster/StopInstanceCommand.java
===================================================================
— src/main/java/com/sun/enterprise/v3/admin/cluster/StopInstanceCommand.java (revision 61586)
+++ src/main/java/com/sun/enterprise/v3/admin/cluster/StopInstanceCommand.java (working copy)
@@ -280,11 +280,12 @@
ParameterMap map = new ParameterMap();
map.add("force", Boolean.toString(force));
rac.executeCommand(map);
+ } catch (Exception e)

{ + // The instance server may have died so fast we didn't have time to + // get the (always successful!!) return data. This is NOT AN ERROR! + // see: http://java.net/jira/browse/GLASSFISH-19672 + // also see StopDomainCommand which does the same thing. }
  • catch (CommandException ex) { - return Strings.get("stop.instance.racError", instanceName, - ex.getLocalizedMessage()); - }

return null;
}

Comment by Byron Nevins [ 24/Apr/13 ]

In summary, when this intermittent bug appears DAS will not recognize that the instance server it told to stop - really stopped. If it stops VERY fast, then the Rest connection throws a (useless, unimportant) Exception which should be completely ignored.

The impact on the customer is annoyance. It causes a false negative. The major impact is in automated tests.
It is quite possible that the customer will bump into this issue.

It is not a serious bug because the command actually succeeed but was reported as a failure. If the same command is run again – it will report that the cluster or instance is already stopped.

OTOH - it depends on one's opinion of what's serious. It gives the user a bad impression of the product if he sees it.
The cost to fix it is minimal, in fact it is already fixed and waiting to go in. If it doesn't go into 4.0 it'll go into 4.0.1

The bug appears rarely in Quick Look tests. It's dependent on hardware.

The fix is about as simple as can be – ignore an Exception instead of failing. Changed code is simpler than existing code.

There is little risk. Automated tests, including QuickLook test this area all the time.

No doc impact.

QA need only run their usual standard tests start/stop/restart

This is a core lifecycle fix.

I highly recommend allowing this into 4.0
It is about as risk-free as you can get.

Comment by Tom Mueller [ 24/Apr/13 ]

Approved for 4.0.

Comment by Byron Nevins [ 24/Apr/13 ]

Sending admin/src/main/java/com/sun/enterprise/v3/admin/cluster/StopInstanceCommand.java
Transmitting file data .
Committed revision 61631.





[GLASSFISH-19391] server will not start after download and domain cannot be created due to unresolvable hostname Created: 28/Nov/12  Updated: 26/Apr/13  Resolved: 26/Apr/13

Status: Resolved
Project: glassfish
Component/s: admin
Affects Version/s: 3.1.2.2, 4.0_b86_RC2, 4.0
Fix Version/s: 4.0_b87_RC3

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

Fedora 17


Issue Links:
Duplicate
is duplicated by GLASSFISH-20013 Admin Port does not bind in Windows 8 Resolved
Tags: 4_0-approved

 Description   

Fresh after download I unzip glassfish and do:

./asadmin start-domain

and I get

There is a process already using the admin port 4848 -- it probably is another instance of a GlassFish server.

there is nothing running on port 4848 for sure, I even changed the port in glassfish config and I still get

There is a process already using the admin port 114849 -- it probably is another instance of a GlassFish server.

Many other ppl are having the same issue:
http://www.javaprogrammingforums.com/web-frameworks/19238-glassfish-error-process-already-using-port-4848-a.html
http://www.java.net/forum/topic/glassfish/glassfish/glassfish-wont-start-because-port-4848-use-however-nothing-listening-port-4848
http://www.java.net/forum/topic/glassfish/glassfish/glassfish-error-process-already-using-port-4848



 Comments   
Comment by Tom Mueller [ 28/Nov/12 ]

Typically, the root cause of this issue is that the host name is not resolvable to an IP address.

However, the process that GlassFish uses to check to see if a port is available is actually quite complicated, so there can be other reasons that this message is printed.

At a minimum, the message must be rewritten, as it is possible for it to be output when there isn't another process already using the admin port. The message must be more accurate about the possible reasons for the problem. The trick will be to make the message concise while also conveying the possible reasons.

Here is exactly what happens when the server is performing the check for which failure results in this message:

1. StartServerHelper.checkPorts calls StartServerHelper.adminPortInUse(), which calls StartServerHelper.adminPortInUse(addresses) where addresses is a list of admin host names and port numbers. By default, this is just one entry, localhost:4848.

2. adminPortInUse calls NetUtils.isPortFree on the host and port.

3. isPortFree checks to see if the port is a valid port number (4848 is)

4. isPortFree checks calls NetUtils.isThisMe to determine if this address represents an interface on this system. isThisMe makes a sequence of calls resulting in a call to InetAddress.getAllByName(InetAddress.getLocalHost().getHostName()). It calls this list myadds. Then it calls InetAddress.getAllByName(hostname) where hostname is "localhost" or whatever the admin host has been set to in the config and calls this list theiradds. isThisMe then looks at the theiradds list, and if any one of them is the loopback address (based on calling isLoopbackAddress) or if the address is in the myadds list, then true is returned. Otherwise false is returned.

5. Back in isPortFree, if isThisMe is true (which should be true for the default localhost:4848 case), it calls NetUtils.isPortFreeServer(port). Note that here the hostname is ignored. If isThisMe is false, then NetUtils.isPortFreeClient(host, port) is called.

6. NetUtils.isPortFreeServer(port) checks to see if the port is free on three addresses: 0.0.0.0, InetAddress.getLocalHost(), and InetAddress.getByName("localhost"). It does this by calling NetUtils.isPortFreeServer(host, port) for each of them. All have to be available for this test to pass.

7. NetUtils.isPortFreeServer(host, port) creates a ServerSocket (which internally does a bind on that socket). If that constructor throws an exception, the port is considered in use.

Normally, if a server is really running on the port, this process will fail in step 7, and the current message reflects that failure. But there are several other places in this process where it can fail, and the message will be output even though there is no server running.

The most typical case is in step 6, on the call to InetAddress.getLocalHost. If there is no entry for the hosts hostname in /etc/hosts or DNS lookup on the hostname fails, then this call with throw an UnknownHostException, and the isPortFreeServer check fails.

There are several questionable steps in this algorithm:

a) Why does isPortFree call isPortFreeServer(port) rather than isPortFreeServer(host, port)? If it called the latter, this would avoid the call to InetAddress.getLocalHost in step 6.

b) Why is StartServerHelper.adminPortInUse call isPortFree rather than isPortFreeServer(host, port), thereby bypassing the isThisMe call?

Comment by Romain Grécourt [ 28/Nov/12 ]

Could it be related to http://java.net/jira/browse/GLASSFISH-17990 ?

Comment by walec51 [ 01/Dec/12 ]

PS.My /etc/hosts file:

127.0.0.1		localhost.localdomain localhost zrobmikompa.dev.pl
::1		localhost6.localdomain6 localhost6
91.201.155.85    lupo.qcd.com
91.201.155.85    testowy.qcd.com
Comment by walec51 [ 02/Dec/12 ]

reduced my hosts file to just:

127.0.0.1		localhost

still the same result

Comment by Tom Mueller [ 03/Dec/12 ]

Try running:
nslookup `hostname`

If this fails, then this GlassFish is not working for the same reason. Your host's hostname must be resolvable to an IP address with the current GlassFish implementation.

Comment by walec51 [ 03/Dec/12 ]
[walec51@walec51-linux ~]$ nslookup `hostname`
Server:		192.168.1.1
Address:	192.168.1.1#53

** server can't find walec51-linux: NXDOMAIN

[walec51@walec51-linux ~]$ nslookup localhost
Server:		192.168.1.1
Address:	192.168.1.1#53

Name:	localhost
Address: 127.0.0.1

nslookup works fine with localhost

on linux desktops hostname is rarely in the hosts file

shouldn't localhost be a fall back during startup i hostname fails ?

I use PostgreSQL, Tomcat, Jetty, JBoss and tons of other servers on my laptop. Non of them have problem starting up.

Comment by Tom Mueller [ 03/Dec/12 ]

The name resolution for your host name is not working fine (you got the message "** server can't find walec51-linux: NXDOMAIN")
If you fix this, then GlassFish will work.

You are correct that it would be better if GlassFish did not insist on the host name being resolvable in order to start. However that isn't how the 3.1.2.2 release works. I am trying to help you get the current software running.

Comment by walec51 [ 03/Dec/12 ]

Ok, thanks. I know how to work around this.

I would just like to ask you to schedule this issue to some fixVersion so that people new to glassfish don't get discouraged when they download it. I can try to hack the source a little in the weekend but I never worked with glassfishes internals.

Comment by walec51 [ 25/Dec/12 ]

Just tested trunk of Glassfish 4 and the issue does not happen there.
The stage distribution started without a problem in the same enviorment.

Comment by Tom Mueller [ 25/Apr/13 ]

This problem also prevents a domain from being created. The output from the create-domain command is:

$ asadmin create-domain domain2
Enter admin user name [Enter to accept default "admin" / no password]>
Default port 4848 for Admin is in use. Using 53996
Default port 8080 for HTTP Instance is in use. Using 53997
Default port 7676 for JMS is in use. Using 53998
Default port 3700 for IIOP is in use. Using 53999
Default port 8181 for HTTP_SSL is in use. Using 54000
Default port 3820 for IIOP_SSL is in use. Using 54001
Default port 3920 for IIOP_MUTUALAUTH is in use. Using 54002
Default port 8686 for JMX_ADMIN is in use. Using 54003
Default port 6666 for OSGI_SHELL is in use. Using 54004
Default port 9009 for JAVA_DEBUGGER is in use. Using 54005
Port 53,996 is in use( com.sun.enterprise.admin.servermgmt.InvalidConfigException: Port 53,996 is in use )
CLI130: Could not create domain, domain2
Command create-domain failed.

To recreate this problem, just run:

sudo hostname bogusname

(where bogusname is an unresolvable hostname).

This problem is seen in GlassFish 4.

Comment by Byron Nevins [ 25/Apr/13 ]

After fixing:
– notice how the message is logged once. Actually it is logged once as a warning, then every time the code is triggered at FINE level
Otherwise it would spew warnings.

Bad Network Configuration. DNS can not resolve the hostname:
java.net.UnknownHostException: bogusname.xyz.com: bogusname.xyz.com: nodename nor servname provided, or not known
Using default port 4848 for Admin.
Using default port 8080 for HTTP Instance.
Using default port 7676 for JMS.
Using default port 3700 for IIOP.
Using default port 8181 for HTTP_SSL.
Using default port 3820 for IIOP_SSL.
Using default port 3920 for IIOP_MUTUALAUTH.
Using default port 8686 for JMX_ADMIN.
Using default port 6666 for OSGI_SHELL.
Using default port 9009 for JAVA_DEBUGGER.
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=localhost,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]
Distinguished Name of the self-signed X.509 Server Certificate is:
[CN=localhost-instance,OU=GlassFish,O=Oracle Corporation,L=Santa Clara,ST=California,C=US]

Comment by Byron Nevins [ 25/Apr/13 ]

1) hostname bogusname.xyz.com

2) create-domain d2

3) start-domain d2

Results:
~/dev/main/nucleus/common/common-util> asadmin start-domain d2
Bad Network Configuration. DNS can not resolve the hostname:
java.net.UnknownHostException: bogusname.xyz.com: bogusname.xyz.com: nodename nor servname provided, or not known
Waiting for d2 to start .....
Successfully started the domain : d2
domain Location: /Users/wnevins/glassfish4/glassfish/domains/d2
Log File: /Users/wnevins/glassfish4/glassfish/domains/d2/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

Comment by Byron Nevins [ 25/Apr/13 ]

This is an annoying issue if the user has his hostname set wrong. It is NOT catastrophic if that is the case. But we currently treat it that way. Instead, it should be logged as a WARNING.

Specifically, whether or not the hostname is setup correctly has nothing to do with whether or not a given port is free.

This has a big impact on customers. The error says that, say, port 4848 is in use. The user checks and finds that nothing is using port 4848. Confusion sets in at that point.

It is unlikely that the customer will bump into this issue. He would have to have a bad hostname. I.e. a hostname that can't be resolved by DNS. With the fix we emit a warning with the exact problem so that he can now fix it permanently.

The cost to fix it is minimal, in fact it is already fixed and waiting to go in. If it doesn't go into 4.0 it'll go into 4.0.1

The fix is not too complicated. The main complication is setting it up to emit only one warning message, then fine messages after that.
The actual fix itself is simply catching the right exception at the exact right place and swallowing it rather than turning it into a fatal error.

There is little risk. Automated tests, including QuickLook test this area all the time.

No doc impact.

QA need only run their usual standard tests

Comment by Tom Mueller [ 26/Apr/13 ]

Approved for 4.0

Comment by Byron Nevins [ 26/Apr/13 ]

QL before the change (with a bad hostname)

testng-summary:
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 117, Failures: 44, Skips: 21
[echo] [testng] Configuration Failures: 1, Skips: 0
[echo] [testng] ===============================================
[echo] [testng]
[INFO] Executed tasks

QL After the change (still with bad hostname)

testng-summary:
[echo] [testng]
[echo] [testng] ===============================================
[echo] [testng] QuickLookTests
[echo] [testng] Total tests run: 117, Failures: 0, Skips: 0
[echo] [testng] ===============================================
[echo] [testng]
[INFO] Executed tasks
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

Comment by Byron Nevins [ 26/Apr/13 ]

Sending common/common-util/src/main/java/com/sun/enterprise/util/CULoggerInfo.java
Sending common/common-util/src/main/java/com/sun/enterprise/util/net/NetUtils.java
Transmitting file data ..
Committed revision 61658.

Done





[GLASSFISH-18693] [PERF] regression in startup/deployment benchmark Created: 06/May/12  Updated: 02/May/13  Resolved: 02/May/13

Status: Resolved
Project: glassfish
Component/s: performance
Affects Version/s: 4.0_b01
Fix Version/s: 4.0_b87_RC3

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

Issue Links:
Dependency
depends on GLASSFISH-18941 [PERF] additional regression in start... Open
depends on GLASSFISH-18746 [PERF] memory footprint has increased... Resolved
depends on GLASSFISH-19107 [PERF] Large Regression in DomainXml ... Closed
Tags: 4_0-approved, PSRBUG, devx_web

 Description   

Startup & deployment show 12% regression from the very beginning of GF 4.0. Collector analyzer profiles indicate GF 4.0 loads more classes now.
Recently regression increased to 18%, we have found that when we remove modules/org.apache.felix.bundlerepository.jar regression dips back to 12%.



 Comments   
Comment by Tom Mueller [ 03/Apr/13 ]
  • What is the impact on the customer of the bug?

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?

This is a regression from the 3.x release and this is a PRD release criteria.

  • What is the cost/risk of fixing the bug?

How risky is the fix? How much work is the fix? Is the fix complicated?

Potentially very risking and very costly. See this analysis page for details:
http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Developer+Scenario+Performance+Analysis (internal link)

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    Pretty much everything as these performance fixes could touch all area.
  • Which is the targeted build of 4.0 for this fix?
    Every build until the regression is addressed.
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    n/a.

Note: this bug is primarily an umbrella bug for the overall effort to address the performance issue. So many changes will be made using other issues tagged with the devx_web tag.

Comment by michael.y.chen [ 03/Apr/13 ]

The dev perf benchmark is one of the release criteria, so this bug is approved.
It doesn't mean all issues with devx_web are approved, other issues will be evaluated before approval.

Comment by Tom Mueller [ 09/Apr/13 ]

MonitoringBootstrap changes committed to the trunk in revision 61250.

Comment by Tom Mueller [ 02/May/13 ]

This issue represents the overall work that is being done to reduce the regression in the devx_web benchmark for the 4.0 release. Here is a summary of the accomplishments that have been achieved:

Feb 18, regression is about 50%
Mar 1, asadmin client rewrite to not use Jersey client, regression down to about 38%
Mar 5, StartupConfigBeanOverrider removed (19719, rev 60061), regression down to 36%
Mar 7, asadmin hk2 bypass (issue 19778, rev 60182), regression down to 30%
Mar 11, enhancement to hk2 bypass to limit CLICommand JAR files (rev 60355), regression at 30%
Mar 14, hk2 fix for 19718, uptake of felix 4.2.1, regression down to 22%
Mar 26, admin-cli.jar not activated, regression down to 21%
Apr 5, delay concurrent initialization until used rather than at startup, regression down to 20%
Apr 9, delete monitoring initialization, regression down to 18%
Apr 14, eliminated extra domain.xml writes, regression still at 18%
Apr 15, multi-threaded service startup, regression down to 15%
Apr 23, setting server startup threading to single threaded, regression back to 17.5%

Any final work on devx_web improvements will be done with more specific issues. Look for the devx_web tag on the issues.

Marking this issue as resolved for 4.0.





Generated at Sun Aug 30 22:58:03 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.