see my comments below...
> -----Original Message-----
> From: Scott Stirling [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, September 23, 2000 3:23 PM
> To: JRun-Talk
> Subject: RE: Following the J2EE specs, WAS: RE: [JRun-Talk] Non-Jrun
> specific way to get local EJBHomeObject?
>
>
> Hi Chris,
>
> You raise an interesting point that has also been raised my
> Microsoft and its
> proponents as an argument against J2EE in general.
>
> The idea of J2EE is to provide a base standard for distributed, enterprise
> applications written in Java. But another driving idea behind
> J2EE is "vendor
> value-add," i.e., the idea that vendors make their bread and
> butter in part by
> extending and enriching their containers and components beyond the spec
> standards.
>
> Microsoft and others have attacked J2EE (and especially EJB) for being a
> cross-purposes. Here's an excerpt from an article at Microsoft:
>
> "Portability
>
> Portability of enterprise beans across implementations from
> different vendors is
> frequently cited as a primary goal of EJB. In fact, the EJB
> specification states
> 'An enterprise bean can be developed once and then deployed on multiple
> platforms without recompilation or source code modification.' Yet the
> specification also states that 'specialized containers can
> provide additional
> services beyond those defined by the Enterprise JavaBeans
> specification. An
> enterprise bean that depends on such a service must be deployed only in a
> container that supports the service.' In practice, this is all
> but certain to
> lead to significant differences among products supporting
> Enterprise JavaBeans,
> which brings into question its validity as a standard."
> http://outlook.microsoft.com/com/wpaper/mts-ejb.asp
>
>
> There's a risk there, to be sure. But there's always the
> standard way to fall
> back on. Chris, you are saying that the JRun docs emphasize the
> JRun-specifics
> too much, right? In some areas I'd totally disagree, such as how
> to write and
> deploy servlets and custom tags. But on EJBs, I agree that there
> is no where
> near enough documentation on how to do things the EJB 1.1 way,
> hence all the
> Ejipt properties files documentation.
agreed... as i said, the web services seem to be "up to spec". however,
even with the ejipt properties, i have not yet found a complete listing of
all the possible properties available.
>
> Ejipt was a compliant EJB 1.0 server. But in EJB 1.0 there was
> no such thing as
> ejb-jar.xml, or even any requirement that servers support Entity
> beans! Ejipt
> is also a very compliant 1.1 server, but the documentation
> doesn't reflect it
> very well. That's because a lot of the docs were "ported" from
> Ejipt's existing
> doc set, which primarily covered the EJB 1.0 stuff. So for the
> most part, you
> should be able to use off-the-shelf books on J2EE/EJB as guides
> for developing
> with JRun 3.0. Of course this is barring any bugs in JRun. One
> thing to watch
> out for is the processing of the ejb-jar.xml and empty elements.
> If an element
> should be empty, don't include it. Otherwise you may get errors
> when trying to
> run the bean in the server. I believe this has been fixed in
> JRun 3.0 SP1,
> which should be out next week.
we have been deploying 1.1 ejbs on ejipt. i'm not faulting it for not
working (with some exceptions noted below), it does. however, i just think
the manual could be much better. especially in writing code that's not
going to choke if i move it off of ejipt.
>
> There will always be server-specific information that the System
> Administrator
> role needs to access. That's a large part of what
> deploy.properties is for.
> Most if not all bean-related information from deploy.properties
> can go into
> env-entries in the ejb-jar.xml. But you wouldn't want to specify
> server ports
> or database names in ejb-jar.xml because that stuff can't be
> guaranteed to be
> portable.
>
> Can you point to a more specific reference in section 14 of the
> EJB 1.1 spec
> where you found a problem? I will evaluate it and make sure it's
> entered as a
> bug if it is one.
certainly. what i'm referring to in general is the ability to define
ejb-links and ejb-refs in the ejb-jar.xml file. on page 211 (14.4) the spec
talks about getting datasources from a jndi context defined as a ejb-ref in
the ejb-jar.xml. i have found no way to achieve this kind of functionality
with ejipt. i realize that the database names and setup will vary from
vendor to vendor and need to be handled at the container level. what i see
missing in ejipt at this point is the ability to set up some kind of global
connection pool in the jndi context (whether it be an XA datasource, pooled
datasource, etc), and then at deploy time map the ejb-refs to that pool
through a jndi ref link. for example: i should be able to setup a
connection pool(s) using oracle drivers (not jrun pooling) and register that
with the ejipt jndi context. then in my beans, i should be able to set up
ejb-refs with whatever names i want for the ejb environment (this may change
from bean to bean) to those datasources. when i deploy the bean, i should
be able to map those ejb-refs to any of the available connection pools
sitting in jndi. from what i've read, this is how it's supposed to work.
that would allow me to at least write ejb 1.1 beans to spec and get
connections as defined in sec. 14.4. now, i have to use the
deploy.properties to set up datasources (using ejipt pooling, not my
database vendors) and use ResourceManager to get connections. someday,
when/if i switch to another ejb container, i've got to go in and mess with
all my ejb's (at the code level, not the deploy level) to get their database
connections working again.
it's the setting up of jdbc connection pools and jndi references that should
be container specific at deploy time, not the use of those resources once
you're at the individual ejb level--that should all be spec.
i agree that different vendors will add value by providing performance
enhancements that might not be covered in the specs, but this should be
additional/optional functionality, not the ONLY way to do things.
>
> Scott Stirling
> Allaire
>
cheerio,
chris
| chris wilson || web dev ||| www.wondergeek.com || |
------------------------------------------------------------------------------
Archives: http://www.egroups.com/group/jrun-interest/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/jrun_talk
or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the
body.
