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: RES: Dynamic proxies
Date Sun, 10 Aug 2003 00:44:32 GMT


> -----Mensagem original-----
> De: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> Enviada em: sábado, 9 de agosto de 2003 20:57
> Para: geronimo-dev@incubator.apache.org
> Assunto: RE: RES: RES: Dynamic proxies
> 
> 	Serves me right for speaking up before looking up...  :)
> 
> On Sat, 9 Aug 2003, Jeremy Boynes wrote:
> > Are you sure? My belief is that ejb-link's are restricted to the
same
> EAR
> > but local interfaces can be used to access anything in the same VM.
"A
> local
> > client is a client that is collocated in the same JVM with the
session
> or
> > entity bean that provides the local client view and which may be
tightly
> > coupled to the bean." [1]
> 
> 	Well I came up with this (J2EE 1.3 section 8.1.2):
> 
> "Deployment of a portable J2EE application must be possible using only
the
> application deployment descriptor and the J2EE modules (and their
> dependent libraries) and descriptors listed in it."
> 
> 	In other words, it seems to say that in order for an application
> to be portable, everything it references should be in the modules in
the
> application.  Then under 8.2.1.3.a.ii:
> 
> "Dependencies that are not linked to internal components must be
handled
> by the Deployer as external dependencies that must be met by resources
> previously installed on the platform."
> 
> 	I guess we can argue over whether a different app previously
> deployed counts as a "resource previously installed on the platform."
> 
> 	Anyway, it looks like this one is open to interpretation.
> 

Yes. I agree with that. In my interpretation, for example, the above
says that a J2EE compliant container has to accept an ear that is
composed only by the specified modules, without any server proprietary
files (as if the jboss.xml file in JBOSS would be mandatory, for
example). Again, this is way off-topic.


> > > 	Another way to approach the deployment problem is to allow the
> > > redeployment of JARs/WARs within an EAR.  I think JSR-88 allows
for
> that,
> > > and in general it should be possible to autodetect what's changed
in
> the
> > > EAR (based on file sizes, dates, checksums, or something along
those
> > > lines).
> >
> > I didn't think so. It says redeployment "is valid for
TargetModuleIDs
> that
> > represent a root module. A root TargetModuleID has no parent." [2]
> 
> 	Looks like you're clearly right about JSR-88 -- but that doesn't
> mean we can't detect what's changed on our own, so even if you call
the
> API method to redeploy the whole thing, we can notice that one xAR
didn't
> change and keep the old one as an optimization.
> 

Can this be done? I tried something like that in J2SE applications and
always had problems with suid. The problem is that AFAIK I can only tell
that a class has changed by comparing their suids. But normally the IDE
will recompile all project' classes (and regenerate all xAR files) to
build a new version of the ear file, creating new suids even for classes
that didn't changed. Then how could be verified that a class didn't
changed?

Anyway, even if this can be done, seems a little ugly to me the idea of
an ear file that is in constant expansion as more modules are added to
the corporation (something like "all-systems-of-my-corporation.ear"). 

IMHO, if I can access a local interface of an EJB in another ear files
in WebSphere and JBOSS (heard that I can do that in Oracle too, but not
tested). I think that would be interesting to allow this feature in
Geronimo too. 

Personally, I'm starting to loose the point of this particular
discussion...

Denes



> Aaron


Mime
View raw message