> -----Mensagem original----- > De: Aaron Mulder [mailto:[EMAIL PROTECTED] > Enviada em: sábado, 9 de agosto de 2003 20:57 > Para: [EMAIL PROTECTED] > 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
