[GLASSFISH-6390] Validation Check: All CLIs that require classname should verify if the class can be loaded Created: 02/Oct/08  Updated: 25/Jan/11

Status: Open
Project: glassfish
Component/s: command_line_interface
Affects Version/s: V3
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Sanjeeb Sahoo Assignee: Bill Shannon
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 6,390

 Description   

I tried this command:
glassfish@~/WS/gf/v3.trunk.new$ asadmin create-auth-realm --classname=foo bar

and it succeeded even when there is no class called foo.



 Comments   
Comment by kumarjayanti [ 02/Oct/08 ]

please see server log after the command you gave, it will show

[#|2008-10-02T18:08:50.610+0530|SEVERE|GlassFish10.0|global|_ThreadID=15;_ThreadName=Thread-3;|Exception
while processing config bean changes :
java.lang.RuntimeException:
com.sun.enterprise.security.auth.realm.BadRealmException:
java.lang.ClassNotFoundException: foo
at
com.sun.enterprise.security.SecurityConfigListener.authRealmCreated(SecurityConfigListener.java:241)
at
com.sun.enterprise.security.SecurityConfigListener$1.handleAddEvent(SecurityConfigListener.java:143)
at
com.sun.enterprise.security.SecurityConfigListener$1.changed(SecurityConfigListener.java:126)
at org.jvnet.hk2.config.ConfigSupport.sortAndDispatch(ConfigSupport.java:277)
at
com.sun.enterprise.security.SecurityConfigListener.changed(SecurityConfigListener.java:112)
at
org.jvnet.hk2.config.Transactions$ConfigListenerJob.process(Transactions.java:245)
at org.jvnet.hk2.config.Transactions$ListenerInfo$1.run(Transactions.java:117)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: com.sun.enterprise.security.auth.realm.BadRealmException:
java.lang.ClassNotFoundException: foo
at com.sun.enterprise.security.auth.realm.Realm.doInstantiate(Realm.java:270)
at com.sun.enterprise.security.auth.realm.Realm.instantiate(Realm.java:165)
at
com.sun.enterprise.security.SecurityConfigListener.createRealm(SecurityConfigListener.java:298)
at
com.sun.enterprise.security.SecurityConfigListener.authRealmCreated(SecurityConfigListener.java:239)
... 12 more
Caused by: java.lang.ClassNotFoundException: foo
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:198)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClass(ContentClassLoader.java:109)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at com.sun.enterprise.security.auth.realm.Realm.doInstantiate(Realm.java:246)
... 15 more
Caused by: java.lang.ClassNotFoundException: foo
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:486)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
... 22 more

#]

so please assign this bug to admin since security module does throw an exception
but asadmin command still reports success

Comment by kumarjayanti [ 02/Oct/08 ]

Reassigning to Admin. However this is probably more difficult to fix since
Admin/AMX is submitting the Job as a Worker to be run by a ThreadPool, and hence
does not have the ability to get the result of the excecution of the worker ?.
See the stack trace i pasted above.

Comment by kumarjayanti [ 02/Oct/08 ]

reassign to admin owner

Comment by ne110415 [ 02/Oct/08 ]

reassigning to myself.

Comment by Sanjeeb Sahoo [ 02/Oct/08 ]

I actually don't see any exception in the server.log.

Comment by ne110415 [ 02/Oct/08 ]

create-auth-realm is a config insertion operation. The CLI scope is limited to
creating the config and as in earlier GF versions, there is no validation to
check if class with the provided classname can be located and loaded.
(This generic approach is reflected in various other CLIs such as create-jdbc-
connection-pool, create-audit-module etc)

At a design level, it can considered as a trade-off between using a more
dynamic and flexible configuration approach Vs. statically and conservatively
managing config operations.

Also, there is no exception in the server log as the reporter has noted.

The present implementation is backward compatible and covers its original
scope. Accordingly, marking this bug as invalid.

