[GLASSFISH-20941] create-file-user isn't usable in embedded glassfish 4 Created: 23/Dec/13  Updated: 23/Dec/13

Status: Open
Project: glassfish
Component/s: embedded
Affects Version/s: 3.1, 3.1.1
Fix Version/s: 3.1.2, 4.0_b05, 4.0

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

Tags: 3_1_1-approved, 3_1_1-review

 Description   

Glassfish 3.1's "asadmin create-file-user" command forces password entry on stdin. While this is desirable for many situations, it completely breaks the use case of glassfish embedded. You can't enter stdin text when running commands with org.glassfish.embeddable.CommandRunner , and the "--password" argument has been helpfully removed.



 Comments   
Comment by atrajano [ 23/Dec/13 ]

When using maven-embedded-glassfish-plugin I get the same error as matthewcomell from the original defect. The error I got was

FAILUREorg.jvnet.hk2.component.UnsatisfiedDependencyException: injection failed on com.sun.enterprise.security.cli.CreateFileUser.userpassword with class java.lang.StringDescription: create-file-user commandCannot find userpassword in create-file-user command model, file a bug
Usage: create-file-user
[--authrealmname <authrealm_name>] [--target target]
[--groups user_groups[:user_groups]*]
[?|-help[=<help(default:false)>]] username





[GLASSFISH-20475] [UB] Add release notes documentation concerning the state of the embedded features for 4.0 OSE Created: 06/May/13  Updated: 17/May/13

Status: In Progress
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b87_RC3
Fix Version/s: 4.0

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

Tags: 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

This issue is for making sure the release notes for the 4.0 OSE release describe the anticipated level of testing and quality for the embedded feature.



 Comments   
Comment by Mike Fitch [ 17/May/13 ]

Added the following to the release notes:

Note:
The main thrust of the GlassFish Server Open Source Edition 4.0 release is to provide an application server for developers to explore and begin exploiting the new and updated technologies in the Java EE 7 platform. Thus, the following features of GlassFish Server were not a focus of this release:

  • Clusters and standalone instances
  • High availability features
  • Upgrade
  • Embedded Server

These features are included in the release, but they may not function properly with some of the new features added in support of the Java EE 7 platform.





asadmin create-jmsdest properties not applied to EMBEDDED MQ broker (GLASSFISH-20378)

[GLASSFISH-20405] Docs: Need update the property names of create-jmsdest subcommand Created: 25/Apr/13  Updated: 29/Apr/15

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.2
Fix Version/s: 4.0

Type: Sub-task Priority: Major
Reporter: David Zhao Assignee: Mike Fitch
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The property names are incorrect in document http://docs.oracle.com/cd/E26576_01/doc.312/e24938/create-jmsdest.htm that the property names should be upper case for the first character.

For more details, please see the one pager by running "asadmin create-jmsdest --help".



 Comments   
Comment by sergeich [ 29/Apr/15 ]

Output of the command "asadmin create-jmsdest --help" in Glassfish 4.1 also contains the same error (names of properties start with lower-case letter).





[GLASSFISH-20365] Document guides are not available on the location specified Created: 22/Apr/13  Updated: 23/Apr/13

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

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

Win 8 - IE 10 and OEL 6 - FF20 and WIN7-FF19 - all


Tags: 404, admingui, document, found, guide, not

 Description   

Administration Guide
Application Development Guide
Application deployment guide

The above Guides are not available on the appropriate locations.

Administration Guide - http://glassfish.java.net/docs/4.0/administration-guide.pdf
Application Development Guide - http://glassfish.java.net/docs/4.0/application-development-guide.pdf
Application deployment guide - http://glassfish.java.net/docs/4.0/application-deployment-guide.pdf

getting error as : HTTP 404 Not Found
=================================
The webpage cannot be found

HTTP 404

Most likely causes:
•There might be a typing error in the address.
•If you clicked on a link, it may be out of date.

What you can try:

Retype the address.

Go back to the previous page.

Go to and look for the information you want.

More information More information

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



 Comments   
Comment by Mike Fitch [ 23/Apr/13 ]

Set Fix Version to 4.0, as these links will not be live until GlassFish 4.0 is officially released.





[GLASSFISH-20081] [UB] javax.ejb.NoSuchEJBException in unsyncpcsfsb with ha Created: 27/Mar/13  Updated: 01/May/13

Status: Reopened
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0

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

RHL6.2 and JDK1.7.0_10



 Description   

The problem was reported in
http://java.net/jira/browse/GLASSFISH-20020
which can't be accessed for a few days.
Hence, file this bug for failure analysis.
Will close the 20020 later.



 Comments   
Comment by sherryshen [ 27/Mar/13 ]

glassfish-4.0-b82-03_23_2013.zip
During the test dev and failure analysis for
http://java.net/jira/browse/GLASSFISH-20011
I observed javax.ejb.NoSuchEJBException in unsyncpcsfsb with ha.

To run tests, to see env in
http://java.net/jira/browse/GLASSFISH-20011

test2, persist, joinTx, no flush

test2 without ha, passed.
do "ant ee all-dbg"

test2 with ha, failed.
web.xml has <distributable/>
deploy war with --availabilityenabled=true
do "ant ee all-dbg-ha"

server.log from instance2

Error during checkpoint ([TestEJB]. Key:
[1f0090099dfa82de-ce0085b80d45218a-1])
[com.sun.ejb.containers.StatefulSessionContainer$EMNotSerializableException:
java.io.NotSerializableException:
org.eclipse.persistence.internal.jpa.EntityManagerImpl

.....
javax.ejb.NoSuchObjectLocalException: The EJB does not exist.
session-key: 1f0090099dfa82de-ce0085b80d45218a-1
at
com.sun.ejb.containers.StatefulSessionContainer._getContext(StatefulSessionContainer.java:1616)
at
com.sun.ejb.containers.BaseContainer.getContext(BaseContainer.java:2518)
at
com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1908)
.....
javax.ejb.NoSuchEJBException

Comment by sherryshen [ 27/Mar/13 ]

The JPA2.1 test info can be found at
http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/GF+4.0+Test+Development+Page
As a summary for the bugs on cluster.
1) SFSB tests passed on DAS.
Verified the fix for
http://java.net/jira/browse/GLASSFISH-19597
2) To wrap up my test dev, I ran SFSB tests on a cluster with using
different instances and reported
http://java.net/jira/browse/GLASSFISH-20011
3) Next, I enabled HA to see if it helps for 20011, but it failed with
http://java.net/jira/browse/GLASSFISH-20081
4) After, I tried a simple SFSB tests without JPA, it passed.

I have a hudson run to show to test env and problems.
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_core/job/sherry-lc-d/

#8 dbg failures
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_core/job/sherry-lc-d/8/artifact/appserver-sqe/reports/pe-ee/amd64_easqezorro5_Linux/html/test_results_ejb.html
The 3 tests are executed in the order below.
A) appserver-sqe/pe/ejb/ejb31/fo/sfsb, SFSB with HA, passed
B) appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb, SFSB without HA, test2, passed.
C) appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb, SFSB with HA, test2, failed. GLASSFISH-20081

#2, ejb-cluster with 1 failure, GLASSFISH-20011
http://sqe-hudson.us.oracle.com:8080/hudson/view/Sherry_core/job/sherry-lc-d/2/artifact/appserver-sqe/reports/pe-ee/amd64_easqezorro5_Linux/html/test_results_ejb.html

Comment by Mitesh Meswani [ 29/Mar/13 ]

As this is related to clustering, deferring this for 4.0.1. Ethan and Quiang will investigate further.

Comment by qiang.l.liu [ 17/Apr/13 ]

If the HA enabled, the SFSB container will try to store the ejb's session context for replication. When the container tries to serialize the context object, a NotSerializableException is thrown up:
com.sun.ejb.containers.StatefulSessionContainer$EMNotSerializableException: java.io.NotSerializableException: org.eclipse.persistence.internal.jpa.EntityManagerImpl, and the EJB is marked with destroyed. This is because the TestEJB has a reference of EntityManager. The EJB's context will be removed after it is marked destroyed. So, when a subsequence call to the EJB, the client will get NoSuchObjectLocalException.

Comment by qiang.l.liu [ 17/Apr/13 ]

After I putting "passivationCapable=false" on TestEJB, the test passed.

So, I'd like resolve the issue as work as designed.

Comment by sherryshen [ 18/Apr/13 ]

Thanks Qiang and Mitesh for the analysis for
http://java.net/jira/browse/GLASSFISH-20081

Here is what I understand the problem.

1) HA Limitation:
EntityManager can't be serialized as a context object in SFSB container for HA replication.
2) Workaround:
Update the @Stateful annotation on TestEJB
to @Stateful(passivationCapable=false), then
JPA will work in ha env without replication
or in non-ha env.

Where are these 2 points in the documents?

I verified the test passed on ha env without replication or non-ha env with b85 nightly.
http://javaweb.us.oracle.com/net/asqe-logs.us.oracle.com/export1/4.0/Results/build85/core/b20081/t1/html/test_results_ejb.html

Comment by sherryshen [ 18/Apr/13 ]

Copy the discussion about doc update.

On 4/17/2013 12:19 PM, Paul Davies wrote:
> Hi Mitesh,
>
> The corresponding section in the GlassFish 3.1.2 High Availability Administration guide is at:
>
> http://docs.oracle.com/cd/E26576_01/doc.312/e24934/session-persistence-and-failover.htm#abdlc .
>
> I have copied Mike Fitch on this response as he is leading the documentation effort for GF 4.0 and he should be able to advise how to proceed.
>
> Regards,
> -Paul
>
> On 4/17/2013 11:58 AM, Mitesh Meswani wrote:
>> Hi Paul,
>>
>> We would like to document the restriction that a SFSB injecting EntityManagers can not be passivated and failed over. Which document would it go to and who is the owner for that? We had a section on restrictions in GlassFish 2.1.1 High Availability Administration guide. I could not find a relevant section in GlassFish 3.1.2 High Availability Administration guide that documents such limitations.
>>
>> Thanks,
>> Mitesh

Comment by sherryshen [ 18/Apr/13 ]

Reopen for Mike Fitch to address the limitation in docs.

Comment by Mike Fitch [ 18/Apr/13 ]

Added [UB] to summary so this issue will appear in unbundled (ie, book-related) doc issues queries

Comment by Mike Fitch [ 18/Apr/13 ]

Also set Component to docs.

Comment by marina vatkina [ 18/Apr/13 ]

This behavior is per the EJB spec 3.2.





[GLASSFISH-20011] [UB] joinedTx missed data from another instance Created: 23/Mar/13  Updated: 05/Jun/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b81
Fix Version/s: 4.0

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

RHL6.2 and JDK1.7.0_10


Tags: 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

joinedTx missed data from another instance

glassfish-4.0-b82-03_23_2013.zip

With the fix for
http://java.net/jira/browse/GLASSFISH-19597
appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb
tests passed on das, or using one cluster instance,
but got 1 failure on using 2 cluster instances of cluster.
I will provide test details next.



 Comments   
Comment by sherryshen [ 23/Mar/13 ]

To use sqe-cluster env, please refer II B.
http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/4.0+Core+Test+Instructions

In sqe-cluster env, to reproduce the problem in test dir
appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb
do "ant ee all_run2" and see failure with using 2 instances.
test1: passed
persist data1, not joinedTx, em.flush from instance1
verify db without data1

test2: passed
persist data2, joinedTx from instance2
verify db with data2

test3: failed.
persist data3, not joinedTx, from instance1
verify db without data3, passed.
verify db with data1, failed.

As a comparison,
do "all ee all_run1" and see tests all passed with using 1 instance.

Comment by Mitesh Meswani [ 26/Mar/13 ]

As this is related to clustering, deferring this for 4.0.1. Ethan and Quiang will investigate further.

Comment by sherryshen [ 27/Mar/13 ]

I enabled HA to see if it helps for 20011, but it failed
with a different error, see details in
http://java.net/jira/browse/GLASSFISH-20081

Comment by sherryshen [ 18/Apr/13 ]

Qiang has a very good description about tests. I am exploring how unsyncPC can
work in cluster env. Especially, how to make joinTx in test2 (instance2) to take care the data in test1 (instance1)?

On 4/17/2013 7:39 PM, Qiang Liu wrote:
> Hi Mitesh
> Ethan and I have discussed this test cases together before, and I can give a brief description for it:
>
> 1. The first request is sent to Instance 1, the EJB tries to persist Employee 1 and Employee 2 with not joining transaction, and then flush PC. An expected exception is caught.
>
> 2. The second request is sent to Instance 2, the EJB tries to persist Employee 3 and Emploee4 after join transaction. Even the flush is not invoked, the entities will be persisted to DB when the transaction is committed. But, since this is difference instance from Step 1, Employee 1 and Employee 2 will not be persisted to DB in this step.
>
> 3. The third request is sent to Instance 1, the EBJ tries to persist Employee 5 and Employee 6 without joining transaction, as it doesn't invoke the flush method, all the entities will not be persisted to DB. But, here the test case expects Employee 1 involved in PC in Step 1 will be persisted to DB in Step 2. Since the EM and PC will not be synced between instances in cluster env, so the test3 will not pass.
>
> Thanks
> -Qiang

Comment by sherryshen [ 01/May/13 ]

Mitesh, Ethan and I discussed this issue on April 29, 2013. We agreed
that the failure is due to the limitation of JPA2.1 feature,
unsynchronized persistence context.
It can be documented for 4.0 release, and addressed for later release.
Transfer the bug to docs.

Comment by ethan.wang [ 09/May/13 ]

After discussions with Mitesh and Sherry, we all agreed on following content to document:

Any updates to unsynchronized persistence context, while it's not joint to the current transaction is neither persisted to database nor replicated in cluster therefore subject to data loss. Developers should understand that before joining the PC with current transaction and the transaction being committed, all updates to the PC are only visible to the server instance which it resides and would not survive from server crash or fail over, so cautions should be exercised using unsynchronized PC in data critical application.

Comment by Mike Fitch [ 16/May/13 ]

Added 4_0-release-notes tag so this gets documented in the 4.0 release notes. Leaving the issue Open so the information can get integrated into the appropriate manual for the next release.

Comment by Gail Risdal [ 31/May/13 ]

Added the following to the release notes:

[UB] joinedTx missed data from another instance (20011)

Description
Updates made to an unsynchronized persistence context before it is joined to the current transaction and the transaction is committed are not persisted to a database or replicated in a cluster and data could be lost in the event of a server crash or failover.

Workaround
None. This is a limitation of the JPA 2.1 feature. Exercise caution when using an unsynchronized persistence context in a data-critical application.

Comment by Gail Risdal [ 05/Jun/13 ]

Revised release notes write-up slightly to now read:

Description
Updates made to an unsynchronized persistence context before it is joined to the current transaction and the transaction is committed are not persisted to a database or replicated in a cluster and data could be lost in the event of a server crash or failover.

Workaround
None. This is working as designed. The JPA 2.1 feature delays synchronization to a database until explicitly instructed to synchronize. Exercise caution when using an unsynchronized persistence context in a data-critical application.





[GLASSFISH-19779] Tests overwrite the domain-passwords keystore (was java.lang.RuntimeException: java.io.IOException: Invalid keystore format) Created: 06/Mar/13  Updated: 14/Mar/13

Status: Open
Project: glassfish
Component/s: sqe-test
Affects Version/s: 4.0_b73
Fix Version/s: 4.0

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

Glassfish 4.0 b73, JDK 1.7.0_17



 Description   

Hi,

I am seeing this exception as part of running Metro SQE tests. While running tests, we typically update the glassfish keystores with the certs from copyv3.zip. From glassfish 4.0 b73, after we patch the certificates, I am getting the below exception.

Exception:
==========

