[GLASSFISH-13033] improve error message when existing jdbc/jms resource is created for another target Created: 18/Aug/10  Updated: 03/May/12  Resolved: 03/May/12

Status: Resolved
Project: glassfish
Component/s: jms
Affects Version/s: 3.1
Fix Version/s: 3.1_b28

Type: Improvement Priority: Major
Reporter: easarina Assignee: Simon Meng
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 domain.xml08_18_DAS    
Issuezilla Id: 13,033
Tags: bj-reviewed-t1

 Description   

Build 16 08/18. Installed the build on two machines and created two clusters (c1
and c2), each of them had two instances on both machines.

Then I've run create-jdbc-resource against cluster c1:
asadmin create-jdbc-resource --target c1 --connectionpoolid cmpcustomer-pool
jdbc/cmpcustomer

The resource was created. After that I've executed the same command against
DAS, but in this case the creation failed:
=========================================================
asadmin create-jdbc-resource --connectionpoolid cmpcustomer-pool jdbc/cmpcustomer
remote failure: A resource named jdbc/cmpcustomer already exists.

Command create-jdbc-resource failed.
====================================================
Then against c2 cluster, but it failed again:
============================================================
asadmin create-jdbc-resource --target c2 --connectionpoolid cmpcustomer-pool
jdbc/cmpcustomer

remote failure: A resource named jdbc/cmpcustomer already exists.

Command create-jdbc-resource failed.
====================================================================

I've tried to lis-jdbc-resources:

asadmin list-jdbc-resources c2
Nothing to list.

Command list-jdbc-resources executed successfully.

asadmin list-jdbc-resources c1
jdbc/cmpcustomer

Command list-jdbc-resources executed successfully.

asadmin list-jdbc-resources
jdbc/__TimerPool
jdbc/__default

Command list-jdbc-resources executed successfully.

So the resource was created only for c2, but at the same time I can not create
it for another cluster c1 and for DAS.
I've attached DAS domain.xml

The same happened with jms-resource.



 Comments   
Comment by easarina [ 18/Aug/10 ]

Created an attachment (id=4695)
DAS domain.xml

Comment by Tom Mueller [ 19/Aug/10 ]

The namespace for resources is the domain, not a cluster. So a domain can only
contain a single resource with a given name. If you want to have multiple
clusters or instances reference a resource, then create a resource-ref. If you
want to have two clusters that use different resources with the same name, then
create two domains. The list-jdbc-resources command actually lists all of the
resource-refs that the target has.

Shalini, can you please confirm this? And if this is not the case, please reopen
the bug.

Comment by easarina [ 19/Aug/10 ]

I agree that it works such way. but in this case the error message has to
advice to create a resource-ref to the exeistent resource, and do not tell
that this resource "already exists", because for that cluster or DAS, it
doesn't exist.

Comment by Tom Mueller [ 19/Aug/10 ]

Since this is actually a request for an improved error message, changing this to
be an enhancement.

Comment by easarina [ 25/Aug/10 ]

Also the improvemt of the error message has to be done for the create-resource-
ref.

asadmin create-resource-ref --target c2 cmpcustomer-pool
remote failure: Resource cmpcustomer-pool does not exist.

Command create-resource-ref failed.

Comment by Tom Mueller [ 25/Jan/11 ]

Clear the Fix version since this issue isn't going to be fixed for 3.1.

Comment by Jagadish [ 24/Mar/11 ]

Please refer issue GLASSFISH-14356 that is fixed for :

jdbc-resource
connector-resource
admin-object-resource
jndi-resource
custom-resource
mail-resource.

Transferring to JMS category for fixing it in jms resources.

Comment by Simon Meng [ 03/May/12 ]

jms-resource belongs to admin-object-resource. So the fix for GLASSFISH-14356 resolved this issue. The exact revision is 42538.





[GLASSFISH-14437] [regression] Can't upload a directory in a cluster Created: 05/Nov/10  Updated: 17/Feb/11  Resolved: 06/Nov/10

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

Type: Bug Priority: Major
Reporter: sherryshen Assignee: Tim Quinn
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: 14,437
Tags: 3_1-verified

 Description   

[regression] Can't upload a directory in a cluster

glassfish-3.1-b28-11_05_2010.zip
This error is observed in cluster execution of jpa tests with ear or war.
CLI031 Can't upload a directory, specify --upload=false.
The same tests passed for das run with the same build.
The same tests passed on cluster run with the early build, e.g. build 26.

To reproduce the issue in sqe test env,
http://agni-1.sfbay.sun.com/JSPWiki/Wiki.jsp?page=V31CoreBATInstruction
--get test source with co-ejb
--set up cluster and start derby based on the instruction
--run tests as below
% cd appserver-sqe/pe/ejb/ejb30/persistence/pkgEarTest8
% ant ee all_exp | tee ear.log
% cd appserver-sqe/pe/ejb/ejb30/war/jpaJTAInjectEMFLL
% ant -f buildLib.xml ee all_exp | tee war.log

For war.log:
deploy-exp-common:
[echo] deploying dir
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile
/space/test1/SRC/c31/appserver-sqe/build-config/adminpassword.txt
--interactive=false --echo=true --terse=false deploy --force=false
--precompilejsp=false --verify=false --generatermistubs=false
--availabilityenabled=false --asyncreplication=true --target sqe-cluster
--keepreposdir=false --keepfailedstubs=false --isredeploy=false
--logreportederrors=true
/space/test1/SRC/c31/appserver-sqe/build/ee/sparc_syhill_SunOS/ejb3/explode/JTAInjectEMFLLLibExp
[exec] Application deployed with name JTAInjectEMFLLLibExp.
[exec] WARNING : Command _deploy did not complete successfully on server
instance clustered_instance_1 : CLI031 Can't upload a directory, specify
--upload=false.
[exec] WARNING : Command _deploy did not complete successfully on server
instance clustered_instance_2 : CLI031 Can't upload a directory, specify
--upload=false.
[exec] Command deploy completed with warnings.

