Re: [JBoss-dev] UnifiedClassLoader notifications?
A loader repository sends a jboss.mx.class.removed event type with a message value equal to the class name for each class being removed when a class loader is removed from the repository. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 11:13 PM Subject: [JBoss-dev] UnifiedClassLoader notifications? Can I register with a UnifiedClassLoader for a notification when the class loader is dereferenced by JBoss? I'm writing an object copier service for the new persistence engine and cache, so I'm holding on to some metadata for each class that can be copied. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 6-March-2003
JBoss daily test results SUMMARY Number of tests run: 1138 Successful tests: 1131 Errors:7 Failures: 0 [time of test: 2003-03-06.07-55 GMT] [java.version: 1.4.1_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_01-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-03-06.07-55 for the junit report 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: StatelessSessionUnitTestCase Test: testLocalStatelessSession(org.jboss.test.cts.test.StatelessSessionUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: RuntimeException; nested exception is: java.lang.IllegalStateException: No local home defined. - Suite: SecurityUnitTestCase Test:runValidDynDurSub(org.jboss.test.jbossmq.test.SecurityUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .)) - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: javax.management.InstanceNotFoundException Message: jboss.management.local:J2EEApplication=cts-v1cmp.ear,J2EEServer=Local,j2eeType=EJBModule,name=cts-v1cmp.jar is not registered. - Suite: HttpsUnitTestCase Test:testJSSE(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.net.BindException Message: Address already in use: JVM_Bind - Suite: SRPUnitTestCase Test:testEchoArgs(org.jboss.test.security.test.SRPUnitTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-688613 ] Class loader problem
Bugs item #688613, was opened at 2003-02-18 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=688613group_id=22866 Category: JBossMX Group: None Status: Deleted Resolution: Duplicate Priority: 5 Submitted By: Shyam Sundar (shyamvs) Assigned to: Nobody/Anonymous (nobody) Summary: Class loader problem Initial Comment: Dear Friends, I am using jboss-3.0.5_tomcat-4.1.18. In that i have two applications where in application1 test.ear has a test.jar +test.sar+dtd/myconf.dtd application2 testA.ear has test.sar+dtd/myconf1.dtd In test.jar of test.ear i have test.class which access dtd/myconf.dtd and dtd/myconf1.dtd In test.sar of both applications in the startService method i instantiate the test.class and access the both dtd/myconf.dtd dtd/myconf1.dtd At this point of time i am not able to get the resource dtd/myconf1.dtd from application testA.ear after deploying two applications. i am using this.getClass().getClassLoader().getResource(dtd/myconf1.dtd) This problem happens only in extracted mode of deployment through MainDeployer present in JMX-console -- Comment By: Juha Lindfors (juhalindfors) Date: 2003-03-06 13:23 Message: Logged In: YES user_id=175239 Duplicate of 688607 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=688613group_id=22866 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-692817 ] JDBCOptimisticLock fails under heavy load
Bugs item #692817, was opened at 2003-02-25 11:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=692817group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Simone (milasx) Assigned to: Alexey Loubyansky (loubyansky) Summary: JDBCOptimisticLock fails under heavy load Initial Comment: JBoss 3.2.0 RC1 Windows NT 4 Solaris 8 JDK 1.4.1_01 0) In standardjboss.xml set locking-policy org.jboss.ejb.plugins.lock.JDBCOptimisticLock /locking-policy 1) Define an Entity Bean with an associated Value Object (Xdoclet) 2) Define a finder method 3) Implement an EJB Session Facade to the Entity Bean 4) In the session facade provide a facade to the finder that return an array of Value Object 5) Call the session facade repetedly. 6) Some of the call will fails with Exception: javax.ejb.EJBException: Reentrant method call detected: YourEntityBean 4592 at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:82) -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-03-06 13:27 Message: Logged In: YES user_id=543482 Hi Simone, I just tested with the sources you sent me and had no problems. Could you show the resulting DDs you use? How do you configure optimistic locking? Thanks, alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=692817group_id=22866 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-679705 ] 3.0.6 fails to start with AbstractMethodError on IBM 1.4 VM
Bugs item #679705, was opened at 2003-02-03 20:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=679705group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Pending Resolution: Wont Fix Priority: 5 Submitted By: Stefan Kuehnel (skuehnel) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0.6 fails to start with AbstractMethodError on IBM 1.4 VM Initial Comment: TestingJBoss 3.0.6 with an IBM 1.4 VM on Linux I get an AbstractMethodError on startup for AbstractDeploymentScanner.scan() when starting the URLDeploymentScanner. This happens both if JBoss was compiled with a Sun as well as an IBM JDK. System info: 19:01:34,499 INFO [ServerInfo] Java version: 1.4.0,IBM Corporation 19:01:34,500 INFO [ServerInfo] Java VM: Classic VM 1.4.0,IBM Corporation 19:01:34,526 INFO [ServerInfo] OS-System: Linux 2.4.18-17.7.x,x86 Exception: 2003-02-03 19:01:45,294 INFO [org.jboss.deployment.scanner.URLDeploymentScanner] Starting 2003-02-03 19:01:45,301 ERROR [org.jboss.deployment.MainDeployer] could not start deployment: file:/home/stefan/tools/jboss/jboss-3.0.6-src-IBM/build/output/jboss-3.0.6/server/all/conf/jboss-service.xml java.lang.AbstractMethodError: org/jboss/deployment/scanner/AbstractDeploymentScanner.scan at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:261) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:165) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:40) at java.lang.reflect.Method.invoke(Method.java:335) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:1003) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:413) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:40) at java.lang.reflect.Method.invoke(Method.java:335) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy2.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:230) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:814) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:575) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:61) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:40) at java.lang.reflect.Method.invoke(Method.java:335) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:222) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:566) 2003-02-03 19:01:45,468 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.parentTraceEnabled=true 2003-02-03 19:01:45,470 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.nestedTraceEnabled=false 2003-02-03 19:01:45,470 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true 2003-02-03 19:01:45,471 ERROR [org.jboss.system.server.Server] start failed org.jboss.deployment.DeploymentException: Could not create deployment: file:/home/stefan/tools/jboss/jboss-3.0.6-src-IBM/build/output/jboss-3.0.6/server/all/conf/jboss-service.xml; - nested throwable: (java.lang.AbstractMethodError: org/jboss/deployment/scanner/AbstractDeploymentScanner.scan) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:835) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:627) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:591) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:575) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:61) at
[JBoss-dev] [ jboss-Bugs-698682 ] DynamicQL concurrency problem
Bugs item #698682, was opened at 2003-03-06 09:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=698682group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Mauricio Hiroshi Nagaoka (mhnagaoka) Assigned to: Nobody/Anonymous (nobody) Summary: DynamicQL concurrency problem Initial Comment: I've been using DynamicQL with CMP Entity Beans in JBoss 3.0.6 and it's working quite well, except for a little problem. When I've more than one client running a DynamicQL query at the same time over the same CMP Entity Bean, sometimes I got the following exception: 2003-02-20 18:58:29,857 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackLocalException, causedBy: java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCom mand.execute(JDBCAbstractQueryCommand.java:161) at org.jboss.ejb.plugins.cmp.jdbc.JDBCDynamicQLQuery.e xecute(JDBCDynamicQLQuery.java:101) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCSelectorBridg e.execute(JDBCSelectorBridge.java:64) at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationH andler.invoke(EntityBridgeInvocationHandler.java:96) at org.jboss.proxy.compiler.Runtime.invoke (Runtime.java:59) at br.com.smbsoftware.webflow.tc.entity.TaskInfoBean$Pro xy.ejbSelectGeneric(generated) at br.com.smbsoftware.webflow.tc.entity.TaskInfoBean.ejbH omeSelectGeneric(TaskInfoBean.java:731) at sun.reflect.GeneratedMethodAccessor436.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke Home(EntityContainer.java:1138) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractInterceptor.java:73) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv okeHome(EntitySynchronizationInterceptor.java:207) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invokeHome (CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome (AbstractInterceptor.java:73) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHo me(EntityInstanceInterceptor.java:90) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInterceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHo me(EntityCreationInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome (TxInterceptorCMT.java:62) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome (SecurityInterceptor.java:105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome (LogInterceptor.java:129) at org.jboss.ejb.EntityContainer.invokeHome (EntityContainer.java:487) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv okeHome(BaseLocalContainerInvoker.java:230) at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke (LocalHomeProxy.java:110) at $Proxy198.selectGeneric(Unknown Source) at br.com.smbsoftware.webflow.tc.session.TaskControlBea n.getTaskInfoId(TaskControlBean.java:932) at sun.reflect.GeneratedMethodAccessor483.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatelessSessionContainer$ContainerInterc eptor.invoke(StatelessSessionContainer.java:660) at org.jboss.resource.connectionmanager.CachedConnectio nInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceIntercept or.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:92) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:204) at org.jboss.ejb.StatelessSessionContainer.invoke (StatelessSessionContainer.java:313) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.StatelessSessionProxy.invoke (StatelessSessionProxy.java:81) at $Proxy208.getTaskInfoId(Unknown Source) at br.com.smbsoftware.webflow.tc.TaskControlDelegate.get TaskInfoId(TaskControlDelegate.java:348) at br.com.smbsoftware.bombril.struts.SearchTaskAction.ex ecute(SearchTaskAction.java:87) at org.apache.struts.action.RequestProcessor.processActi onPerform(RequestProcessor.java:446) at org.apache.struts.action.RequestProcessor.process (RequestProcessor.java:266) at org.apache.struts.action.ActionServlet.process
[JBoss-dev] Is JDK 1.4 required to build
Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
+1 to required JDK 1.4 for HEAD --jason On Friday, March 7, 2003, at 12:59 AM, Dain Sundstrom wrote: Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Unified interceptors?
Any idea when this will become reality for HEAD? The spaghetti interceptor model is making the separation of EJB bits from the server module very hairy if not impossible. --jason --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Unified interceptors?
then don't do it and chillThis split is not very important. I am working on it Monday. I'm doing benchmarks the next 2 days. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Dillon Sent: Thursday, March 06, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Unified interceptors? Any idea when this will become reality for HEAD? The spaghetti interceptor model is making the separation of EJB bits from the server module very hairy if not impossible. --jason --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unified interceptors?
I am chill... are you? --jason On Friday, March 7, 2003, at 02:26 AM, Bill Burke wrote: then don't do it and chillThis split is not very important. I am working on it Monday. I'm doing benchmarks the next 2 days. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Dillon Sent: Thursday, March 06, 2003 2:04 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Unified interceptors? Any idea when this will become reality for HEAD? The spaghetti interceptor model is making the separation of EJB bits from the server module very hairy if not impossible. --jason --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-698962 ] BMP deployment of ECperf fails
Bugs item #698962, was opened at 2003-03-06 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=698962group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Nobody/Anonymous (nobody) Summary: BMP deployment of ECperf fails Initial Comment: ECPerf doesn't successfully run in the BMP deployment mode, on either JDK 1.3.1 or JDK 1.4.1 on MacOSX. I also couldn't make it work on Jboss 3.0. What's happening is that com.sun.ecperf.mfg.workorderent.ejb.WorkOrderBmpEJB.ejbStore() can't find the primary key it was created with. To reproduce, recompile and deploy ecperf with the BMP descriptors, and point your web browser to localhost:8080/ECperf/. Follow the customer link, and create an order. The order will fail with the same problem as indicated in the stack trace. 17:03:32,849 ERROR [GlobalTxEntityMap] Entity synchronization failed javax.ejb.EJBException: Exception in store of entity:10101; CausedByException is: Optimistic concurrency control failed at org.jboss.ejb.GlobalTxEntityMap.syncEntities(GlobalTxEntityMap.java:172) at org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanup.beforeCompletion(GlobalTxEntityMap.java:211) at org.jboss.tm.TransactionImpl.doBeforeCompletion(TransactionImpl.java:1182) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:331) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:361) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:247) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:303) at org.jboss.ejb.Container.invoke(Container.java:681) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:341) at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:554) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=698962group_id=22866 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 6-March-2003
JBoss daily test results SUMMARY Number of tests run: 1067 Successful tests: 1062 Errors:1 Failures: 4 [time of test: 2003-03-06.12-04 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.4] See http://users.jboss.org/~starksm/Branch_3_0/2003-03-06.12-04 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: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) 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: SecurityUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: SecurityUnitTestCase Test: testSecureHttpInvokerFailure(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - 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: RemoteServiceUnitTestCase Test:testRecContent(org.jboss.test.jmx.test.RemoteServiceUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: No managed MBean registry avaliable. Start JBoss with -Djbossmx.mbean.registry.class=org.jboss.mx.server.registry.ManagedMBeanRegistry - --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unified interceptors?
Well it is still possible to separate the two w/o unified interceptors. Not including the bits from org.jboss.cmp (this stuff is very independent) there are about 150+ classes which are not directly dependent on the bits from org.jboss.ejb (and related). Some bits are forced to remain in jboss/ejb when they logically do not belong there because of the dependence on org.jboss.ejb.plugins.AbstractInterceptor. Also I am not really sure that the webapp stuff really belongs in the ejb module, but there is too much interaction with the org.jboss.metadata classes to pull them apart with out changes to the core meta data framework. What is left over is: org.jboss.cmp (I am guessing this is some of the new cmp framework) org.jboss.proxy (the core proxy compiler bits, could move to common) org.jboss.aspect (not sure what this is doing here) org.jboss.cache (not sure what this is doing here) org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil (required by org.jboss.cmp, does not depend on org.jboss.ejb) org.jboss.invocation (the invocation framework) org.jboss.jms (jms provider abstraction layer asf fluff) org.jboss.jmx (legacy adapters, connectors and whatever... should go away or move to jmx?) org.jboss.logging (default log4j logging service) org.jboss.metadata.XmlLoadable (the only class which was not EJB/J2EE specific) org.jboss.naming (naming proto handlers, default service helpers) org.jboss.security (jboss security interfaces, minus interceptors which depend on org.jboss.ejb) org.jboss.Shutdown (depends on the jmx fluff and should move to system once jmx/remote stuff is cleaned up) Does anyone know if any of the above is obsolete and can be removed? I still believe that making the EJB-specific components of JBoss separate from the core system services is a very, very good idea. It will help keep JBoss a generic framework by forcing developers to keep service and system classes and components separate. It will also help promote the fact that JBoss is not just an EJB container, or rather isn't an EJB container at all... just a generic framework which happens to also provide EJB/J2EE services. I feel that for the most part, the rest of the server is quite well organized into logical chunks of functionality. It is just this module which is the kitchen sink which has been bothering me for quite some time. I do not believe it is just a style issue either. Separation of functionality makes for better software engineering by isolation of similar components, which promotes simpler builds as well as unit and integration testing. So, I think we should make the change, but I think it will be best to wait until the unified interceptor work has been completed. Hopefully that will be done by middle of next week, after which I can redo this separation, now that I have discovered all of the interaction points. Once that has been completed and proves functional via the testsuite I think we should move the cmp2 bits to its own home. Comments? --jason --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] UnifiedClassLoader notifications?
What about the entire UCL itself? In AOP I have a Javassist type object that is paired with each UCL that I need to cycle when the UCL is done. Right now I have explicit calls in the ULR code to trigger this. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott M Stark Sent: Thursday, March 06, 2003 3:24 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] UnifiedClassLoader notifications? A loader repository sends a jboss.mx.class.removed event type with a message value equal to the class name for each class being removed when a class loader is removed from the repository. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 11:13 PM Subject: [JBoss-dev] UnifiedClassLoader notifications? Can I register with a UnifiedClassLoader for a notification when the class loader is dereferenced by JBoss? I'm writing an object copier service for the new persistence engine and cache, so I'm holding on to some metadata for each class that can be copied. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Unified interceptors?
On Thursday, March 6, 2003, at 04:08 PM, Jason Dillon wrote: What is left over is: org.jboss.cmp (I am guessing this is some of the new cmp framework) This is our new generic persistence code. Jason can you add a new empty module 'persistence' for us and we'll move the stuff over. org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil (required by org.jboss.cmp, does not depend on org.jboss.ejb) I'll move this stuff to org.jboss.util in the common package. I still believe that making the EJB-specific components of JBoss separate from the core system services is a very, very good idea. It will help keep JBoss a generic framework by forcing developers to keep service and system classes and components separate. It will also help promote the fact that JBoss is not just an EJB container, or rather isn't an EJB container at all... just a generic framework which happens to also provide EJB/J2EE services. +1 I feel that for the most part, the rest of the server is quite well organized into logical chunks of functionality. It is just this module which is the kitchen sink which has been bothering me for quite some time. I do not believe it is just a style issue either. Separation of functionality makes for better software engineering by isolation of similar components, which promotes simpler builds as well as unit and integration testing. +1 the server module is junk drawer especially org.jboss.ejb.plugins So, I think we should make the change, but I think it will be best to wait until the unified interceptor work has been completed. Hopefully that will be done by middle of next week, after which I can redo this separation, now that I have discovered all of the interaction points. Once that has been completed and proves functional via the testsuite I think we should move the cmp2 bits to its own home. We will as soon as we have a persistence module. Well the non EJB specific stuff will be moved to persistence, but a small number of classes will be put in org.jboss.ejb.entity.cmp. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Is JDK 1.4 required to build
+2, but already out ranked in earlier thread on same topic -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Dillon Sent: Thursday, March 06, 2003 1:30 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Is JDK 1.4 required to build +1 to required JDK 1.4 for HEAD --jason On Friday, March 7, 2003, at 12:59 AM, Dain Sundstrom wrote: Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
Originally I said I thought we needed to keep 4.0 buildable by JDK 1.3, but I'm starting to think otherwise. I'm about to give in to this demand. If users cannot switch to JDK 1.4 then I'm willing to say they cannot make use of the full set of features in 4.0. The remaining question I had was can the core services remain binary compatible with JDK 1.3, meaning JMX, AOP, deployers, etc. required to have a highly functional microkernel for building on top of. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:59 AM Subject: [JBoss-dev] Is JDK 1.4 required to build Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Is JDK 1.4 required to build
3 cheers for Scott! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott M Stark Sent: Thursday, March 06, 2003 11:50 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Is JDK 1.4 required to build Originally I said I thought we needed to keep 4.0 buildable by JDK 1.3, but I'm starting to think otherwise. I'm about to give in to this demand. If users cannot switch to JDK 1.4 then I'm willing to say they cannot make use of the full set of features in 4.0. The remaining question I had was can the core services remain binary compatible with JDK 1.3, meaning JMX, AOP, deployers, etc. required to have a highly functional microkernel for building on top of. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:59 AM Subject: [JBoss-dev] Is JDK 1.4 required to build Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
There's no requirement from JMX to use 1.4 yet. (excluding JSR160/Remoting) On Thu, 6 Mar 2003, Scott M Stark wrote: Originally I said I thought we needed to keep 4.0 buildable by JDK 1.3, but I'm starting to think otherwise. I'm about to give in to this demand. If users cannot switch to JDK 1.4 then I'm willing to say they cannot make use of the full set of features in 4.0. The remaining question I had was can the core services remain binary compatible with JDK 1.3, meaning JMX, AOP, deployers, etc. required to have a highly functional microkernel for building on top of. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:59 AM Subject: [JBoss-dev] Is JDK 1.4 required to build Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Juha Lindfors Author of JMX: Managing J2EE with Java Management Extensions --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
I got no problem making 99% of CMP working on 1.3 (basicially anything that does not require JDBC3). It is just the #ifdef stuff I hate. -dain On Thursday, March 6, 2003, at 10:49 PM, Scott M Stark wrote: Originally I said I thought we needed to keep 4.0 buildable by JDK 1.3, but I'm starting to think otherwise. I'm about to give in to this demand. If users cannot switch to JDK 1.4 then I'm willing to say they cannot make use of the full set of features in 4.0. The remaining question I had was can the core services remain binary compatible with JDK 1.3, meaning JMX, AOP, deployers, etc. required to have a highly functional microkernel for building on top of. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:59 AM Subject: [JBoss-dev] Is JDK 1.4 required to build Is JDK 1.4 now required to build? If not when are we going to add this requirement? I need an IdentityHashMap for the ObjectCopier and would like to encapsulate and delegate to IdentityHashMap for JDK 1.4 (because of speed) and for JDK 1.3 I will just is an IdentityKey wrapper. This code will be way easier to write if I can assume that we are compiling in 1.4. For now I will just write the 1.3 version. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-629145 ] ejb-link bug
Bugs item #629145, was opened at 2002-10-26 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=629145group_id=22866 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Stefan Wachter (stefanwachter) Assigned to: Christian Riege (lqd) Summary: ejb-link bug Initial Comment: JBoss V 3.0.3 I have an ear that contains an ejb.jar and web.war file. In the deployment descriptor of the web.war file (i.e. the web.xml) I have an ejb-ref to an EJB in the ejb.jar file. The spec says that the ejb-link element must contain the name of the jar-file followed by an '#' followed by the ejb-name of the referenced EJB: ejb-ref ejb-ref-nameejb/Converter/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homede.xyz.converter.ConverterHome/home remotede.xyz.converter.Converter/remote ejb-linkejb.jar#Converter/ejb-link /ejb-ref Running the application causes an exception whereas the SUN reference implementation is happy with this link. If the ejb-link is changed to ejb-linkConverter/ejb-link, i.e. the jar is omitted. then the application also runs on JBoss. The attached ear demonstrates this behaviour. -- Comment By: Christian Riege (lqd) Date: 2003-01-24 09:02 Message: Logged In: YES user_id=176671 hi, sorry for the absence but i was rather busy. as no one seems to have complained in HEAD about the fix as of yet i will backport this. it will take until mid next week though. in the meantime, CVS access by sourceforge should have been fixed by now. -- Comment By: David Calvente (davidcalvente) Date: 2003-01-16 20:41 Message: Logged In: YES user_id=689193 Hi, I´ve the same problem, and tried 3.04 and also 3.2 RC1 and nothing changed. I´ve read that Christian Riege commited a fix, but I´m not able to connect to CVS. Please, coul anyone tell me when will this bug be fixed (wich release) and how can I use Christian´s path do go on till then... Thanks a lot David -- Comment By: Christian Riege (lqd) Date: 2002-12-12 17:53 Message: Logged In: YES user_id=176671 i have commited a fix for this in CVS HEAD. could you please re-check against CVS HEAD and tell me if it solves your problem; if it does I will backport it into 3.0 and 3.2 respectively. -- Comment By: Christian Riege (lqd) Date: 2002-11-27 15:41 Message: Logged In: YES user_id=176671 JBoss currently happily ignores the specified jar file. I will look into this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=629145group_id=22866 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Is JDK 1.4 required to build
Make that 4 cheers! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Thursday, March 06, 2003 11:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Is JDK 1.4 required to build 3 cheers for Scott! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Is JDK 1.4 required to build
Agreed. I don't want that management headache propagated to 4.0. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, March 06, 2003 9:51 PM Subject: Re: [JBoss-dev] Is JDK 1.4 required to build I got no problem making 99% of CMP working on 1.3 (basicially anything that does not require JDBC3). It is just the #ifdef stuff I hate. -dain --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/remoting/output/classes [mkdir] Created dir: /home/jboss/jbossci/jboss-head/remoting/output/gen/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 62 source files to /home/jboss/jbossci/jboss-head/remoting/output/classes /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/remoting/detection/jndi/JNDIDetector.java:19: cannot resolve symbol symbol : class NamingContextFactory location: package interfaces import org.jnp.interfaces.NamingContextFactory; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/remoting/detection/jndi/JNDIDetector.java:20: cannot resolve symbol symbol : class Main location: package server import org.jnp.server.Main; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detection/jndi/JNDIDetectorTest.java:15: cannot resolve symbol symbol : class Main location: package server import org.jnp.server.Main; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/remoting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol symbol : class Main location: class org.jboss.remoting.detection.jndi.JNDIDetector Main server = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/remoting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol symbol : class Main location: class org.jboss.remoting.detection.jndi.JNDIDetector Main server = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/remoting/detection/jndi/JNDIDetector.java:370: cannot resolve symbol symbol : class NamingContextFactory location: class org.jboss.remoting.detection.jndi.JNDIDetector contextFactory = NamingContextFactory.class.getName(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detection/jndi/JNDIDetectorTest.java:57: cannot resolve symbol symbol : class Main location: class test.detection.jndi.JNDIDetectorTest Main JNDIServer = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detection/jndi/JNDIDetectorTest.java:57: cannot resolve symbol symbol : class Main location: class test.detection.jndi.JNDIDetectorTest Main JNDIServer = new Main(); ^ 8 errors BUILD FAILED file:/home/jboss/jbossci/jboss-head/remoting/../tools/etc/buildfragments/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 23 seconds --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
I did this while in process of doing checkin. Should be fixed in a minute. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, March 07, 2003 2:34 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/remoting/output/classes [mkdir] Created dir: /home/jboss/jbossci/jboss-head/remoting/output/gen/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 62 source files to /home/jboss/jbossci/jboss-head/remoting/output/classes /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:19: cannot resolve symbol symbol : class NamingContextFactory location: package interfaces import org.jnp.interfaces.NamingContextFactory; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:20: cannot resolve symbol symbol : class Main location: package server import org.jnp.server.Main; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio n/jndi/JNDIDetectorTest.java:15: cannot resolve symbol symbol : class Main location: package server import org.jnp.server.Main; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol symbol : class Main location: class org.jboss.remoting.detection.jndi.JNDIDetector Main server = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol symbol : class Main location: class org.jboss.remoting.detection.jndi.JNDIDetector Main server = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:370: cannot resolve symbol symbol : class NamingContextFactory location: class org.jboss.remoting.detection.jndi.JNDIDetector contextFactory = NamingContextFactory.class.getName(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio n/jndi/JNDIDetectorTest.java:57: cannot resolve symbol symbol : class Main location: class test.detection.jndi.JNDIDetectorTest Main JNDIServer = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio n/jndi/JNDIDetectorTest.java:57: cannot resolve symbol symbol : class Main location: class test.detection.jndi.JNDIDetectorTest Main JNDIServer = new Main(); ^ 8 errors BUILD FAILED file:/home/jboss/jbossci/jboss-head/remoting/../tools/etc/buil dfragments/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 23 seconds --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
