Re: [JBoss-user] Blind Lookup

2001-05-16 Thread Lucian Bargaoanu


Well, just to test i've written a simple client which does

  try {
System.setSecurityManager(new
java.rmi.RMISecurityManager());
  }
  catch (java.rmi.RMISecurityException exc) {
  System.err.println(Security violation  + exc.toString());
  }
 Context ctx = getInitialContext();//standard stuff
 Object refEJB=ctx.lookup(FirstBean);

I need this client to be ignorant about FirstBeanHome. It works just as it
is on the host with JBoss ( first JBoss ).
It doesn't work on another host: java.lang.ClassNotFoundException:
FirstBeanPackage.FirstBeanHome.
On this other host I need to have JBoss installed ( second JBoss ). Probably
from within a service of this other
JBoss instance I will eventually do the loookup ( an alternative would be to
do it from an mobile agent (IBM aglet)
which arrives at this second host, so still a remote client ). But not yet.
I've read about the bug in JBoss (reported as item #424287) some time ago
and I thought that it might be the cause.
But I was troubled by the fact that it didn't work even when I've set
java.rmi.server.codebase to the path
of the jar with the bean on the first JBoss. A file:// path which is in the
local network so it is reachable from the second JBoss.

If you're not bored yet, the bigger picture.
A client makes a request for a bean to a JBoss instance ( through a custom
JNDI ). This one sends a mobile agent to
a few JBoss fellows to ask them about this name. The agent returns with a
list of servers wich have the name and
server load information. The first JBoss chooses a server based on the load
information and does a lookup to
return the reference to the client ( through the custom JNDI ). I cannot
have one JBoss instance knowing about
all the home interfaces of all its JBoss fellows.

- Original Message -
From: Alexander Kogan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, May 16, 2001 12:53 AM
Subject: Re: [JBoss-user] Blind Lookup





 Lucian Bargaoanu wrote:
 
  Thanks, actually this is more than I need. I just need to return the
result
  of  lookup.
  I've succeeded to do that locally, but from another host it doesn't
