users@glassfish.java.net

Re: application-client.xml :: <callback-handler> ignores my class.

From: Witold Szczerba <pljosh.mail_at_gmail.com>
Date: Tue, 5 Dec 2006 23:51:57 +0100

/* 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
>
>