(In case this change is desired, an RFE would be better description although
this change in approach has to be carried over to all related CLIs too for the
sake of consistency in CLI user experience.)

Comment by Sanjeeb Sahoo [ 02/Oct/08 ]

I am very surprised that we don't do basic verification. I am reopening this bug
as an RFE to do more verification at command execution time. Feel free to change
the subject to reflect the scope of this issue.

Comment by ne110415 [ 02/Oct/08 ]

Changing the issue per earlier discussions.

Comment by ne110415 [ 02/Oct/08 ]

forgot to change component

Comment by janey [ 28/Feb/10 ]

Reassign to Bill.

Comment by Tom Mueller [ 25/Jan/11 ]

Cleared the Fix version field since this issue isn't going to be fixed in V3.





[GLASSFISH-12586] Consolidate "Pinging" Backend Created: 08/Jul/10  Updated: 25/Jan/11

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

Type: Task Priority: Major
Reporter: Byron Nevins Assignee: Bill Shannon
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: 12,586

 Description   

How do we find out if a server is running? A mess of calls to:

1) simple java.net socket calls
2) version command
3) uptime command
4) _directories commands

Perhaps we should go through and consolidate?

Assigning to Bill simply so that he can provide opinions/advice. Maybe make
this 3.2/4.0 ????



 Comments   
Comment by Bill Shannon [ 09/Jul/10 ]

Right now we have these:

LocalServerCommand.isRunning - simply tries to connect to the admin port
DASUtils.pingDAS* - executes the version command on the server
LocalServerCommand.isThisServer - uses __locations to make sure it's talking to
the correct server
LocalDomainCommand.isThisDAS - uses isThisServer
LocalServerCommand.getUptime - used when restarting

A bunch of stuff uses isRunning. A few things use pingDAS*.

The problem with isRunning is that it doesn't tell you if the server you're
asking about is the server that's actually running.

I suspect what we really need is a new method that uses __locations and also
returns detailed failure status like pingDASWithAuth, at least for the cases
where we're asking about the DAS. When asking about an instance, we may have
to settle for isRunning.

Comment by Tom Mueller [ 25/Jan/11 ]

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





[GLASSFISH-20772] GlassFish JavaMail alters Content-Disposition of MIME Parts on MultiPart message with inlined jpeg image Created: 20/Aug/13  Updated: 23/Aug/13

Status: Open
Project: glassfish
Component/s: mail
Affects Version/s: 4.0_b89_RC5
Fix Version/s: None

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

Any



 Description   

When sending an email with an inlined jpeg image using a multipart MIME message with the image being a MIME part declared with:
Content-Disposition: inline;

and referenced via cid.

GlassFish converts the mime part from being 'inline' to being 'attachment':

Content-Disposition: attachment;

And hence the image is not embedded on the email. Same test case sent via JavaSE happens correctly.

This doesn't happen for png images. inlined png images are preserved as inlined



 Comments   
Comment by Bill Shannon [ 21/Aug/13 ]

I'm sure GlassFish isn't changing the message. What evidence do you have that it is?

Are you using the same mail server for both the GlassFish test and the Java SE test?

Turn on JavaMail Session debugging by using session.setDebug(true) and the server log file will show you exactly what JavaMail is sending.

Comment by pranahata [ 22/Aug/13 ]

Hey Bill,

I deliberately made a provocative subject line to try to get attention as soon as possible. But there is something going on with the javamail implementation bundled in glassfish.

The only difference i can see in both environments is the mailcap file in the METAINF of java.mail-1.5.0.jar

The one in glassfish has the following two lines commented:

#

  1. can't support image types because java.awt.Toolkit doesn't work on servers
    #
    #image/gif;; x-java-content-handler=com.sun.mail.handlers.image_gif
    #image/jpeg;; x-java-content-handler=com.sun.mail.handlers.image_jpeg

I think when running on SE, there is a mailcap file in the JRE installation dir that has those two lines enabled.

