Hello, again, Witold.
I read through the NB thread quickly. I cannot take the time just now
to analyze the code fragments there.
The GlassFish unit tests include several that test annotations and
injection. One in particular is the test in this directory:
appserv-tests/devtests/ejb/ejb30/hello/session
<
https://glassfish.dev.java.net/source/browse/glassfish/appserv-tests/devtests/ejb/ejb30/hello/session/>
(If you don't have this in a local workspace, then click on the link
above to browse the GlassFish CVS repository copy.)
The client/Client.java class uses @EJB, and I just now ran the test and
it passed, meaning that the annotation processing and the injection
worked correctly.
I wish I could compare that scenario with what you have been working
with to try to see what the key differences are, but I'm afraid I don't
have the time right now.
- Tim
Witold Szczerba wrote:
> /* sorry for previous post, I sent it by accident
> * below is full version :) */
>
> Well, as long as I can use Glassfish v2 with <callback-handler> it is
> quite simple to provide my own login panel. What bothers me is how to
> provide all the necessary information, so server could treat me as
> logged in before asking application client to ask me for
> user/password. I saw example in book:
> "Mastering Enterprise JavaBeans 3.0"
> by: Rima Patel Sriganesh, Gerald Brose and Micah Silverman
> Chapter 11: Security.
> (book is available for free as PDF somewhere)
>
> What they suggested was to use JAAS on client side before creating
> InitialContext. I did not try that way (same issue as in programmatic
> login you mentioned) because that was complicated and required to
> manipulate in some config files on the client side.
> But the final effect was, that when user accessed some secured bean
> he/she was already authenticated.
>
> For me, in very short way, it looks like it should be possible to get
> Subject somehow, add private credentials to that subject and send it
> to server, so it could decide if I am in required user role or not...
> But I know that is something rather out of topic :)
>
>
> For me what you said about @EJB is very strange. You said it should be
> working, I was expecting you to say the same thing many other people
> said before on NetBeans mailing list, I mean that @EJB is not
> supported in application client outside Java EE server. Please browse
> this thread, there are statements @EJB is not supposed to work in my
> case:
> http://www.netbeans.org/servlets/ReadMsg?list=nbj2ee&msgNo=5079
> do you disagree with him?
> Well, maybe browsing that thread would not be what you would like to
> spend time on, maybe I will prepare very ultra mega simple project
> (few clicks and few lines of code when using NB5.5) with one session
> bean+remote interface, simple application client with nothing more
> that public static void main method and @EJB reference. What I have
> all the time is that when I deploy that Enterprise application (one
> EJB + Application Client) then I will not receive reference to my
> session bean - it will stay null as without @EJB annotation (of course
> application is launched using Java WebStart from server, so it will be
> in ACC, not as a standalone application).
> Well, it is so late, I will do that tomorrow from work :/
>
> p.s.
> I found one issue with Glassfish v2 and NetBeans 5.5 - it is happening
> when I try to launch my application client using NetBeans' "Run Main
> Project (F6)" button. If main project is "Enterprise Application" with
> EJB and Application Client, then it have to:
> 1) compile everything
> 2) deploy it to the server
> 3) launch Application Client
> In fact, NB5.5 with Glassfish v2 b26 is doing step (1) and (2) but it
> fails on (3). Same application configured to use Glassfish v1 has no
> problems with all 3 steps.
> The exception is in attachment. I don't know if that should be
> reported to NB5.5 or Glassfish team...
>
>
> 2006/12/5, Tim Quinn <Timothy.Quinn_at_sun.com>:
>>
>>
>> Witold Szczerba wrote:
>> > 2006/12/5, Tim Quinn <Timothy.Quinn_at_sun.com>:
>> >>
>> >>
>> >>
>> >> Witold Szczerba wrote:
>> >>
>> >
>> > Yes, I saw that 'programmatic login' description, but for me this is
>> > far, far more complicated than it should be; well I mean, why there is
>> > need to write so many lines of code, to configure some 'policy' files
>> > on the server itself, when all that is actually needed is to provide
>> > username and password or something else inside some serializable
>> > object... For me that should be something like one or two additional
>> > lines of simple code, but it is not :/ That is what bothers me :) From
>> > my point of view (which is in fact very limited) it is like doing
>> > something very, very simple in very, very complicated way...
>> I understand your frustration! Of course things would be much better if
>> your callback handler were being invoked correctly, but even building a
>> custom callback handler sounds like more work than you'd like to have to
>> do. I have had on my to-do list for a while creating a sample callback
>> handler that people could use as a starting point for their own. At
>> least that might reduce the coding that individual developers would have
>> to do to use a callback handler.
>> >
>> > And one thing about injection. You mentioned "if your app client uses
>> > annotations...". Maybe you know why @EJB annotation based injection is
>> > not working in application clients? Some time ago, I tried injecting
>> > some @Resource, I can't remember what that was, but it worked well.
>> > When I have added some @EJB public static field, all I got was null.
>> > So, the only way I can get session bean is through Context which is
>> > not what I really love, but couldn't figure out anything better :/
>> > Some people say that injection is not working for Application Clients
>> > that resides outside JEE server (like my client, using Java WebStart),
>> > but I saw @Resource object injected on my own eyes. Why @EJB isn't
>> > working that way as well?
>> The ideal would be if you have a small example that shows the problem,
>> please open a GlassFish issue and attach the sample app to the new
>> issue. This ought to be working. One other thing you can try if you
>> see problems when you launch the app client using Java Web Start is to
>> start the client using the appclient script and see if the same problem
>> occurs. This helps us know whether the problem is related to the Java
>> Web Start support itself or is a more general app client issue.
>>
>> Thanks.
>>
>> - Tim
>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
> ------------------------------------------------------------------------
>
> Copying 1 file to C:\software\workspace-nb55\EnterpriseApplication2\dist
> 2006-12-05 23:46:56 com.sun.enterprise.appclient.MainWithModuleSupport <init>
> WARNING: ACC003: Application threw an exception.
> java.lang.NoClassDefFoundError: javax/security/auth/message/config/AuthConfigFactory
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.sun.enterprise.appclient.MainWithModuleSupport.prepareSecurity(MainWithModuleSupport.java:454)
> at com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:263)
> at com.sun.enterprise.appclient.Main.main(Main.java:185)
> Exception in thread "main" java.lang.RuntimeException: java.lang.NoClassDefFoundError: javax/security/auth/message/config/AuthConfigFactory
> at com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:376)
> at com.sun.enterprise.appclient.Main.main(Main.java:185)
> Caused by: java.lang.NoClassDefFoundError: javax/security/auth/message/config/AuthConfigFactory
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.sun.enterprise.appclient.MainWithModuleSupport.prepareSecurity(MainWithModuleSupport.java:454)
> at com.sun.enterprise.appclient.MainWithModuleSupport.<init>(MainWithModuleSupport.java:263)
> ... 1 more
> Java Result: 1
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>