Try again with --upload=false, still see the error.

deploy-exp-common:
[echo] deploying dir
[exec] asadmin --host localhost --port 4848 --user admin --passwordfile
/space/test1/SRC/c31/appserver-sqe/build-config/adminpassword.txt
--interactive=false --echo=true --terse=false deploy --force=false
--precompilejsp=false --verify=false --generatermistubs=false
--availabilityenabled=false --asyncreplication=true --target sqe-cluster
--keepreposdir=false --keepfailedstubs=false --isredeploy=false
--logreportederrors=true --upload=false
/space/test1/SRC/c31/appserver-sqe/build/ee/sparc_syhill_SunOS/ejb3/explode/JTAInjectEMFLLLibExp
[exec] Application deployed with name JTAInjectEMFLLLibExp.
[exec] WARNING : Command _deploy did not complete successfully on server
instance clustered_instance_1 : CLI031 Can't upload a directory, specify
--upload=false.
[exec] WARNING : Command _deploy did not complete successfully on server
instance clustered_instance_2 : CLI031 Can't upload a directory, specify
--upload=false.
[exec] Command deploy completed with warnings.

ear.log has a similar error.



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

assign to tim to take a look

Comment by Tim Quinn [ 05/Nov/10 ]

Here is what I think the problem is...

I just checked in a change to RemoteAdminCommand to correct a flaw. The error
was in logic that intended to prevent uploading a directory but did not actually
do so. So I changed that.

But I forgot that when we propagate the _deploy command to instances, we
generate a zip containing generated artifacts so we can upload those artifacts
rather than re-generate them on the instance. And so on the _deploy command we
set --upload=true. And that now triggers the error now that the fix I made
yesterday actually detects if a file argument is a directory.

We will need to look into how best to address this.

Comment by Tim Quinn [ 06/Nov/10 ]

Fix checked in.

I fixed this as part of a larger check-in, so not all these files needed to
change to fix this problem! Here's the part of my check-in comments that apply
to this issue:

The fix for 14437 affects RemoteCommand and RemoteAdminCommand. The probem:
I had checked in an earlier fix because RemoteAdminCommand intended to but
did not detect and reject attempts to upload a directory (which we prohibit).
That fix broke part of deployment to instances, because for those deployments
we generate a zip file containing artifacts generated on the DAS and then
upload that zip to each instance where the app is being deployed by setting
--upload=true on the _deploy comamnd. But both asadmin and the DAS
deploy-to-instance logic use RemoteAdminCommand, so
the stricter logic I introduced earlier rejected the --upload=true because
the operand was the original directory.

Sending admin/cli/src/main/java/com/sun/enterprise/admin/cli/AsadminMain.java
Sending admin/cli/src/main/java/com/sun/enterprise/admin/cli/CLICommand.java
Sending
admin/cli/src/main/java/com/sun/enterprise/admin/cli/ProgramOptions.java
Sending
admin/cli/src/main/java/com/sun/enterprise/admin/cli/remote/RemoteCommand.java
Sending
admin/util/src/main/java/com/sun/enterprise/admin/remote/RemoteAdminCommand.java
Sending
cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/SecureAdminCommand.java
Sending
cluster/cli/src/main/java/com/sun/enterprise/admin/cli/cluster/SynchronizeInstanceCommand.java
Sending cluster/ssh/pom.xml
Sending
cluster/ssh/src/main/java/org/glassfish/cluster/ssh/connect/NodeRunner.java
Sending
cluster/ssh/src/main/java/org/glassfish/cluster/ssh/launcher/SSHLauncher.java
Sending
common/common-util/src/main/java/com/sun/enterprise/universal/process/ProcessManager.java
Adding
common/common-util/src/main/java/org/glassfish/common/util/admin/AsadminInput.java
Sending
common/common-util/src/main/java/org/glassfish/common/util/admin/AuthTokenManager.java
Sending
common/common-util/src/main/java/org/glassfish/common/util/admin/LocalStrings.properties
Sending
common/container-common/src/main/java/com/sun/enterprise/container/common/GenericAdminAuthenticator.java
Transmitting file data ...............
Committed revision 42532.

Comment by sherryshen [ 17/Feb/11 ]

Verified the fix on b30 and b43.





[GLASSFISH-14502] WebSockets don't work in latest GlassFish Created: 08/Nov/10  Updated: 26/Nov/10  Resolved: 10/Nov/10

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

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

Operating System: All
Platform: Linux


Issue Links:
Dependency
blocks GLASSFISH-13286 Not able to enable WebSocket support ... Resolved
Issuezilla Id: 14,502

 Description   

