signoff EJB-INTEREST A mailing list for Enterprise JavaBeans development <[EMAIL PROTECTED]> wrote: > > There are 10 messages totalling 421 lines in this issue. > > Topics of the day: > > 1. Newbie question about clustering > 2. dynamically define/deploy a bean (?) (3) > 3. Serializable parameters? (2) > 4. EJB Packaging > 5. Entity beans and table inheritance > 6. filing system or Database (Informix) > 7. Message Driven Beans > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > > ---------------------------------------------------------------------- > > Date: Tue, 12 Jun 2001 23:48:40 -0700 > From: Gene Chuang <[EMAIL PROTECTED]> > Subject: Re: Newbie question about clustering > > Hi, > > Server clustering is not specified anywhere in EJB or J2EE specs, and its > implementation is up to individual vendors. Abraham Kang wrote a nice > article in javaworld that describes various server cluster implementations > in detail: > > http://www.javaworld.com/jw-02-2001/jw-0223-extremescale.html > > Gene Chuang > www.kiko.com > > > -----Original Message----- > From: ZHU Jia > To: [EMAIL PROTECTED] > Sent: 6/12/01 11:36 PM > Subject: Newbie question about clustering > > Hi all, > > can someone explain to me the basic concept about clustering? I mean I > know approximately what and why it is, but I'm interested in the > details. > For example if I have a cluster of EJB AppServer, how does the client > make the call and how is the session maintained with the cluster? Can > one session spawn across several > servers? And how does the cluster realize the load balancing? > We use JBoss now as our EJB platform, but both general tips and JBoss > specific ones are welcome. Also, some pointers to resource in the web > would be highly appreciated. > Many thanks in advance! > > ZHU Jia > > ======================================================================== > === > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > ------------------------------ > > Date: Wed, 13 Jun 2001 08:44:59 -0400 > From: Kenji Konaka <[EMAIL PROTECTED]> > Subject: dynamically define/deploy a bean (?) > > hi! > > if I were to dynamically generate code (ie., some .class files for > home/remote/bean,etc.; maybe by way of a program running externally to > the container), and to deploy it on the fly while the container is > running; what would be the concerns I would probably like to watch out > for? > - is there any tricky consequences regarding the security? > - is there any common programmatic interface which works for (nearly) all containers? > - anything else? > > ;; please excuse if this was a sort of newbie question... > kenji > > ------------------------------ > > Date: Wed, 13 Jun 2001 15:29:36 +0100 > From: Krishnan Subramanian <[EMAIL PROTECTED]> > Subject: Re: dynamically define/deploy a bean (?) > > kenji, > > Most ejb vendors provide some mechanism of > 'hot deploy' for their products. > > This is (as far as i am aware of) completely vendor > specific. For some vendors, it involves just dropping > a jar file into a directory, while for others it involves > using vendor provided deploy utilities (command line > and/or gui tools). > > This realm is outside the ejb specification. There is > no 'common programmatic interface' that works > for any _two_ ejb vendors - let alone 'nearly all' > containers. :) > > -krish > > ----- Original Message ----- > From: Kenji Konaka <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 13, 2001 1:44 PM > Subject: dynamically define/deploy a bean (?) > > > > hi! > > > > if I were to dynamically generate code (ie., some .class files for > > home/remote/bean,etc.; maybe by way of a program running externally to > > the container), and to deploy it on the fly while the container is > > running; what would be the concerns I would probably like to watch out > > for? > > - is there any tricky consequences regarding the security? > > - is there any common programmatic interface which works for (nearly) all >containers? > > - anything else? > > > > ;; please excuse if this was a sort of newbie question... > > kenji > > > > =========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > > > ------------------------------ > > Date: Wed, 13 Jun 2001 09:44:29 -0400 > From: Kenji Konaka <[EMAIL PROTECTED]> > Subject: Re: dynamically define/deploy a bean (?) > > krish, > thanks much! :) > I didn't come up with the correct word ``hot (re)deploy'' > -- now I can find so many references to this topic on the web. > thank you very much again! > regards, > kenji > > > From: "Krishnan Subramanian" <[EMAIL PROTECTED]> > > Date: Wed, 13 Jun 2001 15:29:36 +0100 > > > > kenji, > > > > Most ejb vendors provide some mechanism of > > 'hot deploy' for their products. > > > > This is (as far as i am aware of) completely vendor > > specific. For some vendors, it involves just dropping > > a jar file into a directory, while for others it involves > > using vendor provided deploy utilities (command line > > and/or gui tools). > > > > This realm is outside the ejb specification. There is > > no 'common programmatic interface' that works > > for any _two_ ejb vendors - let alone 'nearly all' > > containers. :) > > > > -krish > > ------------------------------ > > Date: Wed, 13 Jun 2001 13:10:05 -0400 > From: Anish Malhotra <[EMAIL PROTECTED]> > Subject: Re: Serializable parameters? > > YES > > Anish > > -----Original Message----- > From: Rob L'Estrange [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 13, 2001 9:18 AM > To: [EMAIL PROTECTED] > Subject: Serializable parameters? > > Hi All > > Do the parameters of a method in an EJB need to be serializable? > > Thanks > Rob > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > ------------------------------ > > Date: Wed, 13 Jun 2001 21:57:43 +0100 > From: News Groups <[EMAIL PROTECTED]> > Subject: Re: EJB Packaging > > Hi, > > On my last project I used the following technique. All classes related > to an EJB I place within that EJB's package, ie: > > com.foo.ejb.EJBPerson > > (there were no sub-packages below this) > > However, when it came to building and deploying the EJBs I used some > makefile trickery to create two different jar files; one for clients and > one for servers. All classes related to the server (ie. skeletons and > implementation classes) went in the server jar and all classes related > to the client (stubs and data classes) went in the client jar. > > This differs but is similar to the method you described of placing > client, common, and server classes in different sub-packages under the > EJB package. > > Myles > > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Ken Delong > Sent: 08 June 2001 23:31 > To: [EMAIL PROTECTED] > Subject: EJB Packaging > > I've seen very little discussion of the packaging of EJBs. There are > two > facets, as I see it, of packaging. One is the logical packaging - which > Java packages are used for which classes. Then there's physical > packaging - > how many and what JAR files, and where are they deployed. > > First the logical packaging scheme. Often each bean is in its own > subpackage. Under that, there are other subpackages. > > The PetStore app does something like (eliminating all the com.sun.j2ee > etc > etc) > customer.ejb - contains the bean classes themselves > customer.model - contains the serializable objects that the bean > returns > > I've also seen > customer.server - the bean impl class, other server-side helpers > customer.shared - classes needed by both the client and server > (serializables, exceptions) > customer.client - classes only needed by the client (rebinding proxies > etc) > > What other logical packaging schemes are out there? > > Now the physical packaging aspect. There's always at least one JAR, the > one > with the deployment descriptor that gets deployed into the server. It > must > have the EJB interfaces, implementation classes, and other server-side > helpers. > > However, there are also shared classes, like the serializable Model or > Detail objects that are exchanged between the client and server, any > application exceptions, etc. Since these are needed on the server, as > well > as any client that uses the bean, I'd say it makes sense to have a > second > JAR for each bean, called perhaps BeanShared.jar, that must go into the > server's and the client's classpath. > > I can see the case for yet another JAR! Let's say you are building a > bean > for resale to many third parties. There may be some client-side proxies > that you build to encapsulate JNDI lookup, maybe some initialization > logic, > smart failover or retry, etc. These classes are only needed on the > client, > so would you package them in a third JAR, say, BeanClient.jar? > > With the second logical packaging scheme above, we now have congruent > logical and physical packaging. That is, each of the three Java > packages > are packaged into separate phyical deployment units (JARS). In pre-EJB > architectures, I've found that it's usually hard to get the physical and > logical packaging to overlap. It seems like a good idea if it really > works. > > Any comments? > ---------------------- > Kenneth DeLong > Senior Consultant > Valtech, Inc. > Cell phone: 510-517-5839 > > Every complex problem has a simple answer - and it's always wrong. > > ======================================================================== > === > To unsubscribe, send email to [EMAIL PROTECTED] and include in the > body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > ------------------------------ > > Date: Wed, 13 Jun 2001 15:45:07 -0600 > From: Bryan Field-Elliot <[EMAIL PROTECTED]> > Subject: Entity beans and table inheritance > > I am using EJB with PostgreSQL. PostgreSQL supports some types of > polymorphism -- tables can inherit attributes from parent tables, and > queries can even be issued against "all tables which inherit from X". I > believe that some other databases such as Oracle support similar > functionality. > > My question is -- from entity beans (preferably CMP, although BMP would > be ok), can I take advantage of this functionality in an elegant and > designed way? Or is EJB just not there yet with respect to this kind of > OO database functionality? > > Thank you, > > Bryan > > ------------------------------ > > Date: Thu, 14 Jun 2001 03:27:00 -0000 > From: zahid rahman <[EMAIL PROTECTED]> > Subject: filing system or Database (Informix) > > As I wrote before Informix is a reliable database and Datablades are > plugins to the Database. > > These links are from the sun site. > > http://industry.java.sun.com/javanews/stories/story2/0,1072,23293,00.html > > > http://industry.java.sun.com/solutions/company/summary/0,2353,1900,00.htm > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > ------------------------------ > > Date: Thu, 14 Jun 2001 08:18:35 +0200 > From: Benjamin BONNET <[EMAIL PROTECTED]> > Subject: Re: Serializable parameters? > > not necessarily : they must be either serializable or remote references ( = > implementing java.rmi.Remote) > > Anish Malhotra a �crit : > > > YES > > > > Anish > > > > -----Original Message----- > > From: Rob L'Estrange [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, June 13, 2001 9:18 AM > > To: [EMAIL PROTECTED] > > Subject: Serializable parameters? > > > > Hi All > > > > Do the parameters of a method in an EJB need to be serializable? > > > > Thanks > > Rob > > > > =========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > > > =========================================================================== > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > > of the message "signoff EJB-INTEREST". For general help, send email to > > [EMAIL PROTECTED] and include in the body of the message "help". > > ------------------------------ > > Date: Thu, 14 Jun 2001 08:38:27 +0200 > From: Benjamin BONNET <[EMAIL PROTECTED]> > Subject: Re: Message Driven Beans > > Hi all, > > Ken Delong a �crit : > > > >>Date: Thu, 31 May 2001 10:57:14 +0200 > > >>From: Jubin Zawar <[EMAIL PROTECTED]> > > >>Subject: Message Driven Beans > > > > >>7) Schedules, Timers ! > > > > Amen! When are we going to get Timer Beans? This is big hole in J2EE right > > now. > > You may easily implement interesting stuff with java.util.Timer. Do you think > that class is not sufficient ? > > Benjamin > > ------------------------------ > > End of EJB-INTEREST Digest - 12 Jun 2001 to 13 Jun 2001 (#2001-163) > ******************************************************************* > -- Regards, - Justin __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