If i do:

MailcapCommandMap mailcap = (MailcapCommandMap)CommandMap.getDefaultCommandMap();
String[] mimeTypes = mailcap.getMimeTypes();
log.debug("mailCap types are {}", Arrays.asList(mimeTypes));

In SE shows about 7, in GF environment shows about 5

I've tried a few things including adding a mailcap file to my web app and playing with the glassfis-web delegate class loader flag but no luck.

With setDebug(true) as you said, the output shows as Content-Disposition: inline; but the received email shows the jpeg as Content-Disposition: attachment;

Comment by Bill Shannon [ 23/Aug/13 ]

If the received message is different than the sent message, it's your mail server that's changing the message, not JavaMail.

I have a hard time believing that the sent message is the same both in SE and in GlassFish, but different messages are being received. If that's reproducible, I'd like to see the debug output.

The different mailcap entries shouldn't have any effect here. The mailcap entries are only used when converting a byte stream of a given MIME type to a Java object; the x-java-content-hander entry refers to the class that does the conversion. You should never need to do that when sending a message.

It might be easier to continue debugging your problem in email; send me details at javamail_ww@oracle.com.





[GLASSFISH-6816] Mail Debug Messages are written with INFO level (only some messages -- see comments) Created: 19/Nov/08  Updated: 18/Oct/10

Status: Open
Project: glassfish
Component/s: mail
Affects Version/s: 9.1peur2
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: mkarg Assignee: Bill Shannon
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: 6,816

 Description   

When enabling the Mail Debugging, then the debug messages are written using INFO
level:

[#|2008-11-19T17:01:53.330+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=24;_ThreadName=p:
thread-pool-1; w: 5;|
DEBUG: not loading file: C:\Programme\Java\jdk1.6.0_10\jre\lib\javamail.providers|#]

From the view of an administrator, this is the wrong level. Since it is DEBUG
information, it should be logged using a level of FINE, FINER or FINEST.

INFO should stay reserved for information of higher importance, to be able to
separate "essential" from "just debug" information.



 Comments   
Comment by Bill Shannon [ 19/Nov/08 ]

I'm not sure why this is happening.

When a JavaMail resource is created, it's configured to route its debug
output through a stream that converts the output into log messages.
The core of MailLogOutputStream is:

if (msg.startsWith("DEBUG"))
logger.log(Level.FINE, msg);
else
logger.log(Level.FINER, msg);

Are you using a JavaMail Session configured as a resource? Or are you creating
your own JavaMail Session and enabling debug output? In the latter case,
perhaps the app server is collecting all output to System.out and turning it
into log messages at INFO level?

Comment by mkarg [ 19/Nov/08 ]

I am solely using a mail session created using GlassFish Admin GUI as a resource
and enabled debugging in the admin GUI by clicking the check box. I am neither
creating my own mail session by API, nor am I enabling debugging by API. My code
does nothing with the JavaMail API but just ask the injected javax.mail.Session
to create a Message object, set subject, sender, receiver and body, and then
call Transport.send(message). Nothing more.

So I assume it is a bug in the GlassFish code that links JavaMail to the
MailLogOutputStream?

Comment by mkarg [ 27/Apr/09 ]

Increased priority to P3 according to
https://glassfish.dev.java.net/public/IssueTrackerPriority.html as this bug is
neither internal nor invisible. It leads to squandered time and money for the
administrator. From an economic view this is not acceptable in a production
environment.

Comment by peterwx [ 22/Jun/09 ]

V3 uses MailLogOutputStream and most JavaMail log messages are printed at FINE
in that server. However, the first 5 or so messages are printed to the console.

This is because they are printed in the javax.mail.Session constructor and V3
doesn't redirect the debug output until after Session construction is finished.
Log output looks like this:

INFO: DEBUG: JavaMail version 1.4.2
INFO: DEBUG: successfully loaded resource: /META-INF/javamail.default.providers
INFO: DEBUG: Tables of loaded providers
INFO: DEBUG: Providers Listed By Class Name: ...
INFO: DEBUG: Providers Listed By Protocol: ...
INFO: DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map
FINE: DEBUG: setDebug: JavaMail version 1.4.2
FINE: DEBUG: getProvider() returning
javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun
Microsystems, Inc]
FINE: DEBUG SMTP: useEhlo true, useAuth true
...