work.
  I did set a security manager.

 If by from another host you meant from another jboss instance, that
 is
 a bug. I experienced it a few month ago and recently it was discovered
 and
 filed as the bug at sourceforge.

 From other side, if you were talking about a client on another host, it
 should
 work. At least for me.

 Tell us, what are you exactly doing.



 
  //Lucian,
  //
  //it's not legal, according to spec, but it works in jboss:
 
  //try
  //{
  //Object home = context.lookup(componentName);
  //Method createMethod = home.getClass().getMethod(create,
  //null);
 
  //Object component = createMethod.invoke(home, null);
  //}
  //catch (NamingException ne) {}
 
  //and don't forget to set a SecurityManager.
 
  //good luck.
 
  //Lucian Bargaoanu wrote:
  
   I need to look up a bean without knowing about it's home interface.
   Can i do that? I tried and it tells me that it cannot find the home
   interface.
   Can't i download somehow that .class file from the server?
   Maybe with the RMI classloader.
  
   Sorry if this is a silly question.
  
   ___
   JBoss-user mailing list
   [EMAIL PROTECTED]
   http://lists.sourceforge.net/lists/listinfo/jboss-user
 
  --
  __
  Alexander Kogan  PTC   www.ptc.com
  [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494



___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-16 Thread Alexander Kogan

Hi,

Lucian Bargaoanu wrote:
 
 I've read about the bug in JBoss (reported as item #424287) some time ago
 and I thought that it might be the cause.

To me, it looks like that.


 But I was troubled by the fact that it didn't work even when I've set
 java.rmi.server.codebase to the path

I'm lost. Why do you need java.rmi.server.codebase?

 of the jar with the bean on the first JBoss. A file:// path which is in the
 local network so it is reachable from the second JBoss.

ok, but file:// path doesn't include the host/machine name. Even if all
filesystems are mounted together, the local and network paths are
different.
Don't I understand something.

 
 If you're not bored yet, the bigger picture.
 A client makes a request for a bean to a JBoss instance ( through a custom
 JNDI ). This one sends a mobile agent to
 a few JBoss fellows to ask them about this name. The agent returns with a
 list of servers wich have the name and
 server load information. The first JBoss chooses a server based on the load
 information and does a lookup to
 return the reference to the client ( through the custom JNDI ). I cannot
 have one JBoss instance knowing about
 all the home interfaces of all its JBoss fellows.

Aga. I got the idea. We were doing similar tasks. But maybe it is the
problem
in your custom jndi provider?

regards,

-- 
__
Alexander Kogan  PTC   www.ptc.com
[EMAIL PROTECTED]140 Kendrick St. Needham MA 02494

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



RE: [JBoss-user] Blind Lookup

2001-05-16 Thread Sacha Labourey

Hello Lucian,

 -Message d'origine-
 
 Well, just to test i've written a simple client which does
 
   try {
 System.setSecurityManager(new
 java.rmi.RMISecurityManager());
   }
   catch (java.rmi.RMISecurityException exc) {
   System.err.println(Security violation  + exc.toString());
   }
  Context ctx = getInitialContext();//standard stuff
  Object refEJB=ctx.lookup(FirstBean);
 

You should try this:
 System.setProperty (java.rmi.server.codebase, http://TheJbossServer:8080;);
 System.setProperty (java.rmi.server.useCodeBaseOnly, true);
 System.setProperty (java.security.policy, c:/policy.txt);
 
 System.setSecurityManager (new java.lang.SecurityManager());

i.e. do not forget the useCodeBaseOnly property and do not forget to create a policy 
file (with all permission granged for testing purpose)

This should then work.

Cheers,



Sacha


___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-15 Thread Alexander Kogan




Lucian Bargaoanu wrote:
 
 Thanks, actually this is more than I need. I just need to return the result
 of  lookup.
 I've succeeded to do that locally, but from another host it doesn't work.
 I did set a security manager.

If by from another host you meant from another jboss instance, that
is
a bug. I experienced it a few month ago and recently it was discovered
and
filed as the bug at sourceforge.

From other side, if you were talking about a client on another host, it
should
work. At least for me.

Tell us, what are you exactly doing.



 
 //Lucian,
 //
 //it's not legal, according to spec, but it works in jboss:
 
 //try
 //{
 //Object home = context.lookup(componentName);
 //Method createMethod = home.getClass().getMethod(create,
 //null);
 
 //Object component = createMethod.invoke(home, null);
 //}
 //catch (NamingException ne) {}
 
 //and don't forget to set a SecurityManager.
 
 //good luck.
 
 //Lucian Bargaoanu wrote:
 
  I need to look up a bean without knowing about it's home interface.
  Can i do that? I tried and it tells me that it cannot find the home
  interface.
  Can't i download somehow that .class file from the server?
  Maybe with the RMI classloader.
 
  Sorry if this is a silly question.
 
  ___
  JBoss-user mailing list
  [EMAIL PROTECTED]
  http://lists.sourceforge.net/lists/listinfo/jboss-user
 
 --
 __
 Alexander Kogan  PTC   www.ptc.com
 [EMAIL PROTECTED]140 Kendrick St. Needham MA 02494
 
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-user
 
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-user

-- 
__
Alexander Kogan  PTC   www.ptc.com
[EMAIL PROTECTED]140 Kendrick St. Needham MA 02494

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-15 Thread Alexander Kogan

Hi,

Toby Allsopp wrote:
 
 I didn't realise that the situation was calling from an EJB; I thought we
 were talking about application clients.  Come to think of it, the same
 probably applies to J2EE Application Clients.

I think so. Even web-apps (servlets, JSPs) are supposed to use java:env
namespace and have deployment descriptors.

 Why not declare this as an ejb-ref in the deployment descriptor?  Something
 like:
 
 ejb-ref
   ejb-ref-nameejb/Foo/ejb-ref-name
   ejb-ref-typeSession/ejb-ref-type
   homejavax.ejb.EJBHome/home
   remotecom.foo.FooBaseInterface/remote
 /ejb-ref

Ok, two things here. First, what if I have to look for
several hot-deployed beans. I mean several and I
don't know exactly how many. Second, their jndi-names.
jndi-names are runtime parameters in my case.

BTW, your idea is very interesting, especially
in case of predefined names. I'm not sure that
it works, but... At least, I'll think about that.

regards,

Alex.

-- 
__
Alexander Kogan  PTC   www.ptc.com
[EMAIL PROTECTED]140 Kendrick St. Needham MA 02494

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-15 Thread Toby Allsopp

On Tue, May 15, 2001 at 06:13:18PM -0400, Alexander Kogan wrote:
 Hi,
 
 Toby Allsopp wrote:
  
  I didn't realise that the situation was calling from an EJB; I thought we
  were talking about application clients.  Come to think of it, the same
  probably applies to J2EE Application Clients.
 
 I think so. Even web-apps (servlets, JSPs) are supposed to use java:env
 namespace and have deployment descriptors.
 
  Why not declare this as an ejb-ref in the deployment descriptor?  Something
  like:
  
  ejb-ref
ejb-ref-nameejb/Foo/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homejavax.ejb.EJBHome/home
remotecom.foo.FooBaseInterface/remote
  /ejb-ref
 
 Ok, two things here. First, what if I have to look for
 several hot-deployed beans. I mean several and I
 don't know exactly how many. Second, their jndi-names.
 jndi-names are runtime parameters in my case.

Yes, in the more dynamic case, where you are discovering the other beans
at runtime, this won't apply.  I can't personally think of a good reason
for doing this off the top of my head, but there's no reason not to just
use plain JNDI names in that case, IMO.

 BTW, your idea is very interesting, especially
 in case of predefined names. I'm not sure that
 it works, but... At least, I'll think about that.

I don't know if it will work either.  If you need to make these decisions
at runtime rather than at deployment time then the deployment descriptor
is probably not the best mechanism and the spec be damned.

Toby.

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-15 Thread Alexander Kogan

Hi,

Toby Allsopp wrote:
 
 Yes, in the more dynamic case, where you are discovering the other beans
 at runtime, this won't apply.  I can't personally think of a good reason
 for doing this off the top of my head, but there's no reason not to just
 use plain JNDI names in that case, IMO.

FYEO (For your eyes only) I'll give you an example - it's the
simplification
of our project.

Pretend that you have a distributed workflow framework where each
activity 
is a session bean (maybe from another server) with only one business
method run(). 
This method receives String as an input and returns String as a result.
And all activities have to implement this pretty simple RunInterface.

Now to the point. The framework allows users to add/remove/rent/whatever 
their own activities at run-time. By add/remove I mean deploy/undeploy
in our case.
For each client, this framework produced statefull session bean
WorkFlowRunner.
The runner received a workflow descriptor and has to look up all
activities (from that descriptor) 
and run a given workflow. It doesn't have a clue what kind of activities
the user
wants and can use.

Sorry, if I didn't make myself clear. English is not my major.

 
 I don't know if it will work either.  If you need to make these decisions
 at runtime rather than at deployment time then the deployment descriptor
 is probably not the best mechanism and the spec be damned.

Perhaps it's not. I'm about to slightly change the architecture and have
the activities either as plain java classes (to be wrapped in JMX
service)
or as JMX services itself. The container task will be run them and 
correctly keep results, user/account information and some other DB/TX
crap.

-- 
__
Alexander Kogan  PTC   www.ptc.com
[EMAIL PROTECTED]140 Kendrick St. Needham MA 02494

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



[JBoss-user] Blind Lookup

2001-05-14 Thread Lucian Bargaoanu

I need to look up a bean without knowing about it's home interface.
Can i do that? I tried and it tells me that it cannot find the home
interface.
Can't i download somehow that .class file from the server?
Maybe with the RMI classloader.

Sorry if this is a silly question.




___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-14 Thread Alexander Kogan

Lucian,

it's not legal, according to spec, but it works in jboss:

try
{
Object home = context.lookup(componentName);
Method createMethod = home.getClass().getMethod(create,
null);

Object component = createMethod.invoke(home, null);
}
catch (NamingException ne) {}

and don't forget to set a SecurityManager.

good luck.


Lucian Bargaoanu wrote:
 
 I need to look up a bean without knowing about it's home interface.
 Can i do that? I tried and it tells me that it cannot find the home
 interface.
 Can't i download somehow that .class file from the server?
 Maybe with the RMI classloader.
 
 Sorry if this is a silly question.
 
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-user

-- 
__
Alexander Kogan  PTC   www.ptc.com
[EMAIL PROTECTED]140 Kendrick St. Needham MA 02494

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-14 Thread Toby Allsopp

On Mon, May 14, 2001 at 11:37:37AM -0400, Alexander Kogan wrote:
 Lucian,
 
 it's not legal, according to spec, but it works in jboss:

Ok, I'm calling you on this.  Section numbers (and spec version) please.

Toby.

 
 try
 {
 Object home = context.lookup(componentName);
 Method createMethod = home.getClass().getMethod(create,
 null);
 
 Object component = createMethod.invoke(home, null);
 }
 catch (NamingException ne) {}
   
 and don't forget to set a SecurityManager.
 
 good luck.

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-14 Thread Alexander Kogan

Hi, Toby!

Toby Allsopp wrote:
 
  it's not legal, according to spec, but it works in jboss:
 
 Ok, I'm calling you on this.  Section numbers (and spec version) please.

Well, let say that in order to look up other bean from a bean you
have to put ejb-ref in deployment descriptor. Correct?

What if you want to look up for a bean which was deployed (and
created/written) 
AFTER the first one has been deployed. And you have no clue what the
home/remote
interfaces are except that the home interface has simple ejbCreate() and
the remote
interfaces inherited from some generic and already defined known
interface.

Correct me if I'm wrong but in such case you can describe it in the
descriptor and 
look it up as java:/env/...
But in jboss case (and in WebLogic as well) you still can find it by
raw
jndi name. That was what I called spec violation.

However, the ejb-spec suggest (requires?) that all beans have to be
looked up 
in java:env/ context. True?

BTW, If you know the better solution, let me know. I will really
appreciated that.

best regards,

Alex.


-- 
__
Alexander Kogan  PTC   www.ptc.com
[EMAIL PROTECTED]140 Kendrick St. Needham MA 02494

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-14 Thread Toby Allsopp

On Mon, May 14, 2001 at 06:26:14PM -0400, Alexander Kogan wrote:
 Hi, Toby!
 
 Toby Allsopp wrote:
  
   it's not legal, according to spec, but it works in jboss:
  
  Ok, I'm calling you on this.  Section numbers (and spec version) please.
 
 Well, let say that in order to look up other bean from a bean you
 have to put ejb-ref in deployment descriptor. Correct?

Ah, yes.  Section 19.3 of pd2.

I didn't realise that the situation was calling from an EJB; I thought we
were talking about application clients.  Come to think of it, the same
probably applies to J2EE Application Clients.

 
 What if you want to look up for a bean which was deployed (and
 created/written) 
 AFTER the first one has been deployed. And you have no clue what the
 home/remote
 interfaces are except that the home interface has simple ejbCreate() and
 the remote
 interfaces inherited from some generic and already defined known
 interface.
 
 Correct me if I'm wrong but in such case you can describe it in the
 descriptor and 
 look it up as java:/env/...
 But in jboss case (and in WebLogic as well) you still can find it by
 raw
 jndi name. That was what I called spec violation.
 
 However, the ejb-spec suggest (requires?) that all beans have to be
 looked up 
 in java:env/ context. True?
 
 BTW, If you know the better solution, let me know. I will really
 appreciated that.

Why not declare this as an ejb-ref in the deployment descriptor?  Something
like:

ejb-ref
  ejb-ref-nameejb/Foo/ejb-ref-name
  ejb-ref-typeSession/ejb-ref-type
  homejavax.ejb.EJBHome/home
  remotecom.foo.FooBaseInterface/remote
/ejb-ref

Then you can use java:comp/env/ejb/Foo.

Toby.

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] Blind Lookup

2001-05-14 Thread Lucian Bargaoanu


Thanks, actually this is more than I need. I just need to return the result
of  lookup.
I've succeeded to do that locally, but from another host it doesn't work.
I did set a security manager.


//Lucian,
//
//it's not legal, according to spec, but it works in jboss:

//try
//{
//Object home = context.lookup(componentName);
//Method createMethod = home.getClass().getMethod(create,
//null);

//Object component = createMethod.invoke(home, null);
//}
//catch (NamingException ne) {}

//and don't forget to set a SecurityManager.

//good luck.


//Lucian Bargaoanu wrote:

 I need to look up a bean without knowing about it's home interface.
 Can i do that? I tried and it tells me that it cannot find the home
 interface.
 Can't i download somehow that .class file from the server?
 Maybe with the RMI classloader.

 Sorry if this is a silly question.

 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 http://lists.sourceforge.net/lists/listinfo/jboss-user

--
__
Alexander Kogan  PTC   www.ptc.com
[EMAIL PROTECTED]140 Kendrick St. Needham MA 02494

___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user


___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user