Pioneering Fortress inside JBoss (was: fortress .roles file doc?)

[Anton Tagunov <at...@mail.cnt.ru>]

Hello Neeme!

It looks like you're trying to pioneer one of the coolest things
that many of us have had in our mind but just didn't have guts
for! (half-joking :-)

Do I get you right that you want to have (at most) two
avalon (fortress) containers:
* one running locally  (say, from command line or a servlet)
* one running remotely (inside JBoss)

Now, from a component running in your "local" fortress
you want to lookup another component. You want it to
be transparent whether the component is local or remote.

Right?

I see this a pioneering undertaking in two aspects

A)
  transparent lookup of local/remote object (AFAIK)
  has not yet been very much implemented/used in avalon-land

  gurus, am I wrong? :-)

  AFAIK, EOB is about something like this, isn't it?
  (I haven't looked at it personally, what a shame! :)

  Anyway, even if EOB does something similar, using
  stateless EJB as a "transport" for accessing remote
  avalon components is a pioneering undertaking.

B)
  running anything avalon inside a EJB seems to a pioneering
  undertaking too. Horrors have been discussed on this list
  about EJB spec prohibiting things like creation of new
  threads, creating classloaders, etc.

  Can you share your experience, how well does Fortress
  launch inside JBoss?

I believe that paving paths for solving A) is a very worthy
thing but here I've got to step aside as I feel lack of
insight and hope that others on the list will continue this
discussion on the topic so much interesting.

-Anton

  
NP> I'm using Fortress inside JBoss stateless EJB and I need to give clients
NP> (servlets/cli) access to this fortress instance that is running inside 
NP> that EJB. So I figured that I would expose a generic invoke() method on 
NP> my EJB that would use the supplied arguments to delegate the actual work 
NP> to Fortress components.

NP> The generic method on EJB:
NP>     public Object invoke(String role, String methodName, Class[] 
NP> argumentTypes, Object[] argumentValues) throws Exception {
NP>         //TODO reflection is slow, replace it with some bytecode 
NP> generated optimizer
NP>         if (getLogger().isDebugEnabled()) getLogger().debug("invoking: 
NP> role=" + role + ", methodName=" + methodName + ", argumentValues=" + 
NP> argumentValues);
NP>         ServiceManager sm = getServiceManager();
NP>         Object component = null;
NP>         try {
NP>             component = sm.lookup(role);
NP>             Method method = component.getClass().getMethod(methodName, 
NP> argumentTypes);
NP>             return method.invoke(component, argumentValues);
NP>         } catch (Exception e) {
NP>             getLogger().error("error while invoking: role=" + role + ", 
NP> methodName=" + methodName + ", argumentValues=" + argumentValues, e);
NP>             throw e;
NP>         } finally {
NP>             if (component != null) sm.release(component);
NP>         }
NP>     }

NP> Ok, so far so good, this works ok if I invoke it straight from Java. 
NP> Now, as you know, developers are lazy and I'm not an exception. I want 
NP> to create a object factory that would allow me to specify in the .roles 
NP> file if the component should be executed locally or if it should be 
NP> executed remotely. So, I would like to be able to have all my remote 
NP> components to implement the same code for every exposed method, example:

NP>     public Screen getCurrentScreen(Long serviceInstanceId) throws 
NP> Exception {
NP>         Screen screen = null;
NP>         Context context = getContext();
NP>         if (context != null) {
NP>             Object o = context.lookup(ApplicationHome.JNDI_NAME);
NP>             Application a = null;
NP>             try {
NP>                 ApplicationHome home = (ApplicationHome) 
NP> PortableRemoteObject.narrow(o, ApplicationHome.class);
NP>                 a = home.create();
NP>                 return (Screen) a.invoke(ScreenManager.ROLE, 
NP> "getCurrentScreen", new Class[] {Long.class}, new Object[] 
NP> {serviceInstanceId});
NP>             } finally {
NP>                 try {
NP>                     if (a != null) a.remove();
NP>                 } catch (Exception e) {
NP>                     //ignore
NP>                 }
NP>                 closeContext(context);
NP>             }
NP>         }
NP>         return screen;
NP>     }

NP> Now I figured out that probably I should extend the BCEL generator to 
NP> achieve this... or is there an easier way?
NP> Also, I'm not sure if it is possible for the local proxy component to 
NP> know the ROLE string it is providing? I need this to look up the correct 
NP> component remotely...

NP> Rgds,
NP> Neeme

NP> Berin Loritsch wrote:

>>
>> What problem are you trying to solve?
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>> For additional commands, e-mail: dev-help@avalon.apache.org
>>
>>


NP> ---------------------------------------------------------------------
NP> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
NP> For additional commands, e-mail: dev-help@avalon.apache.org




-- 
Best regards,
 Anton                            mailto:atagunov@mail.cnt.ru


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org