appserver-start-notwin:
[exec] Deprecated syntax, instead use:
[exec] asadmin --user admin --passwordfile /space/hudson/hudson-workspace/glassfish3/glassfish/domains/domain1/config/domain-passwords start-domain [options] ...
[exec] Error starting domain domain1.
[exec] The server exited prematurely with exit code 1.Waiting for domain1 to start .....Command start-domain failed.
[exec]
[exec] Before it died, it produced the following output:
[exec]
[exec] Launching GlassFish on Felix platform
[exec] Registry Info:: Total repositories: 1, Total modules = 286
[exec] Attached repository: [javax.ejb-api:org.eclipse.persistence.oracle:org.glassfish.main.web.gui-plugin-common:org.glassfish.javax.enterprise.concurrent:org.glassfish.main.web.cli:org.glassfish.main.persistence.jpa-container:pfl-dynamic:org.glassfish.main.persistence.cmp.support-ejb:org.glassfish.main.admingui.console-ejb-lite-plugin:org.glassfish.main.external.libpam4j-repackaged:org.glassfish.main.webservices.metro-glue:org.glassfish.main.persistence.cmp.utility:org.glassfish.main.ejb.gf-ejb-connector:org.glassfish.main.admingui.console-plugin-service:org.glassfish.main.cluster.ssh:org.glassfish.jersey.containers.glassfish.jersey-gf-ejb:org.glassfish.main.admin.rest-service:GlassFish-Application-Common-Module:org.eclipse.persistence.core:org.glassfish.jersey.core.jersey-server:pfl-basic-tools:org.glassfish.corba.glassfish-corba-omgapi:javax.servlet.jsp-api:org.glassfish.main.admingui.console-jts-plugin:org.glassfish.external.dbschema-repackaged:javax.xml.jaxr-api-osgi:org.glassfish.main.core.logging:org.glassfish.hk2.external.asm-all-repackaged:org.glassfish.jersey.media.jersey-media-sse:org.glassfish.main.ha.shoal-cache-store:org.glassfish.main.batch.connector:org.glassfish.main.persistence.cmp.ejb-mapping:org.glassfish.main.concurrent.config:org.glassfish.main.common.glassfish-naming:javax.interceptor-api:org.glassfish.main.javax.security.jacc:org.glassfish.main.jms.admin:org.glassfish.main.resources.javamail-connector:jackson-mapper-asl:org.shoal.gms-impl:javax.persistence:org.eclipse.persistence.jpa.jpql:org.glassfish.main.security.webservices.security:org.glassfish.main.orb.enabler:org.glassfish.main.cluster.gms-adapter:org.glassfish.main.admin.launcher:org.glassfish.main.security.jaspic.provider.framework:com.sun.pkg.client:com.google.guava:JSR352.API:com.sun.jsftemplating:org.glassfish.main.web.ha:org.glassfish.main.appclient.gf-client-module:org.glassfish.main.deployment.autodeploy:com.sun.xml.bind:org.glassfish.main.jdbc.runtime:org.glassfish.corba.glassfish-corba-internal-api:org.glassfish.main.flashlight.framework:jackson-core-asl:org.glassfish.main.transaction.jta:org.glassfish.main.admin.cli:org.glassfish.main.concurrent.runtime:org.glassfish.main.common.glassfish-api:org.glassfish.main.ejb.ejb-container:org.glassfish.main.loadbalancer.gf-load-balancer-connector:org.glassfish.main.common.glassfish-ee-api:org.glassfish.main.concurrent.admin:org.glassfish.jersey.media.jersey-media-json-jettison:org.glassfish.hk2.config:org.glassfish.main.webservices.soap-tcp:javax.transaction.cdi-api:org.glassfish.main.appclient.server.appclient-connector:javax.servlet.jsp.jstl-api:org.glassfish.main.web.war-util:org.glassfish.metro.webservices-extra-jdk-packages:org.glassfish.main.web.jspcaching-connector:javax.websocket-api:org.glassfish.main.ha.shoal-cache-bootstrap:org.eclipse.persistence.moxy:org.glassfish.main.connectors.internal-api:org.glassfish.main.external.trilead-ssh2-repackaged:org.glassfish.main.persistence.cmp.internal-api:org.glassfish.main.security.inmemory.jacc.provider:org.glassfish.main.ejb.internal-api:org.glassfish.external.schema2beans-repackaged:org.codehaus.jettison.jettison:org.glassfish.main.connectors.admin:org.apache.felix.bundlerepository:org.glassfish.hk2.external.cglib:org.glassfish.main.core.glassfish-extra-jre-packages:org.glassfish.javax.faces:org.glassfish.main.transaction.internal-api:org.glassfish.main.external.j-interop-repackaged:org.glassfish.main.web.glue:org.glassfish.tyrus.server:org.glassfish.main.transaction.jts:org.glassfish.main.admin.core:org.glassfish.main.security.ejb.security:org.glassfish.hk2.utils:org.glassfish.jersey.media.jersey-media-moxy:org.glassfish.main.connectors.runtime:org.glassfish.hk2.osgi-adapter:org.glassfish.main.admin.rest-client:org.glassfish.hk2.api:pfl-tf:org.glassfish.main.jms.core:org.glassfish.main.web.core:org.glassfish.main.common.glassfish-mbeanserver:org.jboss.weld.osgi-bundle:org.glassfish.main.security.ee:pfl-asm:org.glassfish.main.jdbc.admin:org.glassfish.main.common.container-common:org.glassfish.main.admingui.console-jdbc-plugin:org.glassfish.main.admingui.console-corba-plugin:org.glassfish.main.admingui.glassfish-osgi-console-plugin:org.glassfish.main.cluster.admin:org.glassfish.main.deployment.javaee-full:org.glassfish.main.ejb.ejb-full-container:org.glassfish.tyrus.container-grizzly:org.glassfish.main.external.ldapbp-repackaged:org.eclipse.persistence.jpa:org.glassfish.main.core.glassfish:org.glassfish.main.common.amx-core:org.glassfish.tyrus.client:org.eclipse.persistence.dbws:org.glassfish.main.admingui.console-jca-plugin:org.glassfish.main.webservices.connector:org.glassfish.main.persistence.gf-jpa-connector:org.glassfish.main.connectors.inbound-runtime:org.glassfish.main.admingui.connector.gf-admingui-connector:javax.jms-api:org.glassfish.main.orb.connector:com.sun.mail.javax.mail:org.glassfish.main.admin.util:org.glassfish.javax.json:org.glassfish.hk2.config-types:org.glassfish.hk2.external.javax.inject:org.glassfish.main.web.weld-integration:org.glassfish.main.deployment.dol:org.glassfish.main.web.gf-web-connector:org.glassfish.hk2.runlevel:org.glassfish.hk2.hk2:org.glassfish.main.common.annotation-framework:woodstox-core-asl:org.glassfish.main.admingui.console-ejb-plugin:org.glassfish.hk2.core:pfl-tf-tools:org.glassfish.hk2.locator:org.glassfish.main.web.jstl-connector:org.glassfish.main.admin.gf-restadmin-connector:org.glassfish.main.admin.monitoring-core:org.glassfish.main.resources.runtime:org.glassfish.tyrus.spi:org.glassfish.corba.glassfish-corba-csiv2-idl:javax.xml.rpc-api:org.glassfish.main.admin.backup:org.glassfish.main.external.ant:org.glassfish.main.admingui.console-common-full-plugin:org.glassfish.web.javax.servlet.jsp.jstl:org.glassfish.main.admingui.console-common:org.glassfish.main.simple-glassfish-api:org.glassfish.fighterfish.osgi-jpa-extension:org.glassfish.main.web.weld-integration-fragment:org.glassfish.main.persistence.cmp.generator-database:org.glassfish.main.admingui.console-cluster-plugin:org.glassfish.main.web.naming:org.glassfish.main.admingui.dataprovider:org.glassfish.main.common.scattered-archive-api:org.glassfish.main.web.sse:org.glassfish.main.jdbc.config:org.glassfish.hk2.external.bean-validator:gmbal:org.glassfish.main.resources.connector:org.glassfish.main.core.javaee-kernel:org.glassfish.main.javax.security.auth.message:org.glassfish.main.resourcebase.resources.nucleus-resources:org.glassfish.jersey.media.jersey-media-json-jackson:org.glassfish.main.persistence.cmp.enhancer:org.jvnet.mimepull:org.glassfish.main.common.internal-api:org.glassfish.metro.webservices-osgi:org.glassfish.jersey.ext.jersey-bean-validation:org.glassfish.main.osgi-platforms.osgi-container:org.glassfish.main.flashlight.flashlight-extra-jdk-packages:org.glassfish.main.external.antlr-repackaged:javax.resource-api:com.sun.xml.bind.extra:org.glassfish.main.connectors.gf-connectors-connector:pfl-basic:org.glassfish.main.connectors.work-management:org.glassfish.jersey.containers.jersey-container-grizzly2-http:org.glassfish.main.cluster.gms-bootstrap:org.glassfish.main.security.websecurity:org.glassfish.main.grizzly.glassfish-grizzly-extra-all:org.glassfish.main.deployment.common:org.glassfish.main.ha.ha-file-store:org.glassfish.main.jms.gf-jms-injection:org.glassfish.main.deployment.javaee-core:org.glassfish.main.common.stats77:org.glassfish.hk2.osgi-resource-locator:org.glassfish.main.admingui.console-web-plugin:org.glassfish.tyrus.core:org.eclipse.persistence.antlr:org.glassfish.main.persistence.glassfish-oracle-jdbc-driver-packages:org.glassfish.main.registration.registration-impl:org.glassfish.main.persistence.cmp.support-sqlstore:org.glassfish.main.appclient.acc-config:javax.ws.rs.javax.ws.rs-api:org.glassfish.main.deployment.deployment-client:JSR352.Runtime:org.glassfish.main.common.util:org.glassfish.hk2.class-model:org.glassfish.main.common.amx-javaee:org.glassfish.main.security.services:org.glassfish.main.jms.gf-jms-connector:org.glassfish.main.admingui.console-updatecenter-plugin:javax.enterprise.concurrent.javax.enterprise.concurrent-api:org.glassfish.main.appclient.server.appclient-server-core:javax.management.j2ee-api:org.glassfish.main.deployment.admin:org.glassfish.main.registration.glassfish-registration:org.glassfish.main.web.embed-api:org.glassfish.jersey.containers.jersey-container-servlet:javax.transaction-api:org.glassfish.main.persistence.cmp.model:org.glassfish.main.web.gf-weld-connector:org.glassfish.main.registration.registration-api:org.glassfish.main.security.ssl-impl:org.glassfish.ha.ha-api:org.glassfish.main.persistence.common:org.shoal.cache:org.glassfish.jersey.core.jersey-client:org.eclipse.persistence.asm:org.glassfish.javax.el:jackson-jaxrs:org.glassfish.main.grizzly.nucleus-grizzly-all:org.glassfish.main.web.jsf-connector:org.glassfish.main.persistence.entitybean-container:stax2-api:jackson-xc:org.glassfish.jersey.media.jersey-media-multipart:org.glassfish.main.security.appclient.security:org.glassfish.main.admin.config-api:org.glassfish.main.webservices.jsr109-impl:org.glassfish.jersey.core.jersey-common:org.glassfish.external.management-api:org.glassfish.tyrus.container-servlet:javax.servlet-api:org.shoal.gms-api:org.glassfish.jersey.containers.jersey-container-servlet-core:org.glassfish.main.external.jmxremote_optional-repackaged:org.glassfish.main.security:org.glassfish.web.javax.servlet.jsp:org.glassfish.main.orb.iiop:org.glassfish.main.admingui.console-community-branding-plugin:org.glassfish.main.cluster.common:org.glassfish.main.core.kernel:org.glassfish.main.admingui.console-jms-plugin:javax.enterprise.deploy-api:org.glassfish.corba.glassfish-corba-orb:org.eclipse.persistence.jpa.modelgen:org.glassfish.main.resources.javamail-runtime:org.glassfish.tyrus.websocket-core:org.glassfish.main.loadbalancer.load-balancer-admin:]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.jboss.weld.osgi-bundle [38]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.oracle [162]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.ha.shoal-cache-bootstrap [27]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.glassfish-mbeanserver [69]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.external.antlr-repackaged [39]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.concurrent.config [122]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.containers.jersey-container-servlet-core [58]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-jts-plugin [26]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.jms.core [194]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.cluster.common [20]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [jackson-jaxrs [59]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.annotation-api [2]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.containers.jersey-container-grizzly2-http [108]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.core [29]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.web.javax.servlet.jsp.jstl [196]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.containers.glassfish.jersey-gf-ejb [160]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.ejb.ejb-container [40]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.osgi-adapter [205]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.javax.security.auth.message [181]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-web-plugin [99]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.jaspic.provider.framework [126]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.cluster.ssh [60]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.webservices.soap-tcp [19]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.appclient.security [5]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-ejb-plugin [16]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [stax2-api [107]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.ha.ha-file-store [257]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.scattered-archive-api [177]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.web.javax.servlet.jsp [157]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.gui-plugin-common [80]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.webservices.metro-glue [156]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-ejb-container [281]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.external.dbschema-repackaged [152]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.deployment.deployment-client [53]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.ws.rs.javax.ws.rs-api [95]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.loadbalancer.load-balancer-admin [66]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.core.javaee-kernel [15]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.grizzly.nucleus-grizzly-all [9]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.registration.registration-impl [130]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [JSR352.API [239]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.enterprise.deploy-api [159]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [pfl-dynamic [32]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.jpa [149]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.gf-jpa-connector [206]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.corba.glassfish-corba-csiv2-idl [240]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.ha.shoal-cache-store [220]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.external.jmxremote_optional-repackaged [68]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.external.ldapbp-repackaged [166]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.jpa.modelgen [49]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.resources.javamail-runtime [256]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.osgi-platforms.osgi-container [31]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.fileinstall [272]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.gogo.command [286]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.ejb.gf-ejb-connector [103]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.metro.webservices-extra-jdk-packages [73]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.core.glassfish [247]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.ejb.security [248]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.corba.glassfish-corba-omgapi [252]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.javax.faces [231]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.media.jersey-media-multipart [198]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.appclient.acc-config [204]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.external.cglib [192]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.launcher [254]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.internal-api [210]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [GlassFish-Application-Common-Module [168]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.interceptor-api [111]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.config-api [124]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-ejb-lite-plugin [267]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.codehaus.jettison.jettison [114]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [pfl-tf [249]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.ejb-api [25]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-community-branding-plugin [37]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.management.j2ee-api [81]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.bundlerepository [201]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.servlet-api [165]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.tyrus.core [104]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-javaee-base [282]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.jpa.jpql [83]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.gf-restadmin-connector [35]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.corba.glassfish-corba-internal-api [203]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.websocket-api [128]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.connectors.inbound-runtime [71]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.sse [155]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-jpa [278]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [jackson-core-asl [148]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.websecurity [82]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.xml.jaxr-api-osgi [79]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.registration.glassfish-registration [33]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.config-types [178]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.gf-web-connector [167]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [woodstox-core-asl [94]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.osgi-platforms.felix-webconsole-extension [274]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-corba-plugin [174]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.shoal.cache [163]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.jdbc.runtime [188]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.external.asm-all-repackaged [262]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [pfl-basic-tools [217]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [jackson-xc [235]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.media.jersey-media-sse [173]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-cdi [275]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.appclient.server.appclient-connector [169]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.ejb.ejb-full-container [158]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.jpa-container [154]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.core [238]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.external.management-api [96]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.connectors.runtime [230]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.rest-service [263]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.glassfish-osgi-console-plugin [224]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.ssl-impl [161]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.transaction.jts [45]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.resource-api [134]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.containers.jersey-container-servlet [77]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security [142]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.javax.json [237]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.external.javax.inject [14]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.class-model [216]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.osgi-resource-locator [4]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.external.trilead-ssh2-repackaged [258]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.tyrus.spi [46]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.backup [75]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.antlr [28]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.grizzly.glassfish-grizzly-extra-all [10]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.connectors.gf-connectors-connector [52]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [pfl-basic [185]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.common [101]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.javax.enterprise.concurrent [100]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.ext.jersey-bean-validation [91]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.external.j-interop-repackaged [171]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.amx-core [13]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.resources.javamail-connector [215]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.asm [170]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.gf-weld-connector [65]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.deployment.common [110]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.monitoring-core [164]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.glassfish-api [260]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.cli [90]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [com.sun.pkg.client [44]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.ee [41]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.connectors.admin [244]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.glassfish-ee-api [241]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.util [153]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.webservices.security [208]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.core [175]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.loadbalancer.gf-load-balancer-connector [125]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.corba.glassfish-corba-orb [132]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-common [193]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.registration.registration-api [97]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.tyrus.server [127]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.transaction.jta [214]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.resourcebase.resources.nucleus-resources [172]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.jms-api [184]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.ejb-mapping [74]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.concurrent.runtime [43]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.enhancer [151]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.media.jersey-media-moxy [50]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.jdbc.config [123]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.scr [284]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.hk2 [63]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.core.kernel [211]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.servlet.jsp.jstl-api [93]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.transaction.internal-api [88]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.batch.connector [232]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.ha [265]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [JSR352.Runtime [105]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.resources.connector [236]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.annotation-framework [23]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-jpa-extension [118]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.deployment.javaee-full [213]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.glassfish-naming [129]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.naming [8]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.weld-integration [51]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.utils [225]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.external.libpam4j-repackaged [56]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.orb.iiop [268]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.metro.webservices-osgi [6]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.core.jersey-common [243]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.weld-integration-fragment [87]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [jackson-mapper-asl [109]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.metro.webservices-api-osgi [1]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-http [279]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.model [98]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.transaction.cdi-api [12]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.core [190]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.locator [30]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [gmbal [221]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.support-sqlstore [245]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.gogo.runtime [277]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-cluster-plugin [54]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.tyrus.container-servlet [180]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.orb.enabler [78]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.jdbc.admin [57]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [pfl-asm [147]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.tyrus.websocket-core [116]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.webservices.connector [229]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.shoal.gms-api [234]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.webservices.jsr109-impl [86]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.simple-glassfish-api [67]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.api [47]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.moxy [84]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.utility [102]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.cluster.gms-bootstrap [72]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [com.sun.mail.javax.mail [17]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.runlevel [227]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.resources.runtime [113]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-plugin-service [233]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.rest-client [85]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [pfl-tf-tools [34]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admin.cli [195]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.media.jersey-media-json-jackson [266]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.deployment.admin [18]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.enterprise.concurrent.javax.enterprise.concurrent-api [136]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.war-util [89]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.jms.admin [119]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.internal-api [115]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.jvnet.mimepull [131]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.glue [64]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.osgi-platforms.osgi-cli-remote [285]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.media.jersey-media-json-jettison [186]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.support-ejb [212]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-web-container [269]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.orb.connector [200]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.deployment.autodeploy [179]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.shoal.gms-impl [264]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-jdbc [270]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.entitybean-container [36]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.deployment.dol [138]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.external.schema2beans-repackaged [226]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.jms.gf-jms-connector [189]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.core.jersey-client [133]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.connectors.work-management [106]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [com.google.guava [141]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.appclient.server.appclient-server-core [140]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.container-common [143]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [com.sun.jsftemplating [21]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.javax.el [199]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.eventadmin [271]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.jsf-connector [76]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.external.ant [253]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.deployment.javaee-core [139]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.util [62]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.external.bean-validator [222]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.ejb.internal-api [246]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-common-full-plugin [150]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.cluster.gms-adapter [187]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.jspcaching-connector [219]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.servlet.jsp-api [197]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.core.glassfish-extra-jre-packages [183]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.eclipse.persistence.dbws [146]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.jms.gf-jms-injection [250]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.stats77 [24]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.connector.gf-admingui-connector [48]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [jaxb-api [3]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-jdbc-plugin [223]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.jersey.core.jersey-server [22]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.appclient.gf-client-module [144]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.javax.security.jacc [42]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.jstl-connector [218]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.gogo.shell [276]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.flashlight.framework [259]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.ha.ha-api [145]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.inmemory.jacc.provider [120]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.flashlight.flashlight-extra-jdk-packages [55]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.common.amx-javaee [117]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.webconsole [273]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.fighterfish.osgi-jta [283]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.apache.felix.configadmin [280]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-jca-plugin [121]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-updatecenter-plugin [7]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [com.sun.xml.bind [61]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.cluster.admin [209]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.core.logging [202]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.connectors.internal-api [70]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.xml.rpc-api [261]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.console-jms-plugin [112]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.persistence [255]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.admingui.dataprovider [207]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.hk2.config [191]], State = [READY]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.tyrus.client [228]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [com.sun.xml.bind.extra [92]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.web.embed-api [176]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.cmp.generator-database [251]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.persistence.glassfish-oracle-jdbc-driver-packages [182]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.tyrus.container-grizzly [135]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [javax.transaction-api [11]], State = [RESOLVED]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.security.services [242]], State = [NEW]]
[exec] Registered Module: [OSGiModuleImpl:: Bundle = [org.glassfish.main.concurrent.admin [137]], State = [NEW]]
[exec]
[exec] Registered com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime@2401e897 in service registry.
[exec] Found populator: com.sun.enterprise.v3.server.GFDomainXml
[exec] We are in non-embedded mode, so org.glassfish.main.core.glassfish [247] has nothing to do.
[exec] Completed shutdown of GlassFish runtime
[exec] Mar 06, 2013 10:06:18 PM BundleProvisioner createBundleProvisioner
[exec] INFO: clazz = class com.sun.enterprise.glassfish.bootstrap.osgi.BundleProvisioner
[exec] Exception in thread "main" java.lang.reflect.InvocationTargetException
[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 com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
[exec] at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
[exec] Caused by: org.glassfish.embeddable.GlassFishException: com.sun.enterprise.module.bootstrap.BootException: Unable to load service
[exec] at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:103)
[exec] at com.sun.enterprise.glassfish.bootstrap.GlassFishRuntimeDecorator.newGlassFish(GlassFishRuntimeDecorator.java:68)
[exec] at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntime.newGlassFish(OSGiGlassFishRuntime.java:88)
[exec] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
[exec] ... 6 more
[exec] Caused by: com.sun.enterprise.module.bootstrap.BootException: Unable to load service
[exec] at com.sun.enterprise.module.bootstrap.Main.findStartupService(Main.java:228)
[exec] at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:98)
[exec] ... 9 more
[exec] Caused by: A MultiException has 5 exceptions. They are:
[exec] 1. java.lang.RuntimeException: java.io.IOException: Invalid keystore format
[exec] 2. java.lang.IllegalStateException: Unable to perform operation: post construct on org.glassfish.security.services.impl.DomainPasswordAliasStore
[exec] 3. java.lang.IllegalStateException: Unable to perform operation: post construct on com.sun.enterprise.v3.server.SystemTasksImpl
[exec] 4. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of com.sun.enterprise.v3.server.AppServerStartup errors were found
[exec] 5. java.lang.IllegalStateException: Unable to perform operation: resolve on com.sun.enterprise.v3.server.AppServerStartup
[exec]
[exec] at org.jvnet.hk2.internal.Collector.throwIfErrors(Collector.java:84)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:212)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:294)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:433)
[exec] at org.jvnet.hk2.internal.SingletonContext.findOrCreate(SingletonContext.java:87)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2099)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:599)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:581)
[exec] at com.sun.enterprise.module.bootstrap.Main.findStartupService(Main.java:221)
[exec] ... 10 more
[exec] Caused by: java.lang.RuntimeException: java.io.IOException: Invalid keystore format
[exec] at org.glassfish.security.services.impl.DomainPasswordAliasStore.initStore(DomainPasswordAliasStore.java:69)
[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 org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:991)
[exec] at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:270)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:306)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:433)
[exec] at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2099)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.internalGetService(ServiceLocatorImpl.java:599)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:581)
[exec] at org.glassfish.config.support.TranslatedConfigView.domainPasswordAliasStore(TranslatedConfigView.java:160)
[exec] at org.glassfish.config.support.TranslatedConfigView.getTranslatedValue(TranslatedConfigView.java:80)
[exec] at com.sun.enterprise.v3.server.SystemTasksImpl.resolveJavaConfig(SystemTasksImpl.java:232)
[exec] at com.sun.enterprise.v3.server.SystemTasksImpl.postConstruct(SystemTasksImpl.java:108)
[exec] at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:264)
[exec] at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:306)
[exec] at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:433)
[exec] at org.glassfish.hk2.runlevel.internal.RunLevelContext.findOrCreate(RunLevelContext.java:119)
[exec] at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2099)
[exec] at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:540)
[exec] at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:174)
[exec] at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:197)
[exec] ... 17 more
[exec] Caused by: java.io.IOException: Invalid keystore format
[exec] at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:709)
[exec] at java.security.KeyStore.load(KeyStore.java:1214)
[exec] at com.sun.enterprise.security.store.PasswordAdapter.loadKeyStore(PasswordAdapter.java:189)
[exec] at com.sun.enterprise.security.store.PasswordAdapter.<init>(PasswordAdapter.java:158)
[exec] at org.glassfish.security.services.impl.JCEKSPasswordAliasStore.init(JCEKSPasswordAliasStore.java:93)
[exec] at org.glassfish.security.services.impl.DomainPasswordAliasStore.initStore(DomainPasswordAliasStore.java:67)
[exec] ... 42 more
[exec]
[exec] Result: 1



 Comments   
Comment by Tim Quinn [ 06/Mar/13 ]

Can you describe exactly how the test "patches" the certs?

Comment by Sreekanth [ 06/Mar/13 ]

Probably this will help you.

http://docs.oracle.com/cd/E19159-01/820-1072/gfrgz/index.html

Comment by Sreekanth [ 06/Mar/13 ]

The download link to copyv3.zip provided in the link doesn't seem to work. I will send you an email to the link hosted internally on one of my boxes

Comment by Sreekanth [ 06/Mar/13 ]

Hi,

Just by patching the certificates alone, I am unable to reproduce this issue locally. I am able to reproduce this in 3 different automated setups, though.

But in the same automated setups, with glassfish b72 and prior builds this is working fine. So I can tell some thing changed in glassfish 4.0 b73. But I am unable to pinpoint what process of QE automation is creating the problem with b73. This might be caused by some change to glassfish ,that I am not aware.

I will update here as soon as I find what exactly is causing the issue in my setup. In the mean while if any one can security team can figure out what might have caused this, please let me know.

Comment by Sreekanth [ 06/Mar/13 ]

There is this target in our automation script which seems to create a problem.

<copy file="$

{admin.password.file}

" tofile="$

{as.home}

/domains/domain1/config/domain-passwords" overwrite="true"/>

Looks like till b72, when we replace the file with text file, some how glassfish never complained.

Tim,

Can you please take it from here. If there is some thing I need to know / I misunderstood, please guide me.

Thanks,
Sreekanth

Comment by Tim Quinn [ 06/Mar/13 ]

Sreekanth,

domain-passwords is a keystore that holds password aliases. Would a user really expect the system to continue to work if s/he replaced a binary keystore file with a text file?

I do not know why this worked with earlier builds. In fact it seems to me that earlier versions were incorrect if they did not flag this as an error.

If the admin.password.file is a text file you want to specify on asadmin commands using --passwordfile then the script should deposit it somewhere else, not overwrite the existing keystore.

Comment by Alex Pineda [ 08/Mar/13 ]

Needs this issue resolved in GF 4.0

Comment by Tim Quinn [ 08/Mar/13 ]

Alex, please clarify what you mean by needing this resolved for GF 4.0.

the file at $

{domain-dir}

/config/domain-passwords is a binary JCEKS keystore file that holds encrypted password aliases that are managed using "asadmin create-password-alias" and "asadmin delete-password-alias."

From what I understand from Sreekanth the test overwrites this binary file with a text file that the test uses as a password file (asadmin -passwordfile domain-passwords).

My point is that the test should place its password file elsewhere to avoid overwriting the domain's password alias binary file.

As for why this worked in earlier builds... I did some work within the past few weeks generalizing the password alias handling to support both open-source GF and other platforms. It's possible that the revised implementation for GF is reading the password alias keystore in as part of start-up, while the earlier releases might have done so only when an alias was first created or accessed. In either case, the tests should not overwrite this file – that's not something we'd support users doing.

Comment by Alex Pineda [ 12/Mar/13 ]

My request to resolve is based on the issue is marked as a "blocker" for Metro test execution. So, we need to resolve it. Does not mean we have the change the code. I see from your comments that you believe the test behavior is not correct. We need to get Sreekanth's feedback to see what he believes needs to be done.

Comment by Martin Grebac [ 13/Mar/13 ]

Just a side-note - Tim, doesn't what you describe have a performance implication on GF startup time as you describe previously some reading happened lazily?

Comment by Tim Quinn [ 13/Mar/13 ]

Good point, Martin.

I've checked in an change so that the keystore will be opened just-in-time on first actual use which will take it out of the server start-up code path.

Comment by Martin Grebac [ 14/Mar/13 ]

Perfect. Sreekanth - you mentioned yesterday this one is not blocking you any more - can the issue be closed then?

Comment by Tim Quinn [ 14/Mar/13 ]

I would recommend leaving this issue open until the tests have been changed to not overwrite the keystore.

The tests might have begun to pass again, now that the keystore is opened lazily again, but the tests should still be corrected.

Therefore I have changed the description and assigned this issue to Sreekanth.

Comment by Sreekanth [ 14/Mar/13 ]

Hi,

I have changed my test code to change the glassfish admin password using change-admin-password command. Now tests are back in shape.

Tim- I have changed my test code before you have made changes to read the keystore file lazily as you have mentioned in your previous comment. So I think I can close this for now.

Also want to mention that I didn't get a chance to check if my problem got resolved with your changes. I am not sure now if I need to check that as well. For now I will keep the issue open and reduce the severity .

Comment by Sreekanth [ 14/Mar/13 ]

Downgrading the severity as it is no more affecting my tests.

Comment by Tim Quinn [ 14/Mar/13 ]

Hi, Sreekanth.

Can you help me understand what effect changing the test to use change-admin-password will have?

From the original test code, it looked to me as if the test was specifying a text password file with contents like this:

AS_ADMIN_PASSWORD=some-password

and would then specify

--passwordfile $

{as.home}/domains/domain1/config/domain-passwords

on later asadmin commands as a way of choosing what admin password to use.

The basic idea of providing a password file in the test is fine. My point was that the test should not place its password text file at ${as.home}

/domains/domain1/config/domain-passwords because that file path is already used for a completely different purpose by GlassFish...it is the binary keystore file which holds password aliases (not passwords, password aliases).

Instead, the test should copy its password file to some other location - or perhaps not copy it at all and just use "--passwordfile $

{admin.password.file}

" on the asadmin commands.





[GLASSFISH-19772] [UB] Add release notes documentation concerning the state of the clustering/HA features for 4.0 OSE Created: 05/Mar/13  Updated: 17/May/13

Status: In Progress
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b78
Fix Version/s: 4.0

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

Tags: 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

This issue is for making sure the release notes for the 4.0 OSE release describe the anticipated level of testing and quality for the clustering/HA feature.



 Comments   
Comment by Mike Fitch [ 14/Mar/13 ]

Added [UB] to summary so unbundled doc queries will pick up this issue.

Comment by Mike Fitch [ 17/May/13 ]

Added the following to the release notes:

Note:
The main thrust of the GlassFish Server Open Source Edition 4.0 release is to provide an application server for developers to explore and begin exploiting the new and updated technologies in the Java EE 7 platform. Thus, the following features of GlassFish Server were not a focus of this release:

  • Clusters and standalone instances
  • High availability features
  • Upgrade
  • Embedded Server

These features are included in the release, but they may not function properly with some of the new features added in support of the Java EE 7 platform.





[GLASSFISH-19762] [UB] Add release notes documentation concerning the state of the upgrade capability for 4.0 OSE Created: 01/Mar/13  Updated: 17/May/13

Status: In Progress
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b78
Fix Version/s: 4.0

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

Tags: 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 Description   

This issue is for making sure the release notes for the 4.0 OSE release describe the anticipated level of testing and quality for the upgrade feature, i.e., the --upgrade option of the start-domain command.



 Comments   
Comment by Mike Fitch [ 14/Mar/13 ]

Added [UB] to summary so unbundled doc queries will pick up this issue.

Comment by Mike Fitch [ 17/May/13 ]

Added the following to the release notes:

Note:
The main thrust of the GlassFish Server Open Source Edition 4.0 release is to provide an application server for developers to explore and begin exploiting the new and updated technologies in the Java EE 7 platform. Thus, the following features of GlassFish Server were not a focus of this release:

  • Clusters and standalone instances
  • High availability features
  • Upgrade
  • Embedded Server

These features are included in the release, but they may not function properly with some of the new features added in support of the Java EE 7 platform.





[GLASSFISH-19601] [UB] describe how MQ cluster name is generated for a given GlassFish cluster Created: 29/Jan/13  Updated: 14/Mar/13

Status: In Progress
Project: glassfish
Component/s: docs
Affects Version/s: 9.1.1, v2.1, v2.1.1, V3, v3.0.1, 3.1, 3.1.1, 3.1.2, 3.1.2.2
Fix Version/s: 4.0

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


 Description   

see Summary. This issue is first filed to 'jms' to provide text for doc, then please transfer to 'docs'



 Comments   
Comment by David Zhao [ 30/Jan/13 ]

glassfish will pass <gfClusterName>_MQ to MQ for the property of "imq.cluster.clusterid". Please see MQ-275 for details of the doc issue.

Comment by amyk [ 30/Jan/13 ]

David,

According to the following GlassFish forum post, MQ broker sees MYCLSTRDEV_MQ for imq.cluster.clusterid without the '_'s in MY_CLSTR_DEV

http://www.java.net/forum/topic/glassfish/glassfish/glassfish-enhanced-jms-cluster-configuration

Re: Glassfish Enhanced JMS Cluster Configuration
January 29, 2013 - 04:54
#6
hopipouet
.....
To be perfect you can add that "_" are not used in the clusterId generated by glassfish, so you can add how many "_" you want in cluster name, it doesn't count in the length.

for example : MY_CLSTR_DEV
generate following index :
MQCONSTATE41CMYCLSTRDEV_MQIDX1
Comment by Mike Fitch [ 30/Jan/13 ]

Changed component to docs. Changed fix version to 4.0_b76_EE7MS5 for any changes that would go into the configure-jms-cluster man page or the JMS Availability or New Cluster console help pages.

Comment by Mike Fitch [ 14/Mar/13 ]

Added information about name length restrictions to the cluster-name operand in the create-cluster and configure-jms-cluster subcommand man pages. Fix available in main-docs build 4.0-b15, which was picked up by GlassFish as of revision 59613, 18-FEB-2013.

