Thanks all, You have solved my problem. I wasn't 100% sure you could use the same home and remote interfaces for different beans. I tried making it too complicated. Cheers for all your help. Chris Adams ============================== Regus Computer Services Ltd Direct Line: 01279 712010 ESN: 6-741-2010 Switchboard ESN: 6-741-2000 Tel: +44 (0)1279 507988 Fax: +44 (0)1279 507783 E-mail: [EMAIL PROTECTED] <http://47.137.128.160/regus> <http://www.regus-cs.co.uk/> ============================== -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 02, 2001 4:13 PM To: [EMAIL PROTECTED] Subject: JBoss-user digest, Vol 1 #991 - 10 msgs Send JBoss-user mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://lists.sourceforge.net/lists/listinfo/jboss-user or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of JBoss-user digest..." Today's Topics: 1. RE: JBoss-MBean-client to an entity-bean. (Tore B. Pedersen) 2. Re: Re: [JBoss-user] Casting home interface to correct bean type ([EMAIL PROTECTED]) 3. Re: Casting home interface to correct bean type (David Ward) 4. Re: diectory checksum error (Sebastien Alborini) 5. Possible places the Jboss.xml ? ([EMAIL PROTECTED]) 6. Re: how does EJB 2.0 fix CMP? (Ian Butcher) 7. Re: Re: [JBoss-user] Casting home interface to correct bean type (Burkhard Vogel) 8. Segmentation Fault (Kimball Larsen) 9. Re: Possible places the Jboss.xml ? (David Ward) 10. RE: Possible places the Jboss.xml ? (Pelle Poluha) --__--__-- Message: 1 From: "Tore B. Pedersen" <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: RE: [JBoss-user] JBoss-MBean-client to an entity-bean. Date: Mon, 2 Jul 2001 16:06:42 +0200 Reply-To: [EMAIL PROTECTED] Hi, we have already tried that, but we get the same error-message :( ----------------- Tore B. Pedersen Eye on Business AS > From: "Sternagel Annegret (PN-SYS/DAS)" > <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" > <[EMAIL PROTECTED]> > Subject: RE: [JBoss-user] JBoss-MBean-client to an entity-bean. > Date: Fri, 29 Jun 2001 14:19:38 +0200 > Reply-To: [EMAIL PROTECTED] > > Put the primary-key class and the interface classes of the > entitybean into a > jar in jboss\lib\ext. > Maybe there is a better solution ... ?? > > Ciao > Annegret > > > -----Original Message----- > > From: Tore B. Pedersen [SMTP:[EMAIL PROTECTED]] > > Sent: Freitag, 29. Juni 2001 11:11 > > To: '[EMAIL PROTECTED]' > > Subject: [JBoss-user] JBoss-MBean-client to an entity-bean. > > > > We are have problems writing a client which calls some entity-ejb in > > JBoss. > > > > When running as a normal client it runs OK, but we want > this client to be > > started when JBoss starts. Thus, we created it as a > MBean-service. But now > > it fails with a classnotfoundexception on the primarykey-class. > > > > Here is the picture we want: > > > > Mbean -> deployedEJB. > > > > What are we doing wrong? > > > > Here is the errormessage: > > > > [Frame] Starting > > [Frame] Started > > [CabinBean] TRANSACTION ROLLBACK EXCEPTION:Load failed; > nested exception > > is: > > java.rmi.NoSuchObjectException: Entity > > no.eob.titan.cabin.CabinPK@65 > > not > > found; nested exception is: > > java.rmi.ServerException: Load failed; nested exception is: > > java.rmi.NoSuchObjectException: Entity > > no.eob.titan.cabin.CabinPK@65 > > not > > found > > [Service Control] Started 26 services > > [CabinBean] java.rmi.ServerException: Load failed; nested > exception is: > > [CabinBean] java.rmi.NoSuchObjectException: Entity > > no.eob.titan.cabin.CabinP > > K@65 not found > > [CabinBean] java.rmi.NoSuchObjectException: Entity > > no.eob.titan.cabin.CabinPK@65 > > not found > > [CabinBean] at > > org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.handleR > > esult(JDBCLoadEntityCommand.java:106) > > [CabinBean] at > > org.jboss.ejb.plugins.jaws.jdbc.JDBCQueryCommand.executeState > > mentAndHandleResult(JDBCQueryCommand.java:59) > > [CabinBean] at > > org.jboss.ejb.plugins.jaws.jdbc.JDBCCommand.jdbcExecute(JDBCC > > ommand.java:160) > > [CabinBean] at > > org.jboss.ejb.plugins.jaws.jdbc.JDBCLoadEntityCommand.execute > > (JDBCLoadEntityCommand.java:82) > > [CabinBean] at > > org.jboss.ejb.plugins.jaws.JAWSPersistenceManager.loadEntity( > > JAWSPersistenceManager.java:150) > > [CabinBean] at > > org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPer > > sistenceManager.java:341) > > [CabinBean] at > > org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke > > (EntitySynchronizationInterceptor.java:192) > > [CabinBean] at > > org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(Entity > > InstanceInterceptor.java:186) > > [CabinBean] at > > org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxIntercept > > orCMT.java:133) > > [CabinBean] at > > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(Tx > > InterceptorCMT.java:263) > > [CabinBean] at > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCM > > T.java:99) > > [CabinBean] at > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInte > > rceptor.java:190) > > [CabinBean] at > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.ja > > va:195) > > [CabinBean] at > > org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:323 > > ) > > [CabinBean] at > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke > > (JRMPContainerInvoker.java:482) > > [CabinBean] at > > org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invoke(Enti > > tyProxy.java:146) > > [CabinBean] at $Proxy3.getName(Unknown Source) > > [CabinBean] at > > no.eob.titan.client.CabinTable$CabinTableModel.getValueAt(Cab > > inTable.java:50) > > [CabinBean] at javax.swing.JTable.getValueAt(Unknown Source) > > [CabinBean] at > javax.swing.JTable.prepareRenderer(Unknown Source) > > [CabinBean] at > javax.swing.plaf.basic.BasicTableUI.paintCell(Unknown > > Source) > > > > [CabinBean] at > javax.swing.plaf.basic.BasicTableUI.paintCells(Unknown > > Source > > ) > > [CabinBean] at javax.swing.plaf.basic.BasicTableUI.paint(Unknown > > Source) > > [CabinBean] at > javax.swing.plaf.ComponentUI.update(Unknown Source) > > [CabinBean] at > javax.swing.JComponent.paintComponent(Unknown Source) > > [CabinBean] at javax.swing.JComponent.paint(Unknown Source) > > [CabinBean] at > javax.swing.JComponent.paintChildren(Unknown Source) > > [CabinBean] at javax.swing.JComponent.paint(Unknown Source) > > [CabinBean] at javax.swing.JViewport.paint(Unknown Source) > > [CabinBean] at > javax.swing.JComponent.paintWithBuffer(Unknown Source) > > [CabinBean] at javax.swing.JComponent._paintImmediately(Unknown > > Source) > > [CabinBean] at > javax.swing.JComponent.paintImmediately(Unknown Source) > > [CabinBean] at > javax.swing.RepaintManager.paintDirtyRegions(Unknown > > Source) > > [CabinBean] at > > javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.ru > > n(Unknown Source) > > [CabinBean] at > java.awt.event.InvocationEvent.dispatch(Unknown Source) > > [CabinBean] at java.awt.EventQueue.dispatchEvent(Unknown Source) > > [CabinBean] at java.awt.EventDispatchThread.pumpOneEvent(Unknown > > Source) > > [CabinBean] at > java.awt.EventDispatchThread.pumpEvents(Unknown Source) > > [CabinBean] at java.awt.EventDispatchThread.run(Unknown Source) > > > > ----------------- > > Tore B. Pedersen > > Eye on Business AS --__--__-- Message: 2 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Mon, 2 Jul 2001 10:19:43 -0400 Subject: Re: Re: [JBoss-user] Casting home interface to correct bean type Reply-To: [EMAIL PROTECTED] I haven't done this yet, but eventually I will have to. My intended solution was to have a single Home/Remote Interface pair and just provide multiple implementations of the bean class. Each bean would be registered with a separate name in JNDI and the client would just look up the version of the bean that it needs. Since they all have the same Home/Remote Interface pair, the casting would be exactly the same for all implementations. Is this not the expected way to do this in J2EE? - Tim Haley ----- Original Message ----- From: "Chris Adams" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 02, 2001 3:17 PM Subject: [JBoss-user] Casting home interface to correct bean type > Hi, > > Need some help with remote casting objects when using ejb's > > I'm going to have a set of bean which each represent a form. Each for has > the same set of methods, but they need to be independent ejb's because each > has different details. > > The client is a servlet, which will receive a parameter > the type of form to return. This then needs to get the home interface of > the bean. I am going to have a properties file which pairs the form name to > it's home interface class name. > > My problem is that the lookup method just returns an object, so how can I > cast this object to the correct home interface, as the type of form is not > know until the servlet is called. > > I've tried creating standard interfaces, which all form beans could inheret > from, but came up with all sort of problems. > > I could use relfection to call the methods, but would prefer not to. Any > ideas. > > Many Thanks > > Chris Adams --__--__-- Message: 3 Date: Mon, 02 Jul 2001 10:17:56 -0400 From: David Ward <[EMAIL PROTECTED]> Organization: Distributed Object Technologies, Inc. To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Casting home interface to correct bean type Reply-To: [EMAIL PROTECTED] Chris, You shouldn't have to cast your home interfaces; in fact, you can share the same remote and home interface for all your "Form" EJB implementations. Try this, for example: // interfaces/beans public interface Form extends EJBObject; public interface FormHome extends EJBHome; public class FooForm implements SessionBean; public class BarForm implements SessionBean; // inside servlet (bad code for ease of example)... public void service(HttpRequest req, HttpResponse res) { String formName = req.getParameter("formName"); try { InitialContext ctx = new InitialContext(); Object ref; if ( formName.equals("foo") ) ref = ctx.lookup("java:comp/env/ejb/FooForm"); else if ( formName.equals("bar") ) ref = ctx.lookup("java:comp/env/ejb/BarForm"); else // do something... FormHome home = (FormHome)PortableRemoteObject.narrow(ref, FormHome.class); Form form = home.create(); // now use the generic form interface... } catch (Exception e) { throw new ServletException(e); } } Basically, your deployment descriptor will specifcy the same <remote> and <home> interfaces for both FooForm and BarForm, but will obviously have different <ejb-class>'s bound to different JNDI names. Your implementations of FooForm and BarForm can be radically different, but since you said they will have the same method signatures, the client code can just use the "Form" interface. Hope this helps, David -- Chris Adams wrote: > Hi, > > Need some help with remote casting objects when using ejb's > > I'm going to have a set of bean which each represent a form. Each for has > the same set of methods, but they need to be independent ejb's because each > has different details. > > The client is a servlet, which will receive a parameter > the type of form to return. This then needs to get the home interface of > the bean. I am going to have a properties file which pairs the form name to > it's home interface class name. > > My problem is that the lookup method just returns an object, so how can I > cast this object to the correct home interface, as the type of form is not > know until the servlet is called. > > I've tried creating standard interfaces, which all form beans could inheret > from, but came up with all sort of problems. > > I could use relfection to call the methods, but would prefer not to. Any > ideas. > > Many Thanks > > Chris Adams > > > > > Chris Adams > ============================== > Regus Computer Services Ltd > Direct Line: 01279 712010 > ESN: 6-741-2010 > Switchboard ESN: 6-741-2000 > Tel: +44 (0)1279 507988 > Fax: +44 (0)1279 507783 > E-mail: [EMAIL PROTECTED] > <http://47.137.128.160/regus> > <http://www.regus-cs.co.uk/> > ============================== > > > > > Regus Computer Services Ltd. > The information transmitted is intended solely for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any retention, review, retransmission, dissemination, other use, > or taking any action relying on this information by persons or entities, > other than the intended recipient is prohibited. If you received this in > error, please contact the sender and delete the material from any computer. > We will not be liable for direct, indirect or consequential damages arising > from the alteration of the contents of this e-mail by a third party or as a > result of any virus. > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > -- ----------------------------------------------------------------------- David Ward [EMAIL PROTECTED] Senior Software Engineer http://www.dotech.com Distributed Object Technologies, Inc. 716-381-8320 (phone) 500 Linden Oaks, Rochester, NY 14625 716-381-0598 (fax) --__--__-- Message: 4 Date: Mon, 02 Jul 2001 16:22:16 +0200 From: Sebastien Alborini <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] diectory checksum error Reply-To: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: > > I originally did an install of JBoss-2.2.2_Tomcat-3.2.2, while after I did > tar xvf I got the usual output lines but at the end I got this error: > tar : directory checksum error > On my first install I ignored this. I ended up getting a null > pointerException, so I removed the jboss and tomcat directories and am > starting over. > I get tar : directory checksum error once again, anyone know if this is a > unix or jboss error. > Also when Itry to run tomcat with startup.sh I get errors pointing to the > server.xml file(it doesnt like the following two > JBossWebXmlReader,JBossSecurityMgrRealm)if I comment these out I get further > in my setup. > I am running Solaris 5.8 with Apache already installed and j2ee 1.3.1 > Thanks in advance Graham Hi, JBoss binaries are packaged using GNU tar, and I think there are known compatibility issues with solaris tar. Can you try gtar instead of tar ? (or use the zip) Sebastien --__--__-- Message: 5 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Mon, 2 Jul 2001 11:30:06 -0300 Subject: [JBoss-user] Possible places the Jboss.xml ? Reply-To: [EMAIL PROTECTED] Hi, Where it should put the jboss.xml in case of having .ear file ? If it exists in the META-INF of the .ear file, is taken for all the .jar files that they exist in that .ear ? Or necessarily should be in the META-INF of each .jar Adrian Tabak --__--__-- Message: 6 From: "Ian Butcher" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Re: [JBoss-user] how does EJB 2.0 fix CMP? Date: Mon, 2 Jul 2001 10:42:13 -0400 Reply-To: [EMAIL PROTECTED] Allen, Design question. In your example you have a Customer with addresses, phone numbers and so on which in a normalized DB would live in separate tables. In EJB 2.0 do we take a bit of a hit on the load and store methods when we model entities like this or do containers do something clever? In 1.1 (and 1.0) I have tended to use lazy loading with BMP and for CMP not bother with dependent objects/activate passivate stuff just model them as separate entities (which I know is not ideal). TIA, Ian. ----- Original Message ----- From: "Allen fogleson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 02, 2001 12:42 AM Subject: Re: [JBoss-user] how does EJB 2.0 fix CMP? > Jim, > > Well under 1.1 cmp you are pretty much limited to the 1 Entity ejb = 1 > DB row. (or persistent row... whatever). Entity beans were not intended to > be finegrained like that, but to describe a business entity (lets use the > classic example of a customer) Customers have names, and addresses (plural) > and phone numbers (plural). With 1.1 you are pretty much stuck with using > dependent objects... and that means a lot of code in your ejbActivate and > ejbPassivate. At least to do it easily. > > 2.0 CMP has much better management of relationships. Relationships can be > one to one, one to many, or many to one, So it is much easier to handle the > whole concept of an entity there. Definitely The best step for CMP :) > although there are better cool new things in the 2.0 spec. (which some > millenia will actually go final :) > > Al > > ----- Original Message ----- > From: Jim <[EMAIL PROTECTED]> > To: jboss-user <[EMAIL PROTECTED]> > Sent: Sunday, July 01, 2001 9:37 PM > Subject: [JBoss-user] how does EJB 2.0 fix CMP? > > > > Someone on the list said that EJB 2.0 fixes CMP. > > > > The problem with EJB 1.1 and CMP was said to be that one DB row equals one > > entity bean but that one entity bean is supposed to be a coarse grained > > object - a seeming contradiction. > > > > Thanks, > > > > Jim > > > > > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > http://lists.sourceforge.net/lists/listinfo/jboss-user > > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > --__--__-- Message: 7 From: "Burkhard Vogel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Re: Re: [JBoss-user] Casting home interface to correct bean type Date: Mon, 2 Jul 2001 16:46:41 +0200 Reply-To: [EMAIL PROTECTED] You must do somethng wrong... I do this all the time... [from ejb-jar.xml] <ejb-jar> <description>Custom Events</description> <display-name>Custom</display-name> <enterprise-beans> <session> <ejb-name>BeladeBeginn</ejb-name> <home>de.xxx.custom.CustomEventListenerHome</home> <remote>de.xxx.custom.CustomEventListenerRemote</remote> <ejb-class>de.xxx.customer.xxx.event.BeladeBeginn</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> <session> <ejb-name>BeladeMeldung</ejb-name> <home>de.xxx.custom.CustomEventListenerHome</home> <remote>de.xxx.custom.CustomEventListenerRemote</remote> <ejb-class>de.xxx.customer.xxx.event.BeladeMeldung</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> <session> <ejb-name>BeladezeitKontrolle</ejb-name> <home>de.xxx.custom.CustomTimerListenerHome</home> <remote>de.xxx.custom.CustomTimerListenerRemote</remote> <ejb-class>de.xxx.customer.xxx.event.BeladezeitKontrolle</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> .... [from jboss.xml] <enterprise-beans> <session> <ejb-name>BeladeBeginn</ejb-name> <jndi-name>ejb/custom/xxx/BeladeBeginn</jndi-name> </session> <session> <ejb-name>BeladeMeldung</ejb-name> <jndi-name>ejb/custom/xxx/BeladeMeldung</jndi-name> </session> <session> <ejb-name>BeladezeitKontrolle</ejb-name> <jndi-name>ejb/custom/xxx/BeladezeitKontrolle</jndi-name> </session> ... (And, yes you guessed right, I'm german....) Burkhard ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 02, 2001 4:19 PM Subject: Re: Re: [JBoss-user] Casting home interface to correct bean type > > > I haven't done this yet, but eventually I will have to. > > My intended solution was to have a single Home/Remote Interface pair and just > provide multiple implementations of the bean class. Each bean would be > registered with a separate name in JNDI and the client would just look up the > version of the bean that it needs. Since they all have the same Home/Remote > Interface pair, the casting would be exactly the same for all implementations. > > Is this not the expected way to do this in J2EE? > > - Tim Haley > > > ----- Original Message ----- > From: "Chris Adams" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, July 02, 2001 3:17 PM > Subject: [JBoss-user] Casting home interface to correct bean type > > > > Hi, > > > > Need some help with remote casting objects when using ejb's > > > > I'm going to have a set of bean which each represent a form. Each for has > > the same set of methods, but they need to be independent ejb's because > each > > has different details. > > > > The client is a servlet, which will receive a parameter > > the type of form to return. This then needs to get the home interface of > > the bean. I am going to have a properties file which pairs the form name > to > > it's home interface class name. > > > > My problem is that the lookup method just returns an object, so how can I > > cast this object to the correct home interface, as the type of form is not > > know until the servlet is called. > > > > I've tried creating standard interfaces, which all form beans could > inheret > > from, but came up with all sort of problems. > > > > I could use relfection to call the methods, but would prefer not to. Any > > ideas. > > > > Many Thanks > > > > Chris Adams > > > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user --__--__-- Message: 8 Date: Mon, 2 Jul 2001 08:57:35 -0600 From: Kimball Larsen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [JBoss-user] Segmentation Fault Reply-To: [EMAIL PROTECTED] I keep getting a segmentation fault (core dump) when I start up jBoss with anything in it's deploy directory. Here is my system setup: Linux - RedHat 7.1 Sun java - java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) jBoss 2.2.2 Here is the segmentation message that is given: [Service Control] Started 22 services ./run.sh: line 31: 13890 Segmentation fault java $HOTSPOT $JAXP -classpath $JBOSS_CLASSPATH org.jboss.Main $@ If I start jBoss with nothing in the deploy directory, it goes fine, and I can hot deploy and undeploy all kinds of stuff with no problem. However, whenever it starts with things in the deploy directory, this is what I get. Am I correct to understand that this is the jvm core dumping, and not jBoss? What could cause that? -Kimball Larsen --__--__-- Message: 9 Date: Mon, 02 Jul 2001 10:58:31 -0400 From: David Ward <[EMAIL PROTECTED]> Organization: Distributed Object Technologies, Inc. To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Possible places the Jboss.xml ? Reply-To: [EMAIL PROTECTED] Correct usage: jboss.xml's should only be in the META-INF directories of the EJB's jar files. The only files I have in my ear are jar(s), war(s), and an application.xml file. -- [EMAIL PROTECTED] wrote: > Hi, > > Where it should put the jboss.xml in case of having .ear file ? > If it exists in the META-INF of the .ear file, is taken for all the .jar > files that they exist in that .ear ? > Or necessarily should be in the META-INF of each .jar > > > Adrian Tabak > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > --__--__-- Message: 10 From: "Pelle Poluha" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: RE: [JBoss-user] Possible places the Jboss.xml ? Date: Mon, 2 Jul 2001 17:09:52 +0200 Reply-To: [EMAIL PROTECTED] It must be in each of the jar. /Pelle Poluha > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > [EMAIL PROTECTED] > Sent: den 2 juli 2001 16:30 > To: [EMAIL PROTECTED] > Subject: [JBoss-user] Possible places the Jboss.xml ? > > > Hi, > > Where it should put the jboss.xml in case of having .ear file ? > If it exists in the META-INF of the .ear file, is taken for > all the .jar > files that they exist in that .ear ? > Or necessarily should be in the META-INF of each .jar > > > Adrian Tabak > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > http://lists.sourceforge.net/lists/listinfo/jboss-user > --__--__-- _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user End of JBoss-user Digest Regus Computer Services Ltd. The information transmitted is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retention, review, retransmission, dissemination, other use, or taking any action relying on this information by persons or entities, other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. We will not be liable for direct, indirect or consequential damages arising from the alteration of the contents of this e-mail by a third party or as a result of any virus. _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
