Hmmm, this is getting somewhere.
I fell there's something I can't see yet, help me out. (rest inline).
> -----Original Message-----
> From: Victor Langelo [mailto:[EMAIL PROTECTED]]
> Sent: Miércoles, 26 de Septiembre de 2001 14:35
> To: Juan Lorandi (Chile); [EMAIL PROTECTED]
> Subject: Re: EJB 2.0 final - what we have to live with now
>
>
> Juan,
>
> See my comments inline.
>
> "Juan Lorandi (Chile)" wrote:
>
> > <flame-bait>
> > Supposedly, the beans provided by third parties will not
> mutate over the
> > development.
>
> Whose development cycle? Yours or theirs? How are you going
> to stop either?
You don't. You just don't break contract compatibility in the middle of
YOUR dev cycle(unless you're certain the component version you're using
won't cut the
cheddar for your prj.)
>
> >
> > The fragility comes from rapidly evolving components. It's
> as fragile as
> > binary compatibility is.
>
> But it doesn't need to be so. See my earlier post to Andrea.
Seen it, makes sense.
>
> >
> > IMHO, this approach prevents closing versions of the
> components and reusing
> > them in their
> > binary form. It's a quick way to turn Java into C flat ;-).
>
> What's wrong with ejb-refs? With either ejb-refs or CMR
> you're going to need the
> interfaces of the components you're using. Any change to
> those interfaces (both
> syntax and semantics) will cause you to recompile your component.
Which is no problem at all... the _other_ component is the one I cannot
recompile nor need to,
as I'd choose versions carefully.
>
> >
> >
> > It harms the ability to connect to pre-built components,
> which would be done
> > by code instead of by the container's CMR abilities.
> >
> > I'm wondering exactly how each developer will hack his/her
> way around this.
> > Most likely, opening the pre-built component jar,
> extracting class files and
> > part of the deployment descriptor, then adding all of it
> into the final
> > application's jar (some copy/paste work on the descriptors too).
> >
> > Truly, this won't kill anybody, but will add up on the con column of
> > building and selling J2EE components.
> > Then there would be less invesment on R&D. Then there good be less
> > components. Then the quality of those components would be
> low and remain
> > low.
> > </flame-bait>
>
> Actually, reducing coupling between components will increase
> the reusability of
> third party components. This will lead to broader markets,
> increasing sales, and
> more R&D.
Because it boils down to coupling of components, right?
One more question(as I'm still reading EJB 2.0 spec). Loosely coupled
components(using ejb-ref's) won't be
able to leverage EQL fully, won't they?
>
> >
> >
> > Or maybe MrMagic and I are just martians. ;-)
>
> No. Just not experienced in building component systems yet.
>
Maybe.
==========================================================================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".