Added [UB] to the summary so remaining book-related changes will get tracked.

Changed Fix Version to 4.0 for remaining book-related changes.





[GLASSFISH-19407] Move the asadmin[.bat] scripts from nucleus to glassfish Created: 06/Dec/12  Updated: 26/Feb/13

Status: In Progress
Project: glassfish
Component/s: admin
Affects Version/s: 4.0_b66
Fix Version/s: 4.0

Type: Task Priority: Major
Reporter: Chris Kasso Assignee: Chris Kasso
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

asadmin was removed from nucleus and moved to GF in r59023.

Next step will be to clean up asadmin string usage in nucleus.

Feb-26-2013:

First pass complete:

Sending admin/cli/src/main/java/com/sun/enterprise/admin/cli/LocalStrings.properties
Sending admin/server-mgmt/src/main/java/com/sun/enterprise/admin/servermgmt/cli/LocalStrings.properties
Sending admin/server-mgmt/src/main/java/com/sun/enterprise/admin/servermgmt/services/LocalStrings.properties
Sending cluster/cli/src/main/java/com/sun/enterprise/admin/cli/cluster/LocalStrings.properties
Sending common/common-util/src/main/java/org/glassfish/common/util/admin/LocalStrings.properties

There are still some remaining strings to convert. These will be a bit more difficult to deal with.


 Description   

Currently the asadmin script resides in Nucleus. An analogous command already exists in Nucleus. It is called nadmin.

The asadmin scripts (asadmin and asdmin.bat) need to be moved into the GlassFish project because not all projects that depend on Nucleus will use a command named asadmin. They may use the skinning mechanism to provide their own command for admin functions.

As part of this transition Nucleus based tests need to be reviewed to ensure they use nadmin instead of asadmin.

We also need to decide if the AsadminMain class in Nucleus should be renamed to NadminMain. This would impact commands outside of nucleus that currently use the skinning mechanism.






[GLASSFISH-19297] [UB] Doc gives incorrect DTD prolog for GlassFish-specific app client deployment descriptor Created: 06/Nov/12  Updated: 14/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Mike Fitch
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As mentioned in this stackoverflow post

http://stackoverflow.com/questions/13242300/what-is-the-correct-doctype-for-glassfish-application-client-xml

the doc here

http://docs.oracle.com/cd/E18930_01/html/821-2417/beaqo.html

gives the incorrect ID in the example for the GlassFish-specific app client DD.

Here is what the prolog should be using the most current DTD:

<!DOCTYPE glassfish-application-client PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Java EE Application Client 6.0//EN" "http://glassfish.org/dtds/glassfish-application-client_6_0-2.dtd">



 Comments   
Comment by Mike Fitch [ 14/Mar/13 ]

Added [UB] to summary, as this issue applies to unbundled documentation (as opposed to online help. Also, changed Fix Version to 4.0 so issue will show up on 4.0* queries. Actual commitment and build # TBD.





[GLASSFISH-19278] [UB] GlassFish documentation about -Xrs JVM option is unclear Created: 02/Nov/12  Updated: 14/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.2.2
Fix Version/s: 4.0

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


 Description   

The GlassFish documentation set concerning the -Xrs JVM option does not really indicate if this is a requirement for setting up a service on Windows.

If it is a requirement, then shouldn't it be part of the configuration information produced by asadmin create-service?

Given that most of the time a Windows service runs as a different user from the one who is logging out, is this documentation intended to point out that any user's logout will cause the service to terminate?



 Comments   
Comment by ljnelson [ 03/Nov/12 ]

Looks like there's one related issue that claims to be a duplicate of another.

My intent is only to make sure that the documentation reflects whatever the consensus is, not to duplicate either bug.

Comment by Mike Fitch [ 14/Mar/13 ]

Added [UB] to summary as this issue relates to unbundled documentation (as opposed to online help). Also, changed Fix Version to 4.0 so issue will show up on 4.0* queries. Actual commitment and build # TBD.

Comment by Mike Fitch [ 14/Mar/13 ]

Whoops. Really changed fix version this time.





[GLASSFISH-19224] extend gf server adapter to advertise support for new specs/facets Created: 23/Oct/12  Updated: 28/Jan/13

Status: Open
Project: glassfish
Component/s: ide-integration
Affects Version/s: None
Fix Version/s: 4.0

Type: Task Priority: Major
Reporter: vince kraemer Assignee: piotrik
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by vince kraemer [ 23/Oct/12 ]

try to make regular

Comment by shreedhar_ganapathy [ 23/Jan/13 ]

This is for the Eclipse Plugin - will need a server adapter for GF 4.0 (in development) - add ability for server adapter to support Java EE facets representing various Java EE component apis - we need from Eclipse Foundation or our Eclipse team on what new facets are available, or implement those ourselves & change the server adapter to support these facets.

Comment by shreedhar_ganapathy [ 28/Jan/13 ]

Improvement -> Task





[GLASSFISH-19223] Allow user to create web app 3.2 project Created: 23/Oct/12  Updated: 28/Jan/13

Status: Open
Project: glassfish
Component/s: ide-integration
Affects Version/s: None
Fix Version/s: 4.0

Type: Task Priority: Major
Reporter: vince kraemer Assignee: piotrik
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by shreedhar_ganapathy [ 23/Jan/13 ]

Create a facet for EE 7 Web App project in Eclipse - Extend the Web App Project to Java EE 7 Web App project.

Comment by shreedhar_ganapathy [ 28/Jan/13 ]

Improvement -> Task





[GLASSFISH-19222] allow user to create Application 7.0 ear Created: 23/Oct/12  Updated: 28/Jan/13

Status: Open
Project: glassfish
Component/s: ide-integration
Affects Version/s: None
Fix Version/s: 4.0

Type: Task Priority: Major
Reporter: vince kraemer Assignee: piotrik
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Create an Application.ear facet in Eclipse



 Comments   
Comment by shreedhar_ganapathy [ 28/Jan/13 ]

Improvement -> Task





[GLASSFISH-19221] allow user to create App Client 7.0 project Created: 23/Oct/12  Updated: 28/Jan/13

Status: Open
Project: glassfish
Component/s: ide-integration
Affects Version/s: None
Fix Version/s: 4.0

Type: Task Priority: Major
Reporter: vince kraemer Assignee: piotrik
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Eclipse related wrt app client facet.



 Comments   
Comment by shreedhar_ganapathy [ 28/Jan/13 ]

Improvement -> Task





[GLASSFISH-19220] allow user to create EJB 3.2 project Created: 23/Oct/12  Updated: 28/Jan/13

Status: Open
Project: glassfish
Component/s: ide-integration
Affects Version/s: None
Fix Version/s: 4.0

Type: Task Priority: Major
Reporter: vince kraemer Assignee: vince kraemer
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by vince kraemer [ 23/Oct/12 ]

NetBeans and Eclipse allow the user to create a project that represents an ejb jar.

These projects have actions to create beans (Session and MessageDriven)
these wizards may need to be extended to account for new features of EJB 3.2

These projects have a way to generate a deployment descriptor.
the DD generator should provide the correct namespace info to create an EJB 3.2 DD file for a 3.2 project.

These projects have a wizard to generate the server specific DD as a glassfish-ejb-jar file correctly.... as a glassfish-ejb-jar 3.2 for an EJB Jar 3.2 project.

Comment by shreedhar_ganapathy [ 28/Jan/13 ]

Improvement -> Task





[GLASSFISH-19163] [UB]Document -Dwriteout.xml=true option Created: 16/Oct/12  Updated: 15/Mar/13

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

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From Hong's comments on GLASSFISH-17826:

Today you could use a system property to force the writing out of the generated descriptors for debug purpose (in the generated/xml directory like in v2), they are just no longer written out by default.
Add this jvm option to domain.xml and restart server before you deploy:
<jvm-options>-Dwriteout.xml=true</jvm-options>



 Comments   
Comment by Mike Fitch [ 16/Feb/13 ]

Added [UB] to summary and set fix version to 4.0.1 because this fix would be to unbundled documentation.

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 4.0 so this issue gets picked up by OSE 4.0 release queries.





[GLASSFISH-19077] [UB]Need to document how timeout is handled in XA transactions Created: 14/Sep/12  Updated: 15/Mar/13

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

Type: Bug Priority: Major
Reporter: marina vatkina Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If transaction timeout is set to a positive value, and it is an XA transaction a background thread is started that checks every 10 seconds (the value is currently not modifiable) if there are any timed-out transactions. The timed out transactions are marked as such, but the transaction is not marked for rollback. Because the transaction is not marked for rollback, the beforeCompletion callback is still being called, but then the transaction is rolled back. It is not an optimal behavior, but it doesn't break the spec.



 Comments   
Comment by Mike Fitch [ 16/Feb/13 ]

Added [UB] to summary and set fix version to 4.0.1 because this fix would be to unbundled documentation.

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 4.0 so this issue gets picked up by OSE 4.0 release queries.





[GLASSFISH-18946] EAR with two CDI Jersey web archives will not deploy Created: 26/Jul/12  Updated: 23/Jul/14

Status: Reopened
Project: glassfish
Component/s: jax-rs
Affects Version/s: None
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Ramon Rockx Assignee: Jakub Podlesak
Resolution: Unresolved Votes: 16
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7


Attachments: Zip Archive JerseyCDITest2.zip     File TestEAR-0.0.1-SNAPSHOT.ear     Java Archive File TestWAR1-0.0.1-SNAPSHOT-sources.jar     Java Archive File TestWAR2-0.0.1-SNAPSHOT-sources.jar    
Tags: req-weld-fix

 Description   

I already filed this issue in the Jersey JIRA (http://java.net/jira/browse/JERSEY-1232), however, after some research by Michal Gajdos, the issue is closed as "invalid", since the problem would by caused by Weld/GlassFish Weld. I also filed an issue at the Weld JIRA (http://issues.jboss.org/browse/WELD-1175), but they think it should be investigated first by the GlassFish team... (from pillar to post).
Hopefully, the GlassFish team can help solving this problem.

So here are the details:
We are experiencing the following issue with Jersey 1.12 in combination with Weld 1.1.4 and Glassfish 3.1.2:
When using an EAR with two WAR's in it, the last WAR doesn't get deployed. Both WAR's are CDI enabled and contains a REST service. When deploying both WAR's without the EAR, they deploy just fine.
I will attach a test case.

Depending on the VM property
com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager we will get another Exception:

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=false:

java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'com/sun/jersey/config/CDIExtension' in
SerialContext[myEnv=java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory,
 java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, 
java.naming.factory.url.pkgs=com.sun.enterprise.naming}
[Root exception is javax.naming.NameNotFoundException: CDIExtension not found]	
	at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...

com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true

java.lang.NullPointerException
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:94)
	at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
	at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:574)
	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:606)
	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:208)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
	at javax.servlet.GenericServlet.init(GenericServlet.java:244)
	...


 Comments   
Comment by jjsnyder83 [ 03/Oct/12 ]

There is a work-around...I removed the WEB-INF/lib/jersey-gf-servlet-1.12.jar from the wars and I was able to deploy the ear successfully and execute http://localhost:8080/rest1_war/service/rest/RestService1 with "Hello world" as the result. I was able to reproduce the NPE above so I'm still looking into it.

Comment by jjsnyder83 [ 05/Oct/12 ]

I have checked in a fix. The application now deploys. However this has uncovered what I believe to be a bug in Weld. See https://issues.jboss.org/browse/WELD-1175.

I have checked in the fix into 3.1.2 and trunk.

Comment by jjsnyder83 [ 05/Oct/12 ]

Reopening due to the bug in Weld

Comment by Ramon Rockx [ 08/Oct/12 ]

Great that this one is fixed!
I'm looking for a way to patch our GlassFish installation (version 3.1.2.2).
jjsnyder83, you mentioned that it is fixed on trunk and 3.1.2. I can only find commits on the trunk (GF 4.0 I assume). Can you help me out patching 3.1.2/3.1.2.2?

Comment by jjsnyder83 [ 08/Oct/12 ]

I made the change to the 3.1.2-SUSTAINING line as well as trunk (4.0).

I will get back to you on the patching.

Please note that even though the app will deploy a fix to Weld (https://issues.jboss.org/browse/WELD-1175) is still required for the app to work correctly. See the Weld issue for details.

Comment by jjsnyder83 [ 08/Oct/12 ]

The next patch due out is 3.1.2.4 (not sure of the date yet.) But until Weld fixes the issue there's no reason to include this in the patch.

Comment by Ramon Rockx [ 09/Oct/12 ]

Can we expect this fix will be included in 3.1.2.4 since WELD-1175 is fixed too?
(3.1.2.3 is skipped for release?)

Comment by jjsnyder83 [ 11/Oct/12 ]

Yes...I made the fix in the patch line and so it should be included in the next patch release. I have also requested that weld 1.1.10.Final be included as this relies on weld to work properly.

Comment by jjsnyder83 [ 22/Oct/12 ]

GlassFish integration with Weld was updated to Weld 1.1.10.Final with revision 56665.

Comment by jjsnyder83 [ 20/Dec/12 ]

I just tested this on trunk with weld 1.1.10.Final and it doesn't work.

Comment by jwells [ 27/Mar/13 ]

I get this error now when I deploy the above ear in GF 4.0:

Exception while loading the app : CDI deployment failure:Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
org.jboss.weld.resources.spi.ResourceLoadingException: Error loading class com.sun.jersey.server.impl.cdi.CDIExtension
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:179)
at org.jboss.weld.resources.ClassTransformer.getBackedAnnotatedType(ClassTransformer.java:190)
at org.jboss.weld.resources.ClassTransformer.getEnhancedAnnotatedType(ClassTransformer.java:224)
at org.jboss.weld.bootstrap.ExtensionBeanDeployer.deployBeans(ExtensionBeanDeployer.java:71)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:464)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:192)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)

I looked at this a little bit, the class com.sun.jersey.server.impl.cdi.CDIExtension is in the jersey-gf-servlet-1.12.jar included in the WAR files included in the EAR. My guess would be that the old CDIExtension (which no longer exists in the Jersey included in GF 4.0) cannot be loaded properly anymore...

So to me this seems like it is currently a Jersey issue, and may have to do with backwards compatibility...

Comment by Ramon Rockx [ 02/May/13 ]

I'm wondering if this bug will be fixed with the upcoming 4.0 release?
It really makes it impossible for us to use REST in a large modular EAR application properly.

Comment by dbenegiamo [ 03/May/13 ]

As the "double WARs in a EAR" is a common solution for applications that expose a FORM authentication for the web presentation and a BASIC authentication for restful web-services, priority of this bug should - in my opinion - raised.

Comment by Ramon Rockx [ 22/May/13 ]

Like jwells mentioned, the current test case results in ClassNotFoundExceptions.
I downloaded GlassFish 4.0 b88. Tweaked the test case:

  • no Jersey servlet configuration anymore (web.xml is empty)
  • no explicit dependency to Jersey 1.12 anymore (it now depends on Jersey 2.x)
  • used the javax.ws.rs.ApplicationPath annotation to configure the REST path prefix.

Now each REST service does work in both web modules.

However, GlassFish does log warnings like
"[WARNING|glassfish 4.0|javax.enterprise.web.util|_ThreadID=60;_ThreadName=AutoDeployer;_TimeMillis=1369210288543;_LevelValue=900; _MessageID=AS-WEB-UTIL-00035;| Unable to load class nl.asknow.sandbox.RestService1, reason: java.lang.ClassNotFoundException: nl.asknow.sandbox.RestService1|#]".
I'm not sure if this warning can be ignored.

I will attach my new test case.

Comment by Ramon Rockx [ 22/May/13 ]

It seems I cannot add an attachment anymore...

Comment by Jakub Podlesak [ 24/May/13 ]

Ramon, could you please send the test case to my e-mail address (jakub.podlesak at oracle.com)? I will attach it here as well once i get it. Thanks!

Comment by Jakub Podlesak [ 27/May/13 ]

Updated test case from Ramon.

Comment by sebastian2 [ 23/Jul/14 ]

Is there a plan to fix that issue? I am also struggeling with this bug....





command fails to accept --property imqDestinationName=quote.< as destination name (GLASSFISH-6604)

[GLASSFISH-18785] Check invalid characters when creating/editing JMS Destination Resource Created: 06/Jun/12  Updated: 06/Jun/12

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 4.0_b38_ms2
Fix Version/s: 4.0

Type: Sub-task Priority: Major
Reporter: David Zhao Assignee: Anissa Lam
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For jmsra, some invalid characters can not be used in Physical Destination Name. I have added the validation logic in create-jms-resource command. Please add the same to the admin gui if possible.

Web Pages to be affected:
Resources > JMS Resources > Destination Resources > New JMS Destination Resource / Edit JMS Destination Resource.

Field:
Physical Destination Name

Validation logic (in Java language, which is used in MQ):

//Verify identifier start character and part
char[] namechars = name.toCharArray();
if (Character.isJavaIdentifierStart(namechars[0]) ||
(namechars[0]=='*' || namechars[0]=='>')) {
for (int i = 1; i<namechars.length; i++) {
if (namechars[i] == '.')

{ // valid for wildcards } else if (namechars[i] == '*') { // valid for wildcards }

else if (namechars[i] == '>')

{ // valid for whildcards }

else if (!Character.isJavaIdentifierPart(namechars[i]))

{ //Invalid if body characters are not valid using isJavaIdentifierPart(). return false; }

}
} else

{ //Invalid if first character is not valid using isJavaIdentifierStart(). return false; }

return true;






[GLASSFISH-18750] [UB] enable-secure-admin doc incorrect regarding password requirement Created: 22/May/12  Updated: 14/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Chris Kasso Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The 3.1.2 docs says:

http://docs.oracle.com/cd/E26576_01/doc.312/e24940/administrative-security.htm#gkocv

By default, GlassFish Server includes a single account for user "admin" and an empty password. Therefore, if you make no other changes before you enable secure admin, "admin" is the initial default username and no password is required. You need to decide whether enabling secure admin without also requiring a password makes sense in your environment.

But I thought 3.1.2 does not allow secure admin to be enabled without an admin password.



 Comments   
Comment by Tim Quinn [ 22/May/12 ]

Hi, Mike.

Just to be clear...

The current (3.1.2) behavior is that the enable-secure-admin command checks to make sure that there is no administrator user with an empty password. The enable-secure-admin command fails if there is at least one such administrator user.

There is a brief note to this effect in this doc:

http://docs.oracle.com/cd/E26576_01/doc.312/e24940/administrative-security.htm#gknqh

just a few paragraphs above the passage Chris pointed to with the link in the initial problem description.

Comment by Mike Fitch [ 22/May/12 ]

Hi Tim,

I added the note you cite in 3.1.2 (as well as similar notes and statements elsewhere where enabling secure admin and admin passwords are mentioned).

The location Chris cites is an instance I missed, and is certainly incorrect.

Comment by Tim Quinn [ 23/May/12 ]

Hi, Mike.

Yeah, I should probably have caught that spot in my review of the changes.

Comment by Mike Fitch [ 14/Mar/13 ]

Added [UB] to summary as this issue applies to a book, "unbundled" documentation. Also, changed Fix Version to 4.0 so issue will show up on 4.0* queries. Actual commitment and build # TBD.





[GLASSFISH-18732] [UB]Incorrect jndi name of EJB for standalone java client Created: 16/May/12  Updated: 15/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: v2.1, 3.1, 3.1.2, 4.0
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Cheng Fang Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Juan reported this in glassfish interest alias:

According to the documentation http://docs.oracle.com/cd/E26576_01/doc.312/e24930/jndi.htm#beany
The lookup for a standalone client should be done using the interoperable global name
"For a client that doesn't run within a Java EE container, the code just uses the interoperable global name instead of the simple global JNDI name. For example:
Context ic = new InitialContext(); Object o = ic.lookup("corbaname:iiop:host:port#a/b/Foo");
"

But I am trying with the corbaname and I unable to do it work...

If instead of the corbaname I use the portable global name java:global/HelloWorldEE-ejb/NewSessionBean then it works.
-----------

I checked GlassFish 2.1 doc, and it also contains the same instruction as 3.1.2
http://docs.oracle.com/cd/E19879-01/820-4336/beanv/index.html

I tend to think this is a oversight in docs and we should correct:

for 2.x and 3.0, use GlassFish-specific global jndi name for the remote ejb;

for 3.1 or later, one can use either the portable global jndi name (preferred), or GlassFish-specific global jndi name, for the remote ejb.



 Comments   
Comment by Mike Fitch [ 16/Feb/13 ]

Added [UB] to summary and set fix version to 4.0.1 because this fix would be to unbundled documentation.

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 4.0 so this issue gets picked up by OSE 4.0 release queries.





Solaris 11, create-jmsdest, list-jmsdest failed: No response from Domain Admin Server after 600 seconds. (GLASSFISH-18112)

[GLASSFISH-18210] [UB] MQ Administration Guide - loopback network address checking on Solaris Created: 19/Jan/12  Updated: 14/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1.2_b18
Fix Version/s: 4.0

Type: Sub-task Priority: Major
Reporter: David Zhao Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Solaris 11



 Description   

Please decide if Solaris specific thing should be mentioned in MQ Administration Guide.

In the MQ Administration Guide which Amy pointed out, it has:

*************************************************
Network loopback IP address. You must make sure that no broker in the cluster is given an address that resolves to a loopback network (127...*) IP address. Any broker configured with such an address will be unable to connect to other brokers in the cluster.

In particular, some Linux installers automatically set the local host to a loopback network address, most commonly 127.0.0.1. On such systems, you must do the following: For each Linux system participating in the cluster, check the /etc/hosts file as part of cluster setup. If the system uses a static IP address, edit the /etc/hosts file to specify the correct address for the local host. If the address is registered with Domain Name Service (DNS), edit the file /etc/nsswitch.conf so that DNS lookup is performed before consulting the local hosts file.

*************************************************

On Solaris, except for /etc/hosts, /etc/inet/ipnodes should also be checked for not being loopback network address.



 Comments   
Comment by Mike Fitch [ 14/Mar/13 ]

Added [UB] to summary and set fix version to 4.0 so this issue would show up in 4.0 doc issue queries.





[GLASSFISH-16393] Refactor DerbyControl Created: 20/Apr/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Task Priority: Minor
Reporter: Jennifer Chou Assignee: Jennifer Chou
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

During investigation of findbugs for DerbyControl, found that it's ok for DerbyControl to call System.exit since is a separate JVM. However, it's being called in the constructor.

Bill's suggestion:
Seems like everything in this class ought to be static, called from main.
Or, the constructor ought to throw an exception in these cases and the
main method should catch the exception and call System.exit.






[GLASSFISH-16339] [UB]sun-acc.xml (and associated DTD) are now glassfish-acc.xml Created: 11/Apr/11  Updated: 15/Mar/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: Tim Quinn Assignee: Paul Davies
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-16302 Convert sun-application-client-contai... Resolved

 Description   

During 3.1 we converted Glassfish-specific descriptors and DTDs from "sun-xxx" names to "glassfish-xxx" but I did not do this for the sun-acc.xml and the sun-application-client-container_1_2.dtd files.

I have opened issue 16302 which is for the engineering changes to make this change.

The docs should change to change references to sun-application-client-container.dtd to glassfish-application-client-container_1_3.dtd and from sun-acc.sml to glassfish-acc.xml.

Note that customers might have scripts which refer to the sun-acc.xml that has historically been generated into $

{domainDir}

/config, so 3.2 will continue to provide that file as well as glassfish-acc.xml. Officially the use of sun-acc.xml will be deprecated as of 3.2. But the documentation should steer users toward glassfish-acc.xml instead of sun-acc.xml.



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

Linking to 16302 - the issue covering the engineering changes.

Comment by Rebecca Parks [ 11/May/11 ]

Changed target release to 3.2 per Tim Quinn.

Comment by Rebecca Parks [ 11/May/11 ]

Build 3 is when Tim made the fix in the 3.2 code.

Comment by Tim Quinn [ 16/Nov/11 ]

I have made the coding changes in 3.1.2 (which should appear in promoted build 11) for 16302.

The doc or release notes should mention that glassfish-acc.xml becomes the default ACC config file (in the domain's config directory) and if the user does not specify "-xml path-to-acc-config-file" on the appclient command then the ACC will look for glassfish-acc.xml in the domain's config directory as the default. (Prior to these changes it would look for sun-acc.xml.)

If a user does an in-place update from 3.1 to 3.1.2, then the glassfish-acc.xml file will not appear in the domain's config directory. To support this use case the ACC will continue to use the sun-acc.xml file as the default ACC config file if it cannot find glassfish-acc.xml. Note that the user can always control what config file the ACC will read using the -xml option on the appclient command.

Comment by Tim Quinn [ 18/Nov/11 ]

Rebecca,

Upon further review, the small incompatibility that we'd introduce by making these changes in 3.1.2, given that this is a bug release, is one we should not create.

So I'm going to revert the changes for this in he 3.1.2 code base. We will not make the file name changes in 3.1.2.

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 4.0 so this issue gets picked up by OSE 4.0 release queries.





[GLASSFISH-16187] Server will not Die when it should Created: 09/Mar/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0

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

Tags: 3_1-next, 3_1_1-scrubbed

 Description   

Add one line of code to a core/kernel command.
build
copy the jar to modules
(like I've done a million times before)

Mar 9, 2011 5:56:39 PM Main start
WARNING: Exception while starting bundle org.glassfish.core.kernel [71]
org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.core.kernel [71]: Unable to resolve 71.0: missing requirement [71.0] package;
(package=com.sun.management)
at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3443)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1727)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.jvnet.hk2.osgimain.Main.start(Main.java:157)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:629)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1835)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1752)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1156)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:662)

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