Comment by peterwx [ 22/Jun/09 ]

V2.1 behaves similarly – initial messages (from javax.mail.Session constructor)
are printed to the console. All subsequent messages are printed at FINE level.

Annoying, but not as widespread as hinted at. Note this can still print quite a
bit of information in production as mail sessions could be created quite
frequently. This depends on user's application, but a mail session object could
conceivably be created fresh for each usage of javamail.

Comment by peterwx [ 06/Jul/09 ]

I'm lowering this to P4 based on the following reasons:

The only messages written to the console by JavaMail (and thus logged at INFO
level) are debug messages from the javax.mail.Session constructor (and possibly
other messages logged during session construction or requisite static
initialization).

Further, this only happens if debug=true (or the properly "mail.debug=true") has
been set in the mail resource.

Once the mail session has been constructed, all subsequent mail debug messages
will be logged at FINE or FINER as designed.

The correct way to enable JavaMail debug messages in GlassFish is to set the
GlassFish JavaMail log level to the appropriate setting for the domain
configuration in question. There is a setting for this in the web based admin
console or you can use asadmin.

Do not set debug=true or add a "mail.debug=true" property in the mail resource
unless you specifically want debug messages from session construction
(occasionally useful, but not typically).

Comment by Bill Shannon [ 04/Nov/09 ]

The full fix for this will only come when JavaMail is converted to
use java.util.logging directly.





[GLASSFISH-13739] asadmin should be cygwin aware Created: 30/Sep/10  Updated: 01/Oct/10

Status: Open
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: carlavmott Assignee: Bill Shannon
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows (generic)
Platform: All


Issuezilla Id: 13,739

 Description   

Running asadmin on windows in the cgywin shell causes problems with filenames
when those filenames are passed the jvm running on windows. The user must
either escape the backslash with another backslash, put the filename in double
quotes or use a cygwin command to generate the appropriate string for the
filename to be used because the string passed to the jvm on windows will not
recognize it as valid for that platform. We recommend users to use cygwin for
SSH and therefore asadmin should be smarter about how it handles filenames.
Other commands like mvn and ant test if running in cygwin and do the right thing
with the slashes.



 Comments   
Comment by Tom Mueller [ 01/Oct/10 ]

I'm not sure how asadmin is supposed to know which arguments are filenames and
which are not.

Comment by carlavmott [ 01/Oct/10 ]

Not sure how you know this for all things passed to asadmin. I know that if on
windows where I'm using cygwin and I specify the filename for passwordfile as a
Unix style path asadmin will not find the file. I'm compiling information for
what works and what doesn't. I believe that on MKS providing a Unix style path
does work. It may be that we will have to tell the user to provide a path in a
format that is native to the OS they are running (not entirely accurate). It's
really provide a path in a format that is native for the OS that path will run
on. See below for an example where I have the DAS running on windows and the
instance is running on Unix and the paths are setup to be as the OS expects them.

On further thinking about this I don't think we can actually have asadmin do
something because it needs to know where the path will be used in addition to
where the command is run. If you have no suggestions then we can close this bug.

./asadmin --passwordfile
"C:\Users\mode\Software\cygwin\home\cmott\passphrasefile" create-node-ssh
--nodehost dhcp-rmdc-twvpn-2-vpnpool-10-159-52-130.vpn.oracle.com --sshkeyfile
"c:\Users\mode\Software\cygwin\home\cmott\.ssh\id_dsa" --sshuser cmott
--installdir /Users/cmott/gf-v3/glassfishv3/glassfish nodeF

