[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.

Generated at Wed Jan 18 08:34:08 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.