HI Please I need some support with Jboss-Jetty any of the new versions. I tried to link or bind Jetty-Jboss with Apache, the manuall I used is that from jetty home page but that was no too good support for me a new user, so would any kind person give me a detail manuall which support me with step by step to link Jetty-Jboss with Apache by mod_jk or mod_jk2 or any other method.
All the best to you Haidar from Sweden ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, December 08, 2002 6:53 AM Subject: Jboss-development digest, Vol 1 #4841 - 8 msgs > Send Jboss-development mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/jboss-development > 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-development digest..." > > > Today's Topics: > > 1. Re: Proposal for changes to URL deployment to clean up netboot (Jason Dillon) > 2. Re: Proposal for changes to URL deployment to clean up netboot (Scott M Stark) > 3. RE: Coding-Style-page (marc fleury) > 4. Automated JBoss(Branch_3_0) Testsuite Results: 7-December-2002 ([EMAIL PROTECTED]) > 5. Automated JBoss(Branch_3_0) Testsuite Results: 7-December-2002 ([EMAIL PROTECTED]) > 6. [ jboss-Bugs-609902 ] java.lang.LinkageError: loader ... ([EMAIL PROTECTED]) > 7. [ jboss-Bugs-637168 ] Cannot start catalina service ([EMAIL PROTECTED]) > 8. [ jboss-Bugs-641155 ] EAR file class scoping problem ([EMAIL PROTECTED]) > > --__--__-- > > Message: 1 > Date: Sat, 7 Dec 2002 12:10:50 -0800 > Subject: Re: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot > From: Jason Dillon <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > > > Wanted to get feedback before starting to implement... > > ;) > > > > The current support for loading deployment units has several special > > cases > > to deal with loading from the network e.g. in > > SARDeployer.parseXMLClasspath(), NetBootHelper.getDefaultListUrl() or > > even > > HttpURLDeploymentScanner itself. > > Specifically what are the special cases? It has been a while since I > looked, refresh my memory. Some work still needs to be done to remove > all of the http: specific bits are replace them with plain > URLConnnection bits. > > > > I would like to make changes to simplify this and at the same time > > offer > > additional flexibility. > > > > The main change would be to factor out the URL listing functionality > > into > > helpers with a factory to create them based on the scheme. Examples > > would > > be: > > * file: using java.io.File as now > > * http(s): using DAV > > * http: using the current listing mechanisms (if still applicable) > > others could be added as needed (e.g ftp:) > > Explain some of the details here. > > > > The DAV client would allow JBoss to be netbooted from any web server > > supporting DAV, either directly (e.g. Tomcat 4.1, Apache+mod_dav or > > even > > IIS) or via a helper servlet (which could read either the content of > > its war > > or config of its host). > > I am all about more network proto support. Can this be abstracted into > a URL Handler & used with a URLConnection? > > > > This change would isolate the SARDeployer and the > > URLDeploymentScanner's > > from the different URL schemes and remove the special cases. > > Again, explain some details please. > > =] > > --jason > > > > --__--__-- > > Message: 2 > From: "Scott M Stark" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Re: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot > Date: Sat, 7 Dec 2002 12:31:13 -0800 > Organization: JBoss Group, LLC > Reply-To: [EMAIL PROTECTED] > > Sounds ok, but let see some more details. Show how you propose to rewrite > SARDeployer.parseXMLClasspath using this helper framework. > > I think bbtaining a URLLister should mirror the mechanism for obtain a URL > protocol handler in that one can install the class that obtains a listing for a given > URL via package search paths. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > From: "Jeremy Boynes" <[EMAIL PROTECTED]> > To: "Jboss-Development" <[EMAIL PROTECTED]> > Sent: Saturday, December 07, 2002 10:36 AM > Subject: [JBoss-dev] Proposal for changes to URL deployment to clean up netboot > > > > Wanted to get feedback before starting to implement... > > > > The current support for loading deployment units has several special cases > > to deal with loading from the network e.g. in > > SARDeployer.parseXMLClasspath(), NetBootHelper.getDefaultListUrl() or even > > HttpURLDeploymentScanner itself. > > > > I would like to make changes to simplify this and at the same time offer > > additional flexibility. > > > > The main change would be to factor out the URL listing functionality into > > helpers with a factory to create them based on the scheme. Examples would > > be: > > * file: using java.io.File as now > > * http(s): using DAV > > * http: using the current listing mechanisms (if still applicable) > > others could be added as needed (e.g ftp:) > > > > The DAV client would allow JBoss to be netbooted from any web server > > supporting DAV, either directly (e.g. Tomcat 4.1, Apache+mod_dav or even > > IIS) or via a helper servlet (which could read either the content of its war > > or config of its host). > > > > This change would isolate the SARDeployer and the URLDeploymentScanner's > > from the different URL schemes and remove the special cases. > > > > --__--__-- > > Message: 3 > From: "marc fleury" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: RE: [JBoss-dev] Coding-Style-page > Date: Sat, 7 Dec 2002 15:35:33 -0500 > Reply-To: [EMAIL PROTECTED] > > I thought it was funny though, > > marcf > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On > > Behalf Of Scott M Stark > > Sent: Saturday, December 07, 2002 12:00 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Coding-Style-page > > > > > > The coding style pages is not about practices or idioms, just > > style: spaces, brackets, etc. Ignore the actual code. > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > ----- Original Message ----- > > From: "Thomas Peuss" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, December 07, 2002 2:35 AM > > Subject: [JBoss-dev] Coding-Style-page > > > > > > > Hello! > > > > > > On http://www.jboss.org/developers/guides/codestyle.jsp > > > > > > Class cls = Class.forName(dataSourceClass); > > > > > > is given as an example of good coding style. Shouldn't we > > change this > > > to > > > > > Thread.currentThread().getContextClassLoader().loadClass(dataS > > ourceClass)? > > > > > > CU > > > Thomas > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Jboss-development mailing list [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --__--__-- > > Message: 4 > Cc: > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > Date: Sat, 07 Dec 2002 14:03:52 -0800 > Subject: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 7-December-2002 > Reply-To: [EMAIL PROTECTED] > > > > JBoss daily test results > > SUMMARY > > Number of tests run: 1006 > > -------------------------------------------- > > Successful tests: 995 > > Errors: 10 > > Failures: 1 > > -------------------------------------------- > > > > [time of test: 2002-12-07.12-11 GMT] > [java.version: 1.3.1] > [java.vendor: Apple Computer, Inc.] > [java.vm.version: 1.3.1_03-69] > [java.vm.name: Java HotSpot(TM) Client VM] > [java.vm.info: mixed mode] > [os.name: Mac OS X] > [os.arch: ppc] > [os.version: 10.2.2] > > See http://users.jboss.org/~starksm/Branch_3_0/2002-12-07.12-11 > for details of this test. > > NOTE: If there are any errors shown above - this mail is only highlighting > them - it is NOT indicating that they are being looked at by anyone. > > It is assumed that whoever makes change(s) to jboss that > break the test will be fixing the test or jboss, as appropriate! > > -------------------------------------------- > > > > DETAILS OF ERRORS > > > > Suite: LocalWrapperCleanupUnitTestCase > Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupU nitTestCase) > Type: error > Exception: java.rmi.ServerException > Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! > --------------------------------- > > > > Suite: MissingClassUnitTestCase > Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCa se) > Type: error > Exception: org.jboss.deployment.DeploymentException > Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) > --------------------------------- > > > > Suite: SimpleUnitTestCase > Test: testHaInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) > Type: error > Exception: javax.naming.CommunicationException > Message: Receive timed out > --------------------------------- > > > > Suite: SimpleUnitTestCase > Test: testHaParitionName(org.jboss.test.naming.test.SimpleUnitTestCase) > Type: error > Exception: javax.naming.CommunicationException > Message: Receive timed out > --------------------------------- > > > > Suite: SimpleUnitTestCase > Test: testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) > Type: error > Exception: javax.security.auth.login.LoginException > Message: Missing users.properties file. > --------------------------------- > > > > Suite: SimpleUnitTestCase > Test: testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) > Type: error > Exception: javax.naming.AuthenticationException > Message: Failed to login using protocol=testLoginInitialContext > --------------------------------- > > > > Suite: BeanStressTestCase > Test: testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) > Type: failure > Exception: junit.framework.AssertionFailedError > Message: expected a client deadlock for AB BA > --------------------------------- > > > > Suite: RollBackUnitTestCase > Test: testAsynchQueueReceiveBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) > Type: error > Exception: java.lang.NoSuchMethodError > Message: > --------------------------------- > > > > Suite: RollBackUnitTestCase > Test: testAsynchTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestC ase) > Type: error > Exception: java.lang.NoSuchMethodError > Message: > --------------------------------- > > > > Suite: RollBackUnitTestCase > Test: testAsynchDurableTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUn itTestCase) > Type: error > Exception: java.lang.NoSuchMethodError > Message: > --------------------------------- > > > > Suite: CircularityUnitTestCase > Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase ) > Type: error > Exception: javax.management.MBeanException > Message: Exception in MBean operation 'testPackageProtected()' > --------------------------------- > > > > > --__--__-- > > Message: 5 > Cc: > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > Date: Sat, 07 Dec 2002 22:38:55 -0800 > Subject: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 7-December-2002 > Reply-To: [EMAIL PROTECTED] > > > > JBoss daily test results > > SUMMARY > > Number of tests run: 1001 > > -------------------------------------------- > > Successful tests: 990 > > Errors: 9 > > Failures: 2 > > -------------------------------------------- > > > > [time of test: 2002-12-07.21-02 GMT] > [java.version: 1.3.1_05] > [java.vendor: Sun Microsystems Inc.] > [java.vm.version: 1.3.1_05-b02] > [java.vm.name: Java HotSpot(TM) Client VM] > [java.vm.info: mixed mode] > [os.name: Windows 2000] > [os.arch: x86] > [os.version: 5.0] > > See http://users.jboss.org/~starksm/Branch_3_0/2002-12-07.21-02 > for details of this test. > > NOTE: If there are any errors shown above - this mail is only highlighting > them - it is NOT indicating that they are being looked at by anyone. > > It is assumed that whoever makes change(s) to jboss that > break the test will be fixing the test or jboss, as appropriate! > > -------------------------------------------- > > > > DETAILS OF ERRORS > > > > Suite: CircularityUnitTestCase > Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase ) > Type: error > Exception: javax.management.MBeanException > Message: Exception in MBean operation 'testPackageProtected()' > --------------------------------- > > > > Suite: BeanStressTestCase > Test: testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) > Type: failure > Exception: junit.framework.AssertionFailedError > Message: expected a client deadlock for AB BA > --------------------------------- > > > > Suite: RollBackUnitTestCase > Test: testAsynchQueueReceiveBack(org.jboss.test.jbossmq.test.RollBackUnitTestCase) > Type: error > Exception: java.lang.NoSuchMethodError > Message: > --------------------------------- > > > > Suite: RollBackUnitTestCase > Test: testAsynchTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUnitTestC ase) > Type: error > Exception: java.lang.NoSuchMethodError > Message: > --------------------------------- > > > > Suite: RollBackUnitTestCase > Test: testAsynchDurableTopicReceiveRollBack(org.jboss.test.jbossmq.test.RollBackUn itTestCase) > Type: error > Exception: java.lang.NoSuchMethodError > Message: > --------------------------------- > > > > Suite: ContextCLTestCase > Test: testInvokeNeedingTCL(org.jboss.test.jbossmx.implementation.server.ContextCLT estCase) > Type: error > Exception: javax.management.RuntimeMBeanException > Message: RuntimeException in MBean operation 'registerClassLoader(,org.jboss.mx.loading.UnifiedClassLoader)' > --------------------------------- > > > > Suite: BaseConnectionManagerUnitTestCase > Test: testFillToMin(org.jboss.test.jca.test.BaseConnectionManagerUnitTestCase) > Type: failure > Exception: junit.framework.AssertionFailedError > Message: Wrong number of connections counted: 0 > --------------------------------- > > > > Suite: LocalWrapperCleanupUnitTestCase > Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupU nitTestCase) > Type: error > Exception: java.rmi.ServerException > Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! > --------------------------------- > > > > Suite: MissingClassUnitTestCase > Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCa se) > Type: error > Exception: org.jboss.deployment.DeploymentException > Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) > --------------------------------- > > > > Suite: SimpleUnitTestCase > Test: testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) > Type: error > Exception: javax.security.auth.login.LoginException > Message: Missing users.properties file. > --------------------------------- > > > > Suite: SimpleUnitTestCase > Test: testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) > Type: error > Exception: javax.naming.AuthenticationException > Message: Failed to login using protocol=testLoginInitialContext > --------------------------------- > > > > > --__--__-- > > Message: 6 > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > Date: Sat, 07 Dec 2002 21:48:37 -0800 > Subject: [JBoss-dev] [ jboss-Bugs-609902 ] java.lang.LinkageError: loader ... > Reply-To: [EMAIL PROTECTED] > > Bugs item #609902, was opened at 2002-09-16 05:47 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=609902&group_id =22866 > > Category: JBossServer > Group: v3.2 > >Status: Closed > >Resolution: Fixed > Priority: 5 > Submitted By: Alexei Yudichev (sflexus) > Assigned to: Scott M Stark (starksm) > Summary: java.lang.LinkageError: loader ... > > Initial Comment: > Assume some application (client) deployed into jboss uses EJBs > deployed in another application (server). If client's interfaces > declared as throwing some custom exception (in this case this > exception has to be present in both client and server > jars/wars/ears) a java.lang.LinkageError may occur when trying > to invoke inside client methods of server's interface those throwing > that custom exception: > > java.lang.LinkageError: loader > constraints violated when linking xxx/xxx/Clazz class > > In > my case the exception occurs after I re-deploy the client > application. Only by restarting jboss it is possible to restore the > normal functionality once the error is occured. > > I suppose > this is because the custom exception class isn't loaded by a > common classloader as all interface classes, return type classes > etc. are. > > This problem doesn't appear in jboss > 2.4.x. > > EJB spec allows custom exceptions so I think this is > a bug, not a feature. > > ---------------------------------------------------------------------- > > >Comment By: Scott M Stark (starksm) > Date: 2002-12-07 21:48 > > Message: > Logged In: YES > user_id=175228 > > Duplicate classes within a loader repository are no longer > loaded by more than one class loader so this issue should > be resolved. > > ---------------------------------------------------------------------- > > Comment By: Scott M Stark (starksm) > Date: 2002-09-28 13:08 > > Message: > Logged In: YES > user_id=175228 > > In 3.0 this is just a packaging issue. 2.4 would automatically > downgrade communcation to marshall call between > incompatible class loading contexts. 3.0 does not do this so > you simply need to place the shared classes into a common > jar and drop it in the lib directory. 3.2 will try to resolve these > conflicts and create scoped class loading contexts as > neccessary. > > ---------------------------------------------------------------------- > > Comment By: Alexei Yudichev (sflexus) > Date: 2002-09-17 06:55 > > Message: > Logged In: YES > user_id=345880 > > Allright I found that this is a feature of a classloaders architecture which > counts on there're no duplicate classes across deployed applications. > But could the error be handled somehow? > > ---------------------------------------------------------------------- > > Comment By: Alexei Yudichev (sflexus) > Date: 2002-09-16 09:28 > > Message: > Logged In: YES > user_id=345880 > > I have changed my custom exception to JavaMail's AddressException > and the problem still persists. Then I've removed application exceptions > entirely and at last everything started to work well. So the problem > doesn't depend on whether declared in bean interface exceptions are > packaged with application or they are standard exceptions loaded from > jbosshome/server/<name>/lib jars. > > ---------------------------------------------------------------------- > > Comment By: Alexei Yudichev (sflexus) > Date: 2002-09-16 08:52 > > Message: > Logged In: YES > user_id=345880 > > I have changed my custom exception to JavaMail's AddressException > and the problem still persists. Then I've removed application exceptions > entirely and at last everything started to work well. So the problem > doesn't depend on whether declared in bean interface exceptions are > packaged with application or they are standard exceptions loaded from > jbosshome/server/<name>/lib jars. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=609902&group_id =22866 > > > --__--__-- > > Message: 7 > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > Date: Sat, 07 Dec 2002 21:51:03 -0800 > Subject: [JBoss-dev] [ jboss-Bugs-637168 ] Cannot start catalina service > Reply-To: [EMAIL PROTECTED] > > Bugs item #637168, was opened at 2002-11-12 07:19 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=637168&group_id =22866 > > Category: CatalinaBundle > Group: v3.2 > >Status: Closed > >Resolution: Wont Fix > Priority: 5 > Submitted By: Shakeel Mahate (shakeelmahate) > Assigned to: Scott M Stark (starksm) > Summary: Cannot start catalina service > > Initial Comment: > The tomcat service xml file has an error. > > It has entity catalina.home defined as ..\catalina > or ..\tomcat-4.1.x > > As a consequence of that hardcoded .. path the > directory from which you start the run script should > always be tomcat_dist\bin > > If you add tomcat_dist\bin to your path and then try to > execute the script run from lets say tomcat_dist > directory you get a ClassNotFoundException on > org.apache.catalina.context when the tomcat service is > being deployed. > > So what's the workaround. > > Ofcourse > 1. Start the script from the bin directory > 2. Update a README and specify the limitation > > > The correct fix would be to fix the catalina service. > > I am kinda surprised that this bug exists... > > ---------------------------------------------------------------------- > > >Comment By: Scott M Stark (starksm) > Date: 2002-12-07 21:51 > > Message: > Logged In: YES > user_id=175228 > > If you want to start from an arbitrary directory set the entity > path to an absolute value. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=637168&group_id =22866 > > > --__--__-- > > Message: 8 > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] > Date: Sat, 07 Dec 2002 21:52:38 -0800 > Subject: [JBoss-dev] [ jboss-Bugs-641155 ] EAR file class scoping problem > Reply-To: [EMAIL PROTECTED] > > Bugs item #641155, was opened at 2002-11-20 03:14 > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=641155&group_id =22866 > > Category: None > Group: v3.0 Rabbit Hole > >Status: Closed > >Resolution: Out of Date > Priority: 5 > Submitted By: Giles Paterson (gpaterson) > Assigned to: Scott M Stark (starksm) > Summary: EAR file class scoping problem > > Initial Comment: > JBoss: 3.0.4 > OS: Windows 2000 Server > Java Version: > java version "1.3.1_01" > Java(TM) 2 Runtime Environment, Standard Edition (build > 1.3.1_01) > Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode) > > > This bug report has been created at the request of > Scott M Stark in response to my posting to the > jboss-user mailing list > > Here is the content of the email I sent to the mailing > list: > --- > For the full details, take a look at the following > forum thread: > > http://www.jboss.org/forums/thread.jsp?forum=47&thread=24806 > > Basically, I have an EAR file that is structured like this: > > main.ear: > some_ejbs.jar > some_more_ejbs.jar > a_web_app.war > lib/ > third_party_libs.jar > common_code.jar > META-INF/ > application.xml > > This jar was working perfectly under Weblogic 6.1, but > just doesn't want to play when ported to JBoss 3.0.4 > (Yes, JBoss > specific deployment descriptors have been added to the > various EJB jars). > > It is worth noting that the MANIFEST.MF files for the > EJB Jars and the War file reference various third party > and common jars > in the Class-Path element. > > Initially I was encountering all sorts of > IllegalAccessErrors and NoClassDefFoundErrors, and > adding a jboss-app.xml file to > the Ear to scope the classes didn't help at all. I was > making some progress by manually adding various jars to > the JBoss > start-up classpath but that wasn't a great solution. > > Finally I tried unpacking the EAR file into a > subdirectory of the deploy directory and the > application suddenly started > working (with no additional jars in the JBoss start-up > classpath). However, if I removed the jboss-app.xml > file from the > expanded directory, the application would stop working > and give me IllegalAccessErrors again. This suggests to > me that Class > scoping doesn't always work in 3.0.4 if the application > is packaged in an EAR file, but it does work if the EAR > file is > expanded out into a directory. > > After some further trawling of the mailing list > archives, I believe this may be related to the fact > that my EJB jars, > reference the same common and third party jars in their > MANIFEST.MF Class-Path entries (There was a thread > concerning this > back in August/September > http://www.mail-archive.com/[email protected]/msg20584.html > ), and possibly to bug > #602828 > > Currently, I am satisfied with deploy my app as an > expanded EAR directory, but I would prefer to use an > EAR as it simplifies > the deployment process. Does anyone have any comments > or suggestions concerning this? I haven't had a chance > to delve into the > JBoss code yet, but I'm intrigued as to why the Class > loading works differently for Ear files as compared to > expanded > directories. > > --- > > I have been unable, so far, to create a simple test ear > that recreates the problem, so I have instead attached > a UCL log file. > > I will attempt to create an example EAR file and upload > that when I get a chance. > > > > ---------------------------------------------------------------------- > > >Comment By: Scott M Stark (starksm) > Date: 2002-12-07 21:52 > > Message: > Logged In: YES > user_id=175228 > > I have not received any feedback so this is closed until more > info is available. > > ---------------------------------------------------------------------- > > Comment By: Scott M Stark (starksm) > Date: 2002-11-23 18:30 > > Message: > Logged In: YES > user_id=175228 > > The trace log shows no NoClassDefFoundErrors and will not > show any IllegalAccessErrors so what are the corresponding > stack traces seen in the server log so I know what classes > are involved. > > ---------------------------------------------------------------------- > > Comment By: Giles Paterson (gpaterson) > Date: 2002-11-20 03:21 > > Message: > Logged In: YES > user_id=124102 > > Well, the zipped UCL log was too large to attach here, so > I've emailed it to Scott Stark instead. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376685&aid=641155&group_id =22866 > > > > --__--__-- > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > End of Jboss-development Digest > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
