geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Denes" <de...@ppgia.pucpr.br>
Subject RES: RES: Dynamic proxies
Date Sat, 09 Aug 2003 03:39:00 GMT


> -----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
> 
>    Ok ... I finaly now have both email addresses in the list :o)
> 
>    One example at a time.
> 
>    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.

> 
>    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...


> 
>    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.
> 

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´t 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.
> 
> > >    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
> 
> > > > 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
> 
> > > > > 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ário e as que não.
> >
> > -------------------------------------------------
> > This mail sent through IMP: http://horde.org/imp/


Mime
View raw message