Comment by Bill Shannon [ 01/Oct/10 ]

asadmin does know which arguments are filenames based on the type of the
parameter - File vs. String.

It seems possible that asadmin could know that it's running in a cygwin
environment and translate UNIX-style filenames to Windows-style filenames before
using them, but that would be a low priority enhancement request.

Note that arguments representing file names that will be used on a remote
machine need to be declared as String parameters to avoid any of the current
(or future) special handling of filename arguments.

Comment by Rajiv Mordani [ 01/Oct/10 ]

If you look at the scripts that run ant, mvn, etc you will see how they handle
CYGWIN. You need to basically run a command - cygpath --windows <unix-style-path>
to get the corresponding windows path and then pass that to the JVM being
launched.

Comment by Bill Shannon [ 01/Oct/10 ]

Of course the asadmin script doesn't know which arguments are filenames,
so the asadmin code itself would have to call the cygpath program to do the
translation.

Comment by Rajiv Mordani [ 01/Oct/10 ]

I agree that the asadmin script does not what command paramaters / operands are
file names. But the options for asadmin itself the script should be aware of -
like the passwordfile for example will always be a file and on cygwin you could
run cygpath from the script itself. Not sure if there are other options to
asadmin itself which are filenames. The script should handle at least those
cases. The pointer to the script was an example really of what needs to happen.





[GLASSFISH-12906] Need to provide all cli command with --usage as an option Created: 05/Aug/10  Updated: 25/Jan/11

Status: Open
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Homer Yau Assignee: Bill Shannon
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: 12,906

 Description   

Need to provide all cli command with "--usage" as an option.

User either have to type the cli command with wrong option in order to get the
available usage option.
Or User have to either type -? or --help to get help version of the available
option.

./asadmin export-http-lb-config -?
./asadmin export-http-lb-config --help

We asadmin command have --usage as an option, it will provide a much better
GlassFish user experience.

Since user may only need hints of those available options.

Instead of saying --usage is a "Invalid option".

asadmin> export-http-lb-config --usage
Invalid option: --usage
Usage: asadmin [asadmin-utility-options] export-http-lb-config
[--targets <targets>] [--config <config>] [--lbname <lbname>]
[--property <property>] [?|-help[=<help(default:false)>]] file_name
Command export-http-lb-config failed.

asadmin> export-http-lb-config -?

NAME :
export-http-lb-config -

SYNOPSIS :
export-http-lb-config [--targets=targets] [--config=config]
[--lbname=lbname] [--property=property] file_name

OPTIONS :
--lbname

--targets

--config

--property

OPERANDS :
file_name -

Command export-http-lb-config executed successfully.

asadmin> export-http-lb-config --help

NAME :
export-http-lb-config -

SYNOPSIS :
export-http-lb-config [--targets=targets] [--config=config]
[--lbname=lbname] [--property=property] file_name

OPTIONS :
--lbname

--targets

--config

--property

OPERANDS :
file_name -

Command export-http-lb-config executed successfully.



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

Just to confirm the idea...

First, it is possible to enter --usage for any command today and the usage
message will be printed (since --usage isn't a valid option for any command).

The problem with this is two-fold:

1) The command prints "invalid option" before the usage message. It it
desirable that it not do that.

2) The command returns a failure exit code. When requesting a usage message, it
is desirable that it returns a success exit code, similar to what happens with
the help command.

Comment by Homer Yau [ 09/Dec/10 ]

This is are request for adding "--usage" as an option for display
those available options in short format for user to use for any command.

This will increase usability and productivity. Instead of typing wrong options or long help man. page to display the usable options.

Comment by Tom Mueller [ 25/Jan/11 ]

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





[GLASSFISH-11563] start-domain should NOT allow --port Created: 15/Feb/10  Updated: 28/Sep/10

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

Type: Bug Priority: Minor
Reporter: Byron Nevins Assignee: Bill Shannon
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,563

 Description   

