And why that wouldn't be done with an external component?
I can mail the list to set the record straight if it seems to radical for
you(now that I read it,
it seems a bit fanatical... my timing sucks).
However, I'm profoundly concerned about leaving the real posibility of
leaving small bean providers out of the picture. I'm sure that's not the
purpose sought, but still , like it says in the subject, we have to live
with it now. Judging from the time elapsed since the last (1.1) version of
the spec, I wonder for how long this will remain the same.
If I stepped on somebody's toes, I apologize.
Regards,
JP
> -----Original Message-----
> From: Victor Langelo [mailto:[EMAIL PROTECTED]]
> Sent: Viernes, 21 de Septiembre de 2001 13:48
> To: Juan Lorandi (Chile)
> Subject: Re: EJB 2.0 final - what we have to live with now
>
>
> Juan,
>
> I'm afraid you're taking my statement out of context. I was
> asking this in the
> specific case where one ejb-jar file has a required container managed
> relationship to a bean in another ejb-jar file. In that case,
> you don't have the
> option of deploying the jars independently.
>
> --Victor
>
>
> "Juan Lorandi (Chile)" wrote:
>
> > > So what's wrong with a single ejb-jar?
> >
> > 4- It harms external bean providers' integration. I'm
> building a CMS that is
> > composed of an engine (an ejb-jar) and a web app(for the
> backend). You
> > tipically should build a frontend app with the engine and
> any number of web
> > apps. etc(with FREEDOM) and a backend app with both the
> engine and the
> > web-app. If solely CMS is the customer's need, then all is
> fine(I guess--
> > but can't ever tell); but if more EJB's are involved,
> integrating would
> > change from adding a file and a <module/> tag to tinkling
> inside the .jar I
> > provide. Now, add a Transaction Engine, a CRM engine and a
> scheduling
> > component.
> >
> > How's that component oriented?
> >
> > How could a non-major seller gain market share? I mean, if
> a component is
> > _bundled_ in the app server of choice (most places have a
> corp. standard),
> > then it'll be adopted sooner or later, even with the hassle
> of tinkering
> > around. But not a small vendor, and never to the developer's entire
> > satisfaction. One of the things I most appreciate of J2EE
> is that the
> > contract is loose enough(not completely) to allow everybody
> to improve by
> > building _components_, defining architecture, deployment
> scenarios, evolving
> > metodology. The EJB 2 spec is a clear step back if
> approaching J2EE as an
> > _open_ platform. What it really does is leave the small
> guys out. And that's
> > enough for me to stop and rethink if J2EE really is the way
> to go-- what
> > would be next? prosecution of all non J2EE licensees?
>
>
> ______________________________________________________________
> ______________
> For your protection, this e-mail message has been scanned for Viruses.
> Visit us at http://www.neoris.com/
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
