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