The problem is that the server is in a Zombie state. It is not dead. It is not alive.
Isn't this above problem catastrophic enough to warrant killing off the process?

D:\gf\v3\core\kernel>jps
6500 admin-cli.jar
3880
716 ASMain
6412 Jps



 Comments   
Comment by Tom Mueller [ 10/Mar/11 ]

Is this a problem in the bootstrap area or AppServerStartup in that it is not detecting the failure to actually start the system?

Byron, can you please provide an example of the type of change that results in this problem?

Comment by Byron Nevins [ 10/Mar/11 ]

No, sorry, I can't provide a reproducible way. It probably had something to do with switching back and forth between JDK6 and 7.

All I did was add one or two lines of code to UptimeCommand (because it's a handy place to quickly add temporary runtime testing code). Once I got into his problem – it would not go away no matter what. Deleting the cache had zero affect. I had to reinstall GlassFish. The code I added was simply getting the OS MBean from the runtime mbean server.

It should be straight-forward to coax a failure like I had for a savvy OSGi developer/user – I would imagine. That would not be me.

Comment by Sanjeeb Sahoo [ 23/Mar/11 ]

We should use a finite timeout in waitForService call so that the process dies...

Comment by Sanjeeb Sahoo [ 05/Jul/11 ]

Happens in dev env, so reducing the priority





[GLASSFISH-16142] changing admin-listener security-enabled attribute breaks REST, GUI and cannot stop domain Created: 03/Mar/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Anissa Lam Assignee: Tim Quinn
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In v2 and v3, user just need to set the "security-enabled" attribute in 'admin-listener' to turn on security and access through https.
In 3.1, we add the "enable-secure-admin" command.
Many user is not aware of this, and couple bugs has been filed in this area. Here is the issues that one will encounter if you just change this attribute (by hand, using CLI Set or through GUI).

1. Cannot use CLI to stop the domain. you will see this:
~/Sun/v3/3.1/pb43/glassfish/bin 48) ./asadmin stop-domain
It appears that server [localhost:4848] does not accept secure connections. Retry with --secure=false.
CLI306 Warning - server is not running.
Command stop-domain executed successfully.

~/Sun/v3/3.1/pb43/glassfish/bin 59) ./asadmin --secure=false list-domains
It appears that server [localhost:4848] does not accept secure connections. Retry with --secure=false.
domain1 not running
Command list-domains executed successfully.
but the process is still running and you have to kill it manually.

2. Cannot access REST. Going to https://localhost:4848/management/domain gives a blank screen after accepting the certificate, even though the log says:
[#|2011-03-03T09:00:51.923-0800|INFO|glassfish3.1|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=17;_ThreadName=admin-thread-pool-4848(1);|Listening to REST requests at context: /management/domain|#]

3. Cannot access Admin Console. Going to https://localhost:4848 will get redirected to https://localhost:4848/j_security_check with a blank screen.

We can say it is 'user error', they shouldn't just change this attribute, should execute the 'enable-secure-admin'.
But enough user has bumped into this problem that I hope we can do something about this.

In GUI, I plan to make this checkbox read only and let user know about the 'enable-secure-admin' since changing this attribute by itself is causing error down the road.

Will it be possible NOT to allow user set this attribute independently ?
Maybe give an error and suggest using the "enable/disable secure-admin" command ?



 Comments   
Comment by Tim Quinn [ 03/Mar/11 ]

Can we change the behavior of the check-box so checking it results in the admin console sending an enable-secure-admin command and unchecking it causes the console to send a disable-secure-admin?

Presumably that's what the user wants to accomplish by securing the admin listener.

Comment by Anissa Lam [ 03/Mar/11 ]

yes, I can do what Tim suggested. That will take care of GUI user.
But I still hope this can be addressed in the config bean layer since user maybe using CLI set or REST interface to change this attribute.

Comment by Tim Quinn [ 03/Mar/11 ]

One way we might be able to handle this is for an admin config listener to reject a config transaction that includes only this one change, instead requiring that the same transaction include the other changes that go along with enable/disable-secure-admin.

The question becomes whether it's worth it? If the console behavior changes then this problem would happen, as Anissa points out, only if the user runs a set command or uses the REST interface (or manually edits domain.xml which we discourage and cannot control anyway). Do we think this will happen frequently enough to warrant the work to build an intelligent config event listener?

Comment by Tim Quinn [ 23/Mar/11 ]

Marking this for fixing in 3.2.

Need to find out if and how the transaction framework allows a listener to listen for transactions before they are final and conditionally throw an exception that is reported to the user and rolling back the transaction.

Comment by Tim Quinn [ 12/May/11 ]

From an e-mail exchange with Jerome:

o the easiest would probably to add yourself to the Transaction by being a Transactor and invoke Transaction.addTransactor() API. The canCommit() could get the list of participants and ensure proper settings but this is really complicated...

Due to the difficulty in solving this, I have lowered the priority - at least for now.





[GLASSFISH-15997] Intermittent issue : Left tree not refreshed when new elements are added/removed in IE and firefox. Created: 15/Feb/11  Updated: 12/Mar/13

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b43
Fix Version/s: 4.0

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

OS: Windows 2008, and Sparc.
Browsers : IE7, 8 and firefox 3.6


Attachments: JPEG File screenshot-1.jpg    
Issue Links:
Duplicate
is duplicated by GLASSFISH-16967 GUI does not correctly synchronize tr... Resolved
is duplicated by GLASSFISH-17230 Deleting a cluster does not refresh t... Resolved
is duplicated by GLASSFISH-18286 Regression: nodes tree not updated wi... Resolved

 Description   

Build used : GF V3.1 promoted b43.

Sometimes in IE and firefox browsers, when new elements are added, Ex: JDBC Pools, resources, new Configurations, Virtual servers, etc, the left tree node does not get refreshed, while we do see the new items in the right table. This issue is not consistently reproducible and is very intermittent. Reloading the Console solves the issue and displays the new values in the left tree node.
This issue can be documented.



 Comments   
Comment by lidiam [ 16/Feb/11 ]

This is happening very often for me. I think it depends how long Admin Console is in use. The bad thing is that once I remove an element, e.g. a cluster, it is not removed from the nodes tree. I can still click on it there and get the following error:

An error has occurred
The target, c1, is not an instance, cluster, domain, node or config.

I'll attach a screenshot for that.

Once this problem starts, it does not go away till the url is reloaded.

Comment by Anissa Lam [ 14/Mar/11 ]

Summary and workaround:

This issue is not consistently reproducible and is very intermittent. Reloading the Console by pressing the Home button or browser's reload button solves the issue and displays the new values in the left tree node.

Comment by Scott Fordin [ 13/Apr/11 ]

Added issue to 3.1 Release Notes.

Comment by shaline [ 08/Nov/11 ]

I still see this issue on GF 3.1.2 promoted and nightly builds. This issue shows up if the Admin Console is used for quite sometime, and then any new elements added like resources, network listeners, virtual servers, realms, clusters, instances etc , do not show up in the left tree. Even the deleted elements does not get deleted from the left tree. We have to use the browser's reload button for this problem to go away.

Comment by Anissa Lam [ 12/Feb/13 ]

Issues need to be addressed before 4.0 HCF (3/25)

Comment by Anissa Lam [ 12/Mar/13 ]

This is Intermittent with easy work around.
We will continue release notes this. The work around is to click the Home button and the tree should be refreshed correctly.





[GLASSFISH-15989] Properties: creating property with empty value succeeds but does not save Created: 15/Feb/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 4.0

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

promoted build b43


Tags: 3_1-exclude

 Description   

Steps to reproduce:

1. Create a cluster.
2. Go to the new cluster, Properties tab.
3. Click Add Property and enter name but nothing for value. Hit Save. The "New values successfully saved" message appears but the property disappears from the table and is not saved.

This happens for system and cluster properties.






[GLASSFISH-15979] @ManagedBean-annotated interface creates NPE on deploy Created: 14/Feb/11  Updated: 14/Dec/11

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

Type: Bug Priority: Minor
Reporter: Alexis MP Assignee: Hong Zhang
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File ManagedInterface.war    
Tags: 3_1-exclude, 3_1_2-exclude

 Description   

Note sure the spec allows for this but is an interface is marked with @javax.annotations.ManagedBean, it'll fail at deploy time with the following NPE :

[#|2011-02-14T23:36:17.315+0100|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=48;_ThreadName=AutoDeployer;|nullat org.glassfish.apf.AnnotationInfo@139f0bb
java.lang.IllegalStateException: nullat org.glassfish.apf.AnnotationInfo@139f0bb
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:490)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:408)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:216)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:180)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:359)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:145)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:577)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:463)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:395)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:380)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:213)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: nullat org.glassfish.apf.AnnotationInfo@139f0bb
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445)
... 27 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.annotation.handlers.ManagedBeanHandler.getMethodForMethodAnnotation(ManagedBeanHandler.java:292)
at com.sun.enterprise.deployment.annotation.handlers.ManagedBeanHandler.processAnnotation(ManagedBeanHandler.java:133)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
... 33 more

#]

[#|2011-02-14T23:36:17.320+0100|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=48;_ThreadName=AutoDeployer;|Exception while deploying the app [ManagedInterface] : nullat org.glassfish.apf.AnnotationInfo@139f0bb
nullat org.glassfish.apf.AnnotationInfo@139f0bb
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:606)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:445)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:432)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:408)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:383)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:246)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:255)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:216)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:180)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:93)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:826)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:768)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:368)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:359)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:145)
at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:577)
at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:463)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:395)
at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:380)
at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:213)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.lang.NullPointerException
at com.sun.enterprise.deployment.annotation.handlers.ManagedBeanHandler.getMethodForMethodAnnotation(ManagedBeanHandler.java:292)
at com.sun.enterprise.deployment.annotation.handlers.ManagedBeanHandler.processAnnotation(ManagedBeanHandler.java:133)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
... 33 more

#]

Easy to reproduce. Attaching WAR sample.
In any case with the default INFO level, the deployment should fail with a meaningful error message, at least with the annotation and class names it failed to deploy.



 Comments   
Comment by Hong Zhang [ 14/Feb/11 ]

I am not too familar with managed bean (but not sure who owns managed bean now) so I will take an initial look to see what I can find.
I am going to add the 3_1-exclude tag at this point of 3.1 release cycle as it did not seem like a 3.1 show stopper.

Comment by Cheng Fang [ 15/Feb/11 ]

@ManagedBean cannot be applied to inteface, since ManagedBean is intended to be a light-weight foundation component. For cases where interface is needed, use @EJB instead. Quote from Managed Bean spec:

MB.2.1.1 Component Definition
A Managed Bean can be declared by annotating its class with the
javax.annotation.ManagedBean annotation.
A Managed Bean must not be: a final class, an abstract class, a non-static
inner class.
-----------

Even if @ManagedBean is correctly applied to a class, the test war is still invalid since there is no web/ejb components.

Comment by Alexis MP [ 15/Feb/11 ]

Please consider reporting the annotation and class name responsible for the failure.

Comment by Hong Zhang [ 14/Dec/11 ]

As we still don't have a clear owner for the ManagedBean at this point, we will have to defer this to a later release.





[GLASSFISH-15941] restart-local-instance times-out when restarting instance that fails to start Created: 10/Feb/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1_b41
Fix Version/s: 4.0

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

ogs-3.1-web-b41.zip


Attachments: Text File das.server.log     Text File instance.server.log    
Tags: 3_1-exclude

 Description   

Steps to reproduce:

1. Create a standalone instance, in1 and start it.
2. Create a life cycle module for instance in1 and mark "On Load Failure: Prevent Instance Startup" to true in Admin Console.
3. Either from command line or Admin Console restart the instance - they both hang.

Instance's server.log reports correctly that instance cannot be started with reason.

The workaround is to refresh the browser for Admin Console and hit Ctrl-C to kill the command for CLI. Since workaround exists this is most likely not a show stopper for v3.1.



 Comments   
Comment by lidiam [ 10/Feb/11 ]

Forgot to mention in the second step above to enter non existent class name, when creating the lifecycle module.

Comment by lidiam [ 10/Feb/11 ]

An earlier, blocking issue in this area was http://java.net/jira/browse/GLASSFISH-14600.

Comment by Tom Mueller [ 10/Feb/11 ]

This appears to be a problem in the restart-local-instance command.

If the instance is stopped first with stop-instance, and then started with start-instance, the start-instance command detects the failure to start and returns control to the user. However, if the instance is restarted using restart-instance or restart-local-instance, the command hangs until the 10 minute timeout. Since restart-instance calls restart-local-instance, the problem is likely to be in restart-local-instance.

Since there is a workaround, excluding this for 3.1.

Comment by Byron Nevins [ 22/Mar/11 ]

Details please. What precise series of commands need to run? I have no idea how to work with lifecycle modules.

Almost certainly the problem is in the innards of GlassFish - not in restart-local-instance. It is simply sitting there waiting for the server to be up & running and accepting commands.

If the new server becomes a Zombie and refuses to die cleanly (which is the overwhelmingly common case) it is impossible for restart to know that – it just quietly waits and waits and waits.

Reassigning to Tom to get reassigned to LifeCycle folks. They need to simply cleanly kill the process. There is nothing that local command can do about it.

Comment by Tom Mueller [ 24/Mar/11 ]

The lifecycle module handling is already correct. The server exits correctly when it is restarted with a bad lifecycle module. The problem is that restart-local-instance doesn't detect that the server has exited and instead waits around 10 minutes for the server to start.

Here are the commands to reproduce the problem:

asadmin start-domain
asadmin create-local-instance i1
asadmin start-instance i1
asadmin create-lifecycle-module --target i1 --classname foo.Bar --failurefatal=true abc
asadmin restart-local-instance i1

Before running this last command, run tail -f on the instance's log.
You'll see that it exits, restarts, and then initiates a shutdown because the foo.Bar class wasn't found. However, the restart-local-instance command is sitting there waiting for 10 minutes for the instance to come up.

To see how the restart-local-instance should work, run stop-local-instance followed by start-local-instance instead.

Comment by Byron Nevins [ 24/Mar/11 ]

Impossible to fix this in the client. At least I don't see any way of doing it.

The server is exiting before the HTTP listeners are running. That is the ONLY way the client can talk to the server. Since we can't prove a negative all we can do is hang around and wait with a timeout. I.e. we can't tell the difference between slow start and no start.

The Lifecycle module could potentially solve this by dropping a signal file of some kind in the config directory. Then the client can scan for this "I couldn't start!" file and exit right away. I would avoid such a kludge, it's hard to get just right and this is an *EXTREMELY* obscure use-case. I don't think it's worth the money to solve. At any rate – the bug would need to go to the lifecycle team to implement that, once that's done the client can be changed.

So – I'm reassigning back to Tom for disposal. If you can figure out how the client can do this on its own – reassign to me.

Comment by Byron Nevins [ 24/Mar/11 ]

I now understand the problem completely.

here is the algorithm for determining if/when the instance restarts:

1) if pidfile exists == exit with success
2) if the spawned process exited == exit with error
3) if the timeout elapsed == exit with error
4) goto 1

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

start-local-instance obviously has a handle to the spawned process
restart-local-instance doesn't have the handle – and can not have the handle. It can NOT do check #2 above

– why? r-l-i is in process #1 which calls the running instance, process #2, which spawns a new asadmin client in process #3. It is impossible for process #1 to "see" process #3

Solution:
I don't know if it is worth it. It doesn't give any new info compared to timing out and/or killing the client and seeing that the instance didn't start.

But this is how to do it:

Process #3 detects that the spawned process #4 exited prematurely. It communicates with process #1 by writing a -10 into the pid file.
Process #1 looks for the pid file, as usual, and also looks INSIDE it for -10. If it sees -10 it deletes the pid file and exits with an error message.

Comment by Tom Mueller [ 24/Mar/11 ]

As you have by now realized, this situation can happen when the server doesn't restart for any reason at all, not just due to this particular lifecycle module issue. So the situation may not be that rare.

In addition to writing the failure code, one could also have process #3 write the output from process #4 to the file, so that process #1 could write it to its output, so the user would see the same output as when running start-local-instance. This would only help for the local case, i.e., it wouldn't work for restart-domain when run remotely. But for the remote case, we don't have any choice but to wait for the timeout.

BTW, restart-domain has this same problem.

Comment by Byron Nevins [ 25/Mar/11 ]

Changed the summary. It is not a hang. It is a super-long timeout. The length of which was decided by committee.

Comment by Byron Nevins [ 01/Apr/11 ]

This is not a crucial issue. restart server commands are designed as a wonderful way of remotely restarting the servers. It was not designed for this sort of exhaustive complex inter-process platform-specific stuff. Any user that runs into a ONE-TIME problem like this will follow-up the restart command with the corresponding start command. He has to – the server is dead, he has no choice. Then he will get the information from the start command. He will NATURALLY follow this route. Note that the user DID shoot himself in the foot – not us.

This is a nice-to-have for completeness but the cost == very high, risk = medium, benefit = minimal.





[GLASSFISH-15882] Error if one endpoint property is specified Created: 07/Feb/11  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b41
Fix Version/s: 4.0

Type: Bug Priority: Trivial
Reporter: Scott Oaks Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Running a standalone client (e.g, not using appclient) with these options:
-Dcom.sun.appserv.iiop.endpoints=localhost:3700

results in this error:

java.lang.IllegalArgumentException: n must be positive
at java.util.Random.nextInt(Random.java:250)
at com.sun.enterprise.naming.impl.RoundRobinPolicy.getNextRotation(RoundRobinPolicy.java:356)
at com.sun.enterprise.naming.impl.SerialInitContextFactory.getInitialContext(SerialInitContextFactory.java:334)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at org.spec.jent.driver.Driver.<init>(Driver.java:55)

For single-instance access, we can work around this and not use the endpoints property, but the system should be more robust than this.






[GLASSFISH-15803] GUI console and instance are not available after http-listener-1.port is changed into 4848 Created: 02/Feb/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1_b38
Fix Version/s: 4.0

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

Windows



 Description   

I changed setting configs.config.server-config.network-config.network-listeners.network-listener.http-listener-1.port=4848 via GUI admin console and after that GUI console is not available and GF instance as well. Why is it possible to change the port to already occupied with process one?



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

The enforcement of not assigning conflicting port # will need to happen at the backend.
Assigning to 'admin'.

Comment by Tom Mueller [ 18/Feb/11 ]

Validation of network listener config changes happens within Grizzly.
Assigning to the grizzly category.

Comment by oleksiys [ 18/Feb/11 ]

reassigning to Justin.





[GLASSFISH-15765] Letters are accepted as ssh port number when creating a node on localhost Created: 31/Jan/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b39
Fix Version/s: 4.0

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

promoted build b39



 Description   

User can enter letters for SSH port number on Create Node screen, when creating a node on localhost. However, user can successfully create and start an instance on a localhost node that has letters specified for SSH port number. Proper error is displayed when host is remote, hence this is a minor issue. Edit node screen also accepts letters for SSH port number when node host is localhost.






[GLASSFISH-15581] ssl2-enabled attribute on the ssl config element should be deprecated or removed Created: 14/Jan/11  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Tags: 3_1_x-exclude

 Description   

Currently the ssl element in the domain.xml exposes an attribute called ssl2-enabled. This attribute has no real impact on the runtime (at least with the Sun and Apple JDKs) as ssl2 isn't supported by JSSE.

This has two main points of impact:
1) grizzly-config
2) documentation

We need to come to a final decision on deprecation or removal and take the approriate actions on each item.






[GLASSFISH-15437] [UB]Cannot start DAS when custom container has a class called Domain Created: 04/Jan/11  Updated: 15/Mar/13

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

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

Ubuntu 10.04,
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Server VM (build 19.0-b09, mixed mode)


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

 Description   

I'm developing a custom container. It was working fine. I rename one of my class to Domain. I repackaged it. I then copied my container's jar to$GF_HOME/glassfish/modules.

When I tried to start GF, I got

Waiting for DAS to start.......

This goes on for a while then GF says it could not start my domain. Anyway I then renamed the Domain class to something else. Rebuild and recopied the file to modules directory and GF started.



 Comments   
Comment by Nazrul [ 05/Jan/11 ]

Jerome: Should this be documented?

Comment by Nazrul [ 10/Jan/11 ]

Excluding from 3.1 list.

Comment from Jerome:
Looks like folks should not use any of our [GlassFish] configuration names or should use a @configured(name="myspecialname") annotations to disambiguate.

Comment by scatari [ 11/Jun/11 ]

To be considered in the next release.

Comment by Tom Mueller [ 24/Dec/12 ]

Changing this to be a docs bug. The section on extending the configuration of the system should be modified to specify that any new config element must have a unique name, i.e., the name of just the class has to be unique, not just the name including the Java package name.

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 4.0 so this issue gets picked up by OSE 4.0 release queries.





[GLASSFISH-15223] Unable to lookup a DataSource in OSGi bundle activator while deploying using --type=osgi Created: 15/Dec/10  Updated: 02/Dec/11

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

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

Attachments: Java Archive File osgi-jndi-test1.jar    
Tags: 3_1-exclude

 Description   

PFA s simple osgi bundle that does the following in its activator:

public void start(BundleContext ctx) throws Exception

{ Context ic = new InitialContext(); DataSource ds = (DataSource)ic.lookup("jdbc/__default"); Connection c = ds.getConnection(); System.out.println(c); c.close(); }

Run "asadmin deploy --type=osgi osgi-jndi-test1.jar" and you will see the exception mentioned in [1]. The root cause is that when osgi bundle is deployed using --type=osgi, we create an application with null classloader, because we expect the classloading to be handled by OSGi framework. The relevant code is:

public class OSGiDeployedBundle implements ApplicationContainer<OSGiContainer> {
public ClassLoader getClassLoader()

{ return null; }

}

Because of this null class loader, the following code throws an exception:

public ObjectInputStreamWithLoader(InputStream in, ClassLoader loader)
throws IOException, StreamCorruptedException {

super(in);
if (loader == null)

{ throw new IllegalArgumentException("Illegal null argument to ObjectInputStreamWithLoader"); }

this.loader = loader;
}

The fix would be to set some dummy classloader or a wrapped classloader for osgi bundles deployed like this. I am classifying this as a minor issue, because user can workaround the issue by deploying in autodeploy/bundles/ dir.

[1]

[#|2010-12-16T09:12:37.452+0530|SEVERE|glassfish3.1|com.sun.enterprise.naming|_ThreadID=84;_ThreadName=admin-thread-pool-4848(2);|enterprise_naming.excep_in_copymutableobj
java.lang.IllegalArgumentException: Illegal null argument to ObjectInputStreamWithLoader
at com.sun.enterprise.naming.util.ObjectInputStreamWithLoader.<init>(ObjectInputStreamWithLoader.java:69)
at com.sun.enterprise.naming.util.OSGiObjectInputOutputStreamFactoryImpl$OSGiObjectInputStream.<init>(OSGiObjectInputOutputStreamFactoryImpl.java:152)
at com.sun.enterprise.naming.util.OSGiObjectInputOutputStreamFactoryImpl.createObjectInputStream(OSGiObjectInputOutputStreamFactoryImpl.java:138)
at com.sun.enterprise.naming.util.NamingUtilsImpl.makeCopyOfObject(NamingUtilsImpl.java:112)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.rebind(LocalSerialContextProviderImpl.java:113)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:746)
at com.sun.enterprise.naming.impl.SerialContext.rebind(SerialContext.java:763)
at javax.naming.InitialContext.rebind(InitialContext.java:412)
at javax.naming.InitialContext.rebind(InitialContext.java:412)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:206)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:189)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:238)
at com.sun.enterprise.connectors.service.ResourceAdapterAdminServiceImpl.createActiveResourceAdapter(ResourceAdapterAdminServiceImpl.java:347)
at com.sun.enterprise.connectors.ConnectorRuntime.createActiveResourceAdapter(ConnectorRuntime.java:355)
at com.sun.enterprise.connectors.service.ConnectorService.loadDeferredResourceAdapter(ConnectorService.java:183)
at com.sun.enterprise.connectors.service.ConnectorService.loadResourcesAndItsRar(ConnectorService.java:147)
at com.sun.enterprise.connectors.service.ConnectorService.checkAndLoadPool(ConnectorService.java:324)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:100)
at com.sun.enterprise.connectors.ConnectorRuntime.createConnectorResource(ConnectorRuntime.java:295)
at com.sun.enterprise.resource.deployer.JdbcResourceDeployer.deployResource(JdbcResourceDeployer.java:106)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:90)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:548)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at Activator.start(Activator.java:9)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1822)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1739)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.resume(OSGiDeployedBundle.java:83)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.start(OSGiDeployedBundle.java:62)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:372)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

