Rickard �berg wrote:
>
> 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.
>
I'm OK up to System Resource now :-).
Could you define how a system resource is defined in jBoss?
As I understand it an EJB cannot use threads, sockets, files etc.
However it seems that I can write a system resource that allows access
to these things. This means to me that the container has to 'own, start,
know about' the system resource and the EJB can only use it.
So if I write a system resource that conforms to the Connector
Architecture I can use it in any EJB server. If I write it as an MBean I
could use it in jBoss.
thanks
bill
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
