Simple howto for launching application clients using applicationlauncher.jar
Hi there peeps, I've spent the last few hours looking at how to best launch application clients, and I couldn't find any documentation on how to do it nicely (apart from Joe Ottingers's stuff on auto started application clients - http://www.orionsupport.com/articles/appclient.html). I then discovered I was doing it the hard way, and it occurred to me that others may also be doing it this way, so here's what I discovered... Previously I was doing something basic like this to launch my application clients: java -jar %ORION_HOME%\orion.jar;%ORION_HOME%\;%ORION_HOME%/lib/log4j.jar;myapp-client.jar com.acme.MyAppClient And I had a jndi.properties in the same directory which specified how to connect to Orion. This is clunky and requires that you distribute all your jar files to the machine you wish to run it on. Yuck. Then, I "discovered" applicationlauncher.jar (it's not exactly hidden, it's in the Orion dir :-). This lets you launch application clients locally, even if they are installed on remote systems. Its seemingly like an Orion version of java web start. To use it, you need to ensure that your application client is deployed properly in a J2EE sense. For me, all I had to do was: - add a and tags to my application.xml like so: myapp-client.jar - copy my shared libraries into a lib dir inside my .ear file - add a manifest for myapp-client.jar with the main class and any shared libraries like so: Manifest-Version: 1.0 Main-Class: com.acme.MyAppClient Class-Path: lib/log4j.jar Now, I can launch the application client by issuing the command java -jar c:\apps\orion\154\applicationlauncher.jar ormi://localhost/myapp/mayapp-client.jar This is cool because I don't have to frig about with the classpath or jndi.properties at launch time, presumably I could launch it on a remote machine if I wanted with similar ease (!). Presumably all you would need on the remote machine would be applicationlauncher.jar and orion.jar (rather than all your applications jar files), but I've not tested it... Anyone have any comments on this? Cheers Geoff
Re: Orion application clients and Java Web Start
> Suggestions? Is the Java Web Start environment (classloader, > security manager, etc) interfering with Orion? IIRC this is an old issue discussed a lot at the java web start forums on forums.java.sun.com. Try to do a search on Java Web Start + Weblogic/J2EE/EJB, and I think you will probably find some information about problem with the use of the context classloader. (I have actually gotten a JWS + EJB development-hack to work, so it is possible - I just don't remember the actual details ;) > Regards, > /Magnus /Anders
Orion application clients and Java Web Start
Hi, I have an application client that uses EJB that I like to distribute through Java Web Start. The client works fine with both the ApplicationClientInitialContextFactory and the RMIInitialContextFactory JNDI factories when launched from the command line, however when launched from the Java Web Start program manager the client hangs in either new InitalContext() or the ctx.lookup call depending on which of the factories I use. No error messages are given in the logfile. The ear, web application and application client are all run locally with orion 1.5.2. As a side note, if I kill the orion server just after launching the application client through Java Web Start I get: java.io.StreamCorruptedException: InputStream does not contain a serialized object at com.evermind.server.rmi.RMIContext.lookup(Unknown Source) at javax.naming.InitialContext.lookup(Unknown Source) so it seems that some kind of connection is established between the client and the server. Suggestions? Is the Java Web Start environment (classloader, security manager, etc) interfering with Orion? Regards, /Magnus
Re: Security bug with application clients? (More Info)
Lachezar's second example is exactly what I tried,
and I got the same results.
I started looking at the docs related to web
clients, trying to figure out if there was something different between
web-client security and application-client security. (First, I need to
mention that I know next to nothing about web cliens or servlets.) The
Orion security primer on jollem.com seems only to set up permissions per jsp,
not actual ejb security. Is this correct, or does anybody have actual ejb
security working with web clients? (If so, is this using orion's web
server, or apache/tomcat?)
Additionally, I tried using the
RoleManager... First of all, you cannot get a role manager from a
client. It is only available inside EJBs. No problem, I
figured, I can have a "login" account, which will allow the user to connect to
an "authentication" bean to do a "RoleManager.login". Within the context
of the "authentication" bean, this seemed to work. However, on return of
the function call, the principal reverted to the "login" account. (I
suppose you could pass username & password to every method call and
"RoleManager.login" for each one... But what a hack that would be.)
Mike
- Original Message -
From:
Lachezar
Dobrev
To: Orion-Interest
Sent: Wednesday, June 13, 2001 2:31
AM
Subject: RE: Security bug with
application clients? (More Info)
Hello.
Here I want to provide more
information on the problem.
Just for
clarification.
The problem is NOT the security
itself. It works just fine.
The problem lies IMHO in caching
or something.
It is also seen only in the RMI
connection.
EXAMPLE: Consider following
situation:
We have machine OrionA and
OrionB, both running Orion.
Both have a deployed
TestEjb.
TestEjb is:
TestEjbHome
-> Home interface
TestEjbBean
-> Bean class
TestEjb
-> Remote interface.
TestEjb.doTheJob() -> returns a String containing
the
name of the machine the
bean
was executed on
(OrionA
or OrionB)
We have a standalone
client:
public class ResourceTest
{
public static
void main(String[] args){
Context CTX;
Hashtable CtxParams;
TestEjbHome TheHome;
TestEjb TheBean;
// Connect to OrionA and
execute the TestEjb bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider
is the OrionA machine
CtxParams.put (Context.PROVIDER_URL, "ormi://OrionA/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "First
execution on: " + TheBean.doTheJob() );
// Conect to OrionB and execute the TestEjb
bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider
is the OrionB machine
CtxParams.put (Context.PROVIDER_URL, "ormi://OrionB/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "Second
execution on: " + TheBean.doTheJob() );
}
}
Running the above with the
propper libraries should yeld:
First execution on:
OrionA
Second execution on:
OrionB
HOWEVER! The real sitch
returns:
First execution on:
OrionA
Second execution on:
OrionA
Another test:
Modify the code, so that the
bean returns the user name;
Modify the client, so that
it connects to one and the same provider, but with different
user_names.
Code should yeld:
First execution on:
user1
Second execution on:
user2
However it returns:
First execution on:
user1
Second execution on:
user1
In other words. Connecting once
means, that till the end you are connected to the same provider with the same
user/pass.
That's it.
Lachezar.
RE: Security bug with application clients? (More Info)
Hello.
Here I want to provide more
information on the problem.
Just for clarification.
The problem is NOT the security
itself. It works just fine.
The problem lies IMHO in caching or
something.
It is also seen only in the RMI
connection.
EXAMPLE: Consider following
situation:
We have machine OrionA and
OrionB, both running Orion.
Both have a deployed
TestEjb.
TestEjb is:
TestEjbHome ->
Home interface
TestEjbBean
-> Bean class
TestEjb ->
Remote interface.
TestEjb.doTheJob() -> returns a String containing
the
name of the machine the
bean
was executed on
(OrionA
or OrionB)
We have a standalone
client:
public class ResourceTest
{
public static void
main(String[] args){
Context CTX;
Hashtable CtxParams;
TestEjbHome TheHome;
TestEjb TheBean;
// Connect to OrionA and
execute the TestEjb bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider is
the OrionA machine CtxParams.put
(Context.PROVIDER_URL, "ormi://OrionA/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "First
execution on: " + TheBean.doTheJob() );
// Conect to OrionB and execute the TestEjb bean.
CtxParams = new HashTable();
CtxParams.put (Context.INITIAL_CONTEXT_FACTORY,
"com.evermind.server.rmi.RMIInitialContextFactory");
CtxParams.put (Context.SECURITY_PRINCIPAL, "admin");
CtxParams.put (Context.SECURITY_CREDENTIALS, "123);
// Provider is
the OrionB machine
CtxParams.put (Context.PROVIDER_URL, "ormi://OrionB/TestAPP");
CTX = new InitialContext
(CtxParams);
TheHome =
PortableRemoteObject.narrow(
CTX.lookup("TestEjb"), TestEjbHome.class );
TheBean =
TheHome.create();
System.out.println( "Second
execution on: " + TheBean.doTheJob() );
}
}
Running the above with the
propper libraries should yeld:
First execution on:
OrionA
Second execution on:
OrionB
HOWEVER! The real sitch
returns:
First execution on:
OrionA
Second execution on:
OrionA
Another test:
Modify the code, so that the
bean returns the user name;
Modify the client, so that it
connects to one and the same provider, but with different
user_names.
Code should yeld:
First execution on:
user1
Second execution on:
user2
However it returns:
First execution on:
user1
Second execution on:
user1
In other words. Connecting once
means, that till the end you are connected to the same provider with the same
user/pass.
That's it.
Lachezar.
RE: Security bug with application clients?
Please give more details. It is confusing to hear that it doesn't work when
in my case all works. I checked 3 different cases:
1) WEB authentication - OK,
2) application-clent with jndi.prop file - OK.
3) remote client with properties set via Initial Context
(+RMIInitialContextFactory instead of ClientInitialContextFact) - OK.
So what's the point?
> -Original Message-
> From: cybermaster [SMTP:[EMAIL PROTECTED]]
> Sent: &yod;&vav;&fmem; &resh;&bet;&yod;&ayin;&yod; 13 &yod;&vav;&nun;&yod; 2001 01:20
> To: Orion-Interest
> Subject: RE: Security bug with application clients?
>
> Web Application Authentication seems to work fine - a client of mine is
> using FORM based authentication for a simple app. I don't know what you
> mean
> by "dynamic" identities - we store userid info in a relational db.
>
> I have not checked the j2ee specs for required behaviour of non-Web
> application clients - what do the specs say? However, I suspect the
> problem
> may have to do with the RoleManager, which to my knowledge isn't
> configurable at this time in Orion and relies on *.xml ("non-dynamic as in
> rel. db"?) role definitions. You may want to try to use RoleManager.login
> (instead of setting the JNDI properties) on your application client - I
> have
> not tried it, so don't know wether this works. You may have noticed there
> is
> no logout method specified - I don't know how a Web Session does that
> internally (but it sure works)
>
> --peter
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres
> Sent: Tuesday, June 12, 2001 10:51 AM
> To: Orion-Interest
> Subject: Re: Security bug with application clients?
>
> > I think maybe I didn't make something clear. I am using a java
> "application" client, NOT a web client. As such, I cannot invalidate
> sessions, make posts, etc.
> >
>
> I will repeat that we have seen that Orion's InitialContext and Principal
> identity
> features do not work. They do not work in servlets, they do not work in
> client apps.
> They do not work for JMS. They do not work, Sam I am. We have given up on
> using any
> container authentication short of "guest". This is only for "dynamic"
> identities.
> It appears that static identity via the 'jndi.properties' file works ok.
>
> > Orion seems to be written primarily as a web app server, and I have seen
> very little information on using it as a direct application server (in
> Orion
> literature or in the Oracle OC4J docs.) Since very few people are using
> Orion in this way, I guess I should expect to see a few bugs here and
> there.
> (I'm guessing that this is an application-client specific issue.)
> >
>
> We use Orion with standalone Java client applications. They work fine.
> Except for authentication, which does not work.
>
>
RE: Security bug with application clients?
Web Application Authentication seems to work fine - a client of mine is
using FORM based authentication for a simple app. I don't know what you mean
by "dynamic" identities - we store userid info in a relational db.
I have not checked the j2ee specs for required behaviour of non-Web
application clients - what do the specs say? However, I suspect the problem
may have to do with the RoleManager, which to my knowledge isn't
configurable at this time in Orion and relies on *.xml ("non-dynamic as in
rel. db"?) role definitions. You may want to try to use RoleManager.login
(instead of setting the JNDI properties) on your application client - I have
not tried it, so don't know wether this works. You may have noticed there is
no logout method specified - I don't know how a Web Session does that
internally (but it sure works)
--peter
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres
Sent: Tuesday, June 12, 2001 10:51 AM
To: Orion-Interest
Subject: Re: Security bug with application clients?
> I think maybe I didn't make something clear. I am using a java
"application" client, NOT a web client. As such, I cannot invalidate
sessions, make posts, etc.
>
I will repeat that we have seen that Orion's InitialContext and Principal
identity
features do not work. They do not work in servlets, they do not work in
client apps.
They do not work for JMS. They do not work, Sam I am. We have given up on
using any
container authentication short of "guest". This is only for "dynamic"
identities.
It appears that static identity via the 'jndi.properties' file works ok.
> Orion seems to be written primarily as a web app server, and I have seen
very little information on using it as a direct application server (in Orion
literature or in the Oracle OC4J docs.) Since very few people are using
Orion in this way, I guess I should expect to see a few bugs here and there.
(I'm guessing that this is an application-client specific issue.)
>
We use Orion with standalone Java client applications. They work fine.
Except for authentication, which does not work.
Re: Security bug with application clients?
> I think maybe I didn't make something clear. I am using a java "application" >client, NOT a web client. As such, I cannot invalidate sessions, make posts, etc. > I will repeat that we have seen that Orion's InitialContext and Principal identity features do not work. They do not work in servlets, they do not work in client apps. They do not work for JMS. They do not work, Sam I am. We have given up on using any container authentication short of "guest". This is only for "dynamic" identities. It appears that static identity via the 'jndi.properties' file works ok. > Orion seems to be written primarily as a web app server, and I have seen very little >information on using it as a direct application server (in Orion literature or in the >Oracle OC4J docs.) Since very few people are using Orion in this way, I guess I >should expect to see a few bugs here and there. (I'm guessing that this is an >application-client specific issue.) > We use Orion with standalone Java client applications. They work fine. Except for authentication, which does not work.
Re: Security bug with application clients?
I think maybe I didn't make something clear. I am using a java "application" client, NOT a web client. As such, I cannot invalidate sessions, make posts, etc. Orion seems to be written primarily as a web app server, and I have seen very little information on using it as a direct application server (in Orion literature or in the Oracle OC4J docs.) Since very few people are using Orion in this way, I guess I should expect to see a few bugs here and there. (I'm guessing that this is an application-client specific issue.) Anyway, I could be wrong in beleiving that the problem is in stateless session beans... As Lachezar pointed out, it might be in the InitialContext. By the way, I saw this behavior in Orion 1.4.5 and in the latest release, 1.5.2. Any suggestions are appreciated, Mike - Original Message - From: Jara, Michael To: Orion-Interest Sent: Monday, June 11, 2001 7:50 PM Subject: Security bug with application clients? Hi, I'm trying to get the security portion of a project working, in which a java client connects to a stateless session bean after login. As far as I can tell, Orion doesn't seem to properly pass around principal objects in stateless session beans. This is the sequence that my test client runs: 1. Prompt user for user ID & password 2. Create an InitialContext containing the user ID and password (as "java.naming.security.principal" and "java.naming.security.credentials", respectively.) 3. Look up the stateless session bean's home 4. home.create() the stateless session bean So far, so good. The stateless session bean correctly identifies the user ID within its session context's principal. Now I clean things up and repeat the process: 5. remove() the stateless session bean 6. close() the InitialContext (just in case... I even went so far as to remove all of its environment properties.) 7. Log on again: prompt for a different user ID & password 8. Create a new initial context as in step 2. 9. Look up the stateless session bean's home 10. home.create() the stateless session bean This is where things go wrong. I get the principal out of the stateless session bean's session context, which indicates that I'm logged in as the first user! The problem is that the bean is never calling "setSessionContext" on the second creation. If I re-start the client however, it works correctly. The only way I can think of to get around this is to use a stateful session bean instead... I don't like that, because I don't need to maintain state! Has anyone else encountered this problem? Found a solution? Thanks, Mike
Re: Security bug with application clients?
WRONG!!!
As I see it... There is nothing in
the post, that says SESSION or HTTP or JSP or SERVLET.
I have stumbled upon this problem
many times. I've raised that question on this list many times.
However... Except for threads like
"Orion deal blah, blah" I hardly see any meaningful mail on this list. Have to
use it however.
The problem comes from other
place.
SITCH:
Step 1: Set up an InitialContext
(url, factory, principal, credentials)
Step 1.1: Do your job (create,
use, remove etc.)
< watch here >
Step 2: TRY to get another
Context with something different as parameters (let's say different user, url,
password, any of these, except for the factory).
You get an InitialContext, that
points exactly to the same target as the first one. The same target server, the
same target application, the same user, the same password. This is NOT how it
should be.
The only way to get a difefrent
context is to receive an Exception while communicating. Then you can get
different Context.
WHY???
Someone on the list proposed to use
"dedicated.connection=true" in the InitialContext hashtable parameters. Haven't
seen it to work...
Hoping, to put the guns away, and do
some job, isn't that why we are here?
Lachezar.
its
in the "clean things up" step that something went wrong.
You
need to do a session.invalidate(), and then create a new guest session with a
session.create("true"). Here is the bit in the RequestProcessor of the
BluePrint (petstore):
if (event
instanceof LogoutEvent)
{
... whatever
...
session.invalidate();
whatever
HttpSession validSession = req.getSession(true);
...whatever ...
}
This
is usually done in a servlet. I would do the same thing here. Instead of using
the client - > slsb -> whatever ... use client -> servlet -> slsb
-> whatever bean. This way, you can abstract whatever login/logout and
session control directly with the servlet, and you also abstract instancing
the slsb -> whatever bean. The servlet can also be loadbalanced (the slsb
can't be) so if you want failover capability, you get it.
regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
JaraSent: Monday, June 11, 2001 6:51 PMTo:
Orion-InterestSubject: Security bug with application
clients?
Hi,
I'm trying to get the security portion of a
project working, in which a java client connects to a stateless session
bean after login. As far as I can tell, Orion doesn't seem to
properly pass around principal objects in stateless session
beans.
This is the sequence that my test client
runs:
1. Prompt user for user ID &
password
2. Create an InitialContext containing the user
ID and password (as "java.naming.security.principal" and
"java.naming.security.credentials", respectively.)
3. Look up the stateless session bean's
home
4. home.create() the stateless session
bean
So far, so good. The stateless session
bean correctly identifies the user ID within its session context's
principal. Now I clean things up and repeat the process:
5. remove() the stateless session
bean
6. close() the InitialContext (just in case...
I even went so far as to remove all of its environment
properties.)
7. Log on again: prompt for a different user ID
& password
8. Create a new initial context as in step
2.
9. Look up the stateless session bean's
home
10. home.create() the stateless session
bean
This is where things go wrong. I get the
principal out of the stateless session bean's session context, which
indicates that I'm logged in as the first user! The problem is that
the bean is never calling "setSessionContext" on the second creation.
If I re-start the client however, it works correctly.
The only way I can think of to get around this
is to use a stateful session bean instead... I don't like that,
because I don't need to maintain state! Has anyone else encountered
this problem? Found a solution?
Thanks,
Mike
RE: Security bug with application clients?
Don't jump into the conclusions. To my limited experience the Orion's authentication is very intelligent and tolerant to the user mistakes. For reference you may use OCJ4 manual (Oracle app server, see mail list ). I recommend reading it carefully. > -Original Message- > From: Michael Jara [SMTP:[EMAIL PROTECTED]] > Sent: &yod;&vav;&fmem; &shin;&lamed;&yod;&shin;&yod; 12 &yod;&vav;&nun;&yod; 2001 03:51 > To: Orion-Interest > Subject: Security bug with application clients? > > Hi, > > I'm trying to get the security portion of a project working, in which a > java client connects to a stateless session bean after login. As far as I > can tell, Orion doesn't seem to properly pass around principal objects in > stateless session beans. > > This is the sequence that my test client runs: > > 1. Prompt user for user ID & password > 2. Create an InitialContext containing the user ID and password (as > "java.naming.security.principal" and "java.naming.security.credentials", > respectively.) > 3. Look up the stateless session bean's home > 4. home.create() the stateless session bean > > So far, so good. The stateless session bean correctly identifies the user > ID within its session context's principal. Now I clean things up and > repeat the process: > > 5. remove() the stateless session bean > 6. close() the InitialContext (just in case... I even went so far as to > remove all of its environment properties.) > 7. Log on again: prompt for a different user ID & password > 8. Create a new initial context as in step 2. > 9. Look up the stateless session bean's home > 10. home.create() the stateless session bean > > This is where things go wrong. I get the principal out of the stateless > session bean's session context, which indicates that I'm logged in as the > first user! The problem is that the bean is never calling > "setSessionContext" on the second creation. If I re-start the client > however, it works correctly. > > The only way I can think of to get around this is to use a stateful > session bean instead... I don't like that, because I don't need to > maintain state! Has anyone else encountered this problem? Found a > solution? > > Thanks, > Mike
RE: Security bug with application clients?
its in
the "clean things up" step that something went wrong.
You
need to do a session.invalidate(), and then create a new guest session with a
session.create("true"). Here is the bit in the RequestProcessor of the
BluePrint (petstore):
if (event
instanceof LogoutEvent)
{
... whatever
...
session.invalidate();
whatever
HttpSession validSession = req.getSession(true);
...whatever ...
}
This
is usually done in a servlet. I would do the same thing here. Instead of using
the client - > slsb -> whatever ... use client -> servlet -> slsb
-> whatever bean. This way, you can abstract whatever login/logout and
session control directly with the servlet, and you also abstract instancing the
slsb -> whatever bean. The servlet can also be loadbalanced (the slsb can't
be) so if you want failover capability, you get it.
regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
JaraSent: Monday, June 11, 2001 6:51 PMTo:
Orion-InterestSubject: Security bug with application
clients?
Hi,
I'm trying to get the security portion of a
project working, in which a java client connects to a stateless session
bean after login. As far as I can tell, Orion doesn't seem to
properly pass around principal objects in stateless session
beans.
This is the sequence that my test client
runs:
1. Prompt user for user ID &
password
2. Create an InitialContext containing the user
ID and password (as "java.naming.security.principal" and
"java.naming.security.credentials", respectively.)
3. Look up the stateless session bean's
home
4. home.create() the stateless session
bean
So far, so good. The stateless session bean
correctly identifies the user ID within its session context's principal.
Now I clean things up and repeat the process:
5. remove() the stateless session
bean
6. close() the InitialContext (just in case... I
even went so far as to remove all of its environment properties.)
7. Log on again: prompt for a different user ID
& password
8. Create a new initial context as in step
2.
9. Look up the stateless session bean's
home
10. home.create() the stateless session
bean
This is where things go wrong. I get the
principal out of the stateless session bean's session context, which indicates
that I'm logged in as the first user! The problem is that the bean is
never calling "setSessionContext" on the second creation. If I re-start
the client however, it works correctly.
The only way I can think of to get around this is
to use a stateful session bean instead... I don't like that, because I
don't need to maintain state! Has anyone else encountered this
problem? Found a solution?
Thanks,
Mike
Security bug with application clients?
Hi, I'm trying to get the security portion of a project working, in which a java client connects to a stateless session bean after login. As far as I can tell, Orion doesn't seem to properly pass around principal objects in stateless session beans. This is the sequence that my test client runs: 1. Prompt user for user ID & password 2. Create an InitialContext containing the user ID and password (as "java.naming.security.principal" and "java.naming.security.credentials", respectively.) 3. Look up the stateless session bean's home 4. home.create() the stateless session bean So far, so good. The stateless session bean correctly identifies the user ID within its session context's principal. Now I clean things up and repeat the process: 5. remove() the stateless session bean 6. close() the InitialContext (just in case... I even went so far as to remove all of its environment properties.) 7. Log on again: prompt for a different user ID & password 8. Create a new initial context as in step 2. 9. Look up the stateless session bean's home 10. home.create() the stateless session bean This is where things go wrong. I get the principal out of the stateless session bean's session context, which indicates that I'm logged in as the first user! The problem is that the bean is never calling "setSessionContext" on the second creation. If I re-start the client however, it works correctly. The only way I can think of to get around this is to use a stateful session bean instead... I don't like that, because I don't need to maintain state! Has anyone else encountered this problem? Found a solution? Thanks, Mike
Application clients
Hi, Can anyone tell what I have to do to use EJBs in Orion from an application client? thanks, Alexander Jerusalem vknn [EMAIL PROTECTED]
RE: Application clients
There are a number of posts in the archive about how to configure the initial context (either programmatically or by using a jndi.properties file). In addition to that: Define a META-INF/application-client.xml and package it in the client's jar. Define the application client in the j2ee application.xml descriptor with . Package the client jar in the ear. Deploy the ear file. Run the client from the "applications" directory. Theoretically the client has been "deployed", but I don't think Orion does anything to it other than unpack the ear. Make sure that orion.jar is in the classpath when executing the client. This is more challenging that you would think. The Sun JDK 1.3 "java" ignores the classpath (even if you specify it on the command line) if you use the -jar parameter ($@#&%!!). You can either put your app client jar and orion.jar on the classpath and specify the main class, or you can put orion.jar in the Class-Path field of the META-INF/MANIFEST.MF for your application client (but be careful of the path). If you're running on Windows, watch out executing the app client from the orion "applications" directory (or whever you have it deployed to); subsequent deployments of the ear file will fail with an IO error because it can't write to the client jar file. Even if you haven't changed the client jar file and it shouldn't need to be written. There are probably other ways of doing this, but this is what seemed most j2ee-correct to me. I imagine some app servers do something special to the client in the process of deploying it, but Orion is not that sophisticated (yet). Jeff >-Original Message- >From: Alexander Jerusalem [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, February 21, 2001 2:11 PM >To: Orion-Interest >Subject: Application clients > > >Hi, > >Can anyone tell what I have to do to use EJBs in Orion from an >application >client? > >thanks, > >Alexander Jerusalem >vknn >[EMAIL PROTECTED] > > >
SV: Application clients
Title: SV: Application clients Check out the news app in the /demo/ directory for example. WR > -Ursprungligt meddelande- > Från: Alexander Jerusalem [mailto:[EMAIL PROTECTED]] > Skickat: den 21 februari 2001 14:11 > Till: Orion-Interest > Ämne: Application clients > > > Hi, > > Can anyone tell what I have to do to use EJBs in Orion from > an application > client? > > thanks, > > Alexander Jerusalem > vknn > [EMAIL PROTECTED] > >
Application clients howto?
Hi, i'm trying to call an EJB from an application client but orion throws a NamingException saying: "META-INF/application-client.xml resource not found". Now I have two questions: * Where should I put the application-client.xml file? * How can I put the application-client.xml file into the correct naming context? thanks, Alexander Jerusalem [EMAIL PROTECTED] vknn
Multiple application clients sharing oneMETA-INF/application-client.xml file?
For some reason the VM in JBuilder 3.5 looks in the class output directory for META-INF/application-client.xml. Two questions about this: 1. Is there a way to specify where this will be loaded from? Since all of our applications output to the same Classes directory, there's only one application-client.xml. It isn't working because not all of the EJB apps are serving the same EJBs. When the InitialContext() is created it's failing for EJB references to other apps. 2. If there isn't a way to tell the context factory in the client where to load this from, is there a way to have one context look at multiple apps? Then at least the unused references wouldn't throw NamingExceptions. /* Eric Hodges, Chief Technology Officer Mongoose Technology, Inc. "We chase cobras so you don't have to." */
Application clients and user management
Hi, all I have several app clients that have worked just fine (from a security standpoint) as long as I just used principals.xml. Having transitioned over to the user manager API's, in particular DataSourceUserManager, I've been more concerned with working out the details of having users log in over HTTP and be properly authorized by the Role Manager, which is working to a degree (the degree to which it is _not_ working has to do with groups). I noticed today that the app clients (that I was just using 'admin' as the user for) no longer recognize that user. Nothing has changed other than that I am now using the User Manager API's. "orion-application.xml", user manager or no user manager, presumably still uses the principals.xml through the appropriate tag; on the offchance that it might not I added 'admin' to the database for the user manager, but that had no effect. Has anyone else jumped this hurdle, and what did you do? Thanks very much. Arved Sandstrom
RE: ??? concerning application clients, and CMP
Hi, Robert Worked like a charm. I've got a JSP/JavaBean front end successfully calling finder methods on my CMP entity bean now. Thanks very much. Arved Sandstrom -Original Message- From: Robert Krüger [mailto:[EMAIL PROTECTED]] Sent: Friday, March 31, 2000 4:51 AM To: [EMAIL PROTECTED]; Orion-Interest Subject: Re: ??? concerning application clients, and CMP > >2. CMP > >I ran my examples for about a day before I realized that the reason that >finder methods on a CMP entity bean were returning everything, was because >no SQL was associated with the methods. This begs the question, how _do_ we >associate SQL with finder methods in the Orion scenario? I see that the >finder-method tag in orion-ejb-jar.xml ends up containing these query >strings, but where do we actually specify them in ejb-jar.xml? Or do we? you don't. just edit the SQL (the WHERE clause is specified in the query attribute) in orion-ejb-jar.xml and your changes will not get lost on redeployment. >Very, very curious. This one is a show-stopper. :-) > >Arved Sandstrom > (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
Re: ??? concerning application clients, and CMP
> >2. CMP > >I ran my examples for about a day before I realized that the reason that >finder methods on a CMP entity bean were returning everything, was because >no SQL was associated with the methods. This begs the question, how _do_ we >associate SQL with finder methods in the Orion scenario? I see that the >finder-method tag in orion-ejb-jar.xml ends up containing these query >strings, but where do we actually specify them in ejb-jar.xml? Or do we? you don't. just edit the SQL (the WHERE clause is specified in the query attribute) in orion-ejb-jar.xml and your changes will not get lost on redeployment. >Very, very curious. This one is a show-stopper. :-) > >Arved Sandstrom > (-) Robert Krüger (-) SIGNAL 7 Gesellschaft für Informationstechnologie mbH (-) Brüder-Knauß-Str. 79 - 64285 Darmstadt, (-) Tel: 06151 665401, Fax: 06151 665373 (-) [EMAIL PROTECTED], www.signal7.de
??? concerning application clients, and CMP
These are 2 separate questions. I've successfully run application clients, and used CMP, using the J2EE RI from Sun. 1. Application clients I write the client. It may be the same code that successfully ran using the RI. The application-client.xml looks like http://java.sun.com/j2ee/dtds/application-client_1_2.dtd'> RealtorClient The application client for the realtor role. A description of EjbRefName ejb/Realty Session com.eplicity.realestate.RealtyHome com.eplicity.realestate.Realty I JAR it up, include it in the EAR, and deploy. Although there are no indications how to run app clients in the docs, I found that to successfully run the news-app client it was just a case of going java -jar news-client.jar NewsClient the login prompt popped up, I went in as the admin, and entered a news item. So that seemed to work, although I found that procedure to be highly dubious since I don't see where the client-side stubs and things come into it. For example, the J2EE RI returns a client JAR that is stuffed with RMI-related classes, and I don't see how that is taking place here. Oddly enough I can also get a prompt to pop up with my own app client, although once it's dismissed nothing happens. Nevertheless I'm curious as to what the proper procedures are. 2. CMP I ran my examples for about a day before I realized that the reason that finder methods on a CMP entity bean were returning everything, was because no SQL was associated with the methods. This begs the question, how _do_ we associate SQL with finder methods in the Orion scenario? I see that the finder-method tag in orion-ejb-jar.xml ends up containing these query strings, but where do we actually specify them in ejb-jar.xml? Or do we? Very, very curious. This one is a show-stopper. :-) Arved Sandstrom
