Hi!
Bill Petheram wrote:
> OK If an EJB get a new InitialContect it is the EJB server
> implementation of JNDI which only has to implement the java: namespace.
Going strictly by the EJB spec this could fail:
new InitialContext().lookup("foo");
.. since there is no need for a global JNDI namespace, whereas the EJB
container *must* provide the java: namespace.
Yes.
> > Definitely use Resource Factories to do system functionality. Use EJB's
> > to glue things together into an *appliction*. System modules can usually
> > be reused for different applications, and do not contain any code that
> > is specific to the particular application that you are implementing.
> >
>
> By System Modules do you mean ResourceFactories? aka J2EE Connector
> Architecture?
I mean whatever. A JDBC driver is a resource factory. If you access this
through the java: namespace, which is recommended, or by using statics
(e.g. MyResourceFactory.getSomeResource()) or whatever is not important
(although using the java: namespace would be the best idea to implement
it).
As outlined above a system module is typically something that is used to
implement some technical feature, which is not tightly bound to the
particular application you are building, hence it is easily reusable in
different applications. EJB's implement applications by using system
resources in a particular way.
That is my view of it anyway, and which is how you should reason when
deciding which functionality goes where. There are (of course) other
views on this matter though, and I do not see the above as the only
truth here.
> What do you think of the idea of having different containers for
> application specific beans? For example I have been working with e-speak
> does it seem reasonable to think about an e-speak container that has
> e-speak beans? This is surely similar to having a JMS container for the
> JMS beans?
IMHO EJB's implement a particular application. e-speak would be a
"system resource" as it is not tightly bound to any particular
application or usage. So making "e-speak" beans doesn't make sense. It
*does* make sense to make beans that *use* e-speak however to implement
a particular application. There is a distinct difference here. The beans
themselves are not used to provide the system functionality, but instead
use system functionality in the form of e-speak libraries or whatever.
Does this answer your query? I might have misunderstood what you were
asking for.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