Following the youtube demo of websockets in glassfish
(http://www.youtube.com/watch?v=dPPDWzzv86U), I downloaded the chat source from
https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/samples/websockets/chat/,
built it and deployed on the latest 3.1-SNAPSHOT of GlassFish.

But when I access localhost:8080/grizzly-websockets-chat and login as "Bhavani",
it shows: Bhavani: has left the chat

I also tried creating WebSocket via a simple html:

<script>
ws = new
WebSocket("ws://192.168.1.100:8080/grizzly-websockets-chat/chat");
ws.onclose = function()

{ alert("socket closed"); }

;
</script>

and I always see "socket closed"

[Community thread
https://glassfish.dev.java.net/servlets/BrowseList?list=dev&by=thread&from=3109513]



 Comments   
Comment by oleksiys [ 08/Nov/10 ]

reassign to Justin

Comment by Ryan Lubke [ 10/Nov/10 ]

This was an issue with the chat application and not with websockets itself. Grizzly 1.9.22 has been pushed
with an updated version of the application which should resolve this issue.





[GLASSFISH-12739] ensure that secure DAS/instance communication can be established during upgrade Created: 20/Jul/10  Updated: 26/Nov/10  Resolved: 17/Nov/10

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

Type: New Feature Priority: Critical
Reporter: Tom Mueller Assignee: Tim Quinn
Resolution: Fixed 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-12724 Cluster Upgrade Resolved
blocks GLASSFISH-14467 umbrella task for upgrade testing in ... Closed
blocks GLASSFISH-13244 GlassFish 3.1 Release (root issue) Open
Issuezilla Id: 12,739
Tags: 3_1-upgrade

 Description   

This issue is for ensuring that when a node is established based on DAS data as
part of an upgrade, that secure DAS/instance communication can be established.
This may or may not require any actual changes.

For more details about cluster upgrade, see issue 12724.



 Comments   
Comment by Tim Quinn [ 28/Sep/10 ]

updated MS

Comment by Tim Quinn [ 09/Nov/10 ]

Upgrade logic checked in.

Author: tjquinn
Date: 2010-11-09 02:01:02+0000
New Revision: 42593

Added:

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/SecureAdminConfigUpgrade.java
Modified:

trunk/v3/cluster/admin/src/main/java/com/sun/enterprise/v3/admin/cluster/SecureAdminCommand.java

Log:
Adds upgrade support for secure admin.





[GLASSFISH-14530] Unable to stop standalone instance and cluster instance Created: 09/Nov/10  Updated: 10/Nov/10  Resolved: 10/Nov/10

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

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

Operating System: HP-UX
Platform: HP


Issuezilla Id: 14,530

 Description   

Unable to stop standalone instance and cluster instance , asadmin command fails
with timed out error message.

Steps to reproduce :

1.Install 3.1B27 on hpux machine.
Note : Custom installation -> create cluster / create standalone instance.
2.From command line ,execute asadmin start-instance / start-cluster , instance
will start up without any issues.
3.Try to stop the standalone / cluster instance . asadmin stop-instance command
fails with timed error message.

Console Output :
----------------

bash-2.00# ./asadmin version -v
Version = Oracle GlassFish Server 3.1 (build 27), JRE version 1.6.0.07
Command version executed successfully.

bash-2.00# ./asadmin list-instances --user admin
instance1 not running
Command list-instances executed successfully.

bash-2.00# ./asadmin start-instance --user admin instance1
Waiting for instance1 to start .................
Successfully started the instance: instance1
instance Location: /space/glassfish/3.1/b27/glassfish/nodes/localhost/instance1
Log File:
/space/glassfish/3.1/b27/glassfish/nodes/localhost/instance1/logs/server.log
Admin Port: 24848
Command start-local-instance executed successfully.
The instance, instance1, was started on host localhost
Command start-instance executed successfully.

bash-2.00# ./asadmin list-instances --user admin
instance1 running
Command list-instances executed successfully.

bash-2.00# ./asadmin stop-instance --user admin instance1
org.glassfish.api.admin.CommandException: remote failure: Timed out waiting for
instance1 to stop.
Command stop-instance failed.
bash-2.00# ./asadmin stop-instance
Enter the value for the instanceName operand> instance1
org.glassfish.api.admin.CommandException: remote failure: Timed out waiting for
instance1 to stop.
Command stop-instance failed.

---------------cluster start-up--------------------

bash-2.00# ./asadmin version -v
Version = Oracle GlassFish Server 3.1 (build 27), JRE version 1.6.0.07
Command version executed successfully.

bash-2.00# ./asadmin list-instances
instance1 not running
Command list-instances executed successfully.

bash-2.00# ./asadmin start-cluster --user admin c1
Command start-cluster executed successfully.

bash-2.00# ./asadmin list-instances
instance1 running
Command list-instances executed successfully.

bash-2.00# ./asadmin stop-cluster --user admin c1
org.glassfish.api.admin.CommandException: remote failure: instance1: Timed out
waiting for instance1 to stop.
The command stop-instance failed for: instance1
Command stop-cluster failed.



 Comments   
Comment by Tom Mueller [ 09/Nov/10 ]

Are you seeing this only on HP-UX?

Can you provide access to the HP-UX machine to debug?

Recently there were some problems with stop-local-instance which have now been
fixed. However, the symptoms from that problem were different than what you are
seeing. Can you please retry this test with a build from Nov 9 or later?

Comment by hsbhavya [ 09/Nov/10 ]

Machine Details :
Host : jeshp175.india.sun.com ( root / abc123 )
Glassfish Install location : /opt/glassfish3 OR /space/glassfish/3.1/b27

I have tried the scenario only on HPUX machine , I am not sure about other OS.

Comment by Tom Mueller [ 10/Nov/10 ]

This is fixed on the trunk, should be in b28. An install of GlassFish from today
is now available on that system in the /space/glassfish/3.1/14530-test directory
and a stand-alone instance and a cluster can be started and stopped successfully.

I suspect that this is actually a duplicate of the problems we were seeing with
secure admin.





[GLASSFISH-13961] create-local-instance: lbenabled should be a boolean Created: 13/Oct/10  Updated: 10/Nov/10  Resolved: 10/Nov/10

Status: Resolved
Project: glassfish
Component/s: load_balancer
Affects Version/s: 3.1
Fix Version/s: 3.1_b28

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: kshitiz_saxena
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: 13,961

 Description   

These are comments from the ASArch review of asadmin commands that are new to
3.1 on 10/13/2010.

The lbenabled option takes boolean values, but this isn't indicated in the usage
message. The reason for this is that it is declared as a String:

@Param(name="lbenabled", optional = true, acceptableValues = "true,false")
private String lbEnabled;

It should be declared as a boolean with an appropriate default value.



 Comments   
Comment by kshitiz_saxena [ 14/Oct/10 ]

This implementation exists for two commands : create-local-instance and
create-instance. Setting lbenabled to Boolean will start reflecting a default
value of false, which may not be the case. Default value is conditional and
cannot be correctly reflected.

Comment by Tom Mueller [ 14/Oct/10 ]

By "conditional", do you mean that lbenabled is not allowed for a stand-alone
instance, but that for an instance that is part of a cluster, lbenabled by default
is true? Thus, lbenabled really needs to have 3 values (null, true or false), and
only null is allowed for a standalone instance.

Comment by kshitiz_saxena [ 14/Oct/10 ]

There are multiple conditions
1. Standalone instance : Null value. This option is not allowed at all.
2. Clustered instance :
a) If all existing instances in cluster are disabled, then default value is false
b) If above condition does not apply, then use default value specified by system
property org.glassfish.lb-enabled-default
c) If system property is also not specified, then use default value of "true"