I was looking at https://glassfish.dev.java.net/issues/show_bug.cgi?id=11489 and
I noticed that they were running this command:

asadmin --host something --port 4848 start-domain

– This makes no sense and ought to be a fatal error.



 Comments   
Comment by Bill Shannon [ 28/Sep/10 ]

Should probably print a warning if one of these options that's not needed by
the command is specified.





[GLASSFISH-15471] better error message when unable to connect to the server Created: 06/Jan/11  Updated: 07/Jan/11

Status: Open
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1_b36
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: jbenoit Assignee: Bill Shannon
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

request a better error message when unable to connect to the server, but the --host option is the default localhost, as shown in use case below. In this case, asadmin should be able to look at the local domain information and see what the port might be to determine if the server(s) is running.

==========
Use case:
==========
if i change domains/domain1/domain.xml
admin-listener port="46612" i get errors below. if i change admin-port back to 4848 it doesn't error.

// start domain1 on non-default port 46612
$ ./asadmin start-domain domain1
Waiting for domain1 to start ................
Successfully started the domain : domain1
domain Location: /space/glassfish3/glassfish/domains/domain1
Log File: /space/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 46612
Command start-domain executed successfully.

$ ./asadmin list-components
Remote server does not listen for requests on [localhost:4848]. Is the server up?
No such local command, list-components. To run remote commands, start the application server (e.g. 'asadmin start-domain').
Command list-components failed.

$ ./asadmin list-components domain
Remote server does not listen for requests on [localhost:4848]. Is the server up?
No such local command, list-components. To run remote commands, start the application server (e.g. 'asadmin start-domain').
Command list-components failed.

From this output above, I knew I did asadmin start-domain, and pieced together that it is a port problem when i saw 4848, knowing I switched my admin-port to non-default. Would be better to be explicitly told it's a port problem if we know that is cause.

can this reporting be more helpful when I'm not using default admin port? Maybe something like:

$ ./asadmin list-components
Remote server does not listen for requests on [localhost:4848]. Detected that server is up, but using non-default admin-port, so pass --port <port_number> option.
No such local command, list-components. To run remote commands, start
the application server (e.g. 'asadmin start-domain').
Command list-components failed.

Here is the motivation/use case email thread from users@glassfish.java.net reiterating as to why this is requested:

http://java.net/projects/glassfish/lists/users/archive/2011-01/message/56



 Comments   
Comment by Bill Shannon [ 06/Jan/11 ]

Let me see if I understand what you want...

If the connection fails, you want it to look in the domain
directory (assuming the domain is local? or only if the host
is "localhost"?) and find the domain.xml (only if there's only
one domain? or only looking at the domain named "domain1"?),
find the port for the admin server for that domain, find out
if that domain is actually running on localhost on that port,
and then suggest that you use that port number in the future?

Is that right?

If it did all that, would it be better to just retry the command
with the port number it found, as long as you were using the
default port, and as long as the port number it found wasn't
the default port?

Is it better to assume "you probably meant port 46612" and keep
going, even though sometimes it would be wrong?

Or is it better to say "maybe you meant port 46612? if so, try
again with that port", so as to avoid ever accidentally connecting
to the wrong server?

Comment by vince kraemer [ 06/Jan/11 ]

Bill...

I would propose a fourth way... which is a mix between your "assume --port 46612 and run the risk of being wrong" and "provide a message that tells the user: maybe you should retype the command with --port 46612"

Does the following 'output' make sense...

$ ./asadmin list-components
Remote server does not listen for requests on [localhost:4848]. Detected that a Glassfish Server is running on port 46612.
Execute the command 'asadmin --port 46612 list-components'? (Y|n) <cursor stopped here>

If the user selects 'n', the command would complete with output like that shown below.

No such local command, list-components. To run remote commands, start
the application server (e.g. 'asadmin start-domain').
Command list-components failed.

If the user chose Y, then the 'new' command would execute and the output would appear.