#]

[#|2010-12-16T09:12:37.454+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|_ThreadID=84;_ThreadName=admin-thread-pool-4848(2);|RAR8061: failed to load resource-adapter-config or RA [ __ds_jdbc_ra ], com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Cant copy Serializable object:|#]

[#|2010-12-16T09:12:37.461+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|ThreadID=84;_ThreadName=admin-thread-pool-4848(2);|RAR8060: Unable to lookup pool [ DerbyPool ], javax.naming.NamingException: Lookup failed for '_SYSTEM/pools/DerbyPool' in SerialContext[targetHost=null,targetPort=null [Root exception is javax.naming.NameNotFoundException: pools]|#]

[#|2010-12-16T09:12:37.461+0530|SEVERE|glassfish3.1|javax.enterprise.resource.resourceadapter.com.sun.enterprise.connectors.service|ThreadID=84;_ThreadName=admin-thread-pool-4848(2);|RAR6017 : Failed to get connection pool object jdbc/default via JNDI lookup : com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Lookup failed for '_SYSTEM/pools/DerbyPool' in SerialContext[targetHost=null,targetPort=null|#]

[#|2010-12-16T09:12:37.462+0530|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=84;_ThreadName=admin-thread-pool-4848(2);|Exception while invoking class org.glassfish.extras.osgicontainer.OSGiDeployedBundle start method
org.osgi.framework.BundleException: Activator start error in bundle osgijndi.test1 [255].
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1869)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1739)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.resume(OSGiDeployedBundle.java:83)
at org.glassfish.extras.osgicontainer.OSGiDeployedBundle.start(OSGiDeployedBundle.java:62)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:130)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:290)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:372)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:453)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:220)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:817)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:718)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1007)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.naming.NamingException: Lookup failed for 'jdbc/_default' in SerialContext[targetHost=null,targetPort=null [Root exception is javax.naming.NamingException: Unable to lookup resource : jdbc/default [Root exception is com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Lookup failed for '_SYSTEM/pools/DerbyPool' in SerialContext[targetHost=null,targetPort=null]]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:561)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at Activator.start(Activator.java:9)
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1822)
... 34 more
Caused by: javax.naming.NamingException: Unable to lookup resource : jdbc/_default [Root exception is com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Lookup failed for '_SYSTEM/pools/DerbyPool' in SerialContext[targetHost=null,targetPort=null]
at org.glassfish.javaee.services.ResourceProxy.throwResourceNotFoundException(ResourceProxy.java:119)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:95)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:548)
... 40 more
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Lookup failed for '__SYSTEM/pools/DerbyPool' in SerialContext[targetHost=null,targetPort=null
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:149)
at com.sun.enterprise.connectors.ConnectorRuntime.createConnectorResource(ConnectorRuntime.java:295)
at com.sun.enterprise.resource.deployer.JdbcResourceDeployer.deployResource(JdbcResourceDeployer.java:106)
at org.glassfish.javaee.services.ResourceProxy.create(ResourceProxy.java:90)
... 41 more
Caused by: javax.naming.NamingException: Lookup failed for '__SYSTEM/pools/DerbyPool' in SerialContext[targetHost=null,targetPort=null [Root exception is javax.naming.NameNotFoundException: pools]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:561)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:223)
at com.sun.appserv.connectors.internal.api.ResourceNamingService.lookup(ResourceNamingService.java:230)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.createConnectorResource(ConnectorResourceAdminServiceImpl.java:109)
... 44 more
Caused by: javax.naming.NameNotFoundException: pools
at com.sun.enterprise.naming.impl.TransientContext.resolveContext(TransientContext.java:307)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:215)
at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:216)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:77)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:119)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:545)
... 50 more

#]

