[GLASSFISH-13066] Cluster tree node in navigation tree does not expand with available clusters Created: 20/Aug/10  Updated: 26/Sep/10  Resolved: 26/Sep/10

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 13,066

 Description   

The cluster treenode in the navigation tree does not expand to show child treenodes with defined clusters.
Selecting the cluster treenode does bring up the pane with available clusters, however.



 Comments   
Comment by Anissa Lam [ 26/Sep/10 ]

This has been fixed. cluster is showing under clusters treenode now.





[GLASSFISH-11487] Cannot enable OSGI Bundle: Exception thrown Created: 25/Jan/10  Updated: 21/Sep/10  Resolved: 21/Sep/10

Status: Resolved
Project: glassfish
Component/s: OSGi
Affects Version/s: V3
Fix Version/s: 3.1_b21

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

Operating System: Linux
Platform: Linux


Attachments: Java Archive File simple-declarative-service.jar     File webclient.war    
Issuezilla Id: 11,487

 Description   

I created an OSGI Bundle and successfully deployed it
( like in this documentation: )

If the application/bundle once is in disabled state, its not possible to restart
it again: The Cli and Admin-GUI show the following message:

There is no installed container capable of handling this application
com.sun.enterprise.deploy.shared.FileArchive@d3b8dae

I'll attach the created jars to this bug.

( Also, as a side note: Netbeans stops showing installed apps in services >
glassfish > applications once an osgi bundle is deployed )



 Comments   
Comment by domdorn [ 25/Jan/10 ]

Created an attachment (id=4180)
simple-declarative-service.jar

Comment by domdorn [ 25/Jan/10 ]

Created an attachment (id=4181)
osgi client (webapp)

Comment by domdorn [ 25/Jan/10 ]

forgot to mention to url:
http://www.javapassion.com/handsonlabs/glassfish_osgi/#Exercise_5

Comment by Sanjeeb Sahoo [ 01/Mar/10 ]

Reassigning to Jerome to look into it.

Comment by herrer4a [ 21/Apr/10 ]
      • Issue 11487 has been confirmed by votes. ***
Comment by dochez [ 17/Jul/10 ]

looks like the deployment backend is going through a complete deployment when enable() is called yet
forgetting that --type osgi was passed initially.

Reassigning to Hong.

Comment by Hong Zhang [ 21/Sep/10 ]

Derive the type information from the application config bean when invoking the
enable code path





[GLASSFISH-12092] osgi bundle should be deployed as javaee archive when --type=osgi is not specified Created: 01/Jun/10  Updated: 21/Sep/10  Resolved: 21/Sep/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 12,092

 Description   

Sahoo reported that an osgi bundle (ejb jar) was not deployed successfully as a
JavaEE archive when the --type=osgi is not specified.

I am filing the issue so I don't lose track of it while focusing on other
things right now.

