Both of those solutions sound pretty crappy.  We need to develop an EAR that
can run on any J2EE server without user interaction.  Is that possible?  If
not, J2EE is pretty useless as a standard.


----- Original Message -----
From: "Juan Lorandi (Chile)" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Sunday, February 04, 2001 12:55 PM
Subject: RE: Questions about running an EJB client


> sorry for the delay, I'll try and explain it again:
>
> let's say I (Juan) am a bean developer. Let's say you (Eric) are the
> application assembler, and let's say Lauren Commons is the deployer.
>
> I build a bean. I package the bean in a jar, then pass it on to you. It
has
> some(but not all) of the info needed in ejb-jar.xml . So far it's
completly
> portable across servers.
>
> You pick up my bean, add a few of your own, and repackage the .jar . You
> touch ejb-jar.xml to match your assembly needs(As an example, you want to
> mark some methods as TX_MANDATORY). You put the .jar in an .ear with the
> rest of the application modules, and application.xml. This is still
PORTABLE
> across servers (As all in the spec).
>
> Now... deployment.
> A: simple deployment
>
> Lauren takes your ear and uses a deploy tool to install the app on a given
> server. She defines ejb-ref bindings
> runs required SQL scripts in the DB, maps the security to a given domain
> etc. To store all of these data(which is server DEPENDANT), the app server
> creates some files. The app is deployed.
>
> B: pre-deployment
>
> Deployment is in the corporate HQ of HAL, Inc. If you fuck up there,
you're
> toast.
> Lauren works with a sturdy, fast server called orion. Regretably, it
doesn't
> include a deploy tool (no, deploytool doesn't work... yet), so she wants
to
> pre-deploy as much as possible about this app in order to have less work
to
> do in the final deployment. So she deploys her app in a test machine.
> orion-xxxxxx.xml files are created. How does she use these files? She
> REPACKAGES the App, storing the new files alongside its counter-part
> (orion-application.xml and application.xml go in the same dir), except in
> the case of ejb-jar.xml, which goes in an orion directory inside the ejb
> jar. This app is still portable across servers, but it contains now some
> information on how to deploy on orion-servers. The same process could be
> done for J2EERI and WLS 6.0, making the actual deployment very accesible.
>
> When Lauren deploys this modified .ear, orion will find the orion-xxx
files
> inside the ear, and instead of creating deployment files from scratch,
using
> defaults, it will use the in-ear files to create the actual,
> $orion\application-deployment resident, orion-xxxxxx.xml files.
>
>
> I sure do hope this helps...
>
> JP
>
>
> PS: Lauren... may I stick my tongue in your ear?
>
>
>
> > -----Original Message-----
> > From: Eric Hodges [mailto:[EMAIL PROTECTED]]
> > Sent: Jueves, 01 de Febrero de 2001 19:20
> > To: Orion-Interest
> > Subject: Re: Questions about running an EJB client
> >
> >
> >
> > ----- Original Message -----
> > From: "Juan Lorandi (Chile)" <[EMAIL PROTECTED]>
> > To: "Orion-Interest" <[EMAIL PROTECTED]>
> > Sent: Thursday, February 01, 2001 3:33 PM
> > Subject: RE: Questions about running an EJB client
> >
> >
> > > Read the j2ee spec again.
> > >
> > > orion-xxxxx.xml files are deployment info; deployment info is server
> > > dependant (in contrast to bean developer info & assembly
> > info); deployment
> > > info may override & complete
> > > for j2eeri, files are named j2eeri-xxxx.xml
> > >
> > > basically, there's one of these per every .xml in the specs:
> > >
> > > SPEC file Orion file packageplace
> > > application.xml orion-application.xml   \YOURAPP.ear\META-INF\
> > > ejb-jar.xml orion-ejb-jar.xml
> > > \YOURAPP.ear\YOUREJB.jar\orion
> > > web.xml orion-web.xml \YOURAPP.ear\YOURWAR.war\WEB-INF\
> >
> > I don't really understand what you just typed.
> >
> > So orion-application.xml gets its info from application.xml?
> > If so, do I
> > just stick this namespace stuff in application.xml?
> >
> >
> >
> >
>


Reply via email to