Comment by Bill Shannon [ 14/Oct/10 ]

Sigh. Yes, it looks like this is a case for which there's no good way to
indicate the default value automatically. You might consider providing a
custom usage message that says:

[--lbenabled[=<lbenabled>]]

And then use Boolean in the implementation so that the CLI will allow the
full boolean option syntax and will check that the value is a proper boolean
value, while still allowing you to support the null case where the option
isn't specified.

Comment by kshitiz_saxena [ 14/Oct/10 ]

Fix targeted for ms07.

Comment by kshitiz_saxena [ 10/Nov/10 ]

Changed String to Boolean and added usage text.

Comment by kshitiz_saxena [ 10/Nov/10 ]

Changed String to Boolean and added usage text.





[GLASSFISH-14443] [BLOCKING] Grizzly does not use setNeedClientAuth on SSLSocket despite config setting Created: 05/Nov/10  Updated: 09/Nov/10  Resolved: 09/Nov/10

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

Type: Bug Priority: Blocker
Reporter: Tim Quinn Assignee: Justin Lee
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: 14,443

 Description   

Grizzly does not honor a config setting of clientAuth="want"

Secure admin requires the admin listener to want SSL client auth. Thanks to
Justin's config script enable-secure-admin sets that config option.

The GrizzlyRequest.getUserPrincipal always returns null, though. After testing
with javax.net.debug=ssl I found that the server never asks the client for a cert.

As a further test, I configured the listener with clientAuth="need" and then the
logging showed the client cert exchange and GrizzlyRequest.getUserPrincipal
returned the correct Principal object.

It looks as if, in the Grizzly utils module, JSSE14SocketFactory looks for an
attribute named "clientauth" and, if found, uses its value to invoke
sslSocket.setNeedClientAuth. There seems to be no way for a caller to specify
that setWantClientAuth should be invoked instead.

I am not sure if GlassFish or other part of Grizzly is already setting an
attribute that these classes could inspect to distinguish between "need" and
"want" or whether that code might need to change also so the config info in
domain.xml is propagated into Grizzly and, eventually, the SSLSocket.



 Comments   
Comment by Ryan Lubke [ 09/Nov/10 ]

Issue resolved in the grizzly workspace (grizzly~svn:5359). Tim confirmed the fix.

Grizzly 1.9.22 integrated into 3.1-b28 branch.





[GLASSFISH-12912] create-instance should be disabled on instances Created: 06/Aug/10  Updated: 09/Nov/10  Resolved: 09/Nov/10

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

Type: Bug Priority: Major
Reporter: Byron Nevins Assignee: Tim Quinn
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,912

 Description   

I have no DAS running. I have an instance, i1, running w/ admin port = 24848

1. asadmin --port 24848 create-instance i2
Enter the value for the node option> localhost

remote failure: Exception while adding the new configuration
org.jvnet.hk2.config.TransactionFailure: Can''t find the default config (an
element named "default-
config") in domain.xml. You may specify the name of an existing config element
next time. : org.jvnet.hk2.config.TransactionFailure: Can''t find the default co
nfig (an element named "default-config") in domain.xml. You may specify the
name of an existing config element next time.

Command create-instance failed.

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

Easy Fix – disable the command on instances.



 Comments   
Comment by Byron Nevins [ 06/Aug/10 ]

See 12911 for similar bug.

I swear I'm not on a QA expedition. These bugs are just popping out at me
automatically! In this case I had the following env. variable set so I called
the instance by mistake. Good thing I did so this bug was identified!

AS_ADMIN_PORT=24848

btw the above is VERY VERY handy (thanks Bill!)

Comment by Tom Mueller [ 06/Aug/10 ]

As with issue 12911, it will not be possible for asadmin to directly run a remote
command on an instance once Tim's changes are in. But if you want to implement
this, that would be fine.

Comment by Byron Nevins [ 07/Aug/10 ]

Note that it is specifically and explicitly determining if it is running inside
of a server instance, and then explicitly trying to start itself even though it
is illogical. Almost the textbook definition of a bug.

The code is confusing to the next person maintaining it and unnecessary.

EXTREMELY easy to fix permanently.

Comment by Jennifer Chou [ 28/Sep/10 ]

Target for MS6.
Fail if env is not DAS.

if(!env.isDas())

{ String msg = Strings.get("notAllowed"); logger.warning(msg); report.setActionExitCode(ActionReport.ExitCode.FAILURE); report.setMessage(msg); return; }
Comment by Jennifer Chou [ 21/Oct/10 ]

There are 2 cases - running asadmin --port 24848 create-instance i2 with and
without DAS running.

1) With DAS running

