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\ 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. 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. -- "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 [EMAIL PROTECTED]: > > > 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:[EMAIL PROTECTED] > > > > Enviada em: sexta-feira, 8 de agosto de 2003 12:43 > > > > Para: [EMAIL PROTECTED]; > > > [EMAIL PROTECTED] > > > > 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/