My earlier investigation showed this probably has never worked. When we trying
to find suitable ArchiveHandler for an archive, we look in the
CompositeArchiveHandler list first and then the regular ArchiveHandler list (so
CompositeArchiveHandler could have the precedence when the archive matches more
than one ArchiveHandler). So in this case, the OSGiArchiveHandler was picked up
(as it's a CompositeArchiveHandler), and the EjbArchiveHandler did not get a
chance to be chosen.

One solution I was thinking is if the --type is not specified as osgi, we will
skip OSGiArchiveHandler when trying to search for appropriate archive handler.



 Comments   
Comment by Hong Zhang [ 21/Sep/10 ]

Skipped the osgi archive handler when --type is not specified as osgi, allowing
an OSGi JavaEE application to deploy as a JavaEE application when the type is
not specified.





[GLASSFISH-13554] repeated deploy message when application already deployed Created: 20/Sep/10  Updated: 21/Sep/10  Resolved: 21/Sep/10

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

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

Operating System: Windows XP
Platform: All


Issuezilla Id: 13,554

 Description   

When I accidentally deployed an application for the second time, I noticed the
same error message is shown twice:

D:\GFv3.1\glassfish-3.1-b21-09_17_2010\glassfishv3>bin\asadmin deploy web25.war
remote failure: Error occur during deployment: Application with name web25 is
already registered. Either specify that redeployment must be f
orced, or redeploy the application. Or if this is a new deployment, pick a
different name. : Application with name web25 is already register
ed. Either specify that redeployment must be forced, or redeploy the
application. Or if this is a new deployment, pick a different name.. Pl
ease see server.log for more details.

Command deploy failed.

Once would make it easier to read.



 Comments   
Comment by Hong Zhang [ 21/Sep/10 ]

Filtered out the duplicated error messag from the CLI output.





[GLASSFISH-12964] Need operand instead of option list-custom-resources, list-mail-resources, list-jndi-resources Created: 12/Aug/10  Updated: 20/Sep/10  Resolved: 20/Sep/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: 3.1_b21

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

Operating System: All
Platform: All


Issuezilla Id: 12,964

 Description   

In v3,
list-custom-resources, list-javamail-resources, list-jndi-resources has "target"
as an "option" rather than "operand".
This is a regression from v2.x where "target" was an operand. This will not be a
major issue in v3 since --target is not a valid option as v3 is a single
instance server which does not support instances/clusters.

Fix would be to make "target" as "operand" in v3.1 to be compatible with v2.x



 Comments   
Comment by Jagadish [ 12/Aug/10 ]

FIX INFORMATION :

svn log -v -r 39629

https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=22179

Comment by Jagadish [ 20/Sep/10 ]

Just in case for backward compatibility, retaining "target" option, but will be
ignored.

svn log -v -r 40981





[GLASSFISH-12062] msg key rardeployment.jndi_lookup_failed logged instead of message Created: 27/May/10  Updated: 20/Sep/10  Resolved: 20/Sep/10

Status: Resolved
Project: glassfish
Component/s: jca
Affects Version/s: 3.1
Fix Version/s: 3.1_b21

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

Operating System: All
Platform: All


Attachments: Text File server.log    
Issuezilla Id: 12,062

 Description   

Running quicklook tests on a build of my local workspace that's up to date to
r37298, I get the following error:

[exec] org.glassfish.api.admin.CommandException: remote failure: Exception
while preparing the app : java.lang.RuntimeException: javax.
naming.NamingException: Lookup failed for 'jdbc/__default' in SerialContext
[Root exception is javax.naming.NamingException: Unable to look
up resource : jdbc/__default [Root exception is
com.sun.appserv.connectors.internal.api.ConnectorRuntimeException:
rardeployment.jndi_lookup
_failed]]

Note the message key instead of a proper message.

The code is a bit weird. The key is stored in a variable, but later overridden
with a hard-coded message. Apparently here the exception occurred before the
key was overridden, and the key could not be resolved.
The package name passed to the logger
is "com.sun.enterprise.connectors.service" but the log file is
in "com/sun/logging/enterprise/resource/resourceadapter". Shouldn't those match?



 Comments   
Comment by Dies Koper [ 27/May/10 ]

Created an attachment (id=4386)
log file with full stacktrace

Comment by Jagadish [ 15/Sep/10 ]

Thanks Dies, yes we seem to try to override the message key. But if the
exception happens before that
ConnectorRuntimeException is created with the "key" as the message which is
incorrect.

Fix would be to handle the exceptions appropriately during lookup failure and
connector resource bind failure.

> The package name passed to the logger
> is "com.sun.enterprise.connectors.service" but the log file is
> in "com/sun/logging/enterprise/resource/resourceadapter". Shouldn't those match?

RSR_LOGGER's root LogStrings.properties is
com/sun/logging/enterprise/resource/resourceadapter
and so this "key" will be found appropriately.

Comment by Jagadish [ 15/Sep/10 ]

RSR_LOGGER's root LogStrings.properties is
com/sun/logging/enterprise/resource/resourceadapter
and so this "key" will be found appropriately.

please read as

RSR_LOGGER's root LogStrings.properties is
connectors/connectors-runtime/src/main/resources/com/sun/logging/enterprise/resource/resourceadapter/LogStrings.properties
and so this "key" will be found appropriately.

Comment by Jagadish [ 20/Sep/10 ]

FIX INFORMATION :

svn log -v -r 40982





[GLASSFISH-12411] Support for HttpOnly flag of JSESSIONIDSSO cookie Created: 29/Jun/10  Updated: 17/Sep/10  Resolved: 17/Sep/10

Status: Resolved
Project: glassfish
Component/s: web_container
Affects Version/s: v3.0.1
Fix Version/s: 3.1_b21

Type: Improvement Priority: Major
Reporter: koloale Assignee: Shing Wai Chan
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 12,411

 Description   

Currently there is only 'sso-cookie-secure' attribute of 'virtual-server' that
set "Secure" flag of JSESSIONIDSSO cookie and . Another attribute is also needed
to configure setting "HttpOnly" flag on JSESSIONIDSSO, the same as for
JSESSIONID in web.xml.



 Comments   
Comment by koloale [ 30/Jun/10 ]
      • Issue 12411 has been confirmed by votes. ***
Comment by Shing Wai Chan [ 30/Jun/10 ]

reassigned

Comment by Shing Wai Chan [ 30/Jun/10 ]

change subcomponent to web_container

Comment by Shing Wai Chan [ 17/Sep/10 ]

One can set the new attribute in virtual-server as follows:
asadmin set
$

{appserver.instance.name}

.http-service.virtual-server.server.sso-cookie-http-only=true

Sending
web-core/src/main/java/org/apache/catalina/authenticator/AuthenticatorBase.java
Sending web-core/src/main/java/org/apache/catalina/core/StandardHost.java
Sending web-glue/src/main/java/com/sun/enterprise/web/VirtualServer.java
Transmitting file data ...
Committed revision 40960.

Sending
src/main/java/com/sun/enterprise/config/serverbeans/VirtualServer.java
Transmitting file data .
Committed revision 40961.

Sending build.xml
Adding singleSignOnCookieHttpOnly
Adding singleSignOnCookieHttpOnly/WebTest.java
Adding singleSignOnCookieHttpOnly/build.properties
Adding singleSignOnCookieHttpOnly/build.xml
Adding singleSignOnCookieHttpOnly/descriptor
Adding singleSignOnCookieHttpOnly/descriptor/glassfish-web.xml
Adding singleSignOnCookieHttpOnly/descriptor/web.xml
Adding singleSignOnCookieHttpOnly/docroot
Adding singleSignOnCookieHttpOnly/docroot/error.jsp
Adding singleSignOnCookieHttpOnly/docroot/index.jsp
Adding singleSignOnCookieHttpOnly/docroot/login.jsp
Transmitting file data .........
Committed revision 40962.





[GLASSFISH-13486] Connector deploy error difficult to read Created: 16/Sep/10  Updated: 17/Sep/10  Resolved: 17/Sep/10

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

Type: Bug Priority: Major
Reporter: Dies Koper Assignee: Hong Zhang
Resolution: Fixed 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 j2eesample.ear    
Issuezilla Id: 13,486

 Description   

I have an ear file with a rar module which has its ra.xml in the wrong location.
The deploy error is formatted in a way that makes it hard to read:

D:\GFv3.1\glassfish-3.1-b20-09_15_2010\glassfishv3>bin\asadmin deploy
\j2eesample.ear
remote failure: Exception while loading the app : java.lang.RuntimeException:
Unable to get active RA for module j2eesample#whitebox-notx
Unable to get active RA for module j2eesample#whitebox-notxException while
invoking class com.sun.enterprise.connectors.module.ConnectorDepl
oyer load method : java.lang.RuntimeException: Unable to get active RA for
module j2eesample#whitebox-notx
Unable to get active RA for module j2eesample#whitebox-notx

Command deploy failed.

Note that:

  • The "Exception while (...)" part is appended straight after the module name. A
    line break or period+space would make it much easier to read.
  • "Unable to get active RA for module j2eesample#whitebox-notx" is printed four
    times. It doesn't make it easy on the eyes.

Also, the server log might have a clear message explaining the cause but it
doesn't get logged because the resource bundle can't be found:

[#|2010-09-16T16:07:27.156+0900|SEVERE|glassfish3.1|javax.enterprise.system.core.org.glassfish.internal.data|_ThreadID=15;_ThreadName=Thread-1;|Exception
while invoking class com.sun.enterprise.connectors.module.ConnectorDeployer load
method|#]

[#|2010-09-16T16:07:27.171+0900|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-1;|Exception
while loading the app|#]

[#|2010-09-16T16:07:27.171+0900|WARNING|glassfish3.1|javax.enterprise.system.core|_ThreadID=15;_ThreadName=Thread-1;|Can
not find resource bundle for this logger. class name that failed:
org.glassfish.internal.data.ModuleInfo|#]



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

Created an attachment (id=4901)
test app

Comment by Hong Zhang [ 16/Sep/10 ]

Funny I was just working on this yesterday:
1. improving the CLI output to conform to the proposed standard: no class name
printed out, refer to server.log for more details. Also remove the duplicate
output.
2. in the server.log, also print out the failure cause if it's set
3. fixed the logger resource bundle issue for ModuleInfo/ApplicationInfo

Please try again with today's build and see what you think. This is the current
CLI output. As the stack trace in server.log is too long. I will not add them
here.

$ asadmin deploy j2eesample.ear
remote failure: Error occur during deployment: Exception while loading the
app : Unable to get active RA for module j2eesample#whitebox-notx. Please see
server.log for more details.

Command deploy failed.

Comment by Dies Koper [ 17/Sep/10 ]

That looks very nice now Hong!
The output in the server log also looks better.

If you could just fix the grammar this issue can be closed:

Error occur during deployment
->
Error occurred during deployment

I'll try some more patterns over the next weeks and will file separate issues if
I find anything. Thanks!

Comment by Hong Zhang [ 17/Sep/10 ]

Fixed the typo, thanks for pointing it out.

Yes, more issues are welcomed to help us improve the error messages.





Generated at Thu Jul 28 05:14:32 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.