asadmin start-domain
asadmin create-local-instance i1
asadmin start-local-instance i1
asadmin --port 24848 create-instance i2
Enter the value for the node option> localhost
remote failure: Exception while adding the new configuration Can''t find the def
ault config (an element named "default-config") in domain.xml. You may specify
the name of an existing config element next time. : org.jvnet.hk2.config.Transac
tionFailure: Can''t find the default config (an element named "default-config")
in domain.xml. You may specify the name of an existing config element next time
.
Can''t find the default config (an element named "default-config") in domain.xml
. You may specify the name of an existing config element next time.

Command create-instance failed.

2) Without DAS running

asadmin start-domain
asadmin create-local-instance i1
asadmin stop-domain
asadmin start-local-instance i1
asadmin --port 24849 create-instance i2
Enter admin user name> admin
Enter admin password for user "admin">
Authentication failed for user: admin
(Usually, this means invalid user name and/or password)
Command create-instance failed.

=====================
I can fix case #1 with the fix above and an error message is diplayed:
This fix is checked in CreateInstanceCommand.

asadmin start-domain
asadmin create-local-instance i1
asadmin start-local-instance i1
asadmin --port 24848 create-instance i2
Enter the value for the node option> localhost
remote failure: This command can only be run on DAS.

Command create-instance failed.
===========================================

Transfer to Tim to look into a better error message for case #2.

Comment by Tim Quinn [ 09/Nov/10 ]

This should now be fixed.

The correct behavior, from a security perspective, in both case #1 and #2 is for
the instance to reject the attempt to run an admin command from a client
directly to an instance with an authentication error.

We want to prevent all admin access from clients directly to instances, except
for local commands that know to use the locally-provisioned password. Yet
obviously the DAS and those local commands do need to talk to the instance admin
port. The authentication logic is where we tell whether to accept a given
request or not, based on whether it's an instance or the DAS receiving the
request and on what kind of authentication was provided on the request.





[GLASSFISH-14538] EarHandler throws NPE when used from verifier Created: 09/Nov/10  Updated: 09/Nov/10  Resolved: 09/Nov/10

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo 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: 14,538

 Description   

Thanks to auto-unboxing feature of Java 5, the following line can now throw NPE
and it does when I try to verify an ear file containing appclient jar:
if (subCl instanceof URLClassLoader &&
context.getTransientAppMetaData(ExtendedDeploymentContext.IS_TEMP_CLASSLOADER,
Boolean.class))

Fix: Check for null before using in &&. I am surprised findbugs does not catch this.



 Comments   
Comment by Sanjeeb Sahoo [ 09/Nov/10 ]
      • Issue 11744 has been marked as a duplicate of this issue. ***
Comment by Hong Zhang [ 09/Nov/10 ]

adde a null check to avoid the potential NPE when checking for the temp
classloader flag.





[GLASSFISH-14529] WarScanner throws NPE when invoked from verifier Created: 09/Nov/10  Updated: 09/Nov/10  Resolved: 09/Nov/10

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo 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: 14,529

 Description   

I have started to revisit all verifier bugs. With my local changes, when I run
verifier against a war, I get the following exception:
java.lang.NullPointerException
at
com.sun.enterprise.deployment.annotation.impl.ModuleScanner.calculateResults(ModuleScanner.java:143)
at
com.sun.enterprise.deployment.annotation.impl.WarScanner.process(WarScanner.java:146)
at
com.sun.enterprise.deployment.annotation.impl.WarScanner.process(WarScanner.java:71)
at
com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:552)
at
org.glassfish.web.embed.impl.EmbeddedWebArchivist.processAnnotations(EmbeddedWebArchivist.java:126)
at
com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:440)
at
com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:427)
at
com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:403)
at
com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:378)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:243)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:252)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:213)
at
com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at
com.sun.enterprise.tools.verifier.DescriptorFactory.createApplicationDescriptor(DescriptorFactory.java:154)
at com.sun.enterprise.tools.verifier.Verifier.initStandalone(Verifier.java:381)
at com.sun.enterprise.tools.verifier.Verifier.init(Verifier.java:189)
at com.sun.enterprise.tools.verifier.Main.main(Main.java:80)

The patch below solves the issue. Please apply if you are satisfied.

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn diff deployment/
Index:
deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/impl/WarScanner.java
===================================================================

deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/impl/WarScanner.java
(revision 42543)
+++
deployment/dol/src/main/java/com/sun/enterprise/deployment/annotation/impl/WarScanner.java
(working copy)
@@ -48,6 +48,7 @@
import org.glassfish.apf.impl.AnnotationUtils;
import org.glassfish.api.deployment.archive.ReadableArchive;
import org.glassfish.hk2.classmodel.reflect.Parser;
+import org.glassfish.hk2.classmodel.reflect.ParsingContext;
import org.glassfish.internal.api.ClassLoaderHierarchy;
import org.jvnet.hk2.annotations.Inject;
import org.jvnet.hk2.annotations.Scoped;
@@ -101,6 +102,12 @@

this.archiveFile = new File(readableArchive.getURI());
this.classLoader = classLoader;
+ if (parser == null)

{ + ParsingContext.Builder builder = new ParsingContext.Builder(); + builder.logger(logger); + ParsingContext pc = builder.build(); + parser = new Parser(pc); + }

this.classParser = parser;