Comment by jbenoit [ 07/Jan/11 ]

I like Vince's idea better than what is currently implemented, and I think it addresses your questions. It's a more appropriate response being returned to user in this use case.

To see current response - "Remote server does not listen for requests on [localhost:4848]. Is the server up?"

I answer "yes" to this question, but it still doesn't help me solve the problem. Yes the server's up, so now what should I do? If the server wasn't started, I'd answer "No", and then go start the server. I'd then see if this error message went away and if the command executed properly, but it still would return the same error.

Looking at other text from response I see "Remote server does not listen for requests on [localhost:4848]." That was my clue that it's looking at default port 4848, but I know that admin-port was changed. I tried to discover how to get this port info known to this command, so it wouldn't think it was using default 4848 port. That lead to me emailing users@glassfish.java.net alias asking how to pass port to list-components command, after not finding what I was looking for in 'asadmin --help list-components', see http://java.net/jira/browse/GLASSFISH-15470

The more information given back to the user initially, of how to fix the command that isn't working, the better user's chances of solving this problem, without reading "--help list-components" or consulting users email alias.

Comment by Bill Shannon [ 07/Jan/11 ]

This is one of those cases where we have to be careful that improving the situation in
a common case doesn't mislead people or set expectations that can't be met for the
less common cases.

"Automagically" choosing the correct port number in the simple case would probably lead
to surprises later.

Doing as suggested and prompting the user (when interactive) in the simple case is
probably ok. But note that as soon as you create a second domain (e.g., for testing),
you'll no longer get a prompt because there's no way to know which domain you intended
to target. And if you ever actually do remote administration, you might be surprised
at the results in this case.

Once you leave the simple case (single local domain) you really do need to understand
the administration model and the use of host names and port numbers.

Still, we could do better in this case, although I consider it relatively low priority.





[GLASSFISH-15038] certificate prompt ignores the --interactive=false option Created: 08/Dec/10  Updated: 15/Dec/10

Status: Open
Project: glassfish
Component/s: command_line_interface
Affects Version/s: 3.1_b31
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Tom Mueller Assignee: Bill Shannon
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When secure admin is enabled, a prompt is generated by the AsadminTrustManager class to see if the user wants to trust the certificate. This class uses the following code to set whether the prompt should be generated:

Console cons = System.console();
if (cons != null) {

However, the asadmin command has a --interactive option that is supposed to prevent prompts when set to false. The AsadminTrustManager is ignoring the --interactive option.



 Comments   
Comment by Harshad Vilekar [ 08/Dec/10 ]

Hudson plugin for GlassFish 3.1 cluster broke in build 31 (see 14913). The fix for the plugin depends upon this - add "asadmin --interactive=false enable-secure-admin" to the plugin startup routine for multinode cluster.

Comment by Bill Shannon [ 11/Dec/10 ]

If you actually aren't interactive, i.e., you're not attached to
a terminal, you won't get the certificate prompt. In the rare case
where you're running this from a terminal and yet still don't want
to get prompted, you can redirect stdin to /dev/null to disable to
prompt.

Note that the original intent of the --interactive flag was to compensate
for the fact that there was no way to know whether the program was
actually attached to a terminal or not. Now that we have java.io.Console
and we can tell, the --interactive flag is mostly left around for
compatibility.

While it would be possible to modify all the intervening layers between
asadmin and the AsadminTrustManager to pass in the --interactive flag,
it just doesn't seem to be worth the effort.

I've lower the priority of this bug for now. Unless I hear a strong
reason for why this really needs to be fixed, I'm likely to close it
as "will not fix".

Comment by Harshad Vilekar [ 15/Dec/10 ]

Thank you for the evaluation. I tested and confirmed that "asadmin enable-secure-admin" - when invoked from hudson plugin - does execute in non-interative mode, and doesn't wait for the certificate prompt.





Generated at Sun May 24 04:04:37 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.