[#|2010-12-16T09:12:37.495+0530|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=84;_ThreadName=admin-thread-pool-4848(2);|Exception while loading the app|#]

[#|2010-12-16T09:12:37.503+0530|INFO|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=84;_ThreadName=admin-thread-pool-4848(2);|Uninstalled osgijndi.test1 [255]|#]






[GLASSFISH-15210] [PERF] Regression (Rel. v2.1) in IORFactories.makeIOR Created: 15/Dec/10  Updated: 03/Dec/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1_b32
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Scott Oaks Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: PSRBUG

 Description   

With the latest builds, the total regression in the orb copyObject is significantly reduced, but

The current largest contributor to that is IORFactories.makeIOR(), which takes >2x longer in 3.1 than in 2.1 and accounts for 4.5% of total time in our testing. In both releases, EncapsulationFactoryBase.create() is the main component taking the time (and from the, code code appears to be somewhat recursive with a loop back to EncapsulationFactoryBase.create(), so the time attribution below that in current profiles can't be traced).



 Comments   
Comment by Ken Cavanaugh [ 15/Dec/10 ]

Most of the IOR code has been touched for years, certainly since well before v2.1.1. The only new bit is in
the addition of the direct support for the ClusterInstanceInfo component, which is used for IIOP FOLB.
The ORB has not changed much from 2.1.1 to 3.1 for FOLB support, but this is one change. It is possible that
the difference is that this used to be read as a generic tagged component (that is, just a byte[] which is
a GIOP encapsulation), but now it is fully unmarshaled. This may make a difference, because the
tagged component may be getting completely unmarshaled all the time, instead of just when actually needed.

I don't think I can go back to the old model at this point. Ideally I'd prefer to use a lazy unmarshaling model,
where the data is held as a byte[] and only unmarshalled as needed.

If this is the problem, I'd expect to see some activity in the profile in two classes:

  • com.sun.corba.ee.impl.folb.ClusterInstanceInfo
  • com.sun.corba.ee.impl.folb.SocketInfo

The constructors for these two classes do several read_string and read_long calls to the InputStream,
so it might be possible to see some activity in the profile showing this, even if the calls are at
a relatively low frequency. ORB marshalling produces flat profiles, with a lot of calls that individually
don't take much time to things like read_long and read_string.

It is also possible that the underlying InputStream (CDRInputStream_1_0) has gotten slower, but I don't
think that's the case here. Most of the code has seen little change, other than the ORB tracing facility,
but the instrumented methods basically add just a couple of if (mm == null)

{ skip to method }

kinds of calls, which should be << 1% of the execution team, even for small methods.

If further analysis of the profile suggests that the ClusterInstanceInfo is the problem, I'll need to
investigate making unmarshaling lazy, but I don't yet know how difficult that would be.

Comment by Ken Cavanaugh [ 15/Dec/10 ]

If lazy unmarshaling would help, it can be done as follows:

  • Modify IIOPFactories.makeClusterInstanceInfoComponentFactory to pass the InputStream directly to the
    ClusterInstanceInfoComponentImpl constructor instead of unmarshaling it in the ClusterInstanceInfo
    constructor.
  • Add a constructor for ClusterInstanceInfoComponentImpl that takes an input stream. It stores the input
    stream in a private data member.
  • With appropriate synchronization, do the unmarshaling into the current clusterInstanceInfoValue field
    whenever necessary, which is basically when the field is null at the beginning of a call to
    writeContents, equals, hashCode, toString, or getClusterInstanceInfo.

Let me know if you think this fix is worth trying.

Comment by Ken Cavanaugh [ 21/Dec/10 ]

After discussion with Scott on 12/20, it appears that the regression is fixed,
so this fix is not needed in GF 3.1. Moving to 3.2/P4.





[GLASSFISH-14829] GlassFishORBFactory.getIiopEndpoints should always return a valid string Created: 20/Nov/10  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Tim Quinn Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 14,829
Tags: 3_1-exclude

 Description   

Ken reported in e-mail that the current implementation will fail if invoked from
a server that is not a cluster member.

The method should work in either case. If the current server is not in a
cluster then the return value should be the endpoint for the current server.



 Comments   
Comment by Ken Cavanaugh [ 13/Dec/10 ]

I'm moving this to the next release, as I've run out of time to fix it in
MS7, and I don't think it meets the criteria for MS8.





[GLASSFISH-14347] (UC) I can't run updatetool, due to some PYTHON bug Created: 02/Nov/10  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: update_center
Affects Version/s: V3
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Yegor Bugayenko Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 14,347

 Description   

This is what I'm getting:

/opt/local/share/java/glassfishv3/updatetool/bin$ sudo ./updatetool
Unable to block on application (GetProcessPID() returned 18446744073709551016)
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "/opt/local/share/java/glassfishv3/updatetool/bin/../vendor-packages/updatetool/main.py", line
426, in ?
main(sys.argv[1:])
File "/opt/local/share/java/glassfishv3/updatetool/bin/../vendor-packages/updatetool/main.py", line
51, in main
from common.boot import uc_error, init_app_locale, check_ips
File "/opt/local/share/java/glassfishv3/updatetool/vendor-packages/updatetool/common/boot.py",
line 42, in ?
import gettext
ImportError: No module named gettext

Where is a problem and how can I solve it? Thanks.



 Comments   
Comment by Bobby Bissett [ 02/Nov/10 ]

Switching over to update subcategory. (Happens all the time.)

Comment by Snjezana Sevo-Zenzerovic [ 02/Nov/10 ]

Could you please provide exact platform you use and which GlassFish version is this?

Comment by Yegor Bugayenko [ 02/Nov/10 ]

It's MacOS Darwin 10.6, Glassfish 3.0. Maybe this information will be helpful:

$ sudo port list glassfish* and installed
glassfishv3 @3 java/glassfishv3

$ sudo port list python* and installed
python24 @2.4.6 lang/python24
python24 @2.4.6 lang/python24
python26 @2.6.6 lang/python26
python_select @0.3 sysutils/python_select
python_select @0.3 sysutils/python_select

Comment by Joe Di Pol [ 13/Dec/10 ]

FYI, I've run updatetool 2.3u2 on MacOS 10.6.5 without a problem and that's consistent with what we see in our repository access data (many hits from MacOS 10.6). The gettext module is definitely include in the python runtime bundled with Update Center. What happens if you do:

/opt/local/share/java/glassfishv3/pkg/python2.4-minimal/bin/python
Python 2.4.5 (#17, Aug 7 2009, 12:39:30)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gettext

Comment by Snjezana Sevo-Zenzerovic [ 21/Dec/10 ]

Based on Joe's analysis this seems to be environment issue. Targeting for future release.





[GLASSFISH-14009] Investigate using JDK support to generate SSH keys Created: 15/Oct/10  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0

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

Operating System: All
Platform: All


Issuezilla Id: 14,009

 Description   

setup-ssh currently uses ssh-keygen to generate SSH keys. Apparently the JDK has
support for generating RSA and DSA keys. We should investigate this and test if
those keys work with SSH.






[GLASSFISH-13831] setup-ssh: update known_hosts file Created: 06/Oct/10  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Joe Di Pol Assignee: Yamini K B
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 13,831

 Description   

In the ASArch meeting there was a request that setup-ssh should also update the
user's known_hosts file so that running the ssh(1) later would not prompt the
user (asking if the host is trusted). Note this is not needed for
create-node-ssh to work, since it adds the host as a known host to it's
in-memory host list. This only impacts the first use of ssh(1).

There was a dissenting opinion that setup-ssh should not do this – it should
only do the bare minimum for GlassFish.






[GLASSFISH-13552] deploy error not as clear as with GFv2.1.1 when no class found Created: 20/Sep/10  Updated: 02/Dec/11

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

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

Operating System: Windows XP
Platform: All


Attachments: File is_classloader-web.war    
Issuezilla Id: 13,552

 Description   

I'm comparing deployment error messages in GFv3.1 and GFv2.1.1.
In this WS app, a class is missing.

On glassfish-3.1-b21-09_17_2010, the error message has four exception class
names but nothing related to a user class missing:

D:\GFv3.1\glassfish-3.1-b21-09_17_2010\glassfishv3>bin\asadmin deploy
\is_classloader-web.war
remote failure: Error occur during deployment: Exception while loading the app :
java.lang.IllegalStateException: ContainerBase.addChild: st
art: org.apache.catalina.LifecycleException:
org.apache.catalina.LifecycleException: javax.servlet.ServletException. Please
see server.log f
or more details.

Command deploy failed.

The server log has many stacktraces with one having a NoClassDefFoundError with
the missing class name in its 'caused by' part.

On GFv2.1.1 the missing class name is included in the initial error message:

D:\GFv2.1.1\glassfish-v2.1.1-b22\glassfish>bin\asadmin deploy
\is_classloader-web.war
CLI171 Command deploy failed : Deploying application in domain failed;
annotations/server/common/AddNumbersCommon

The server log here has only three error messages, all clearly indicating the
missing class name and the fact that it could not be loaded.



 Comments   
Comment by Dies Koper [ 20/Sep/10 ]

Created an attachment (id=4925)
test app

Comment by Hong Zhang [ 21/Sep/10 ]

Yes, from tracing the code, this part of the code paths have changed so the
exception got thrown at a different place (therefore different stack traces and
different error messages).

I will check with webservices team to see why the code paths have changed, but
this is something we may not be able to change.

I do see this exception in the very beginning of the first stack trace of my
server.log though when I deployed it to 3.1:

[#|2010-09-21T09:25:52.549-
0400|WARNING|glassfish3.1|javax.enterprise.webservices.org.glassfish.webservices

_ThreadID=14;_ThreadName=Thread-1; Servlet web service endpoint 'j2w_base'
failure
java.lang.NoClassDefFoundError: annotations/server/common/AddNumbersCommon
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.glassfish.webservices.JAXWSServlet.registerEndpoint
(JAXWSServlet.java:292)
at org.glassfish.webservices.JAXWSServlet.doInit(JAXWSServlet.java:274)
at org.glassfish.webservices.JAXWSServlet.init(JAXWSServlet.java:109)
at org.apache.catalina.core.StandardWrapper.initServlet
(StandardWrapper.java:1427)
at org.apache.catalina.core.StandardWrapper.load
(StandardWrapper.java:1229)
at org.apache.catalina.core.StandardContext.loadOnStartup
(StandardContext.java:5045)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:5337)
at com.sun.enterprise.web.WebModule.start(WebModule.java:497)
at org.apache.catalina.core.ContainerBase.addChildInternal
(ContainerBase.java:917)
at org.apache.catalina.core.ContainerBase.addChild
(ContainerBase.java:901)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:697)
at com.sun.enterprise.web.WebContainer.loadWebModule
(WebContainer.java:1929)
at com.sun.enterprise.web.WebContainer.loadWebModule
(WebContainer.java:1606)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:100)
...
Comment by Dies Koper [ 22/Sep/10 ]

I found the NoClassDefFoundError with the class name in my old logs as first
message. Must have missed it the first time. So there is enough info in server.log.

This issue can focus on the (lack of useful) details in the CUI error message.

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 10/Dec/10 ]

I took a look at this again today, there is not much we can do (the message is different as the code path has changed). As the error message is pointing to the server.log where the cause could be found, I am going to downgrade the bug and revisit in the future release if needed.





[GLASSFISH-13021] simultaneous start-instance commands fail Created: 18/Aug/10  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: admin
Affects Version/s: 3.1
Fix Version/s: 4.0

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

Operating System: All
Platform: All


Issue Links:
Dependency
blocks GLASSFISH-4357 SYNC-005: Scale the cluster size to a... Resolved
Issuezilla Id: 13,021

 Description   

If multiple start-instance commands which use SSH are executed in parallel, most (or all) of them fail to start
the instance. After setting up a cluster with multiple instances using an SSH node, the following command
recreates the problem:

for i in 1 2 3 4 5 6 7 8 9 10; do asadmin start-instance i1-1-$i </dev/null >logs/1/i1-1-$

{i}

.log 2>&1 & done;
time wait; grep -i fail logs/1/*

Some commands output the following:

remote failure: Timed out waiting for i1-1-1 to start.

Command start-instance failed.

Others produce this:

java.net.SocketException: Unexpected end of file from server
Command start-instance failed.

The server.log file contains the following messages:
[#|2010-08-18T10:47:33.985-0700|INFO|glassfish3.1|null|_ThreadID=14;_ThreadName=Thread-1;|CLI802 Synchronization
failed for directory config|#]

[#|2010-08-18T10:47:33.985-0700|INFO|glassfish3.1|null|_ThreadID=14;_ThreadName=Thread-1;|Command start-local-
instance failed.|#]

NOTE: this problem DOES NOT occur if start-local-instance is used. Also, this problem does not occur if start-
instance is used where the node for the instance is a config node (rather than an SSH) node.

This problem DOES occur for both instances that are on the same host as the DAS and for instances that are on a
host different from the DAS.



 Comments   
Comment by Tom Mueller [ 18/Aug/10 ]

Update on this (determined by turning on the log messages):

For the case where the instance has an SSH node, but the node is local to the
DAS, the start-instance code is correctly determining that the node is local and
it is invoking start-local-instance without using SSH. But the failure is still
there. So this problem is not strictly limited to the SSH case. However, I have
yet to see the failure when using a config node rather than an SSH node.

In summary:
start-local-instance - never fails
start-instance on local config nodes - never fails
start-instance on local SSH nodes - fails
start-instance on remote SSH nodes - fails

Comment by Tom Mueller [ 18/Aug/10 ]

Another update...

It turns out that start-instance with local config nodes does fail also. So at
least the behavior is consistent - start-instance is failing with all types of
instances that I've tried. It is start-local-instance that doesn't fail when
started directly.

Comment by Tom Mueller [ 18/Aug/10 ]

This problem is partially due to the default size (5) of the thread pool that is used for servicing admin
requests. If 5 or more start-instance commands are run simultaneously, there are no threads to process
the _synchronize-files requests that are generated by starting the instances.

If the thread pool size is increase, say to 200, then a different error results:

Exception while processing command: org.jvnet.hk2.component.ComponentException: problem initializing -
cycle detected involving: com.sun.hk2.component.SingletonInhabitant@2cec33
Closest matching local and remote command(s):
restart-instance
start-instance
Command start-instance failed.

Comment by Tom Mueller [ 19/Aug/10 ]

I haven't been able to reproduce the initialization problem that was reported in
the last comment. So let's use this issue to focus on what to do about the small
default value (5) for the admin thread pool and whether start-instance needs to be
aware of the thread pool size.

Comment by carlavmott [ 14/Sep/10 ]

I'm still trying to find a way to get the number of threads used currently from
grizzly. What I have found is that there are only probe listeners that maybe
provide this info. I'm still working with the grizzly folks.

Comment by carlavmott [ 27/Sep/10 ]

I have checked with the grizzly team and there is no API for finding the number
of busy or available threads. Also we talked about using the probes but think
that will not work. At this point I don't think there is anything I can do at
the command level. Waiting for feedback on this topic from Jerome.

Comment by carlavmott [ 05/Oct/10 ]

this bug is being down graded because it happens less often now that the thread
pool size is larger and the command start-cluster can start instances. I'm
including all notes from discussions here so we don't lose the work that has
been done. Wiki page is located at:

http://wikis.sun.com/display/GlassFish/AdminCustomThreadPool

The important notes from the wiki follow:

The following proposal will allievate the problem and allow commands like
start-instance to run in parallel successfully regardless of the number of
instances the user is trying to start in parallel. We specifically don't want an
unbounded thread pool as that could be a security breach. Therefore, we want to
release the grizzly thread so it doesn't wait for a long running command to
complete while still waiting for the initial command to complete before
returning execution. This is done by using a custom thread pool in the
AdminAdapter code.

  • Add a new annotation for commands like start-instance. The new annotation
    is called @UseThreadPool(name="pool-name"). A new thread pool will be declared
    within the "server-config".
  • AdminAdapter will access this new thread pool.
  • The original thread that was servicing the command will have the grizzly
    context and will call grizzlyResponse.suspend() to signal to grizzly that the
    thread can be returned to the thread pool.
  • A new thread from the thread pool will be used to execute the command.
  • When processing is complete the new thread calls resumes on grizzly using
    grizzlyResponse.resume();
  • AdminAdapter code is still responsible for building the Action Report with
    the results of the command

Here is some pseudo-code based on what Alexey sent:

static class AdminAdapter extends GrizzlyAdapter {

@Override
public void service(final GrizzlyRequest grizzlyRequest,
final GrizzlyResponse grizzlyResponse) {

// get the command, check if it is annotated with @UseThreadPool
if (annotated) {
grizzlyResponse.suspend(); // Suspend response here
threadpool = get thread pool named in annotation

threadpool.execute(new Runnable() { // Run task in the separate
thread

@Override
public void run() {
try

{ doCommand(....); // run the command the same way it is normally run, but in a different thread // write the response (same code that is at the end of AdminAdapter.service() ) }

catch (IOException e) {
} catch (InterruptedException e) {
} finally

{ grizzlyResponse.resume(); // finish the HTTP request processing }

}
});
return; // return from the command, this releases the thread
to be used for another request, but doesn't finish the response
}
}





[GLASSFISH-11670] NPE when deploying app with mistakes in sun-ejb-jar.xml Created: 10/Mar/10  Updated: 02/Dec/11

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

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

Operating System: All
Platform: All


Attachments: File MyApplication.ear    
Issuezilla Id: 11,670

 Description   

When I deploy an application with illegal values in sun-ejb-jar.xml, I get the
following message:

D:\GFv3.1\glassfish-v3_1-b01-03_10_2010\glassfishv3\bin>asadmin deploy
D:\shared\MyApplication.ear
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
deploying the app : java.lang.NullPointerException

Command deploy failed.

The server log has more useful messages (and a stacktrace).
Why not list the warnings and errors in the message above and not mention or log
the NPE?

[#|2010-03-11T14:04:31.453+1100|WARNING|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|This
bean [MyEjb] has no ejb reference by the name of [...]|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|DPL8006:
get/add descriptor failure : ejb-ref TO ...|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|DPL8007:
Invalid Deployment Descriptors element jndi-name value ...|#]

[#|2010-03-11T14:04:31.453+1100|WARNING|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|This
bean [MyEjb] has no resource reference by the name of [...]|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|DPL8007:
Invalid Deployment Descriptors element jndi-name value ...|#]

[#|2010-03-11T14:04:31.453+1100|SEVERE|glassfishv3.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=23;_ThreadName=Thread-1;|Exception
while deploying the app
java.lang.NullPointerException
at
com.sun.enterprise.deployment.node.runtime.ResourceRefNode.addDescriptor(ResourceRefNode.java:116)
at
com.sun.enterprise.deployment.node.runtime.DefaultResourcePrincipalNode.postParsing(DefaultResourcePrincipalNode.java:86)
at
com.sun.enterprise.deployment.node.DeploymentDescriptorNode.endElement(DeploymentDescriptorNode.java:330)
at
com.sun.enterprise.deployment.node.SaxParserHandler.endElement(SaxParserHandler.java:450)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601)
at
com.sun.org.apache.xerces.internal.impl.dtd.XMLNSDTDValidator.endNamespaceScope(XMLNSDTDValidator.java:263)



 Comments   
Comment by Dies Koper [ 10/Mar/10 ]

Created an attachment (id=4265)
reproducible test app

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 13/Dec/10 ]

I have fixed the NPE. We still don't have the ability to show the warnings from DOL code back to the user yet. But the error message as other error messages will have "Please see server.log for more details.", so at least we point user to the server.log where they could see the warnings. And once we fix 15114, user will be able to see these warnings from the verifier output.
I am downgrading this issue to P4 but keep it open to see if there is any improvement we can make to pass the warnings back to the user in the normal deployment in the future release.





[GLASSFISH-11642] EJB deploys and silently fails Created: 04/Mar/10  Updated: 02/Dec/11

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

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

Operating System: All
Platform: Linux


Attachments: Java Archive File ejbproblem-0.0.1-SNAPSHOT.jar     Zip Archive ejbproblem.zip     Text File ejbproblem0.0.2-SNAPSHOT.zip    
Issuezilla Id: 11,642

 Description   

I have an example EJB that deploys, but not all of the EJB's materialize.
i.e. the deploy fails silently

In the example app you will see a reference to log4j logger in the EJBs EJBTest1
and EJBTest2

The server log says the following :
[#|2010-03-04T09:54:15.414+0200|SEVERE|glassfishv3.0|global|_ThreadID=25;_ThreadName=Thread-1;|Class
[ Lorg/apache/log4j/Logger; ] not found. Error while loading [ class
za.co.enerweb.entity.ejbs.EJBTest1 ]|#]

But the application deploys on the admin GUI.

(Log4j is not in the EJB jar.)

I spent hours trying to figure out why I could not resolve my EJB in my WAR
application.



 Comments   
Comment by rjdkolb [ 04/Mar/10 ]

Created an attachment (id=4252)
Sample maven app

Comment by rjdkolb [ 04/Mar/10 ]

Work around is to add the following plugin to the maven pom.xml

The application should still fail to deploy, rather than fail silently

<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>

Comment by Alexis MP [ 04/Mar/10 ]

cc

Comment by Hong Zhang [ 04/Mar/10 ]

Can you attach the archive for me to reproduce? I tried to do mvn install from
the attached maven project and it told me a couple artifacts were missing..

[INFO] Failed to resolve artifact.

Missing:
----------
1) com.sun.jdmk:jmxtools:jar:1.2.1

...

2) com.sun.jmx:jmxri:jar:1.2.1

...

Comment by rjdkolb [ 04/Mar/10 ]

Created an attachment (id=4255)
EJB JAR of attached sample project

Comment by Hong Zhang [ 05/Mar/10 ]

Thanks for attaching the jar. When I tried to deploy the problematic ejb jar,
the deployment failed for me with the following error message:

$ asadmin deploy ejbproblem-0.0.1-SNAPSHOT.jar
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
deploying the app : java.lang.IllegalArgumentException: Invalid ejb jar
[ejbproblem-0.0.1-SNAPSHOT]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or
message-driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component
level annotations (@Stateless, @Stateful, @MessageDriven, @Singleton), please
check server.log to see whether the annotations were processed properly.

And #3 seems to be the right cause in this case, and if you follow its
instruction to look at the server.log, you will see the NoClassDefFoundError as
you have seen:

[#|2010-03-05T09:19:31.717-0500|SEVERE|glassfishv3.0|global|_ThreadID=23;_ThreadName=Thread-1;|Class
[ Lorg/apache/log4j/Logger; ] not found. Error while loading [ class
za.co.enerweb.entity.ejbs.EJBTest1 ]|#]

[#|2010-03-05T09:19:31.717-0500|WARNING|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=23;_ThreadName=Thread-1;|Error
in annotation processing: java.lang.NoClassDefFoundError:
Lorg/apache/log4j/Logger;|#]

So the deployment was succcessful for you? How did you deploy the app? I
deployed through admin cli..

Comment by rjdkolb [ 08/Mar/10 ]

I originally deployed with the web front end

I just tried again on a clean Glassfish 3 release.
Now deployed with the command line.

I got the following :
(I needed to create the jdbc/sample jdbc data source)

./bin/asadmin deploy ejbproblem-0.0.1-SNAPSHOT.jar
Authentication failed with password from login store: /home/richard/.asadminpass
Enter admin password for user "admin">
Application deployed successfully with name ejbproblem-0.0.1-SNAPSHOT.

Command deploy executed successfully.

And the in the logs :

[#|2010-03-08T11:17:06.527+0200|SEVERE|glassfishv3.0|global|_ThreadID=29;_ThreadName=Thread-1;|Class
[ Lorg/apache/log4j/Logger; ] not found. Error while loading [ class
za.co.enerweb.entity.ejbs.EJBTest1 ]|#]

[#|2010-03-08T11:17:06.528+0200|WARNING|glassfishv3.0|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=29;_ThreadName=Thread-1;|Error
in annotation processing: java.lang.NoClassDefFoundError:
Lorg/apache/log4j/Logger;|#]

Comment by Hong Zhang [ 08/Mar/10 ]

Tim and I found the behavior was actually intermittent. Sometimes it would say
deployment successful and sometimes it would give the error message I got earlier.
I suspect this is related to the fact that the classes being prepared for
annotation processing are stored in a Set (so the order of classes getting
processed for annotations could change from time to time), and depending on
which class gets processed first, we might be getting different behavior. I will
take a further look to see what I can find.
In the meanwhile, I think I have all the information I need and don't need any
additional information from you at this point. Thanks.

Comment by rjdkolb [ 08/Mar/10 ]

> Tim and I found the behavior was actually intermittent.

Yes, I seem to have had the same behavior.
If another EJB tried to use one of the EJB's that was giving an error the deploy
would fail the first time. And then on the second deploy , it deployed correctly.
I will try produce a sample of this as well.

Comment by rjdkolb [ 08/Mar/10 ]

Here is the new sample where EJBTest4 injects the EJB EJBTest2Local that refers
to log4j.
I deploy it twice, the first time it fails, the second time it passes.
After the second time I go to the localhost:4848 and click on the deployed
application. The only EJB that gets materialized is EJBTest3. i.e. EJBTest1,
EJBTest2 and EJBTest4 fail to materialized after the successful deploy.

( I will attache the maven sample again as ejbproblem-0.0.2-SNAPSHOT)

richard@silla64:~/install/java6/glassfishv3$ ./bin/asadmin deploy
ejbproblem-0.0.2-SNAPSHOT.jar
Authentication failed with password from login store: /home/richard/.asadminpass
Enter admin password for user "admin">
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
deploying the app : java.lang.IllegalArgumentException: Invalid ejb jar
[ejbproblem-0.0.2-SNAPSHOT]: it contains zero ejb.
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or
message-driven bean.
2. EJB3+ entity beans (@Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component
level annotations (@Stateless, @Stateful, @MessageDriven, @Singleton), please
check server.log to see whether the annotations were processed properly.

Command deploy failed.
richard@silla64:~/install/java6/glassfishv3$ ./bin/asadmin deploy
ejbproblem-0.0.2-SNAPSHOT.jar
Authentication failed with password from login store: /home/richard/.asadminpass
Enter admin password for user "admin">
Application deployed successfully with name ejbproblem-0.0.2-SNAPSHOT.

Command deploy executed successfully.

Comment by rjdkolb [ 08/Mar/10 ]

Created an attachment (id=4259)
Maven sample 0.0.2 with packaged output in target directory

Comment by Hong Zhang [ 09/Mar/10 ]

Thanks for the additional information. After looking further into the code, the
randomness does come from the class ordering during annotation processing. If it
happens to process the class which references the missing class first, the
deployment failed from there, and you don't get any ejb instantiated. If it
happens to process the class which does not reference the missing class first,
that ejb gets instantiated and it then continues to the next class till when the
deployment failed for the class which references the missing class.

Failing to load certain class probably should not be treated as fatal error
which causes the whole deployment to fail, and I have changed the code to
continue with warning after failing to load certain class. So now we will have
consistent behavior: all the classes will be processed for annotations and the
ones which failed will be logged as warning in the server.log (unfortunately
there is no easy way to propagate this part of the warning to the client,
hopefully if/when that missing class indeed causes trouble, user would look back
in the server.log and find those warnings at that time).

With the change I checked in, now I get this consistent error message for the
ejbproblem-0.0.2-SNAPSHOT.jar:
$ asadmin deploy ejbproblem-0.0.2-SNAPSHOT.jar
com.sun.enterprise.admin.cli.CommandException: remote failure: Exception while
deploying the app : java.lang.RuntimeException: Cannot resolve reference Local
ejb-ref name=za.co.enerweb.entity.ejbs.EJBTest4/local,Local 3.x interface
=za.co.enerweb.entity.ejbs.EJBTest2Local,ejb-link=null,lookup=null,mappedName=,jndi-name=,refType=Session

Comment by rjdkolb [ 09/Mar/10 ]

> Failing to load certain class probably should not be treated as fatal error
which causes the whole deployment to fail, and I have changed the code to
continue with warning after failing to load certain class.

This is the part I don't agree with. Surely the deployment should act in the
same way when a jdbc resource does not exists ? i.e. fail deploy fails.

> all the classes will be processed for annotations and the
ones which failed will be logged as warning in the server.log (unfortunately
there is no easy way to propagate this part of the warning to the client,
hopefully if/when that missing class indeed causes trouble, user would look back
in the server.log and find those warnings at that time).

Will there be a general warning to the user to look back the server.log ?

If a developer is deploying through NetBeans or Eclipse also get this warning ?
This is where I struggled, I thought my EJB application was working 100% and
only after a few hours of debugging I found a few of my EJB's did not
materialize and a few hours after that I read my server.log top to bottom.
(Hence my frustration)

Comment by rjdkolb [ 10/Mar/10 ]

I tested this same application on GlassFish 2.1.1 (without the persistence.xml
because that's JPA2)

The application (version 0.0.2-SNAPSHOT) failed to deploy twice, and on the
third try it deployed. So this issue applies to GlassFish 2.1.1 as well

Comment by Hong Zhang [ 10/Mar/10 ]

Re: This also happens in v2.*:
Yes, the code has been like this since beginning.

Re: Whether we should fail deployment when one class failed to load during
annotation processing like how the missing resource is handled:
This is certainly a debating point. After talking with a few people on this:
it's hard to tell which class is really critical to load and process annotations
for and in general it is a little too restrictive to fail the whole deployment
because certain class fail to load.

Re: General warning for user to look at the server.log:
This will not be easy with how the code was written now. But I understand your
concern here. I will think more about this and see what I can do. Thanks!

Comment by rjdkolb [ 10/Mar/10 ]

Thanks for the comments Hong,
Perhaps what really is 'messing up' is Maven's EJB packaging as it by default
does not bundle the dependencies in the EJB jar

Where Maven's WAR packaging bundles it by default.

Not sure why they decided this. Very confusing.

Comment by rjdkolb [ 16/Mar/10 ]

FYI discussion on the NetBeans forum about this:
http://netbeans.org/projects/www/lists/nbusers/archive/2010-03/message/812

Comment by Hong Zhang [ 16/Mar/10 ]

Richard: thanks for following this up and trying to get the source of the
problem fixed! It will be very nice if we can start with a correct packaging.

Comment by rjdkolb [ 16/Mar/10 ]

> Richard: thanks for following this up and trying to get the source of the
> problem fixed! It will be very nice if we can start with a correct packaging.

My pleasure Hong. That will make everyone's life easier.

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 07/Dec/10 ]

Scrubbing issue. As the source of the problem was already fixed and we do have warnings in the server.log, I am going to move it to P4 and see if we can improve the error reporting in the future release.





[GLASSFISH-11178] Deployment can half-succeed, half-fail Created: 25/Nov/09  Updated: 02/Dec/11

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

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

Operating System: All
Platform: All


Issuezilla Id: 11,178
Status Whiteboard:

v3_exclude


 Description   

Before fixing 11143, a side effect was that the failed download (described in
11143) would seem to partially invalidate the deployment but not entirely.
Attempting to redeploy the app would be accepted - so the app was still
partially registered - but the redeployment would fail because the
UndeployCommandParameters retrieved from the deployment context would be null.



 Comments   
Comment by Tim Quinn [ 25/Nov/09 ]

Excluding from v3, targeting v3.1.

Comment by Hong Zhang [ 03/Feb/10 ]

tim: do you still have the steps to reproduce this?

Comment by Tim Quinn [ 03/Feb/10 ]

The fix to 11143 removed the only trigger I know of that caused this error.

We could revert that change (locally only, only to reproduce the problem) and
use the sample app attached to 11143. Or, we could probably insert some
temporary logic to simulate the error condition of 11143...maybe just a "throw"
in the right place would be enough.

Let me look into it shortly to see if it's easy to create the error scenario.

Comment by Hong Zhang [ 28/Sep/10 ]

scrubbing issue, move state to NEW

Comment by Hong Zhang [ 04/Oct/10 ]

scrubbing issues

Comment by Hong Zhang [ 08/Dec/10 ]

Discussed this with Tim, as this error condition can only occur due to internal error and there is not an easy/simple fix to handle the error condition more gracefully, we will just revisit this if/when needed.





[GLASSFISH-10216] required elements are not present in config Created: 13/Oct/09  Updated: 02/Dec/11

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

Type: Bug Priority: Trivial
Reporter: llc Assignee: Bhakti Mehta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 10,216
Status Whiteboard:

v3_exclude


 Description   

Validation code should ensure that configuration is not created without the required elements. For example, one can create the
following:

<config name="TEST" dynamic-reconfiguration-enabled="false">
</config>

In spite of Config declaring the HttpService is a required element (and others):

public interface Config extends ConfigBeanProxy, Injectable, Named, PropertyBag, SystemPropertyBag {
...
@Element(required=true)
HttpService getHttpService();
...
}



 Comments   
Comment by kumara [ 02/Nov/09 ]

Create Configuration is more important for end users in v3.1. In v3 release (which supports one instance
only), there is no need to create an additional configuration because there is no way to use the additional
configuration.

Should be addressed for v3.1, excluding from v3 defect tracking.

Comment by llc [ 03/Nov/09 ]

This isn't about creating another <config>; that was just one example.

The problem is that any element can be created without required sub-elements.

Comment by ne110415 [ 03/Nov/09 ]

Hmm...where did my comment go...anyway...

llc, yes I understand that. My comment was that though it is necessary to make
sure @Element(required=true) works, v3 user will hit this issue rarely as some
attrib under the element would be used and as @Attribute(required=true) works,
it automatically implicitly ensures that attrib's parent Element is present.

In any case, the bug needs to be resolved, but it's not urgent.

Comment by llc [ 05/Nov/09 ]

I agree it's not urgent.

It will probably bite us unexpectedly at some point though.

Comment by Nazrul [ 15/May/10 ]

-> Tom

Comment by Bhakti Mehta [ 14/Jul/10 ]

I will look into this

Comment by Bhakti Mehta [ 05/Oct/10 ]

If users are going to create elements without clis I do not think this is
valid, supported or documented anywhere please comment if this needs to be fixed
for 3.1

Comment by Bhakti Mehta [ 06/Oct/10 ]

Based on discussions in oct 5 iteam meeting downgrading this to P4. The
validate-domain-xml should validate such cases but this is not required for this
release

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared fix version as this will not be fixed for 3.1.





[GLASSFISH-9161] (RN) (UC) Unable to bring up updatetool on RHEL 5 Created: 18/Aug/09  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: update_center
Affects Version/s: V3
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: nluu Assignee: Snjezana Sevo-Zenzerovic
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 9,161

 Description   

OS: RHEL 5.3
Build: GFv3 B59/SDK B15

I installed GFv3 B59 on Red Hat EL 5.3 and ran into the problem below:

  1. ./updatetool
    IPS pkg command is not installed. Please make sure that the client libraries are
    on the PYTHONPATH before executing.
    The following can be reported to Update Tool 2.2.0 Development Team
    <dev@updatecenter.dev.java.net>.

Traceback (innermost last):
File
"/opt/glassfishv3b59sdkb15full/updatetool/vendor-packages/updatetool/common/boot.py",
line 298, in check_ips
import common.ips
File
"/opt/glassfishv3b59sdkb15full/updatetool/vendor-packages/updatetool/common/ips/_init_.py",
line 50, in ?
import pkg.misc as pkgmisc
File "/opt/glassfishv3b59sdkb15full/pkg/vendor-packages/pkg/misc.py", line 32,
in ?
import OpenSSL.crypto as osc
File "/opt/glassfishv3b59sdkb15full/pkg/vendor-packages/OpenSSL/_init_.py",
line 11, in ?
import rand, crypto, SSL, tsafe
ImportError:
/opt/glassfishv3b59sdkb15full/pkg/vendor-packages/OpenSSL/crypto.so: cannot
restore segment prot after reloc: Permission denied

Steps to reproduce:
-------------------
1) Install the build using the default values.
2) Invoke <install-dir>/bin/updatetool
3) Observe the above error message



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 15/Sep/09 ]

Quoting Joe Di Pol:

>Is it possible SE Linux has been enabled on the system?
>
>You can turn SE Linux off and try again:
>
>/usr/sbin/setenforce 0
>
>Apparently there is a way to just enable text relocation with
>shared libraries – but I haven't figured out the command yet.

Reassigning to submitter, please check if this is indeed the issue with enabled
SE Linux...

Comment by nluu [ 15/Sep/09 ]

/usr/sbin/setenforce 0

resolved the problem. Thanks!

Comment by nluu [ 16/Sep/09 ]

Marked fixed by mistake. Although there is a workaround, this issue is reopened
(with priority lowered) until a permanent solution is found or for release notes
for the SE Linux environment.

Comment by Snjezana Sevo-Zenzerovic [ 17/Sep/09 ]

Adjusting summary since this is not a regression after all. Corresponding UC
issue is:

https://updatecenter2.dev.java.net/issues/show_bug.cgi?id=1211

Comment by Snjezana Sevo-Zenzerovic [ 13/Oct/09 ]

Downgrading to P4 since this is not targeted for fix in UC 2.3 and it is not a
regression nor a release stopper. Needs to be documented, though...

Comment by Snjezana Sevo-Zenzerovic [ 30/Aug/10 ]

...





[GLASSFISH-7959] ejb lookup faild when resource adapter with remote interface deployed Created: 22/Apr/09  Updated: 15/Feb/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: v2.1.1
Fix Version/s: 4.0

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

Operating System: Linux
Platform: Linux


Attachments: GZip Archive ejb-lookup-problem-src-bin.tar.gz    
Issuezilla Id: 7,959
Status Whiteboard:

v3_exclude


 Description   

I'm using Sun Java System Application Server 9.1_02 (build b04-fcs)
I also reproduced this problem using GlassFish v3 (build 44)

Scenerio:
I have two Enterprise Applications (EAR) TEST-MODULE (EAR_1) and SMS-ACTIVE (EAR_2)
one Web Application (WAR_1) and one Connector Module (RAR_1)

EAR_1 : TEST-MODULE have one ejb (EJB_1):

@Stateless(mappedName = "ejb/sms/active/module/EJBCActivityTest")
@Remote(

{ActivityProcessableRemote.class}

)
public class EJBCActivityTest implements ActivityProcessableRemote {

public void doInit()

{ Logger.getLogger(this.getClass().getName()).info("doInit"); }

}

EAR_2 : SMS-ACTIVE have one ejb (EJB_2):

@Stateless(mappedName = "ejb/sms/active/SMSMainBean")
@TransactionAttribute(value = TransactionAttributeType.NOT_SUPPORTED)
public class SMSMainBean implements SMSBeanRemote
public void onTextMessage(String message) {
InitialContext ctx;
try

{ ctx = new javax.naming.InitialContext(); Object lookup = ctx .lookup("ejb/sms/active/module/EJBCActivityTest"); ActivityProcessableRemote activity = (ActivityProcessableRemote) lookup; activity.doInit(); } catch (NamingException e) { e.printStackTrace(); }

}

}

WAR_1 : Servlet (SERVLET_1) with <load-on-startup>1</load-on-startup> in
web.xml (this servlet is packaged in SMS-ACTIVE.ear)

ublic final class LifeCycleServlet extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet {

private transient java.util.logging.Logger logger;


@Override
public void init() throws ServletException {
// start first part of code
getLogger().info("--------- part 1");
InitialContext ctx;
try { ctx = new javax.naming.InitialContext(); Object lookup = ctx .lookup("ejb/sms/active/module/EJBCActivityTest"); ActivityProcessableRemote activity = (ActivityProcessableRemote) lookup; activity.doInit(); }

catch (NamingException e)

{ e.printStackTrace(); }
// end first part of code
// start second part of code
getLogger().info("--------- part 2");
try { ctx = new javax.naming.InitialContext(); Object lookup = ctx .lookup("ejb/sms/active/SMSMainBean"); SMSBeanRemote activity = (SMSBeanRemote) lookup; activity.onTextMessage("message"); } catch (NamingException e) { e.printStackTrace(); }

// end second part of code

super.init();
}

public java.util.logging.Logger getLogger()

{ return logger == null ? logger = Logger .getLogger(LifeCycleServlet.class.getName()) : logger; }

}

So, in first part of (see servlet code listening) this code servlet call EJB_1
from SERVLET_1 and in second part it call EJB_2 which call EJB_1.

First part of this code always successes.
But in some cases the second part of this code crashed with exception:

javax.naming.NamingException: ejb ref resolution error for remote business
interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root exception is
java.lang.IllegalArgumentException: object is not an instance of declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
(...)
Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
(...)

I described the cases when this code crashed here:
Case 1.
Step 1. deploy RAR_1 with ActivityProcessableRemote.class (remote interface of
EJB_1) on glassfish
Step 2. deploy EAR_1
Step 3. deploy EAR_2
Step 3. deploy WAR_1 – init method of SERVLET_1 is called
OUTCOME:
First part of code: OK
Second part of code: Exception.

Case 2.
Step 1. deploy EAR_1
Step 2. deploy EAR_2
Step 3. deploy RAR_1 with ActivityProcessableRemote.class (remote interface of
EJB_1) on glassfish
Step 4. deploy WAR_1 – init method of SERVLET_1 is called
OUTCOME:
First part of code: OK
Second part of code: OK.

Case 3.
Step 1. deploy EAR_1
Step 2. deploy EAR_2
Step 3. deploy WAR_1 – init method of SERVLET_1 is called
(RAR_1 is not on the glassfish)
OUTCOME:
First part of code: OK
Second part of code: OK.

Case 4.
Step 1. deploy RAR_1 without definition of ActivityProcessableRemote interface
Step 2. deploy EAR_1
Step 3. deploy EAR_2
Step 3. deploy WAR_1 – init method of SERVLET_1 is called
OUTCOME:
First part of code: OK
Second part of code: OK.

Conclusion:
Problem occurred only when definition of ejb interface are deployed in RAR_1
before EAR_2 is deployed.

Full exception:
[#|2009-04-22T05:54:52.542+0000|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_RequestID=ecfcfc68-5b91-4c18-97c4-064f5ad358bb;|
javax.naming.NamingException: ejb ref resolution error for remote business
interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root exception is
java.lang.IllegalArgumentException: object is not an instance of declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:74)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at pl.smi.sms.active.manager.SMSMainBean.onTextMessage(SMSMainBean.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.rFull exception:
[#|2009-04-22T05:54:52.542+0000|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_RequestID=ecfcfc68-5b91-4c18-97c4-064f5ad358bb;|
javax.naming.NamingException: ejb ref resolution error for remote business
interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root exception is
java.lang.IllegalArgumentException: object is not an instance of declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:74)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
at
javaxeflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at
com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
at
com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:203)
at
com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:77)
at $Proxy23.onTextMessage(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:154)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:687)
at
com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:227)
at
com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1846)
at
com.sun.corba.ee.impl.protocol.SharedCDRClientRequestDispatcherImpl.marshalingComplete(SharedCDRClientRequestDispatcherImpl.java:183)
at
com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:219)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:192)
at
com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at
com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
at
pl.smi.sms.active.manager._SMSBeanRemote_Remote_DynamicStub.onTextMessage(pl/smi/sms/active/manager/_SMSBeanRemote_Remote_DynamicStub.java)
at
pl.smi.sms.active.manager._SMSBeanRemote_Wrapper.onTextMessage(pl/smi/sms/active/manager/_SMSBeanRemote_Wrapper.java)
at pl.smi.sms.active.LifeCycleServlet.init(LifeCycleServlet.java:48)
at javax.servlet.GenericServlet.init(GenericServlet.java:254)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1178)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1007)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4808)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5196)
at com.sun.enterprise.web.WebModule.start(WebModule.java:326)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222)
at
com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:182)
at
com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:278)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.invokeModuleDeployEventListener(AdminEventMulticaster.java:974)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.handleModuleDeployEvent(AdminEventMulticaster.java:961)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:464)
at
com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
at
com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
at
com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at
com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at
com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:591)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:635)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at
com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at
com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at
com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at
com.sun.enterprise.admin.jmx.remote.server.callers.InvokeCaller.call(InvokeCaller.java:69)
at
com.sun.enterprise.admin.jmx.remote.server.MBeanServerRequestHandler.handle(MBeanServerRequestHandler.java:155)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.processRequest(RemoteJmxConnectorServlet.java:122)
at
com.sun.enterprise.admin.jmx.remote.server.servlet.RemoteJmxConnectorServlet.doPost(RemoteJmxConnectorServlet.java:193)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(Sta|#]

[#|2009-04javax.naming.NamingException: ejb ref resolution error for remote
business interfacepl.smi.sms.active.process.ActivityProcessableRemote [Root
exception is java.lang.IllegalArgumentException: object is not an instance of
declaring class]
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:425)
at
com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:74)-22T05:54:52.543+0000|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err|_ThreadID=16;_ThreadName=httpWorkerThread-4848-0;_RequestID=ecfcfc68-5b91-4c18-97c4-064f5ad358bb;|ndardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at
com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at
com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:116)
Caused by: java.lang.IllegalArgumentException: object is not an instance of
declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:372)
... 106 more

#]


 Comments   
Comment by rmalinowski [ 22/Apr/09 ]

Created an attachment (id=2641)
source and bin with maven poms

Comment by ksak [ 11/Oct/09 ]

Marked v3_exclude

Comment by marina vatkina [ 08/Sep/10 ]

-> Cheng

Comment by Tom Mueller [ 15/Feb/13 ]

Reassigning to component lead as the assignee is no longer with the project.





[GLASSFISH-7717] Wrong handling of RuntimeExceptions in JMS cluster Created: 14/Apr/09  Updated: 02/Nov/12

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 9.1peur2
Fix Version/s: 4.0

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

Operating System: Linux
Platform: All


Issuezilla Id: 7,717
Status Whiteboard:

v3_exclude, v2.1.1_exclude

Tags: bj-reviewed

 Description   

I installed a v2.1 cluster with two nodes and set up a default jms
ConnectionFactory and logical + physical queue.
I composed a testcase with one MDB doing nothing but throwing a RuntimeException.
The MDB was configured with "EndpointExceptionRedeliveryAttempts=5" and deployed
to the cluster.
A JavaSE Client uses JNDI to send 10000 transactional messages to the queue.
The load gets distributed evenly between the two cluster instances. Instance one
behaves as expected and retries 5 times before moving the messages to DMQ.
Instance two instead seems to ignore EndpointExceptionRedeliveryAttempts and
keeps trying to deliver the bad messages. Instance two loops forever using a lot
of CPU. The Queue shows around 5000 "Not ACK" messages.

The same testcase runs flawlessly in a non-clustered environment.



 Comments   
Comment by Satish Kumar [ 09/Sep/09 ]

This is a v2.1 issue not relevant for V3. Hence adding 'v3_exclude' in the
status whiteboard.

Comment by Ed Bratt [ 15/Oct/09 ]

Will not fix in v2.1.1

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by Simon Meng [ 24/Oct/12 ]

I can't reproduce the described issue. The expected RuntimeException appeared. There is no infinite loop.

But I found other issue in my testing. When sending a message from the standalone java client to queue, the MDB behaves as expected and retries 5 times, we can see 6 RuntimeExceptions. Then the message was moved to DMQ. It looks everything works fine at this point. But when I restart domain and server, the MDB throws 6 RuntimeExceptions again. The message also enters queue and marked as "UnAck". Each time I retart domain, the MDB still throws 6 RuntimeExceptions. It looks to me the behavior is not correct. The message has been moved to the DMQ, why it is delivered again and again when domain restart?

Comment by Simon Meng [ 02/Nov/12 ]

The "other issue" that simeng_oracle noticed in his testing as mentioned in his above comment - that involves a transacted sender client and restart domain is a MQ bug MQ-227.





[GLASSFISH-7059] no exception thrown to client when error occurs while sending big data packet Created: 17/Jan/09  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: v2.1
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File remarshalExc.patch     Text File stacktrace-client.txt     Text File stacktrace-server.txt    
Issuezilla Id: 7,059

 Description   

While sending a big data packet (250 MBytes)from an EJB client running in the
ACC, I got the following message outputted in my window.
No exception was thrown to the client code, so it was unaware that the IIOP
request failed.
Second problem is the unsubstituted

{4} in the IOP00410227 message.

[java] 2008/02/23 11:17:24
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl write
[java] 致命的: "IOP00410227: (COMM_FAILURE) Unexpected exception when writing
with a temporary selector: bytes written = 0, total bytes requested to write =
4,096, time spent waiting = 7,280 ms, max time to wait = {4}

."
[java] org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 227 completed: No
[java] at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.exceptionWhenWritingWithTemporarySelector(ORBUtilSystemException.java:3416)

[java] at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.exceptionWhenWritingWithTemporarySelector(ORBUtilSystemException.java:3442)

[java] at
com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.write(SocketOrChannelConnectionImpl.java:741)

[java] at
com.sun.corba.ee.impl.encoding.CDROutputObject.writeTo(CDROutputObject.java:196)



 Comments   
Comment by Dies Koper [ 17/Jan/09 ]

Created an attachment (id=2221)
proposed patch (based on V3 src from Kenai)

Comment by Dies Koper [ 17/Jan/09 ]

Sometimes when I try to reproduce the error I get an IOP00410225 (exceeded TCP
timeout) instead, but the problem seems to be as follows:

It tries to marshal the 250MByte array, fails, retries, fails again and throws a
RemarshalException. The exception is not propagated properly.

The patch also fixes the trivial problem with the final argument in the message.

Comment by Ken Cavanaugh [ 20/Jan/09 ]

The patch for the exception messages is fine; I think
the error may have been left over from an earlier fix
that took care of a problem with lack of exception chaining.

Your fix is interesting, but I'm not sure it's correct.
Propagting RemarshalException through the ValueHandler seems
unfortunate (the ValueHandler should be relatively independent
of such details), but may be necessary. I'm more concerned
about why the operation failed in the first place.

Do you have more details on the stack trace when the operation fails?
I'm particularly interested in what happens in the
SocketOrChannelConnectionImpl.write call. It sounds like either the
getSocketChannel().write() call fails, or else the timeout
(which is configurable) trips, because the socket is so backed up
with data that it does not accept more data for longer than the
timeout.

A 250 MB request will generate around 63000 4 KB GIOP messages and do it
fairly quickly. I wonder what is happening at the OS level in this case?
I understand getting held off because no kernel buffers are available, but
why is there a failure here? More details would be very helpful.

Comment by kurti [ 05/Jun/09 ]

Created an attachment (id=2850)
I get the same problem, but only, if I have I direct network LAN connection. If I am using a wireless connection - even if I am in the same IP subnet - the problem goes away. This is the stacktrace on the server.

Comment by kurti [ 05/Jun/09 ]

Created an attachment (id=2851)
And this the stacktrace on the client. Server is Ubuntu 7.10 i686, JDK 1.6.0_13; client is WindowsXP JDK 1.6.0_13

Comment by kurti [ 05/Jun/09 ]

I think I found the reason and a workaround for this problem:

The default Corba timeouts are 2 seconds. If the server is fast, the network
connection is fast but the client is too slow and you have lots of data, the
server hits this timeout and the exception occurs. This matches my observations
that it works when connected via WLAN but does not work via LAN.

The workaround is to increase the network timeout: open domain.xml, look for the
jvm-options and add a line like this:

<jvm-options>-Dcom.sun.corba.ee.transport.ORBTCPTimeouts=20000:60000:20</jvm-options>

The first number is the timeout in milliseconds, the second the maximum timeout
and the last an increase percent (default: 2000:6000:20). According to the
original exception, the server only waited 2000ms, so something went wrong here.
With 20000 it works for me. You can find an explanation of this option here:

http://blogs.sun.com/ejcorba/entry/more_on_tcp_timeouts_in

Hey bug owner, this is you own page. Thanks for that, it showed me the right
direction.

Comment by kurti [ 06/Jun/09 ]

Unfortunately, the command line option does not work as expected. I set it to
60000, but after about 10 seconds I got the very same error message with "time
spent waiting = 60.000 ms". So it looks as if the time is set but not used.

Comment by kurti [ 09/Jun/09 ]

I think I found the reason why the option does not work: issue #4382

I get

"IOP00110231: (BAD_PARAM) Timeout data must be 3 positive decimal integers
separated by :"
org.omg.CORBA.BAD_PARAM: vmcid: SUN minor code: 231 completed: No
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.badTimeoutDataLength(ORBUtilSystemException.java:2370)
at
com.sun.corba.ee.impl.logging.ORBUtilSystemException.badTimeoutDataLength(ORBUtilSystemException.java:2392)
at
com.sun.corba.ee.impl.transport.TcpTimeoutsImpl.<init>(TcpTimeoutsImpl.java:62)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
com.sun.corba.ee.spi.orb.OperationFactoryExt$ConvertAction.operate(OperationFactoryExt.java:73)
at
com.sun.corba.ee.impl.orb.NormalParserAction.apply(NormalParserAction.java:58)
at com.sun.corba.ee.spi.orb.PropertyParser.parse(PropertyParser.java:81)
at com.sun.corba.ee.spi.orb.ParserImplBase.init(ParserImplBase.java:81)
at
com.sun.corba.ee.impl.orb.ORBDataParserImpl.<init>(ORBDataParserImpl.java:481)
at com.sun.corba.ee.impl.orb.ORBImpl.postInit(ORBImpl.java:587)
at com.sun.corba.ee.impl.orb.ORBImpl.set_parameters(ORBImpl.java:701)
at org.omg.CORBA.ORB.init(ORB.java:337)
at com.sun.enterprise.util.ORBManager.initORB(ORBManager.java:546)
at com.sun.enterprise.util.ORBManager.getORB(ORBManager.java:278)
at com.sun.enterprise.util.ORBManager.getORB(ORBManager.java:289)
at
com.sun.enterprise.server.ondemand.EjbServiceGroup.createORB(EjbServiceGroup.java:511)
at
com.sun.enterprise.server.ondemand.EjbServiceGroup.startORB(EjbServiceGroup.java:437)
at
com.sun.enterprise.server.ondemand.EjbServiceGroup._start(EjbServiceGroup.java:156)
at
com.sun.enterprise.server.ondemand.EjbServiceGroup.start(EjbServiceGroup.java:143)
at
com.sun.enterprise.server.ondemand.ServiceGroup$1.run(ServiceGroup.java:193)
at java.security.AccessController.doPrivileged(Native Method)
at
com.sun.enterprise.server.ondemand.ServiceGroup.startChildren(ServiceGroup.java:190)
at
com.sun.enterprise.server.ondemand.MainServiceGroup.start(MainServiceGroup.java:58)
at
com.sun.enterprise.server.ondemand.ServerEntryListenerImpl.notifyEntry(ServerEntryListenerImpl.java:85)
at
com.sun.enterprise.server.ondemand.entry.ServerEntryHelper.sendEvent(ServerEntryHelper.java:75)
at
com.sun.enterprise.server.ondemand.entry.ServerEntryHelper.generateStartUpEntryContext(ServerEntryHelper.java:64)
at
com.sun.enterprise.server.ondemand.OnDemandServer.generateEntryContext(OnDemandServer.java:154)
at
com.sun.enterprise.server.ondemand.OnDemandServer.onStartup(OnDemandServer.java:133)
at com.sun.enterprise.server.PEMain.run(PEMain.java:409)
at com.sun.enterprise.server.PEMain.main(PEMain.java:336)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.server.PELaunch.main(PELaunch.java:415)

Changing the line in domain.xml to

<jvm-options>-Dcom.sun.corba.ee.transport.ORBTCPTimeouts=60000:180000:20:2000000</jvm-options>

does not cause the Exception. I cannot test if anything differs now, as we
reduced the object size in our code.

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Ken Cavanaugh [ 06/Oct/09 ]

Not for the current v3 release.

Comment by jagadesh [ 15/Oct/09 ]

Will not be fixed for V2.1.1

Comment by Ken Cavanaugh [ 21/Jan/10 ]

Given the number of votes on this issue, I'd like to know if there is still a
problem on v3, which has the ORBTCPTimeouts parsing error fixed. I'll write an
ORB test sending large amounts of data and see what happens in the current ORB.

If the problem is still present, I can increase the timeouts, but sending
250 MB messages to an EJB is unusual enough that perhaps adjusting the
timeouts should be expected. Another possibility is to investigate
automatic adjustment of the timeouts when a very large transfer is detected.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moved to v3.1

Comment by Ken Cavanaugh [ 17/Nov/10 ]

No time to write the test for GF 3.1. Moving to 3.2.





[GLASSFISH-6776] application hangs when concurrency nears default threadpool max Created: 15/Nov/08  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 3.1
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: Dies Koper Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive iiiop-thread-app-hang.zip     Text File iiop-req-threadpool.patch     Text File iiop-req-threadpool2.patch    
Issuezilla Id: 6,776

 Description   

When an EJB application uses the default ORB thread pool and accesses beans on
another server, it will hang when the number of requests nears the point where
the thread pool runs out of threads.

In our case our application's session facades hangs while trying to distribute
requests over several servers.

If we create a custom thread pool and specify it in all the sun-ejb-jar.xml's
for all the beans, the application does not hang, even if the number of requests
exceeds the maximum number of threads of the thread pools.

It would be nice if GF would not hang with the default settings.

The cause of the problem seems to be that to send an IIOP request out (i.e. to
access an EJB on a different server), an extra thread is used and it is taken
from the ORB's default thread pool. So if your application uses the same pool
and gets accessed enough to use all its threads, it cannot send any requests out
to any remote beans anymore (which means the method does not end, which means no
threads return to the pool, which means everybody keeps waiting).

I have reproduced it with a simple test application on GF V2.1 b53. I'll attach
it, together with a thread dump.



 Comments   
Comment by Dies Koper [ 15/Nov/08 ]

Created an attachment (id=2105)
reproducible test case. Readme.txt inside.

Comment by Dies Koper [ 16/Nov/08 ]

I also tried the following (with no success):
I created another thread pool and specified this pool in the ORB thread pool
list-box (which corresponds to server-config.iiop-service.orb.use-thread-pool-ids).

I expected that my bean's business methods would be executed in threads from
this pool, and hoped that for sending IIOP requests it would use thread-pool-1,
but alas, it keeps using thread-pool-1.
(Which makes me wonder in what kind of case the specified pool does get used..)

Comment by Dies Koper [ 05/Jan/09 ]

Created an attachment (id=2186)
proposed patch that creates another thread pool before the default thread pool

Comment by Dies Koper [ 05/Jan/09 ]

Please ignore the attachment iiop-req-threadpool.patch. One file with changes
is missing from it. I'll attach a new patch file after this comment.

Currently, a thread from the first thread pool is used for making IIOP requests.

With this patch a thread pool is created and inserted into the thread pool map
with ID 0, before the user customized thread pools (the default pool and any
extra pools a user might have specified) are created and added to the map.
It will make sure threads from different pools are used for IIOP requests and
responses, preventing them from fighting for the same threads (and deadlocking
in the process).

Comment by Dies Koper [ 05/Jan/09 ]

Created an attachment (id=2187)
complete proposed patch (prev missed a file)

Comment by sanandal [ 11/Jan/09 ]

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

Comment by Dies Koper [ 10/Feb/09 ]

Hi Ken,

Would you evaluate the patch that I had attached?

Thanks,
Dies

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moving to v3.1.

Comment by Ken Cavanaugh [ 18/Oct/10 ]
      • Issue 12962 has been marked as a duplicate of this issue. ***
Comment by Dies Koper [ 19/Oct/10 ]

Updating to version 3.1 to make sure it doesn't accidentally get filtered out.
As Greg's findings in issue 12962 show, applications hang in V3.1 too.

Comment by Ken Cavanaugh [ 08/Dec/10 ]

I've run out of time for this in 3.1: too many higher-priority issues. Moving to 3.2.





[GLASSFISH-6742] commandLink styleClass doesn't work Created: 07/Nov/08  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: v2.1
Fix Version/s: 4.0

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

Operating System: All
Platform: Linux


Issuezilla Id: 6,742
Tags: 3_1-exclude

 Description   

Hi...

I have a JSF page in which I set the styleClass for a commandLink. However, the
generated page does not rendered the stylized link.

Here is the excerpt from my stylesheet:
.commandLink {

font-weight: bold;
text-decoration: none;

color: #661A0E;

margin: 0px 0px 0px 0px;
padding: 5px 15px 5px 15px;

}

.commandLink:hover {
background: #F5F0DA;
}

Here is the commandLink tag:
<h:commandLink sytleClass="commandLink" value="Logout"
action="#

{AuthenticationBean.logout}

"/>

And here is the generated link when the page is rendered:
<a href="#" onclick="if(typeof jsfcljs ==
'function')

{jsfcljs(document.forms['wondercart'],'wondercart:j_id7,wondercart:j_id7','');}

return
false">Logout</a>

Notice that the "class" attribute is not rendered as described in the tag lib in
http://java.sun.com/javaee/javaserverfaces/1.2_MR1/docs/tlddocs/index.html

I don't want to set the stylesheet with the a and a:hover definitions globally
(which would then render the links properly) because I have different kinds of
links that should be stylized differently.



 Comments   
Comment by jluehe [ 07/Nov/08 ]

I'll have Ryan take a look.

Comment by sanandal [ 11/Jan/09 ]

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

Comment by kumara [ 01/Sep/09 ]

Changing version from 9.1.1 to v2.1 to reflect new name/version.

Comment by Ryan Lubke [ 21/Jun/10 ]

Passing to Ed.

Comment by Ed Burns [ 19/Nov/10 ]

Not planned for 3.2. Not high enough priority.





[GLASSFISH-6422] [UB] [Release Note] newly created vs didn't show under HTTPService monitoring Created: 03/Oct/08  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: 4.0

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

Operating System: Solaris
Platform: PC


Attachments: JPEG File monitoring1.JPG    
Issuezilla Id: 6,422
Status Whiteboard:

gfv3-prelude-excluded


 Description   

b27, open solaris, IE 7

after creation of a new virtual server, I go to monotoring tab, from the drop
down list, I didn't see this new virtual server. I have tried reload browser,
click refresh page, still doesn't show. CLI command doesn't have new virtual
server listed either.

to reproduce:

1. turn monitoring level to HIGH and save
2. configuration->virtual servers>click new>input myvs1 as id->click save
3. configuration->http listeners>click new->
put name as myhs1, network address 0.0.0.0 listener port 6666 default virtual
server myvs1-> click next--> click finish
4. access http://myhost:6666 , make sure the new http listener for myvs1 is working
5. application server->monitor->HTTP Service
notice the virtual server named myvs1 is not on the pulldown list

6. corresponding CLI command doesn't return the stats for myvs1 either

  1. uname -a/asadmin get --monitor=true "server.http-service.*"
    server.http-service.__asadmin.request.count5xx-count = 0
    server.http-service.server.request.count404-count = 0
    server.http-service.__asadmin.request.count503-count = 0
    server.http-service.__asadmin.request.requestCount = 0
    server.http-service.__asadmin.request.processingTime = NaN
    server.http-service.server.request.count200-count = 0
    server.http-service.server.request.count2xx-count = 0
    server.http-service.server.request.count302-count = 0
    server.http-service.server.request.countother-count = 0
    server.http-service.server.request.requestCount = 0
    server.http-service.server.request.count4xx-count = 0
    server.http-service.server.request.count400-count = 0
    server.http-service.__asadmin.request.count401-count = 0
    server.http-service.__asadmin.request.countother-count = 0
    server.http-service.__asadmin.request.count400-count = 0
    server.http-service.server.request.errorCount = 0
    server.http-service.server.request.maxTime = 0
    server.http-service.__asadmin.request.count403-count = 0
    server.http-service.__asadmin.request.count302-count = 0
    server.http-service.server.request.count5xx-count = 0
    server.http-service.__asadmin.request.count3xx-count = 0
    server.http-service.__asadmin.request.count2xx-count = 0
    server.http-service.__asadmin.request.count4xx-count = 0
    server.http-service.__asadmin.request.errorCount = 0
    server.http-service.server.request.count503-count = 0
    server.http-service.__asadmin.request.count200-count = 0
    server.http-service.server.request.count3xx-count = 0
    server.http-service.server.request.count401-count = 0
    server.http-service.server.request.processingTime = NaN
    server.http-service.__asadmin.request.count304-count = 0
    server.http-service.__asadmin.request.count404-count = 0
    server.http-service.server.request.count403-count = 0
    server.http-service.server.request.count304-count = 0
    server.http-service.__asadmin.request.maxTime = 0


 Comments   
Comment by yifeng1 [ 03/Oct/08 ]

Created an attachment (id=1929)
add attachment

Comment by yifeng1 [ 03/Oct/08 ]

add one attachment, in the picture, left side window shows the newly created
http listener myhs1 is running on myvs1, right side window is Admin console, the
drop down list doesn't have myvs1.

Comment by Anissa Lam [ 03/Oct/08 ]

This is a monitoring issue, related to dynamic reconfiguration.
The newly created VS will show up after server restart.
Transferring to monitoring.

Comment by Nazrul [ 08/Oct/08 ]

Discussed this with Jerome and Abhijit. Will be fixed after GFv3 Prelude. User
will need to restart to see stats for newly created virtual server.

We may release note this.

Comment by Nazrul [ 15/Oct/08 ]

Need to release note for GFv3 Prelude.

Comment by kumara [ 24/Oct/08 ]

Prashanth: Please be sure to get a release note entry added for this issue. Excluding from prelude release.

Comment by kumara [ 24/Oct/08 ]

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

Comment by Gail Risdal [ 08/Dec/09 ]

Added to v3 Release Notes.

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Jennifer Chou [ 18/Jan/11 ]

Consider for 3.2.





[GLASSFISH-6238] [UB] [Release Note] monitoring:after change virtual server for app, monitoring page shows old value Created: 22/Sep/08  Updated: 02/Dec/11

Status: Open
Project: glassfish
Component/s: monitoring
Affects Version/s: V3
Fix Version/s: 4.0

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

Operating System: Solaris
Platform: PC


Issuezilla Id: 6,238
Status Whiteboard:

gfv3-prelude-excluded

Tags: 3_1-exclude

 Description   

platform: open solaris
b25

to reproduce:
1. configuration -> monitoring->set value to high and save
2. applications->web applications->deploy, deploy webapps-simple.war and point
to server1
3. configuration->virutal servers->create new called myvs1, provide id,
hosts,and save
4. configuration->http listeners->create new http listeners,provide name,
network address, listener ort, default virtual server point to myvs1
5. applications->web applications-->click webapps-simple and change virtual
server to myvs1 , save
6.application server->monitoring->web container,
select application webapps-simple, notice that after page refresh, virtual
server shows server --> bug



 Comments   
Comment by Anissa Lam [ 23/Sep/08 ]

not sure if this is gui issue or monitoring.
Jennifer please take a look

Comment by kumara [ 23/Sep/08 ]

v3 defect tracking

Comment by Jennifer Chou [ 23/Sep/08 ]

I also see this issue on CLI: asadmin get --monitor=true "server.applications.*"

When I restart the appserver, then both the gui (Web Container tab) and CLI
(asadmin get --monitor=true "server.applications.*") show the newly changed
virtual-server, myvs1.

Seems to be a dynamic reconfig issue.
------------------------
There is a second problem I see though. After I restarted the appserver, the
HTTP Service tab (in gui) and the 'server.http-service.<virtual-server>.request
nodes from CLI get --monitor=true "request" still shows the old 'server' name:

C:\gfv3_0922\v3\distributions\web\target\glassfish\bin>asadmin get --monitor=tr
e "request"
server.http-service.__asadmin.request.count5xx-count = 0
server.http-service.__asadmin.request.count503-count = 0
server.http-service.myvs1.request.count5xx-count = 0
server.http-service.__asadmin.request.requestCount = 0
server.http-service.server.request.count302-count = 0
server.http-service.server.request.countother-count = 0
server.http-service.server.request.requestCount = 0
server.http-service.server.request.count400-count = 0
server.http-service.__asadmin.request.count401-count = 0
server.http-service.myvs1.request.count4xx-count = 0
server.http-service.__asadmin.request.countother-count = 0
server.http-service.__asadmin.request.count400-count = 0
server.http-service.server.request.errorCount = 0
server.web.request.processingTime = 149.55345911949686
server.web.request.maxTime = 14375
server.http-service.myvs1.request.count302-count = 0
server.http-service.__asadmin.request.count3xx-count = 0
server.http-service.myvs1.request.count401-count = 0
server.http-service.myvs1.request.count400-count = 0
server.http-service.myvs1.request.errorCount = 0
server.web.request.errorCount = 0
server.http-service.__asadmin.request.count200-count = 0
server.http-service.myvs1.request.maxTime = 0
server.http-service.__asadmin.request.count304-count = 0
server.http-service.server.request.count403-count = 0
server.http-service.__asadmin.request.maxTime = 0
server.http-service.myvs1.request.count403-count = 0
server.http-service.server.request.count404-count = 0
server.http-service.myvs1.request.countother-count = 0
server.http-service.__asadmin.request.processingTime = NaN
server.http-service.server.request.count200-count = 0
server.http-service.server.request.count2xx-count = 0
server.http-service.server.request.count4xx-count = 0
server.web.request.requestCount = 159
server.http-service.myvs1.request.count2xx-count = 0
server.http-service.server.request.maxTime = 0
server.http-service.__asadmin.request.count403-count = 0
server.http-service.myvs1.request.count200-count = 0
server.http-service.__asadmin.request.count302-count = 0
server.http-service.myvs1.request.processingTime = NaN
server.http-service.server.request.count5xx-count = 0
server.http-service.myvs1.request.count3xx-count = 0
server.http-service.__asadmin.request.count2xx-count = 0
server.http-service.myvs1.request.count503-count = 0
server.http-service.__asadmin.request.count4xx-count = 0
server.http-service.__asadmin.request.errorCount = 0
server.http-service.server.request.count503-count = 0
server.http-service.server.request.count3xx-count = 0
server.http-service.server.request.count401-count = 0
server.http-service.myvs1.request.requestCount = 0
server.http-service.server.request.processingTime = NaN
server.http-service.myvs1.request.count304-count = 0
server.http-service.myvs1.request.count404-count = 0
server.applications.hello.server.requestCount = 159
server.http-service.__asadmin.request.count404-count = 0
server.http-service.server.request.count304-count = 0

Comment by abbagani [ 23/Sep/08 ]

Looking into the problem

Comment by kumara [ 24/Sep/08 ]

Not a must have for Prelude release.

Comment by Nazrul [ 15/Oct/08 ]

Release note that user will need to restart the server to see virtual server
changes in monitoring tier.

Comment by kumara [ 24/Oct/08 ]

Prashanth: Please be sure get this recorded in the release note. Exclude from the prelude release.

Comment by kumara [ 24/Oct/08 ]

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

Comment by Gail Risdal [ 08/Dec/09 ]

Added to v3 Release Notes.

Comment by Tom Mueller [ 06/Jan/11 ]

User is no longer on the project. Reassigning to default assignee for monitoring.

Comment by Byron Nevins [ 07/Feb/11 ]

Jennifer - can you verify that this still exists?

I'm setting it to 3.2 so it doesn't get lost...

Comment by Jennifer Chou [ 07/Feb/11 ]

This issue still exists in 3.1. It's now called Network Listeners, instead of HTTP Listeners.
Turn on monitoring for http-service.





[GLASSFISH-5261] [UB] ACC Should use JRE but not JDK Created: 05/Jul/08  Updated: 29/Apr/13

Status: In Progress
Project: glassfish
Component/s: docs
Affects Version/s: 9.1peur2
Fix Version/s: 4.0

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 5,261

 Description   

When deploying to a lot of client computers, it is not fun to install more
megabytes than needed. Currently the ACC wants to have a complete JDK (not just
JRE) installed on each client computer:

http://docs.sun.com/app/docs/doc/819-3675/package-appclient-1m?a=view

Actually it seems that the only sense of having a JDK (instead of JRE) is that
the above documentation says one shall unjar appclient.jar on the client. It
seems, there is no other part of the JDK used besides jar.exe.

So I propose that the installation procedure gets changed: Do not pack the
appclient as a JAR but as a ZIP (virtually all target operating systems already
have ZIP installed, so no need for a complete JDK anymore), or do not pack it at
all but provide an installation image file system folder instead (can be copied
to the client without the need to unpack anything there).

This will reduce the footprint of the client installation by far.



 Comments   
Comment by Snjezana Sevo-Zenzerovic [ 07/Jul/08 ]

Moving to appropriate subcategory for evaluation.

Comment by Tim Quinn [ 08/Jul/08 ]

Because JAR files are ZIP files also, you could already use a local UNZIP
utility to unpack the appclient.jar.

Have you tried that and encountered problems?

Where the documentation mentions defining AS_JAVA to point to the JDK directory,
you can instead just define it to point to the JRE directory.

Would that meet your needs?

Comment by Tom Mueller [ 06/Mar/12 ]

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

Comment by mkarg [ 14/Nov/12 ]

If I understand correctly, Tim agrees that the JRE is sufficient. So please modify the documentation.

Comment by Tim Quinn [ 16/Nov/12 ]

Changing component to documentation.

Comment by Mike Fitch [ 14/Mar/13 ]

Changed Fix Version to 4.0 so issue will show up on 4.0* queries. Actual commitment and build # TBD.

Comment by Mike Fitch [ 24/Mar/13 ]

Updated the manpage to mention that you can unzip the JAR file and to specify that you can point AS_JAVA to a JDK or JRE directory.

This update will become accessible in GlassFish when the next main-docs build is promoted and picked up by GlassFish builds.

Comment by Mike Fitch [ 01/Apr/13 ]

Correction: this manpage is not visible in GlassFish because package-appclient is not an asadmin subcommand.

Adding [UB] to the summary so this issue will get picked up by "unbundled" (book) doc queries. The material will appear in the Reference Manual.

Comment by mkarg [ 29/Apr/13 ]

As there is a Special "Server JRE" distribution available since JRE 7u21, I think it makes sense to modify the documentation that this "Server JRE" is sufficient to run GlassFish. So People don't need to download and install a fully-featured Oracle JRE (including things like ActiveX bridge etc.).





[GLASSFISH-4629] [UB]Some wrong MDB warnings at startup when attribute value is 0 Created: 06/Apr/08  Updated: 15/Mar/13

Status: Reopened
Project: glassfish
Component/s: docs
Affects Version/s: 4.0
Fix Version/s: 4.0

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

Operating System: Windows XP
Platform: PC


Issuezilla Id: 4,629

 Description   

There were a couple of observed WARNING messages during cluster startup when
some of the EJB attribute settings were 0:

For example,

error 3
[#|2008-03-27T13:32:19.175+1100|WARNING|sun-appserver9.1|javax.enterprise.system.container.ejb.mdb|_ThreadID=10;_ThreadName=main;ejbtuning_server:MDB;0;max-pool-size;1;_RequestID=6dc41603-cc8f-44d9-85d5-75abf1fc7963;|MDB00060:
[ejbtuning_server:MDB]: Invalid value [0] for [max-pool-size] , use [1] instead|#]

...

error 3
[#|2008-03-27T15:55:07.433+1100|WARNING|sun-appserver9.1|javax.enterprise.system.container.ejb.mdb|_ThreadID=10;_ThreadName=main;ejbtuning_server:MDB;0;idle-timeout-in-seconds;1;_RequestID=6dd3f8e6-6a6d-4945-b61c-c2f2b9b17f27;|MDB00060:
[ejbtuning_server:MDB]: Invalid value [0] for [idle-timeout-in-seconds] , use
[1] instead|#]

...

It seems to me that there may be a bug in the code for
MessageBeanContainer.validateValue method because the validation code is not
accounting for the fact that 0 has a special meaning for some of the MDB
attributes (accounting to the administration manual)



 Comments   
Comment by sanandal [ 11/Jan/09 ]

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

Comment by ksak [ 28/Jan/09 ]

Reassigning bugs from Mahesh

Comment by Cheng Fang [ 03/Jun/11 ]

This issue exists in 3.x too.

With <mdb-container idle-timeout-in-seconds="0">

there is this warning in server.log when running mdb tests:

[#|2011-06-03T14:47:05.425-0400|WARNING|glassfish3.2|javax.enterprise.system.container.ejb.mdb.com.sun.ejb.containers|_ThreadID=14;_ThreadName=Thread-1;|MDB00060: [ejb-ejb30-hello-mdbApp:MessageBean]: Invalid value [0] for [idle-timeout-in-seconds] , use [600] instead|#]

According to dev guide:

Idle Timeout
Specifies the maximum time in seconds that a bean can remain idle in the pool. After this
amount of time, the bean is destroyed. The default is 600 (10 minutes). A value of 0 means a
bean can remain idle indefinitely.

Comment by Nigel Deakin [ 27/Jun/11 ]

This constraint is enforced in two places, both of which need to be changed to allow a value of 0.

com.sun.ejb.containers.MessageBeanContainer (part of the EJB container in GlassFish)

com.sun.messaging.jms.ra.ActivationSpec (part of JMSRA which is part of MQ)
MQ bug MQ-103 has been opened to cover this second change.

Comment by marina vatkina [ 27/Jun/11 ]

One more note from the email discussion, that will need to go into the docs when 0 is fixed: (Nigel adds: make clear that this applies only when JMSRA is used)

If endpointPoolMaxSize < max-pool-size then the maximum number of MDB instances used at any given time will be limited to endpointPoolMaxSize

If endpointPoolMaxSize > max-pool-size then JMSRA will attempt to create more MDBs than there are in the pool, and you will see lots of messages of the form:
INFO: MQJMSRA_MR1101: createEndpoint-UnavailableException:Sleeping for:1000

So generally, users should set endpointPoolMaxSize only (or set both to the same value) since settings them to different values either has no effect or generated errors.

Comment by Nigel Deakin [ 28/Jun/11 ]

MQ bug MQ-103 has been resolved in MQ 4.6 (which will be delivered in GlassFish 3.2).

Comment by Cheng Fang [ 17/Aug/11 ]

Fixed ejb-container MessageBeanContainer in 3.2 trunk
Committed revision 48856

Comment by Cheng Fang [ 17/Aug/11 ]

re-assign to docs team to adjust GlassFish dev guide, according to Nigel and Marina's comments above.

Comment by Rebecca Parks [ 28/Nov/11 ]

Does this apply to 3.1.2?

Comment by Paul Davies [ 20/Dec/11 ]

[UB]: Unbundled documentation

Comment by Mike Fitch [ 15/Mar/13 ]

Changed fix version to 4.0 so this issue gets picked up by OSE 4.0 release queries.

Nigel & Cheng:
Given that GL 3.2 is now 4.0 and MQ 4.6 is now 5.0, am I right in assuming that this issue is applicable to GF 4.0 (which bundles MQ 5.0)?
Thanks,
--Mike





[GLASSFISH-3935] Orderly ORB shutdown behaves wrong Created: 19/Dec/07  Updated: 08/Feb/12

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 9.1pe
Fix Version/s: 4.0

Type: Bug Priority: Minor
Reporter: fmeili Assignee: Harshad Vilekar
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,935
Tags: 3_1-exclude

 Description   

In case of an orderly shutdown of GlassFish v2 it should block new incoming
requests and throw a CORBA exception with COMPLETE_NO while the shutdown is in
progress. This is documented in section "Impact of orderly shutdown" in this
document https://glassfish-corba.dev.java.net/design/orbdArchitecture.html

But the client receives an java.rmi.ServerException with a notice "server is in
STOPPING". But this exception is not a CORBA exception and so it's impossible
for the client to initiate a failover. Only if it's a CORBA exception with
COMPLETE_NO the client tries to failover, as described in this document.

The result is that all rmi-iiop calls to a server instance which is in a
shutdown in progress state will fail and will not failover to other instances.

More details are in the forum Threads
http://forums.java.net/jive/thread.jspa?threadID=34528&tstart=15
and
https://glassfish-corba.dev.java.net/servlets/ProjectForumMessageView?forumID=2940&messageID=22494



 Comments   
Comment by fmeili [ 14/Jan/08 ]
      • Issue 3935 has been confirmed by votes. ***
Comment by Ken Cavanaugh [ 06/Feb/08 ]

Changed target to V3.

Comment by sanandal [ 11/Jan/09 ]

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

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moved to v3.1.

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moving to P3: we should fix this in V3.1.

Comment by Ken Cavanaugh [ 01/Oct/10 ]

I decided to leave this in 3.1 for now, to remind me to look at it.

Comment by Ken Cavanaugh [ 08/Nov/10 ]

This issue is likely to have changed behavior significantly in GF 3.1.
But I cannot address this in GF 3.1, because for many other reasons,
we don't have a completely clean orderly shutdown. The asadmin command
stop-instance of course shuts down the instance, but it forces the shutdown
with a System.exit or equivalent mechanism due to some unresolved issues
with non-daemon threads.

There are also problems in the EJB container, because the EJB contained
does not shutdown the ORB. It should, and it should to this BEFORE it
undeploys EJBs and marks the container as STOPPED (or whatever the equivalent
is in GF 3.1). Consequently, I am moving this issue to GF 3.2 for further
consideration in the next release.

Comment by Nazrul [ 18/Nov/10 ]

Excluding from 3.1 query

Comment by Ken Cavanaugh [ 23/Feb/11 ]

Moving to orb component (where it belongs).





[GLASSFISH-3888] Can't create new InitialContext with different host Created: 02/Dec/07  Updated: 10/Oct/14

Status: Open
Project: glassfish
Component/s: orb
Affects Version/s: 9.0pe
Fix Version/s: 4.0

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

Operating System: All
Platform: All


Issuezilla Id: 3,888

 Description   

Following client code:
package test;

import java.util.Properties;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import org.logicstreams.server.engine.service.StatusService;

/**
*

  • @author Marek Mosiewicz
    */
    public class GlassfishTest {

public static void main(String args[]) {
try

{ Properties props = new Properties(); props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming"); props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost"); props.setProperty("org.omg.CORBA.ORBInitialPort", "3700"); InitialContext ic; ic = new InitialContext(props); ic.lookup(StatusService.class.getCanonicalName()); props = new Properties(); props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming"); props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); //change host to non existing one props.setProperty("org.omg.CORBA.ORBInitialHost", "bleee"); props.setProperty("org.omg.CORBA.ORBInitialPort", "3700"); ic = new InitialContext(props); //lookup succesed ic.lookup(StatusService.class.getCanonicalName()); }

catch (NamingException ex)

{ Logger.getLogger(GlassfishTest.class.getName()).log(Level.SEVERE, null, ex); }

}
}
will succeed althogh second host does not exists. Glassfish will always connect
to first entered server no matter I will change parameters for second
InitialContext. Same with port number.

Marek Mosiewicz
http://www.jotel.com.pl



 Comments   
Comment by Ken Cavanaugh [ 03/Dec/07 ]

I think what is probably happening is that the first InitialContext
sets up the single shared ORB instance that is used to communicate with
the server ORB using CosNaming. After that, a subsequent attempt to
set initial host and port is ignored, because the ORB has already been
created.

This is currently the way this is designed to work, and there is no
workaround at the new InitialContext level. CosNaming is flexible
enough to get around this, by binding the root naming context of the
second host into the namespace of the name service running on the first
host, but I don't know if there is a reasonable workaround with GlassFish.

It might be more helpful to broaden your issue and to understand what
you are trying to do, to see if there is a better way to approach the
problem.

Comment by marekmosiewicz [ 03/Dec/07 ]

I want to have dialog to choose server I want to connect. But there is also
option to verify given connection so there is possible to choose try many
different connections in application.

I believe that creating new initial context SHOULD connect to new server. If
there is shared ORB maybe it should return different part of subtree in this
case which binds to different server.

Initial Context is standrd way to connect EJB server not CORBA (we want to
connect to different servers too) (not mentioning servapp-rt.jar which is
limited to one server only)

Comment by marekmosiewicz [ 05/Dec/07 ]

I looked into the code and it would be not difficult to change it.
com.sun.enterprise.naming.SerialInitContextFactory calls for
ORBManager.getORB(Properties) where is static reference to ORB. It ignores
properties if there is already ORB instance.

I could aplly patch for it if it would be accepted. There are two solutions I
see. One add some refresh.orb property to initial context properties which will
force refresh. Second is to remember host and port and make new orb if it
changed (but there maybe also other properties which can change)

This issue also not work if you first connect to not existing host. Then there
is no way to get new host.

Comment by Ken Cavanaugh [ 06/Feb/08 ]

Changed target to V3.

A few thoughts on this:

1. It's unfortunate that the naming client is bound to the ORB. Creating an ORB
is a fairly heavy-weight operation, and we do not want to create multiple
ORBs just for handling this case.

2. This entire mechanism does not work well in a cluster. We have made all EJB
references support IIOP failover, but the bootstrap does not, which creates a
single point of failure.

3. The code example makes sense: it's the internal GlassFish implementation that
is incorrect. But it's not just an ORB problem: it spans the ORB, GlassFish,
SerialContextFactory, and the JNDI CosNaming provider.

What is needed here is a different path through the naming provider to get
a root naming context without binding the root naming context to the ORB
instance. Keeping the same APIs makes sense, and so we need to change
the context provider initialization to create an appropriate IIOP URL for
the desired name service instance while using the ORB instance in the
GlassFish server. This is probably doable, but more investigation of the
naming code is required.

Comment by sanandal [ 11/Jan/09 ]

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

Comment by Ken Cavanaugh [ 23/Mar/10 ]

Moving to v3.1.

Comment by Ken Cavanaugh [ 01/Oct/10 ]

I THINK this should in GF3.1. I should write a test and see if it does
or not.

Comment by Ken Cavanaugh [ 17/Nov/10 ]

No time to write test and make sure this is fixed in 3.1.
Deferring to 3.2. Proper use requires setting an IIOP URL
for the endpoints, rather than ORBInitialHost/Port, which as
noted only applies the first time the ORB is created.

Comment by salocinxxx [ 10/Oct/14 ]

Hi - is this issues meanwhile solved ? Thanks





[GLASSFISH-3424] Instance logs go to wrong file - partially Created: 25/Jul/07  Updated: 02/Dec/11

Status: Reopened
Project: glassfish
Component/s: admin
Affects Version/s: 9.1peur1
Fix Version/s: 4.0

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

Operating System: Windows XP
Platform: All


Attachments: Zip Archive 3424.zip    
Issuezilla Id: 3,424
Tags: 3_1-exclude

 Description   

How to reproduce:
Set the logging file for an instance to any non-default location, e.g. I set it to:
c:/temp/i1.log

Now start the instance.

default file == <as>/nodeagents/na/i1/logs/server.log
Observe that the default file (<as>/nodeagents/na/i1/logs/server.log) still
gets, in my case, 5 log messages:

[#|2007-07-25T12:15:21.593-0700|INFO|sun-appserver9.1|javax.ee.enterprise.system.tools.sync
;|IdentityManager Data: User:admin|#]

[#|2007-07-25T12:15:22.359-0700|INFO|sun-appserver9.1|javax.ee.enterprise.system.tools.sync
;0.500;|SYNC010: Synchronization completed in 0.500 seconds.|#]

[#|2007-07-25T12:15:23.093-0700|INFO|sun-appserver9.1|javax.ee.enterprise.system.tools.sync
;0.734;|SYNC073: Repository cleaning cycle took 0.734 seconds to complete.|#]

[#|2007-07-25T12:15:26.265-0700|INFO|sun-appserver9.1|javax.enterprise.system.core|_ThreadI
System Application Server 9.1 (build local) ...|#]

[#|2007-07-25T12:15:26.312-0700|INFO|sun-appserver9.1|javax.enterprise.system.core|_ThreadI
enterprise.interceptor.DynamicInterceptor;|MBeanServer started:
com.sun.enterprise.intercep

Everything thing else goes to c:/temp/i1.log as expected



 Comments   
Comment by Byron Nevins [ 25/Jul/07 ]

I mostly fixed this by:

1)Figure out the correct logfile for the instance inside NA
2)Pass this logfile to Synch.
3)create the correct FileHandler, using the file, in Sync and then fixup the logger.

Now there are TWO log messages that go into the "wrong" file. By wrong I mean
the hrd-coded <instance-root>/logs/server.log

Both of these messages are created in the core itself after the instance is
launched. I.e. the core does something like this:

create instance logger
log messages – which uses the default logfile
read domain.xml
fix the logger to use the correct logfile.

I am leaving these final 2 log messages as is – they are in the core and it's
too messy/not worth it to fix now. Here are the messages:

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

[#|2007-07-25T15:50:10.453-0700|INFO|sun-appserver9.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=pool-1-thread-2;com.sun.enterprise.interceptor.DynamicInterceptor;|MBeanServer
started: com.sun.enterprise.interceptor.DynamicInterceptor|#]

[#|2007-07-25T15:50:24.531-0700|INFO|sun-appserver9.1|javax.enterprise.system.core|_ThreadID=11;_ThreadName=main;|Starting
Sun Java System Application Server 9.1 (build local) ...|#]

Comment by gfbugbridge [ 25/Jul/07 ]

<BT6585513>

Comment by Byron Nevins [ 26/Jul/07 ]

Created an attachment (id=1065)
the fix

Comment by Byron Nevins [ 26/Jul/07 ]

fixed. changes attached

Comment by Dhiru Pandey [ 20/Aug/07 ]

Changes backed out to fix http://bugs.sun.com/view_bug.do?bug_id=6593897

Reopening the bug. Not a release stopper for 9.1

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version field since this issue isn't going to be fixed in 9.1peur1.

Comment by Byron Nevins [ 07/Feb/11 ]

I don't know if this is still applicable. Leaving it alive until I get time to investigate





[GLASSFISH-2027] <BT6400967>Type cast of user-defined class to Object for business method argument will cause MarshalException Created: 11/Jan/07  Updated: 08/Feb/12

Status: Reopened
Project: glassfish
Component/s: orb
Affects Version/s: 9.1pe
Fix Version/s: 4.0

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

Operating System: All
Platform: All


Issuezilla Id: 2,027

 Description   

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6400967
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6400967
**********READ-ONLY Data from Bugtraq Ends********



 Comments   
Comment by gfbugbridge [ 24/Jan/07 ]

*********READ-ONLY Data from Bugtraq*********************
Inside SWAN :http://swsblweb1.central.sun.com:8080/CrPrint?id=6400967
Outside SWAN :http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6400967
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Description Sun Application Server 8.1/8.2 PE, bundled with Sun Java Studio Creator 2.0/2.1
The attached file EJB_Problem.zip contains:
1. EAR-file, which included a tested stateless session EJB (directory: EJB_Many_Methods, file: EJB_Many_Methods.ear)
2. source java code of the tested EJB (directory: EJB_Many_Methods/javaSRC, files: MethodsTesterHome.java, MethodsTester.java, MethodsTesterEJB.java, UserInfo.java - user-defined class)
3. source java code of a standalone application, which is used for testing of EJB business methods (directory: EJB_Many_Methods/javaSRC, file: UserInfoClient.java)
4. client-jar file with RMI stub, created by Sun App Server 8.2 PE, when the mentioned above EAR-file was deployed on it (file: EJB_Many_MethodsClient.jar)
5. web-application, which is created by Sun Java Studio Creator 2.1 (build 060312_2) and is used for testing of EJB business methods (directory: WebApplication3)
6. additional files "sun-acc.xml" and "UserInfoClient.bat", which were used for running the standalone application

The tested EJB has 2 business methods, which differ in type of their 2nd argument only: user-defined class "javaSRC.UserInfo" and "java.lang.Object":

  • method_Collection_String_UserInfo_double(String s, UserInfo u, double d)
  • method_Collection_String_Object_double(String s, Object o, double d)

If both these methods is invoked from standalone application, there will be no issues (see lines

Collection collection = tester.method_Collection_String_UserInfo_double(
"Hello, world", new UserInfo("Alex", "Petrov", "RaveQE", 123), 123.456);

collection = tester.method_Collection_String_Object_double(
"Hello, world", "Good bye", 123.456);

collection = tester.method_Collection_String_Object_double(
"Hello, world", new UserInfo("Alex", "Petrov", "RaveQE", 123), 123.456);

in the file "EJB_Many_Methods/javaSRC/UserInfoClient.java").

In the source code above:

  • an instance of user-defined class "UserInfo" is passed as value of method argument of type "UserInfo"
  • an instance of class "java.lang.String" is passed as value of method argument of type "java.lang.Object"
  • an instance of user-defined class "UserInfo" is passed as value of method argument of type "java.lang.Object"

BUT if the method "method_Collection_String_Object_double(String, Object, double)" is invoked from deployed on Sun App Server and running web-application, the "MarshalException" will be thrown, if an instance of user-defined class "UserInfo" is passed as value of method argument of type "java.lang.Object" (see lines

textArea1.setText(methodsTesterClient1.method_Collection_String_Object_double(
"Hello, world", "Good bye", 123.456));

textArea1.setText(textArea1.getText().toString() +
methodsTesterClient1.method_Collection_String_UserInfo_double(
"Hello, world",
new javaSRC.UserInfo("Alex", "Petrov", "RaveQE", 123),
123.456));

textArea1.setText(textArea1.getText().toString() +
methodsTesterClient1.method_Collection_String_Object_double(
"Hello, world",
new javaSRC.UserInfo("Alex", "Petrov", "RaveQE", 123),
123.456));

at the end of the file "WebApplication3/src/webapplication3/Page1.java").

In other words, an attempt to cast an instance of user-defined class "UserInfo" to type "java.lang.Object", when an ejb-business method is invoked from web-application on server side, will cause the "MarshalException":

java.rmi.MarshalException: CORBA MARSHAL 1398079745 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: ---------BEGIN server-side stack trace---------
org.omg.CORBA.MARSHAL: vmcid: SUN minor code: 257 completed: Maybe
at com.sun.corba.ee.impl.logging.ORBUtilSystemException.couldNotFindClass(ORBUtilSystemException.java:8101)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:1013)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_value(CDRInputStream_1_0.java:879)
at com.sun.corba.ee.impl.encoding.CDRInputStream.read_value(CDRInputStream.java:255)
at com.sun.corba.ee.impl.corba.TCUtility.unmarshalIn(TCUtility.java:269)
at com.sun.corba.ee.impl.corba.AnyImpl.read_value(AnyImpl.java:559)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.read_any(CDRInputStream_1_0.java:739)
at com.sun.corba.ee.impl.encoding.CDRInputStream.read_any(CDRInputStream.java:226)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.readAny(Util.java:422)
at javax.rmi.CORBA.Util.readAny(Util.java:92)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.read(DynamicMethodMarshallerImpl.java:251)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readArguments(DynamicMethodMarshallerImpl.java:393)
at com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:121)
at com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:648)
...........................................................................................
at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371)
at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281)
at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)
Caused by: java.lang.ClassNotFoundException
... 83 more