if (AnnotationUtils.getLogger().isLoggable(Level.FINE)) {



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

The patch looks good. Thanks for reporting the issue and providing the patch. I
checked the other scanners to see if we need similar changes there, seems the
AppClientScanner already has similar logic, so we should be all set with your
patch.

Comment by Hong Zhang [ 09/Nov/10 ]

applied the patch





[GLASSFISH-14540] asadmin deploy does not report if incorrect value is passed to compatibility property Created: 09/Nov/10  Updated: 09/Nov/10  Resolved: 09/Nov/10

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo 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: 14,540

 Description   

asadmin deploy --help says that the only legal value for compatibility is v2,
yet it didn't even give a warning when I executed:
asadmin deploy --properties compatibility=2 foo.ear



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

will add a check for this

Comment by Hong Zhang [ 09/Nov/10 ]

Added a check for the compatibility property and provide a warning if the
specified property value is not a supported value.





[GLASSFISH-14356] Create more appropriate error message, when resources left, cluster recreated and was an attempt to recreate a resource. Created: 02/Nov/10  Updated: 08/Nov/10  Resolved: 08/Nov/10

Status: Resolved
Project: glassfish
Component/s: jdbc
Affects Version/s: 3.1
Fix Version/s: 3.1_b28

Type: Bug Priority: Major
Reporter: easarina 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: 14,356

 Description   

Build 26. Solaris 10 Sparc.

Created a cluster with two instances and created diffrent resources for that
cluster. Did not remove the resources, but deleted instances that were belong
to this cluster and deleted a cluster. Then restarted domain and recreated a
cluster and instances. Adte that tried to create the same resources again, saw
such output:

===============================================================
org.glassfish.api.admin.CommandException: remote failure: A resource named
jdbc/cmpcustomer already exists.
Command create-jdbc-resource failed.
org.glassfish.api.admin.CommandException: remote failure: Unable to create
admin object.
A resource named jms/MyQueue already exists.
Command create-jms-resource failed.
org.glassfish.api.admin.CommandException: remote failure: A JNDI resource named
jndi/simple already exists.
Command create-jndi-resource failed.
org.glassfish.api.admin.CommandException: remote failure: Resource named
mail/MyMailSession already exists.
Command create-javamail-resource failed.
============================================

But I believe that the error messages should not tell that the resource already
exists, but has to ask a user to use the create-resource-ref command instead
(because the resource will be available only after create-resource-ref will be
executed).

Also see GLASSFISH-13979.



 Comments   
Comment by Tom Mueller [ 02/Nov/10 ]

See issue 13979 for the change that Hong already made for deploy.

Comment by Jagadish [ 08/Nov/10 ]

FIX INFORMATION :
https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=25095
svn log -v -r 42538

We now fail with one of the following messages, depending on whether the
duplicate resource
1) is of same type
or
2) resource-ref also already exists
or
3)resource exists but not resource-ref.

A resource by name jdbc/__default already exists.

A JdbcResource by name jdbc/__default already exists with resource-ref in target
in1.

A JdbcResource named jdbc/__default already exists.
If you are trying to create the existing resource configuration in target in1,
please use 'create-resource-ref' command (or create resource-ref using admin
console).





[GLASSFISH-14402] Confusing verbiage on "New Node" screen Created: 03/Nov/10  Updated: 04/Nov/10  Resolved: 04/Nov/10

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

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: Sun


Issuezilla Id: 14,402

 Description   

"New Node" screen: The description of the "Installation Directory" field is
confusing:
"Installation directory of GlassFish on local machine."

Local machine in the context of the DAS? The node? The local desktop?

Less confusing verbage is as follows:
"Installation directory of GlassFish Server on the node host"



 Comments   
Comment by Anissa Lam [ 03/Nov/10 ]

Request Joe to clarify and provide the help text.

I am in the process of modifying the node creation page, to support create-node-config, and better
user experience. Stay tuned.

Comment by Joe Di Pol [ 04/Nov/10 ]

jclingan's suggest is good. How about:

"Base installation directory of GlassFish Server on the node host. For example:
/export/glassfish3"

I think it is good to give a "for example" since there is always confusion
concerning /export/glassfish3 versus /export/glassfish3/glassfish.

Comment by Anissa Lam [ 04/Nov/10 ]

Inline help changed as suggested.





[GLASSFISH-14428] Attempt to upload with directory deployment fails with IndexOutOfBounds exception Created: 04/Nov/10  Updated: 04/Nov/10  Resolved: 04/Nov/10

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

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

Operating System: All
Platform: All


Issuezilla Id: 14,428

 Description   

The asadmin code tries to prevent a user from uploading a directory during
deployment. But due to a flaw, that checking does not work and it instead
throws an IndexOutOfBounds exception.



 Comments   
Comment by Tim Quinn [ 04/Nov/10 ]

Fix checked in.

Author: tjquinn
Date: 2010-11-04 23:10:28+0000
New Revision: 42470

Modified:

trunk/v3/admin/util/src/main/java/com/sun/enterprise/admin/remote/RemoteAdminCommand.java

Log:
Fix for 14428





[GLASSFISH-14423] Page -> Help-page links blank or TBD Created: 04/Nov/10  Updated: 04/Nov/10  Resolved: 04/Nov/10

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

Type: Bug Priority: Blocker
Reporter: Mike Fitch Assignee: Mike Fitch
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: 14,423

 Description   

When clicking the Help button on several pages in the admin gui, the help window
comes up blank, with a generic page, or with a 404 error due to missing or "TBD"
entries in the Page -> Help-page mappings. This issue needs immediate correction
so that the documentation team can determine what help pages are lacking.



 Comments   
Comment by Mike Fitch [ 04/Nov/10 ]

In progress

Comment by Mike Fitch [ 04/Nov/10 ]

Committed revision 42451.

Updated these key/value pairs in cluster module's Helplinks.properties:

