Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
From: "Denes" <denes@ppgia.pucpr.br>
To: <geronimo-dev@incubator.apache.org>
Subject: RES: RES: Dynamic proxies
Date: Sat, 9 Aug 2003 00:39:00 -0300
Message-ID: <000001c35e27$c57c2990$0301a8c0@sheridan>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20030808210737.1DBE72B0066@hermes.ppgia.pucpr.br>
Importance: Normal


> -----Mensagem original-----
> De: a.vasconcelos@att.net [mailto:a.vasconcelos@att.net]
> Enviada em: sexta-feira, 8 de agosto de 2003 17:56
> Para: denes@ppgia.pucpr.br
> Cc: geronimo-dev@incubator.apache.org
> Assunto: Re: RES: Dynamic proxies
>=20
>    Ok ... I finaly now have both email addresses in the list :o)
>=20
>    One example at a time.
>=20
>    1. Can you define "use" for me ? I think that making a remote call
to
> an
> EJB deployed in a different EAR constitutes a "use" relationship right
?
> In
> that case number 1 is not a problem if you consider separate EARs as
> different applications. Did I miss something ? :o\

Yes. This is a problem because I want to call the Local, and not the
Remote Interface of the EJB that is in another EAR.

>=20
>    2. What do you mean by "I tried to do the same thing in several
jars
> inside a single ear, but all applications servers that I tried stops
and
> restars all EJBs in the ear file when updating" ? If you are replacing
the
> EAR with a new one with the new JARs in it, the application server
will
> have
> to stop the application right ? I am not sure what you meant by that
> phrase.

For example, I have a system that integrates several legacy applications
(SAP, CICS and DL1, among others) and performs some processing on these
data. You can see this application as a core module, which has the
common features that almost all other modules uses, and the other
modules that perform some specific tasks. By separating this way, I can
update almost every module other than core without stopping the overall
application. So, if I want to update the DL1 module, while it's
restarting the CICS and SAP modules are still working. I can also add
other modules to integrate the remaining legacy systems without stopping
the application as a whole.

Hope that's clear. My English in not enough to explain it better,
sorry...


>=20
>    I still think that keeping the concept of an application and of
modules
> within the application as the spec has is the way to go.
>    Alex V.
>=20

Can you tell me where in the specs is an ear file defined? I overlooked
the 1.4 spec and EJB 2.0 spec and can=B4t find it.

Thanks.

Denes


> --
> "Many pilots buy performance and
> think they are buying skill." Ken
> Stewart
> > That's not exactly the point that I had in mind. I had to work with
this
> issue
> > of multiple ears to create an application in several projects,
basically
> to
> > solve 2 problems:
> >
> > 1. When you have an application that has to use EJBs that are
already
> created
> > for another application in the same corporation. I prefer the idea
that
> this
> > application simply uses the EJBs of another ear than have to
redeploy
> all the
> > classes in each ear.
> >
> > 2. When you have a large application that has several modules that
work
> > togheter, several ears optimize the process of hot deployment, as
the
> > application server will replace only the EJBs of the ear being
updated.
> (I
> > tried to do the same thing in several jars inside a single ear, but
all
> > applications servers that I tried stops and restars all EJBs in the
ear
> file
> > when updating).
> >
> > Denes
> >
> > Citando a.vasconcelos@att.net:
> >
> > >    Not sure if I agree with this one, although I think it is
mainly an
> > > academic issue.
>=20
> > >    The way I read the spec the EAR IS indeed what sets the
boundary of
> an
> > > application. The different JAR and WAR files set the boundaries
for
> sub-
> > > systems and possibly business objects. In other words, different
> concerns of
> > >
> > > an overall application are bundled inside the EAR while
interations
> between
> > >
> > > EARs show dependencies between disparate applications that are not
> > > necessarily part of an "overall application" ... unless of course
we
> want to
> > >
> > > end up with a grouping of every EAR ever written since one way or
> another one
> > >
> > > could argue that they are all part of the same "overall" scheme
:o)
> > >
> > >    Sharing classes between EARs is IMHO counter-intuitive.
> > >
> > >    Alex V.
> > >
> > > --
> > > "Many pilots buy performance and
> > > think they are buying skill." Ken
> > > Stewart
> > > > IMHO this is not a so huge mistake... If you think about the
J2EE
> > > > architecture, one of the goals is to provide a set of business
>=20
> > > > components, which can be (ideally) integrated to create an
> application.
> > > >
> > > > When you have several ears in a server, one could argue that
these
> ears
> > > > are different concerns about different features of the overall
> > > > application. The application is not the ear, but the interaction
of
> the
> > > > several components that are in each ear file.
> > > >
> > > > If you want to isolate components, you should create different
> server
> > > > configurations to isolate them.
> > > >
> > > > Denes
> > > >
> > > > > -----Mensagem original-----
> > > > > De: Michael Remijan [mailto:remijan@ncsa.uiuc.edu]
> > > > > Enviada em: sexta-feira, 8 de agosto de 2003 12:43
> > > > > Para: geronimo-dev@incubator.apache.org;
> > > > geronimo-dev@incubator.apache.org
> > > > > Assunto: Re: Dynamic proxies
> > > > >
> > > > > JBoss redid their classloader for version 3 and it is very
> > > > > counter-intuitive.  Basically, unless you use a jboss specific
> config
> > > > > file,
> > > > > when you deploy an EAR it will share classes from other ears!
> IMNSHO
> > > > this
>=20
> > > > > is a huge mistake.  The JBoss documentation says the
classloaders
> were
> > > > > redesigned this way to more fully incorporate JMX.
> > > > >
> > > >
> > >
> >
> >
> > --
> > Existem 10 tipos de pessoas: as que entendem bin=E1rio e as que =
n=E3o.
> >
> > -------------------------------------------------
> > This mail sent through IMP: http://horde.org/imp/