---------END server-side stack trace--------- vmcid: SUN minor code: 257 completed: Maybe

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation The marshal error is caused by a classnotfoundexception. It's unclear from the stack trace snippet in the description which class is not being found, although there's a good chance it's UserInfo since that looks to be the only application class involved in the business method call in question. Requested that submitter provide the full server.log.
**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation Server.log doesn't provide any more detail about marshal error. The web app and ejb are packaged in two different applications running within the same server instance. It looks like the error occurs when the orb is unmarshalling the request before dispatching to the servant. I asked submitter to re-run with corba log-level = FINE.
Reassigning to orb team for further analysis.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Evaluation The most likely cause of this problem is a difference in the waya value type is marshaled between the Object case (which uses
Util.writeAny and marshals the object as a CORBA Any) and the
value case (which just calls write_value/read_value directly).
Determining the exact cause will require further investigation.

**********READ-ONLY Data from Bugtraq Ends********
*********READ-ONLY Data from Bugtraq*********************
Justification Priority changed from [] to [1-Very High]Type cast of user-defined class to Object for business method argument will cause XXXXXX 2006-03-20 17:43:15 GMT

Priority changed from [1-Very High] to [2-High]
downgrading to XXXXXX 2006-03-20 18:22:49 GMT

Priority changed from [2-High] to [4-Low]
not a regression and too hard to fix 2 days before XXXXXX 2006-03-24 21:47:28 GMT

**********READ-ONLY Data from Bugtraq Ends********

Comment by Ken Cavanaugh [ 06/Feb/08 ]

Moved target to V3.

Comment by Ken Cavanaugh [ 16/Mar/10 ]

Closing since also present in bugster

Comment by Ken Cavanaugh [ 17/Nov/10 ]

Re-opening issue for GF 3.2, because now I track everything in IssueTracker
and avoid bugster whenever possible. Closing issue 6400967 in bugster,
but that issue may contain more useful information.





Generated at Sun Jul 05 21:27:54 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.