availabilityService=ref-availabilityservice.html
clusterApplications=ref-clusterapplications.html
clusterGeneral=ref-clustergeneral.html
clusterInstanceConfigPropperties=ref-clusterinstanceconfigproperties.html
clusterInstanceEdit=ref-clusterinstanceedit.html
clusterInstanceNew=ref-clusterinstancenew.html
clusterInstanceProperties=ref-clusterinstanceproperties.html
clusterInstances=ref-clusterinstances.html
clusterMigrateEjbTimers=ref-migrateejbtimers.html
clusterNew=ref-clusternew.html
clusterProperties=ref-clusterproperties.html
clusterrecoverTransactions=ref-recovertransactions.html
clusterResources=ref-clusterresources.html
clusters=ref-clusters.html
clusterSystemProperties=ref-clustersystemproperties.html
configurationSystemProperties=ref-configurationsystemproperties.html
gms=ref-gms.html
nodeEdit=ref-nodeedit.html
nodeNew=ref-nodenew.html
nodes=ref-nodes.html
standaloneApplications=ref-standaloneinstanceapplications.html
standaloneInstanceConfigPropperties=ref-standaloneinstanceconfigproperties.html
standaloneInstanceGeneral=ref-standaloneinstancegeneral.html
standaloneInstanceNew=ref-standaloneinstancenew.html
standaloneInstanceProperties=ref-standaloneinstanceproperties.html
standaloneInstanceResources=ref-standaloneinstanceresources.html
standaloneInstances=ref-standaloneinstances.html
sysInstanceValues=ref-sysinstancevalues.html

Updated these key/value pairs in common module's Helplinks.properties:

applicationTargetListing=ref-apptargets.html
configurationsNew=ref-configurationsnew.html
DisplayDD=ref-webapp-displaydd.html
jvmReport=ref-jvmreport.html
lifecycleTargetListing=ref-lifecycletargets.html
manageApplicationTarget=ref-appmanagetargets.html
manageLifecycleTarget=ref-lifecyclemanagetargets.html
manageResourceTarget=ref-resourcemanagetargets.html
manageVirtualServers=ref-managevirtualservers.html
resourceTargetListing=ref-resourcetargets.html

Added these key/value pairs to common module's Helplinks.properties:

logEntryDetail=ref-logentrydetail.html
serverInstResources=ref-serverinstresources.html

Updated these key/value pairs in ejb module's Helplinks.properties:

ejbContainerAvailability=ref-ejbcontaineravailability.html

Updated these key/value pairs in jms-plugin module's Helplinks.properties:

clusterPhysDest=ref-clusterphysdest.html
jmsAvailabilityService=ref-jmsavailability.html
jmsPhysicalDestinationStats=ref-jmsphysdeststats.html
serverPhysDest=ref-serverphysdest.html

Updated these key/value pairs in web module's Helplinks.properties:

webContainerAvailability=ref-webcontaineravailability.html

Also, changed the resource reference in applications.jsf to refer to the correct
resource bundle.

Also, added helpKey definition to serverInstResources.jsf.





[GLASSFISH-14414] Connection leak detection is enabled by default and gives incorect results with ACC Created: 04/Nov/10  Updated: 04/Nov/10  Resolved: 04/Nov/10

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

Type: Bug Priority: Major
Reporter: Nigel Deakin Assignee: Jagadish
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: 14,414

 Description   

If I create a connection pool using either asadmin or the admin console,
connection leak tracing is enabled by default, with a leak timeout of 3 seconds.

This means that any application client which keeps a connection open for more
than three seconds will see a warning message after three seconds, despite this
being perfectly normal and common for application clients. Example of warning
message below:

This is incorrect and confusing for users.

Please do not enable connection leak tracing by default, or ensure it doesn't
operate in the application client.

example:
[exec] WARNING: A potential connection leak detected for connection pool
qcpool. The stack trace of the thread is
> provided below :
> [exec]
com.sun.enterprise.resource.pool.ConnectionPool.setResourceStateToBusy(ConnectionPool.java:324)
> [exec]
com.sun.enterprise.resource.pool.ConnectionPool.getResourceFromPool(ConnectionPool.java:752)
> [exec]
com.sun.enterprise.resource.pool.ConnectionPool.getUnenlistedResource(ConnectionPool.java:630)
> [exec]
com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:523)
> [exec]
com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
> [exec]
com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:242)
> [exec]
com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:167)
> [exec]
com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:332)
> [exec]
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:295)
> [exec]
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:227)
> [exec]
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:156)
> [exec]
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:151)
> [exec]
com.sun.genericra.outbound.ConnectionFactory.createConnection(ConnectionFactory.java:75)
> [exec]
com.sun.genericra.outbound.ConnectionFactory.createQueueConnection(ConnectionFactory.java:115)
> [exec]
test.performance.queue.client.PerformanceClient$Sender.getDataDestConnection(PerformanceClient.java:101)
> [exec]
test.performance.queue.client.PerformanceClient$Sender.getDataDestProducer(PerformanceClient.java:121)
> [exec]
test.performance.queue.client.PerformanceClient$Sender.sendMessagesToDestination(PerformanceClient.java:224)
> [exec]
>
test.performance.queue.client.PerformanceClient$Sender.repeatedlySendMessagesToDestination(PerformanceClient.java:157)
> [exec]
test.performance.queue.client.PerformanceClient$Sender.runSender(PerformanceClient.java:85)
> [exec]
test.performance.queue.client.PerformanceClient.main(PerformanceClient.java:47)
> [exec] sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [exec]
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [exec]
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [exec] java.lang.reflect.Method.invoke(Method.java:597)
> [exec]
org.glassfish.appclient.client.acc.AppClientContainer.launch(AppClientContainer.java:432)
> [exec]
org.glassfish.appclient.client.AppClientFacade.launch(AppClientFacade.java:154)
> [exec]
org.glassfish.appclient.client.AppClientGroupFacade.main(AppClientGroupFacade.java:65)



 Comments   
Comment by Nigel Deakin [ 04/Nov/10 ]

This was observed with GlassFish 3.1 M6 (build 26).

Comment by Satish Kumar [ 04/Nov/10 ]
      • Issue 14364 has been marked as a duplicate of this issue. ***
Comment by Jagadish [ 04/Nov/10 ]

FIX INFORMATION :
https://glassfish-svn.dev.java.net/servlets/ReadMsg?list=commits&msgNo=25007
svn log -v -r 42450

Fix will be available in 5th Nov 2010 nightly / 3.1 promoted build 28





[GLASSFISH-14315] InputJarArchive returns incorrect URI for subArchives Created: 30/Oct/10  Updated: 04/Nov/10  Resolved: 04/Nov/10

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

Type: Bug Priority: Major
Reporter: Sanjeeb Sahoo 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: 14,315

 Description   

Imagine an InputJarArchive corresponding to URI "/tmp/a.jar". If a.jar contains
an entry called b.jar, then currently InputJarArchive.getSubArchive("b.jar")
returns "jar:b.jar" instead of "jar:file:/tmp/a.jar!/b.jar." The following patch
fixes the issue:

Index:
common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java
===================================================================

common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java
(revision 42252)
+++
common/src/main/java/com/sun/enterprise/deployment/deploy/shared/InputJarArchive.java
(working copy)
@@ -436,7 +436,7 @@
if (je!=null) {
JarInputStream jis = new JarInputStream(new
BufferedInputStream(jarFile.getInputStream(je)));
try

{ - ija.uri = new URI("jar",name, null); + ija.uri = new URI("jar:" + new File(jarFile.getName()).toURI()+"!/" + name); }

catch(URISyntaxException e)

{ // do nothing }

May be this is why we have the ugly piece of workaround in
ReadableArchiveScannerAdapter:
// this is non sense, the subArchive should do this job for
me but it does not.
// see the long comment from Tim on entries().
URI subURI=subArchive.getURI();
if (subURI.getScheme().startsWith("jar")) {
try

{ subURI = new URI( "jar", "file:" + uri.getSchemeSpecificPart() + "!/" + name, null); }

catch(URISyntaxException e)

{ logger.log(Level.FINE, e.getMessage(),e); }

}

If we fix this issue, the above code can be removed as well.



 Comments   
Comment by Hong Zhang [ 30/Oct/10 ]

Yes, the workaround in the ReadableArchiveScannerAdapter is for this. I do plan
to discuss with tim on this part of the logic of InputJarArchive (he knows more
about the history of the file)

Comment by Hong Zhang [ 04/Nov/10 ]

Looking at this more closely, actually the workaround in the
ReadableArchiveScannerAdapter is no longer needed. The code mentioned in the
issue is only used for InputJarArchive inside InputJarArchive, and will not be
invoked on the server side (as the top level archive is always expanded first).
I have cleaned up the code in ReadableArchiveScannerAdapter.





[GLASSFISH-14390] can't access REST from browser if authentication is required Created: 03/Nov/10  Updated: 03/Nov/10  Resolved: 03/Nov/10

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

Type: Bug Priority: Critical
Reporter: Anissa Lam Assignee: Jason Lee
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: 14,390

 Description   

Both Jennifer and I notice that once you add another admin user or add password to the admin
user, going to http:localhost:4848/management/domain will result in "Web Page Not Found"

No webpage was found for the web address: http://localhost:4848/management/domain
Below is the original error message
Error 6 (net::ERR_FILE_NOT_FOUND): The file or directory could not be found.

To reproduce this, you can go to
Domain -> Administration Password
and add a password

or
Add another admin user by going to:
-> Configuration -> Security -> Realms -> admin-realm
click on Manage User button, add another user by giving this info:

User ID: admin2
Group List: asadmin

AFter this, you cannot access REST in the browser.



 Comments   
Comment by Jennifer Chou [ 03/Nov/10 ]

Also, if you try to run a command like
http://localhost:4848/management/domain/get-runtime-info.xml

You will see

<map>
<entry key="message" value="REST: Exception java.lang.NullPointerException

at
com.sun.enterprise.container.common.GenericAdminAuthenticator.authenticateAsTrustedSender(GenericAdminAuthenticator.java:234)

at
com.sun.enterprise.container.common.GenericAdminAuthenticator.loginAsAdmin(GenericAdminAuthenticator.java:171)

at
com.sun.enterprise.container.common.GenericAdminAuthenticator.loginAsAdmin(GenericAdminAuthenticator.java:148)

at
org.glassfish.admin.rest.adapter.RestAdapter.authenticateViaAdminRealm(RestAdapter.java:304)

at org.glassfish.admin.rest.adapter.RestAdapter.authenticate(RestAdapter.java:227)

at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:161)

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)

"/>
<entry key="exit_code" value="FAILURE"/>
<entry key="command"/>
</map>

Comment by Mitesh Meswani [ 03/Nov/10 ]

Tim,

Ludo just showed me this issue. The NPE is because authRelatedHeaders is null as
passed by loginAsAdmin() two frames down the stack. May be
authenticateAsTrustedSender needs to do some more checks.

-Mitesh

Comment by Tim Quinn [ 03/Nov/10 ]

Mitesh is right.

Rather than go through the extra step of reassigning this to me and then closing
it, I'm closing it now.

Fix checked in.

Author: tjquinn
Date: 2010-11-03 22:35:19+0000
New Revision: 42436

Modified:

trunk/v3/common/container-common/src/main/java/com/sun/enterprise/container/common/GenericAdminAuthenticator.java

Comment by Tim Quinn [ 03/Nov/10 ]

Looks like it's build 28 that'll have this fix.





Generated at Sun May 24 06:21:17 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.