[JBoss-dev] [ jboss-Bugs-642250 ] CNFE Jdom
Bugs item #642250, was opened at 2002-11-22 12:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=642250group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Phil Cornelius (smapjb) Assigned to: Scott M Stark (starksm) Summary: CNFE Jdom Initial Comment: I have submitted this ear following the thread on jboss-user included below. The submitted ear works on Jboss-3.0.2 but not on 3.0.4 SNIP 3.0.4 should work, and does for the jbosstest-web.ear which I updated to include a servlet that accesses a class loaded from a jar referenced by an ejb-jar manifest Class-Path entry. If you have an ear that demonstrates the problem that you can submit to sourceforge open a bug and include the ear. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Phil Cornelius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 2:35 AM Subject: Re: [JBoss-user] JBoss 3.0.4 w/ Jetty Classloader Attached. I have however solved this by adding a copy of the manifest that is in the ejb jar to the war file (details in thread). So the question I have now is should the servlets have been able to find the jdom classes in 3.0.2? Yours Phil On Fri, 2002-11-15 at 17:19, Scott M Stark wrote: Show the complete stack trace of the CNFE coming from the servlet. The indentation of the ear is not coming through in this mail well so run the attached class on it and send that. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Phil Cornelius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 1:43 AM Subject: RE: [JBoss-user] JBoss 3.0.4 w/ Jetty Classloader Actually now you mention it.. I noticed something too.. My app is structured thus: -myear.ear -lib/ jdom.jar junit.jar +blah.war -blah.jar -META-INF/ Manifest.mf +otherstuff +META-INF/ In the manifest of my ejb jar I have Manifest-Version:1.0 Class-Path: ./lib/jdom.jar ./lib/junit.jar Now in Jboss-3.0.2 everything works fine and my servlets can access the jdom classes.. However in Jboss-3.0.4 I get ClassNotFound org.jdom.Element thrown from my servlets. I had a sniff around.. currently I am happy that it works with 3.0.2.. Can anyone shed light on this? Is there anything that I need to set in my WAR file like a Manifest.mf? I want to keep my third party libs in one place and I don't want to clutter the Jboss dist. so I want to avoid putting a copy in WEB-INF/lib Yours Phil /SNIP -- Comment By: Phil Cornelius (smapjb) Date: 2002-11-25 09:07 Message: Logged In: YES user_id=559447 JDK 1.4.1_01 on W2K. The exeption is thrown when the servlet is invoked.. http://localhost:8080/jdomtest/TestJDom I didn't include an EJB jar with manifest because I was able to reproduce the problem without. I am still unclear: why should it work? i.e. I am happy that I am required to add a classpath directive to the manifest of the war file.. so in a sense I am happy that it does not work in 3.0.4. -- Comment By: Scott M Stark (starksm) Date: 2002-11-24 02:44 Message: Logged In: YES user_id=175228 I have tried deploying the attached ear using both JDK 1.3.1_05 and JDK 1.4.1_01 with jboss-3.0.4 on a WinXP system and both work fine. The deployment info is shown below. What is the JVM and OS on which you see a problem? 19:37:24,379 INFO [Server] JBoss (MX MicroKernel) [3.0.4 Date:200211021607] Started in 0m:18s:807ms 19:37:49,405 INFO [MainDeployer] Starting deployment of package: file:/C:/tmp/JBoss/jboss- 3.0.4/server/default/deploy/testear.ear 19:37:49,415 INFO [EARDeployer] Init J2EE application: file:/C:/tmp/JBoss/jboss -3.0.4/server/default/deploy/testear.ear 19:37:49,505 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationContext=5,context=/j domtest 19:37:49,525 INFO [jbossweb] Extract jar:file:/C:/tmp/JBoss/jboss-3.0.4/server/ default/tmp/deploy/server/default/deploy/testear.ear/59.testear .ear-contents/web stuff.war!/ to C:\WINDOWS\TEMP\Jetty_0_0_0_0_8080__jdomtest\webapp 19:37:49,945 INFO [jbossweb] Started WebApplicationContext[/jdomtest,testWeb] 19:37:49,965 INFO [jbossweb] successfully deployed file:/C:/tmp/JBoss/jboss-3.0 .4/server/default/tmp/deploy/server/default/deploy/testear.ear/5 9.testear.ear-contents/webstuff.war to /jdomtest 19:37:49,965 INFO [MainDeployer] Deployed package: file:/C:/tmp/JBoss/jboss- 3.0.4/server/default/deploy/testear.ear -- You can respond by visiting:
[JBoss-dev] getting error timed out. status=STATUS_ACTIVE
Hello, I am getting following error frequently and then i have to restart jboss.I am using Jboss 3.0 with culstering feacture. this will cause my website to be down for the while. please write me proper solution as early as possible. 13:39:54,456 WARN [TxCapsule] Transaction XidImpl [FormatId=257, GlobalId=web1.myjaring.net//380568, BranchQual=] timed out. status=STATUS_ACTIVE 13:39:56,776 ERROR [BeanLock] Thread[RMI TCP Connection(42253)-61.6.32.121,5,RMI Runtime]Saw rolled back tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=web1.myjaring.net//380568, BranchQual=] waiting for txLock 13:39:56,777 ERROR [LogInterceptor] TransactionRolledbackException, causedBy: java.lang.IllegalStateException: removing bean lock and it has tx set! at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.removeRef(QueuedPessimisticEJBLock.java:469) at org.jboss.ejb.BeanLockManager.removeLockRef(BeanLockManager.java:78) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:124) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.EntityInterceptor.invoke(EntityInterceptor.java:116) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy190.getDeviceVendorId(Unknown Source) at net4nuts.scheduler.sendingservicesession.SendingServiceSessionBean.getConfiguredPortfolioServices(SendingServiceSessionBean.java:875) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:664) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke(JRMPInvokerHA.java:169) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) 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:479) 13:39:56,781 INFO [STDOUT] Exception ==javax.transaction.TransactionRolledbackException: removing bean lock and it has tx set!; nested exception is: java.lang.IllegalStateException: removing bean lock and it has tx set! thanks vishal --- 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
RE: [JBoss-dev] getting error timed out. status=STATUS_ACTIVE
no one heres gonna reply to it..post it to jboss user.. -Original Message- From: Vishal Shukla [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 3:36 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] getting error timed out. status=STATUS_ACTIVE Hello, I am getting following error frequently and then i have to restart jboss.I am using Jboss 3.0 with culstering feacture. this will cause my website to be down for the while. please write me proper solution as early as possible. 13:39:54,456 WARN [TxCapsule] Transaction XidImpl [FormatId=257, GlobalId=web1.myjaring.net//380568, BranchQual=] timed out. status=STATUS_ACTIVE 13:39:56,776 ERROR [BeanLock] Thread[RMI TCP Connection(42253)-61.6.32.121,5,RMI Runtime]Saw rolled back tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=web1.myjaring.net//380568, BranchQual=] waiting for txLock 13:39:56,777 ERROR [LogInterceptor] TransactionRolledbackException, causedBy: java.lang.IllegalStateException: removing bean lock and it has tx set! at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.removeRef(QueuedPess imisticEJBLock.java:469) at org.jboss.ejb.BeanLockManager.removeLockRef(BeanLockManager.java:78) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor .java:124) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInt erceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterce ptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptor CMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.jav a:129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:1 02) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.jav a:73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.EntityInterceptor.invoke(EntityInterceptor.java:116) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy190.getDeviceVendorId(Unknown Source) at net4nuts.scheduler.sendingservicesession.SendingServiceSessionBean.getCo nfiguredPortfolioServices(SendingServiceSessionBean.java:875) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Stat elessSessionContainer.java:664) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke( CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Statele ssSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterce ptor.java:96) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptor CMT.java:167) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.jav a:129) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer .java:313) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke(JRMPInvokerHA.java :169) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.ja va:701) at java.lang.Thread.run(Thread.java:479) 13:39:56,781 INFO [STDOUT] Exception ==javax.transaction.TransactionRolledbackException: removing bean lock and it has tx set!; nested exception is: java.lang.IllegalStateException: removing bean lock and it has tx set! thanks vishal --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
[JBoss-dev] [ jboss-Bugs-643465 ] IllegalStateException: INSERTING AN AL..
Bugs item #643465, was opened at 2002-11-25 12:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643465group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zoltan Luspai (zluspai) Assigned to: Nobody/Anonymous (nobody) Summary: IllegalStateException: INSERTING AN AL.. Initial Comment: Hi, I've encountered with an java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN exception during my experiments with JBOSS, which looks like a bug in which you have already recognized in the code of: org.jboss.ejb.plugins.AbstractInstanceCache.insert (AbstractInstanceCache.java:221). I've used JBOSS 3.0.3 with jdk1.4.1 on windows. To allow you to reproduce the bug I have compressed (rar) the very simple eclipse project I've used. This contains bean called NamedCountBean.java which should be used to generate the EJB interfaces with the Lomboz Eclipse plugin (in fact with XDOCLET), and built myEJBContainer.jar deployed to the JBOSS. Then when running the CountClient test code you can experience the bug after running it about 7 times. Actually this bean is a simple counter with a name as a key, and the client code removes this entity bean it the counter can be divided by seven. After the entity-bean is removed the next run of the client will throw this exception. I hope this helps. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643465group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-643465 ] IllegalStateException: INSERTING AN AL..
Bugs item #643465, was opened at 2002-11-25 12:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643465group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Zoltan Luspai (zluspai) Assigned to: Nobody/Anonymous (nobody) Summary: IllegalStateException: INSERTING AN AL.. Initial Comment: Hi, I've encountered with an java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN exception during my experiments with JBOSS, which looks like a bug in which you have already recognized in the code of: org.jboss.ejb.plugins.AbstractInstanceCache.insert (AbstractInstanceCache.java:221). I've used JBOSS 3.0.3 with jdk1.4.1 on windows. To allow you to reproduce the bug I have compressed (rar) the very simple eclipse project I've used. This contains bean called NamedCountBean.java which should be used to generate the EJB interfaces with the Lomboz Eclipse plugin (in fact with XDOCLET), and built myEJBContainer.jar deployed to the JBOSS. Then when running the CountClient test code you can experience the bug after running it about 7 times. Actually this bean is a simple counter with a name as a key, and the client code removes this entity bean it the counter can be divided by seven. After the entity-bean is removed the next run of the client will throw this exception. I hope this helps. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643465group_id=22866 --- 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
[JBoss-dev] Re: [JBoss-user] CMR Performance: Weblogic7 Much Faster Then JBoss
Dain, I've moved this to the dev list because I think it's more appropriate. I have now run the benchmark on 4.0. Initial results were disappointing until I realised that debug log output is on in a HEAD build and off in a Branch_3_0 build. Each time, the test was run three times: 1) Create the entities and retrieve; 2) Retrieve again; 3) Flush the cache; 4) Retrieve again. Essentially, the performance is the same, although cache flushing using the jmx-console appears to have done nothing apart from speed up the finder in 4.0. For some reason, finder speed with results in cache is significantly slower. I'm going to add the GlobalTxEntityMap.java fix and try profiling again. The current O(n/2) search of the ArrayList tends to dominate the numbers below. I've appended the container config to the end so that you can review it, as I needed to revise it for 4.0. Here are the results: jboss-4.0.0alpha (as of about an hour ago): 21:52:17,226 INFO [STDOUT] creating 1000 Blobs... 21:52:38,894 INFO [STDOUT] Creation complete, took 21665ms. 21:52:44,278 INFO [STDOUT] testing retrival speed... 21:52:44,280 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 21:52:44,670 INFO [STDOUT] finder took 388ms. 21:52:50,470 INFO [STDOUT] External ValueObject creation took 5798ms for 1000 objects. 21:52:52,052 INFO [STDOUT] Internal ValueObject creation took 1579ms for 1000 objects. 21:52:52,054 INFO [STDOUT] Secondary Retrival, beans are in cache. 21:52:52,565 INFO [STDOUT] finder took 504ms. 21:52:58,086 INFO [STDOUT] External ValueObject creation took 5519ms for 1000 objects. 21:52:59,613 INFO [STDOUT] Internal ValueObject creation took 1524ms for 1000 objects. 21:53:19,111 INFO [STDOUT] testing retrival speed... 21:53:19,113 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 21:53:19,369 INFO [STDOUT] finder took 254ms. 21:53:25,001 INFO [STDOUT] External ValueObject creation took 5629ms for 1000 objects. 21:53:26,536 INFO [STDOUT] Internal ValueObject creation took 1531ms for 1000 objects. 21:53:26,538 INFO [STDOUT] Secondary Retrival, beans are in cache. 21:53:27,014 INFO [STDOUT] finder took 475ms. 21:53:32,583 INFO [STDOUT] External ValueObject creation took 5567ms for 1000 objects. 21:53:34,122 INFO [STDOUT] Internal ValueObject creation took 1537ms for 1000 objects. 21:54:15,752 INFO [EntityContainer] flushing cache 21:54:47,076 INFO [EntityContainer] flushing cache 21:54:56,454 INFO [STDOUT] testing retrival speed... 21:54:56,456 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 21:54:56,693 INFO [STDOUT] finder took 235ms. 21:55:02,582 INFO [STDOUT] External ValueObject creation took 5886ms for 1000 objects. 21:55:04,170 INFO [STDOUT] Internal ValueObject creation took 1585ms for 1000 objects. 21:55:04,172 INFO [STDOUT] Secondary Retrival, beans are in cache. 21:55:04,658 INFO [STDOUT] finder took 475ms. 21:55:10,265 INFO [STDOUT] External ValueObject creation took 5604ms for 1000 objects. 21:55:11,839 INFO [STDOUT] Internal ValueObject creation took 1572ms for 1000 objects. jboss-3.0.5RC1 (before the fix to GlobalTxEntityMap.java): 22:21:18,622 INFO [STDOUT] creating 1000 Blobs... 22:21:39,016 INFO [STDOUT] Creation complete, took 20391ms. 22:21:44,309 INFO [STDOUT] testing retrival speed... 22:21:44,311 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 22:21:44,581 INFO [STDOUT] finder took 268ms. 22:21:50,336 INFO [STDOUT] External ValueObject creation took 5753ms for 1000 objects. 22:21:51,858 INFO [STDOUT] Internal ValueObject creation took 1519ms for 1000 objects. 22:21:51,861 INFO [STDOUT] Secondary Retrival, beans are in cache. 22:21:52,457 INFO [STDOUT] finder took 589ms. 22:21:57,761 INFO [STDOUT] External ValueObject creation took 5301ms for 1000 objects. 22:21:59,272 INFO [STDOUT] Internal ValueObject creation took 1508ms for 1000 objects. 22:22:29,303 INFO [STDOUT] testing retrival speed... 22:22:29,305 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 22:22:29,808 INFO [STDOUT] finder took 501ms. 22:22:36,482 INFO [STDOUT] External ValueObject creation took 6672ms for 1000 objects. 22:22:37,988 INFO [STDOUT] Internal ValueObject creation took 1504ms for 1000 objects. 22:22:37,990 INFO [STDOUT] Secondary Retrival, beans are in cache. 22:22:38,597 INFO [STDOUT] finder took 605ms. 22:22:43,968 INFO [STDOUT] External ValueObject creation took 5368ms for 1000 objects. 22:22:45,490 INFO [STDOUT] Internal ValueObject creation took 1520ms for 1000 objects. 22:24:56,018 INFO [EntityContainer] flushing cache 22:25:32,450 INFO [EntityContainer] flushing cache 22:25:49,847 INFO [STDOUT] testing retrival speed... 22:25:49,849 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache.
[JBoss-dev] [ jboss-Bugs-642250 ] CNFE Jdom
Bugs item #642250, was opened at 2002-11-22 04:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=642250group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Phil Cornelius (smapjb) Assigned to: Scott M Stark (starksm) Summary: CNFE Jdom Initial Comment: I have submitted this ear following the thread on jboss-user included below. The submitted ear works on Jboss-3.0.2 but not on 3.0.4 SNIP 3.0.4 should work, and does for the jbosstest-web.ear which I updated to include a servlet that accesses a class loaded from a jar referenced by an ejb-jar manifest Class-Path entry. If you have an ear that demonstrates the problem that you can submit to sourceforge open a bug and include the ear. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Phil Cornelius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 18, 2002 2:35 AM Subject: Re: [JBoss-user] JBoss 3.0.4 w/ Jetty Classloader Attached. I have however solved this by adding a copy of the manifest that is in the ejb jar to the war file (details in thread). So the question I have now is should the servlets have been able to find the jdom classes in 3.0.2? Yours Phil On Fri, 2002-11-15 at 17:19, Scott M Stark wrote: Show the complete stack trace of the CNFE coming from the servlet. The indentation of the ear is not coming through in this mail well so run the attached class on it and send that. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Phil Cornelius [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 15, 2002 1:43 AM Subject: RE: [JBoss-user] JBoss 3.0.4 w/ Jetty Classloader Actually now you mention it.. I noticed something too.. My app is structured thus: -myear.ear -lib/ jdom.jar junit.jar +blah.war -blah.jar -META-INF/ Manifest.mf +otherstuff +META-INF/ In the manifest of my ejb jar I have Manifest-Version:1.0 Class-Path: ./lib/jdom.jar ./lib/junit.jar Now in Jboss-3.0.2 everything works fine and my servlets can access the jdom classes.. However in Jboss-3.0.4 I get ClassNotFound org.jdom.Element thrown from my servlets. I had a sniff around.. currently I am happy that it works with 3.0.2.. Can anyone shed light on this? Is there anything that I need to set in my WAR file like a Manifest.mf? I want to keep my third party libs in one place and I don't want to clutter the Jboss dist. so I want to avoid putting a copy in WEB-INF/lib Yours Phil /SNIP -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 09:25 Message: Logged In: YES user_id=175228 Without an ejb jar with a manifest reference to lib/jdom.jar, jboss.jar is not loaded and the NoClassDefFoundError is expected. Add the ejb to complete the example. This should work because the unified loader repository includes the ejb classes and its referenced classes, and it the parent class loader of the web application. -- Comment By: Phil Cornelius (smapjb) Date: 2002-11-25 01:07 Message: Logged In: YES user_id=559447 JDK 1.4.1_01 on W2K. The exeption is thrown when the servlet is invoked.. http://localhost:8080/jdomtest/TestJDom I didn't include an EJB jar with manifest because I was able to reproduce the problem without. I am still unclear: why should it work? i.e. I am happy that I am required to add a classpath directive to the manifest of the war file.. so in a sense I am happy that it does not work in 3.0.4. -- Comment By: Scott M Stark (starksm) Date: 2002-11-23 18:44 Message: Logged In: YES user_id=175228 I have tried deploying the attached ear using both JDK 1.3.1_05 and JDK 1.4.1_01 with jboss-3.0.4 on a WinXP system and both work fine. The deployment info is shown below. What is the JVM and OS on which you see a problem? 19:37:24,379 INFO [Server] JBoss (MX MicroKernel) [3.0.4 Date:200211021607] Started in 0m:18s:807ms 19:37:49,405 INFO [MainDeployer] Starting deployment of package: file:/C:/tmp/JBoss/jboss- 3.0.4/server/default/deploy/testear.ear 19:37:49,415 INFO [EARDeployer] Init J2EE application: file:/C:/tmp/JBoss/jboss -3.0.4/server/default/deploy/testear.ear 19:37:49,505 INFO [jbossweb] Registered jboss.web:Jetty=0,JBossWebApplicationContext=5,context=/j domtest 19:37:49,525 INFO [jbossweb] Extract jar:file:/C:/tmp/JBoss/jboss-3.0.4/server/ default/tmp/deploy/server/default/deploy/testear.ear/59.testear .ear-contents/web stuff.war!/ to C:\WINDOWS\TEMP\Jetty_0_0_0_0_8080__jdomtest\webapp 19:37:49,945 INFO [jbossweb] Started
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 15:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alvaro Mota Goncalves (alvaromota) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException Initial Comment: SO - Linux RedHat JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun JBOSS Server 3.0.4 and 3.0.3 A session Bean packaged in a jar file (Session01.jar) is calling one entity bean packaged in another jar file (Entity01.jar) . Works great. I have one client in Tomcat in another machine. If I hot-deploy Session01.jar, it's work. But hot-deploy Entity01 get 20:34:59,449 ERROR [LogInterceptor] RuntimeException: java.lang.ClassCastException: $Proxy156 at com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find All(SManterTes teEJB.java:75) The solution is to hot-deploy Entity01 and Session01 in sequence works fine. Thanks Alvaro -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 09:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 Category: JBossServer Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alvaro Mota Goncalves (alvaromota) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException Initial Comment: SO - Linux RedHat JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun JBOSS Server 3.0.4 and 3.0.3 A session Bean packaged in a jar file (Session01.jar) is calling one entity bean packaged in another jar file (Entity01.jar) . Works great. I have one client in Tomcat in another machine. If I hot-deploy Session01.jar, it's work. But hot-deploy Entity01 get 20:34:59,449 ERROR [LogInterceptor] RuntimeException: java.lang.ClassCastException: $Proxy156 at com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find All(SManterTes teEJB.java:75) The solution is to hot-deploy Entity01 and Session01 in sequence works fine. Thanks Alvaro -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 10:26 Message: Logged In: YES user_id=175228 Deployments with explicit references to each other must be deployed as a unit so that the Java type system remains consistent. The type of a class is its fully qualified name + the class loader that loaded it. You cannot arbitrary redeploy components and introduce a new type and expect previously deployed components to continue to work unless the interaction between the components is completely stateless with respect to the classes shared between deployments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(JBoss_3_2_0_beta2 WonderLand) Testsuite Results: 25-November-2002
Number of tests run: 1033 Successful tests: 1020 Errors:11 Failures: 2 [time of test: 2002-11-25.17-51 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] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2002-11-25.17-51 for the junit report of this test. - http://users.jboss.org/~starksm/Branch_3_2/2002-11-25.17-51/logs/ for the logs for 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. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)
O.K. I have checked in the Authentication part (It shouldn't break the build). It consists of an axis handler (org.jboss.net.axis.security.SigAuthenticationHandler) which is where I thought the login (or at least preparation for the login) should happen. and the login module(s) (org.jboss.net.axis.security.login.spi.CertificateLoginModule). I have not checked in the xml digital signature verification handler yet, as it depends upon the Apache XML-Security library. Is that something that could be added to thirdparty? Thanks -jason On Saturday, November 23, 2002, at 02:51 PM, Scott M Stark wrote: There is no cached information unless you invoked the security manager isValid method. If you are doing the LoginContext then you are effectively replacing the security manager and only using the configured login module. You should be looking up the security manager rather than doing the login yourself. Just checkin the code and I'll point it in the right direction. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Essington To: [EMAIL PROTECTED] Sent: Friday, November 22, 2002 8:57 AM Subject: Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback) I think I understand this part well enough, however, here is what is happening in the case I am having trouble with. I am attempting to authenticate an X509Certificate that has arrived in an email (via jboss.net) I have a request handler that creates a LoginContext and a CallbackHandler and performs the login (successfully). Everyting has worked as expected so far, but when jboss.net attempts to invoke the requested method on the bean, JBoss wants the credentials authenticated again (still in the same domain), only this time it seems the JaasSecurityManager has no cached credentials to compare, so it falls through to the defaultLogin method where it attempts to use the SecurityAssociationHandler (CallbackHandler) that only knows how to deal with NameCallback and PasswordCallback. Since my login module retrieves the X509Certificate via an ObjectCallback, the login fails at this point with an UnsupportedCallbackException. I am wondering what has happened to my cached login information? What would cause JBoss to want to perform the authentication again? thanks -jason
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 12:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 Category: JBossServer Group: None Status: Open Resolution: Invalid Priority: 5 Submitted By: Alvaro Mota Goncalves (alvaromota) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException Initial Comment: SO - Linux RedHat JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun JBOSS Server 3.0.4 and 3.0.3 A session Bean packaged in a jar file (Session01.jar) is calling one entity bean packaged in another jar file (Entity01.jar) . Works great. I have one client in Tomcat in another machine. If I hot-deploy Session01.jar, it's work. But hot-deploy Entity01 get 20:34:59,449 ERROR [LogInterceptor] RuntimeException: java.lang.ClassCastException: $Proxy156 at com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find All(SManterTes teEJB.java:75) The solution is to hot-deploy Entity01 and Session01 in sequence works fine. Thanks Alvaro -- Comment By: Bill Burke (patriot1burke) Date: 2002-11-25 14:32 Message: Logged In: YES user_id=176497 Re-opening. Look at the stack trace. The CCE is around $Proxy156. Is there something going on between UCL and dynamically generated classes via java.lang.reflect.Proxy? -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 13:26 Message: Logged In: YES user_id=175228 Deployments with explicit references to each other must be deployed as a unit so that the Java type system remains consistent. The type of a class is its fully qualified name + the class loader that loaded it. You cannot arbitrary redeploy components and introduce a new type and expect previously deployed components to continue to work unless the interaction between the components is completely stateless with respect to the classes shared between deployments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643732 ] MainDeployer can't undeploy bad EARs
Bugs item #643732, was opened at 2002-11-25 14:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643732group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Michael Newcomb (mnewcomb) Assigned to: Nobody/Anonymous (nobody) Summary: MainDeployer can't undeploy bad EARs Initial Comment: Facts about MainDeployer: - all deployments (DeploymentInfo), both good or bad, go into a List called deploymentList when MainDeployer.init() completes (in a finally clause) - all deployments that that do not fail their DeploymentInfo.deployer.init() calls go into a Map called deploymentMap (DeploymentInfo.url to DeploymentInfo) This can cause problems when the DeploymentInfo.deployer throws a DeploymentException. The DeploymentInfo does not get inserted into the deploymentMap and can therefore never be removed. Any call to MainDeployer.undeploy() fails quietly because there is no entry inside of deploymentMap (because the DeploymentInfo.deployer threw an exception skipping that deploymentMap.put() call). All attempts to redeploy the application (even if the errors were corrected) fall on deaf ears and the new DeploymentInfos just keep getting put into the deploymentList List (small memory leak). A simple test case to demonstrate this error: 1. create an empty EAR file (nothing in the jar file) 2. deploy it 3. watch EARDeployer throw a DeploymentException stating that META-INF/application.xml doesn't exist 4. delete the EAR file (nothing happens) 5. try to re-deploy the EAR file (valid or not) and you get a new exception about how it is waiting for an appropriate deployer The only way to redeploy the application is to restart JBoss. I fixed this problem by adding some additional code to MainDeployer.undeploy. If undeploy can't find the DeploymentInfo object in deploymentMap, it simply searches through deploymentList looking for a match. I've fixed this in CVS, just entering it here so we can track the bug. The above test should now always throw only the no META-INF/application.xml file found exception. Michael -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643732group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-641740 ] jboss-3.0.4 classloader bug
Bugs item #641740, was opened at 2002-11-21 01:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641740group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: Later Priority: 5 Submitted By: Vladimir Korenev (vkorenev) Assigned to: Scott M Stark (starksm) Summary: jboss-3.0.4 classloader bug Initial Comment: The same bug was submitted against v.3.0.2 (see #606359) and it appeared again in v.3.0.4 -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 11:39 Message: Logged In: YES user_id=175228 The attached ia.log is a distillation of the server.log and ucl.log sent to me by Vladimir. It shows the CurrentUser class being loaded from the client-core-ejb.jar and the CbUser being loaded from the admin-ejb.jar. Presumably the classes are redundantly included in both of the jars. In order for this to work with the current class loading scheme the common classes that use package protected or protected access must be loaded by the same class loader. This means these utility classes must be factored out into a seperate jar that is referenced by the ejb-jars manifest Class- Path attribute. In 3.2 we will be looking at either transforming the deployment into a canonical set of classes or using a single UnifiedClassLoader for all of the jars in the top level deployment to avoid this. -- Comment By: Vladimir Korenev (vkorenev) Date: 2002-11-21 01:43 Message: Logged In: YES user_id=622967 I have got an IllegalAccessError when accessing a field with package access. IMHO it is a classloader bug. I have attached an archive with logs an 2 source files. P.S. The source files are ugly (they are not mine), but they worked fine on Orion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641740group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 09:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 Category: JBossServer Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alvaro Mota Goncalves (alvaromota) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException Initial Comment: SO - Linux RedHat JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun JBOSS Server 3.0.4 and 3.0.3 A session Bean packaged in a jar file (Session01.jar) is calling one entity bean packaged in another jar file (Entity01.jar) . Works great. I have one client in Tomcat in another machine. If I hot-deploy Session01.jar, it's work. But hot-deploy Entity01 get 20:34:59,449 ERROR [LogInterceptor] RuntimeException: java.lang.ClassCastException: $Proxy156 at com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find All(SManterTes teEJB.java:75) The solution is to hot-deploy Entity01 and Session01 in sequence works fine. Thanks Alvaro -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 11:42 Message: Logged In: YES user_id=175228 All that says is that the $Proxy156 does not implement the interface the proxy is being cast to. This is expected if you redeploy the entity bean and perform a finder call from the session bean that has an explicit reference to the previous version of the entity interface. Unless there is an example that shows the session bean has no explicit references to the entity interfaces the redeployment described is not valid. -- Comment By: Bill Burke (patriot1burke) Date: 2002-11-25 11:32 Message: Logged In: YES user_id=176497 Re-opening. Look at the stack trace. The CCE is around $Proxy156. Is there something going on between UCL and dynamically generated classes via java.lang.reflect.Proxy? -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 10:26 Message: Logged In: YES user_id=175228 Deployments with explicit references to each other must be deployed as a unit so that the Java type system remains consistent. The type of a class is its fully qualified name + the class loader that loaded it. You cannot arbitrary redeploy components and introduce a new type and expect previously deployed components to continue to work unless the interaction between the components is completely stateless with respect to the classes shared between deployments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643732 ] MainDeployer can't undeploy bad EARs
Bugs item #643732, was opened at 2002-11-25 14:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643732group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: Fixed Priority: 5 Submitted By: Michael Newcomb (mnewcomb) Assigned to: Nobody/Anonymous (nobody) Summary: MainDeployer can't undeploy bad EARs Initial Comment: Facts about MainDeployer: - all deployments (DeploymentInfo), both good or bad, go into a List called deploymentList when MainDeployer.init() completes (in a finally clause) - all deployments that that do not fail their DeploymentInfo.deployer.init() calls go into a Map called deploymentMap (DeploymentInfo.url to DeploymentInfo) This can cause problems when the DeploymentInfo.deployer throws a DeploymentException. The DeploymentInfo does not get inserted into the deploymentMap and can therefore never be removed. Any call to MainDeployer.undeploy() fails quietly because there is no entry inside of deploymentMap (because the DeploymentInfo.deployer threw an exception skipping that deploymentMap.put() call). All attempts to redeploy the application (even if the errors were corrected) fall on deaf ears and the new DeploymentInfos just keep getting put into the deploymentList List (small memory leak). A simple test case to demonstrate this error: 1. create an empty EAR file (nothing in the jar file) 2. deploy it 3. watch EARDeployer throw a DeploymentException stating that META-INF/application.xml doesn't exist 4. delete the EAR file (nothing happens) 5. try to re-deploy the EAR file (valid or not) and you get a new exception about how it is waiting for an appropriate deployer The only way to redeploy the application is to restart JBoss. I fixed this problem by adding some additional code to MainDeployer.undeploy. If undeploy can't find the DeploymentInfo object in deploymentMap, it simply searches through deploymentList looking for a match. I've fixed this in CVS, just entering it here so we can track the bug. The above test should now always throw only the no META-INF/application.xml file found exception. Michael -- Comment By: Michael Newcomb (mnewcomb) Date: 2002-11-25 14:46 Message: Logged In: YES user_id=382427 I fixed this in CVS. Can someone close this? I don't seem to have close priviledges. Thanks, Michael -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643732group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 12:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 Category: JBossServer Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alvaro Mota Goncalves (alvaromota) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException Initial Comment: SO - Linux RedHat JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun JBOSS Server 3.0.4 and 3.0.3 A session Bean packaged in a jar file (Session01.jar) is calling one entity bean packaged in another jar file (Entity01.jar) . Works great. I have one client in Tomcat in another machine. If I hot-deploy Session01.jar, it's work. But hot-deploy Entity01 get 20:34:59,449 ERROR [LogInterceptor] RuntimeException: java.lang.ClassCastException: $Proxy156 at com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find All(SManterTes teEJB.java:75) The solution is to hot-deploy Entity01 and Session01 in sequence works fine. Thanks Alvaro -- Comment By: Bill Burke (patriot1burke) Date: 2002-11-25 14:51 Message: Logged In: YES user_id=176497 Thanks for clarifying. -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 14:42 Message: Logged In: YES user_id=175228 All that says is that the $Proxy156 does not implement the interface the proxy is being cast to. This is expected if you redeploy the entity bean and perform a finder call from the session bean that has an explicit reference to the previous version of the entity interface. Unless there is an example that shows the session bean has no explicit references to the entity interfaces the redeployment described is not valid. -- Comment By: Bill Burke (patriot1burke) Date: 2002-11-25 14:32 Message: Logged In: YES user_id=176497 Re-opening. Look at the stack trace. The CCE is around $Proxy156. Is there something going on between UCL and dynamically generated classes via java.lang.reflect.Proxy? -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 13:26 Message: Logged In: YES user_id=175228 Deployments with explicit references to each other must be deployed as a unit so that the Java type system remains consistent. The type of a class is its fully qualified name + the class loader that loaded it. You cannot arbitrary redeploy components and introduce a new type and expect previously deployed components to continue to work unless the interaction between the components is completely stateless with respect to the classes shared between deployments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-641740 ] jboss-3.0.4 classloader bug
Bugs item #641740, was opened at 2002-11-21 01:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641740group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: Later Priority: 5 Submitted By: Vladimir Korenev (vkorenev) Assigned to: Scott M Stark (starksm) Summary: jboss-3.0.4 classloader bug Initial Comment: The same bug was submitted against v.3.0.2 (see #606359) and it appeared again in v.3.0.4 -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 11:58 Message: Logged In: YES user_id=175228 Looking more at the server.log I see: 2002-11-21 12:20:28,271 WARN [org.jboss.deployment.MainDeployer] The manifest e ntry in file:/D:/java/jboss- 3.0.4/server/default/tmp/deploy/server/default/deplo y/cboss.ear/66.cboss.ear-contents/client-core-ejb.jar references URL file:/D:/ja va/jboss- 3.0.4/server/default/tmp/deploy/server/default/deploy/cboss.ea r/66.cbos s.ear-contents/client-common.jar which could not be opened, entry ignored Run the attached ListJar class on the cboss.ear so I can see the complete structure and manifest references. You should be able to attach the output to this bug unless your ear is huge. -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 11:39 Message: Logged In: YES user_id=175228 The attached ia.log is a distillation of the server.log and ucl.log sent to me by Vladimir. It shows the CurrentUser class being loaded from the client-core-ejb.jar and the CbUser being loaded from the admin-ejb.jar. Presumably the classes are redundantly included in both of the jars. In order for this to work with the current class loading scheme the common classes that use package protected or protected access must be loaded by the same class loader. This means these utility classes must be factored out into a seperate jar that is referenced by the ejb-jars manifest Class- Path attribute. In 3.2 we will be looking at either transforming the deployment into a canonical set of classes or using a single UnifiedClassLoader for all of the jars in the top level deployment to avoid this. -- Comment By: Vladimir Korenev (vkorenev) Date: 2002-11-21 01:43 Message: Logged In: YES user_id=622967 I have got an IllegalAccessError when accessing a field with package access. IMHO it is a classloader bug. I have attached an archive with logs an 2 source files. P.S. The source files are ugly (they are not mine), but they worked fine on Orion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641740group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643740 ] 3.0.4 - distributable tag breaks deploy
Bugs item #643740, was opened at 2002-11-25 20:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643740group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: James Manning (jmm) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0.4 - distributable tag breaks deploy Initial Comment: This may be user error - it's kind of hard for me to follow the servlet 2.3 specification in terms of what exactly the distributable tag in a web-app means in terms of the application. However, AFAICT an empty webapp with only a distributable tag shouldn't break anything, but just such a web-app causes lots of problems. Even if the .war is to blame in this case, JBoss (IMHO) should handle it much more elegantly than current. When distributable was specified in a normal webapp I was trying to deploy, the error I got was bizarre: 2002-11-25 14:55:01,736 ERROR [org.mortbay.j2ee.session.Manager] could not create Store: org.mortbay.j2ee.session.JGStore java.lang.ClassNotFoundException: org.mortbay.j2ee.session.JGStore tons others, but that as my exception made it very hard to figure out what was going on :) Looks like the JGStore path may be because of a use of the mortbay stuff as the httpsession manager for the distributable case. 2002-11-25 15:04:15,299 INFO [org.jboss.jetty.JBossWebApplicationContext#/dummy] using Distributable HttpSession Manager: org.mortbay.j2ee.session.Manager@73a -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643740group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 15:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 Category: JBossServer Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alvaro Mota Goncalves (alvaromota) Assigned to: Nobody/Anonymous (nobody) Summary: ClassCastException Initial Comment: SO - Linux RedHat JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun JBOSS Server 3.0.4 and 3.0.3 A session Bean packaged in a jar file (Session01.jar) is calling one entity bean packaged in another jar file (Entity01.jar) . Works great. I have one client in Tomcat in another machine. If I hot-deploy Session01.jar, it's work. But hot-deploy Entity01 get 20:34:59,449 ERROR [LogInterceptor] RuntimeException: java.lang.ClassCastException: $Proxy156 at com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find All(SManterTes teEJB.java:75) The solution is to hot-deploy Entity01 and Session01 in sequence works fine. Thanks Alvaro -- Comment By: Alvaro Mota Goncalves (alvaromota) Date: 2002-11-25 18:07 Message: Logged In: YES user_id=354157 My enviroment is the following. 1 ) a remote client in a linux machine 2) JBOSS in another machine, Session Façade -- Entity Bean 3 ) Oracle 8.i RDMS in server/default/deploy/ i have : - One Remote SLSB in Session01.jar - One Local Entity in Entity02.jar First Scenario: - I change SLSB and make redeploy coping and overwriting Session01.jar it works. Second Scenario: - I change Entity and make redeploy coping and overwriting Entity01.jar I get an error: ClassCastException $Proxy - I redeploy Session it works. i attached the server log in this message. What's UCL? Thanks Alvaro -- Comment By: Bill Burke (patriot1burke) Date: 2002-11-25 17:51 Message: Logged In: YES user_id=176497 Thanks for clarifying. -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 17:42 Message: Logged In: YES user_id=175228 All that says is that the $Proxy156 does not implement the interface the proxy is being cast to. This is expected if you redeploy the entity bean and perform a finder call from the session bean that has an explicit reference to the previous version of the entity interface. Unless there is an example that shows the session bean has no explicit references to the entity interfaces the redeployment described is not valid. -- Comment By: Bill Burke (patriot1burke) Date: 2002-11-25 17:32 Message: Logged In: YES user_id=176497 Re-opening. Look at the stack trace. The CCE is around $Proxy156. Is there something going on between UCL and dynamically generated classes via java.lang.reflect.Proxy? -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 16:26 Message: Logged In: YES user_id=175228 Deployments with explicit references to each other must be deployed as a unit so that the Java type system remains consistent. The type of a class is its fully qualified name + the class loader that loaded it. You cannot arbitrary redeploy components and introduce a new type and expect previously deployed components to continue to work unless the interaction between the components is completely stateless with respect to the classes shared between deployments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643740 ] 3.0.4 - distributable tag breaks deploy
Bugs item #643740, was opened at 2002-11-25 20:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643740group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: James Manning (jmm) Assigned to: Nobody/Anonymous (nobody) Summary: 3.0.4 - distributable tag breaks deploy Initial Comment: This may be user error - it's kind of hard for me to follow the servlet 2.3 specification in terms of what exactly the distributable tag in a web-app means in terms of the application. However, AFAICT an empty webapp with only a distributable tag shouldn't break anything, but just such a web-app causes lots of problems. Even if the .war is to blame in this case, JBoss (IMHO) should handle it much more elegantly than current. When distributable was specified in a normal webapp I was trying to deploy, the error I got was bizarre: 2002-11-25 14:55:01,736 ERROR [org.mortbay.j2ee.session.Manager] could not create Store: org.mortbay.j2ee.session.JGStore java.lang.ClassNotFoundException: org.mortbay.j2ee.session.JGStore tons others, but that as my exception made it very hard to figure out what was going on :) Looks like the JGStore path may be because of a use of the mortbay stuff as the httpsession manager for the distributable case. 2002-11-25 15:04:15,299 INFO [org.jboss.jetty.JBossWebApplicationContext#/dummy] using Distributable HttpSession Manager: org.mortbay.j2ee.session.Manager@73a -- Comment By: James Manning (jmm) Date: 2002-11-25 20:08 Message: Logged In: YES user_id=11485 take 2 at attaching the dummy war file -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643740group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643739 ] unknown-pk? missing in jbosscmp-jdbc_3_0
Bugs item #643739, was opened at 2002-11-25 21:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643739group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Harald Venström (hvenstrom) Assigned to: Nobody/Anonymous (nobody) Summary: unknown-pk? missing in jbosscmp-jdbc_3_0 Initial Comment: The optional defaults element unknown-pk? is missing in the online document: http://www.jboss.org/j2ee/dtd/jbosscmp-jdbc_3_0.dtd for reason unknowed it seem to have been lost in the latest update? (fFrom the 22/11...). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643739group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 15:40
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866
Category: JBossServer
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Alvaro Mota Goncalves (alvaromota)
Assigned to: Nobody/Anonymous (nobody)
Summary: ClassCastException
Initial Comment:
SO - Linux RedHat
JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun
JBOSS Server 3.0.4 and 3.0.3
A session Bean packaged in a jar file (Session01.jar)
is calling
one entity bean packaged in another jar file
(Entity01.jar) .
Works great.
I have one client in Tomcat in another machine.
If I hot-deploy Session01.jar, it's work. But hot-deploy
Entity01
get
20:34:59,449 ERROR [LogInterceptor] RuntimeException:
java.lang.ClassCastException: $Proxy156
at
com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find
All(SManterTes
teEJB.java:75)
The solution is to hot-deploy Entity01 and Session01 in
sequence works fine.
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:17
Message:
Logged In: YES
user_id=354157
Hi Mr. Scott
--Deployments with explicit references to each other must be
deployed as a unit so that the Java type system remains
consistent.
How is possible to make an unexplicit reference to Entity Local
in another ejb-jar.file(Entity01.jar).?
Session -- Entity
The source code is:
private ECepTituloHome getHome() {
ECepTituloHome home = null;
try {
//Implementar o getHome Local para o JBOSS
InitialContext jndi = new InitialContext();
// delete all organizations
home = (ECepTituloHome)
jndi.lookup(ejb/entityEJB/ECepTituloBeanRef);
}
catch (Exception e) {
System.err.println(e.getMessage());
}
finally {
return home;
}
}
The client lookup source code is:
private SManterTesteHome getHome() {
SManterTesteHome home = null;
try {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
env.put(Context.PROVIDER_URL, alvaro.rededc.com.br:1099);
Context jndi = new InitialContext(env);
Object ref =
jndi.lookup(ejb/statelessEJB/SManterTesteBeanRef);
home = (SManterTesteHome) PortableRemoteObject.narrow(ref,
SManterTesteHome.class);
}
catch (Exception e) {
System.out.println(A + e.getMessage());
e.printStackTrace();
}
finally {
return home;
}
}
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:07
Message:
Logged In: YES
user_id=354157
My enviroment is the following.
1 ) a remote client in a linux machine
2) JBOSS in another machine, Session Façade -- Entity Bean
3 ) Oracle 8.i RDMS
in server/default/deploy/ i have :
- One Remote SLSB in Session01.jar
- One Local Entity in Entity02.jar
First Scenario:
- I change SLSB and make redeploy coping and overwriting
Session01.jar
it works.
Second Scenario:
- I change Entity and make redeploy coping and overwriting
Entity01.jar
I get an error:
ClassCastException $Proxy
- I redeploy Session
it works.
i attached the server log in this message.
What's UCL?
Thanks
Alvaro
--
Comment By: Bill Burke (patriot1burke)
Date: 2002-11-25 17:51
Message:
Logged In: YES
user_id=176497
Thanks for clarifying.
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-25 17:42
Message:
Logged In: YES
user_id=175228
All that says is that the $Proxy156 does not implement the
interface the proxy is being cast to. This is expected if you
redeploy the entity bean and perform a finder call from the
session bean that has an explicit reference to the previous
version of the entity interface. Unless there is an example
that shows the session bean has no explicit references to
the entity interfaces the redeployment described is not valid.
--
Comment By: Bill Burke (patriot1burke)
Date: 2002-11-25 17:32
Message:
Logged In: YES
user_id=176497
Re-opening.
Look at the stack trace. The CCE is around $Proxy156. Is there
something going on
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 15:40
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866
Category: JBossServer
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Alvaro Mota Goncalves (alvaromota)
Assigned to: Nobody/Anonymous (nobody)
Summary: ClassCastException
Initial Comment:
SO - Linux RedHat
JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun
JBOSS Server 3.0.4 and 3.0.3
A session Bean packaged in a jar file (Session01.jar)
is calling
one entity bean packaged in another jar file
(Entity01.jar) .
Works great.
I have one client in Tomcat in another machine.
If I hot-deploy Session01.jar, it's work. But hot-deploy
Entity01
get
20:34:59,449 ERROR [LogInterceptor] RuntimeException:
java.lang.ClassCastException: $Proxy156
at
com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find
All(SManterTes
teEJB.java:75)
The solution is to hot-deploy Entity01 and Session01 in
sequence works fine.
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:25
Message:
Logged In: YES
user_id=354157
Ok
I need to redeploy only the ejb-jar, without needing to
redeploy the whole application (ear).
How can i do this?
Thanks
Alvaro
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-25 18:20
Message:
Logged In: YES
user_id=175228
Its not possible which is why these ejbs need to be deployed
together in an ear so that redeployment cycles the classes
consistently.
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:17
Message:
Logged In: YES
user_id=354157
Hi Mr. Scott
--Deployments with explicit references to each other must be
deployed as a unit so that the Java type system remains
consistent.
How is possible to make an unexplicit reference to Entity Local
in another ejb-jar.file(Entity01.jar).?
Session -- Entity
The source code is:
private ECepTituloHome getHome() {
ECepTituloHome home = null;
try {
//Implementar o getHome Local para o JBOSS
InitialContext jndi = new InitialContext();
// delete all organizations
home = (ECepTituloHome)
jndi.lookup(ejb/entityEJB/ECepTituloBeanRef);
}
catch (Exception e) {
System.err.println(e.getMessage());
}
finally {
return home;
}
}
The client lookup source code is:
private SManterTesteHome getHome() {
SManterTesteHome home = null;
try {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
env.put(Context.PROVIDER_URL, alvaro.rededc.com.br:1099);
Context jndi = new InitialContext(env);
Object ref =
jndi.lookup(ejb/statelessEJB/SManterTesteBeanRef);
home = (SManterTesteHome) PortableRemoteObject.narrow(ref,
SManterTesteHome.class);
}
catch (Exception e) {
System.out.println(A + e.getMessage());
e.printStackTrace();
}
finally {
return home;
}
}
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:07
Message:
Logged In: YES
user_id=354157
My enviroment is the following.
1 ) a remote client in a linux machine
2) JBOSS in another machine, Session Façade -- Entity Bean
3 ) Oracle 8.i RDMS
in server/default/deploy/ i have :
- One Remote SLSB in Session01.jar
- One Local Entity in Entity02.jar
First Scenario:
- I change SLSB and make redeploy coping and overwriting
Session01.jar
it works.
Second Scenario:
- I change Entity and make redeploy coping and overwriting
Entity01.jar
I get an error:
ClassCastException $Proxy
- I redeploy Session
it works.
i attached the server log in this message.
What's UCL?
Thanks
Alvaro
--
Comment By: Bill Burke (patriot1burke)
Date: 2002-11-25 17:51
Message:
Logged In: YES
user_id=176497
Thanks for clarifying.
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-25 17:42
Message:
Logged In: YES
user_id=175228
All that says is that the $Proxy156 does not implement the
interface the proxy
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 09:40
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866
Category: JBossServer
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Alvaro Mota Goncalves (alvaromota)
Assigned to: Nobody/Anonymous (nobody)
Summary: ClassCastException
Initial Comment:
SO - Linux RedHat
JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun
JBOSS Server 3.0.4 and 3.0.3
A session Bean packaged in a jar file (Session01.jar)
is calling
one entity bean packaged in another jar file
(Entity01.jar) .
Works great.
I have one client in Tomcat in another machine.
If I hot-deploy Session01.jar, it's work. But hot-deploy
Entity01
get
20:34:59,449 ERROR [LogInterceptor] RuntimeException:
java.lang.ClassCastException: $Proxy156
at
com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find
All(SManterTes
teEJB.java:75)
The solution is to hot-deploy Entity01 and Session01 in
sequence works fine.
Thanks
Alvaro
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-25 12:20
Message:
Logged In: YES
user_id=175228
Its not possible which is why these ejbs need to be deployed
together in an ear so that redeployment cycles the classes
consistently.
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 12:17
Message:
Logged In: YES
user_id=354157
Hi Mr. Scott
--Deployments with explicit references to each other must be
deployed as a unit so that the Java type system remains
consistent.
How is possible to make an unexplicit reference to Entity Local
in another ejb-jar.file(Entity01.jar).?
Session -- Entity
The source code is:
private ECepTituloHome getHome() {
ECepTituloHome home = null;
try {
//Implementar o getHome Local para o JBOSS
InitialContext jndi = new InitialContext();
// delete all organizations
home = (ECepTituloHome)
jndi.lookup(ejb/entityEJB/ECepTituloBeanRef);
}
catch (Exception e) {
System.err.println(e.getMessage());
}
finally {
return home;
}
}
The client lookup source code is:
private SManterTesteHome getHome() {
SManterTesteHome home = null;
try {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
env.put(Context.PROVIDER_URL, alvaro.rededc.com.br:1099);
Context jndi = new InitialContext(env);
Object ref =
jndi.lookup(ejb/statelessEJB/SManterTesteBeanRef);
home = (SManterTesteHome) PortableRemoteObject.narrow(ref,
SManterTesteHome.class);
}
catch (Exception e) {
System.out.println(A + e.getMessage());
e.printStackTrace();
}
finally {
return home;
}
}
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 12:07
Message:
Logged In: YES
user_id=354157
My enviroment is the following.
1 ) a remote client in a linux machine
2) JBOSS in another machine, Session Façade -- Entity Bean
3 ) Oracle 8.i RDMS
in server/default/deploy/ i have :
- One Remote SLSB in Session01.jar
- One Local Entity in Entity02.jar
First Scenario:
- I change SLSB and make redeploy coping and overwriting
Session01.jar
it works.
Second Scenario:
- I change Entity and make redeploy coping and overwriting
Entity01.jar
I get an error:
ClassCastException $Proxy
- I redeploy Session
it works.
i attached the server log in this message.
What's UCL?
Thanks
Alvaro
--
Comment By: Bill Burke (patriot1burke)
Date: 2002-11-25 11:51
Message:
Logged In: YES
user_id=176497
Thanks for clarifying.
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-25 11:42
Message:
Logged In: YES
user_id=175228
All that says is that the $Proxy156 does not implement the
interface the proxy is being cast to. This is expected if you
redeploy the entity bean and perform a finder call from the
session bean that has an explicit reference to the previous
version of the entity interface. Unless there is an example
that shows the session bean has no explicit references to
the entity interfaces the
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 25-November-2002
Number of tests run: 995 Successful tests: 987 Errors:7 Failures: 1 [time of test: 2002-11-25.11-56 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-11-25.11-56 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. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] status of 3.2 branch
Hi all What's the current status of 3.2 branch? I just got 3.2 from cvs (without tags) and it creates a /output/jboss-3.2.0RC1/ dir to put the server. but when the server is started it shows : 19:04:35,618 INFO [Server] JBoss (MX MicroKernel) [3.2.0RC1 (build: CVSTag=JBoss_3_2_0_beta2 date=200211251337)] Started in 56s:312ms what's the tag, RC1 or beta2? -- | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959| | SICREDI Serviços | | Porto Alegre - Brasil| |xx| --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 11:40
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866
Category: JBossServer
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Alvaro Mota Goncalves (alvaromota)
Assigned to: Nobody/Anonymous (nobody)
Summary: ClassCastException
Initial Comment:
SO - Linux RedHat
JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun
JBOSS Server 3.0.4 and 3.0.3
A session Bean packaged in a jar file (Session01.jar)
is calling
one entity bean packaged in another jar file
(Entity01.jar) .
Works great.
I have one client in Tomcat in another machine.
If I hot-deploy Session01.jar, it's work. But hot-deploy
Entity01
get
20:34:59,449 ERROR [LogInterceptor] RuntimeException:
java.lang.ClassCastException: $Proxy156
at
com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find
All(SManterTes
teEJB.java:75)
The solution is to hot-deploy Entity01 and Session01 in
sequence works fine.
Thanks
Alvaro
--
Comment By: Bill Wadley (wrwadley)
Date: 2002-11-25 15:33
Message:
Logged In: YES
user_id=223475
My problem:
ClassCastExceptions on results from finders: $Proxy123
(numbers different per invocation)
- EJB's in .jar, Servlets in .war, all in .ear.
- Hot-deploy or server restart, it didn't matter.
- changed JVM's for server (1.3.1, 1.3.1_01, 1.4.1,
1.4.1_01); didn't matter
My solution:
Stop compiling with Jikes 1.15 and use the same java/javac
that I'm running the server with (Sun JDK 1.4.1).
Now all is well.
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 14:25
Message:
Logged In: YES
user_id=354157
Ok
I need to redeploy only the ejb-jar, without needing to
redeploy the whole application (ear).
How can i do this?
Thanks
Alvaro
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-25 14:20
Message:
Logged In: YES
user_id=175228
Its not possible which is why these ejbs need to be deployed
together in an ear so that redeployment cycles the classes
consistently.
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 14:17
Message:
Logged In: YES
user_id=354157
Hi Mr. Scott
--Deployments with explicit references to each other must be
deployed as a unit so that the Java type system remains
consistent.
How is possible to make an unexplicit reference to Entity Local
in another ejb-jar.file(Entity01.jar).?
Session -- Entity
The source code is:
private ECepTituloHome getHome() {
ECepTituloHome home = null;
try {
//Implementar o getHome Local para o JBOSS
InitialContext jndi = new InitialContext();
// delete all organizations
home = (ECepTituloHome)
jndi.lookup(ejb/entityEJB/ECepTituloBeanRef);
}
catch (Exception e) {
System.err.println(e.getMessage());
}
finally {
return home;
}
}
The client lookup source code is:
private SManterTesteHome getHome() {
SManterTesteHome home = null;
try {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
env.put(Context.PROVIDER_URL, alvaro.rededc.com.br:1099);
Context jndi = new InitialContext(env);
Object ref =
jndi.lookup(ejb/statelessEJB/SManterTesteBeanRef);
home = (SManterTesteHome) PortableRemoteObject.narrow(ref,
SManterTesteHome.class);
}
catch (Exception e) {
System.out.println(A + e.getMessage());
e.printStackTrace();
}
finally {
return home;
}
}
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 14:07
Message:
Logged In: YES
user_id=354157
My enviroment is the following.
1 ) a remote client in a linux machine
2) JBOSS in another machine, Session Façade -- Entity Bean
3 ) Oracle 8.i RDMS
in server/default/deploy/ i have :
- One Remote SLSB in Session01.jar
- One Local Entity in Entity02.jar
First Scenario:
- I change SLSB and make redeploy coping and overwriting
Session01.jar
it works.
Second Scenario:
- I change Entity and make redeploy coping and overwriting
Entity01.jar
I get an
[JBoss-dev] [ jboss-Bugs-643740 ] 3.0.4 - distributable tag breaks deploy
Bugs item #643740, was opened at 2002-11-25 20:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643740group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: James Manning (jmm) Assigned to: Jules Gosnell (jules_gosnell) Summary: 3.0.4 - distributable tag breaks deploy Initial Comment: This may be user error - it's kind of hard for me to follow the servlet 2.3 specification in terms of what exactly the distributable tag in a web-app means in terms of the application. However, AFAICT an empty webapp with only a distributable tag shouldn't break anything, but just such a web-app causes lots of problems. Even if the .war is to blame in this case, JBoss (IMHO) should handle it much more elegantly than current. When distributable was specified in a normal webapp I was trying to deploy, the error I got was bizarre: 2002-11-25 14:55:01,736 ERROR [org.mortbay.j2ee.session.Manager] could not create Store: org.mortbay.j2ee.session.JGStore java.lang.ClassNotFoundException: org.mortbay.j2ee.session.JGStore tons others, but that as my exception made it very hard to figure out what was going on :) Looks like the JGStore path may be because of a use of the mortbay stuff as the httpsession manager for the distributable case. 2002-11-25 15:04:15,299 INFO [org.jboss.jetty.JBossWebApplicationContext#/dummy] using Distributable HttpSession Manager: org.mortbay.j2ee.session.Manager@73a -- Comment By: Jules Gosnell (jules_gosnell) Date: 2002-11-25 22:09 Message: Logged In: YES user_id=49106 distributable support requires classes that are shipped with the 'all' configuration only. Try your webapp again with 'all'. -- Comment By: James Manning (jmm) Date: 2002-11-25 20:08 Message: Logged In: YES user_id=11485 take 2 at attaching the dummy war file -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=643740group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-643673 ] ClassCastException
Bugs item #643673, was opened at 2002-11-25 15:40
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=643673group_id=22866
Category: JBossServer
Group: None
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Alvaro Mota Goncalves (alvaromota)
Assigned to: Nobody/Anonymous (nobody)
Summary: ClassCastException
Initial Comment:
SO - Linux RedHat
JVM 1.3.1-06 Sun , 1.3.1 - Blackdown , 1.4.1 Sun
JBOSS Server 3.0.4 and 3.0.3
A session Bean packaged in a jar file (Session01.jar)
is calling
one entity bean packaged in another jar file
(Entity01.jar) .
Works great.
I have one client in Tomcat in another machine.
If I hot-deploy Session01.jar, it's work. But hot-deploy
Entity01
get
20:34:59,449 ERROR [LogInterceptor] RuntimeException:
java.lang.ClassCastException: $Proxy156
at
com.da.motion.testeAlvaro.model.statelessEJB.SManterTesteEJB.find
All(SManterTes
teEJB.java:75)
The solution is to hot-deploy Entity01 and Session01 in
sequence works fine.
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 21:17
Message:
Logged In: YES
user_id=354157
Mr Scott
When the session doesn't reference the local entity, the
entity redeploy
works. But, when the session makes at least one lookup to
Entity, the problem occurs.
Since the lookup Session--Entity doesn't keep state,
Why the link between the Session and the entity keeps the state?
Regards
Alvaro
--
Comment By: Bill Wadley (wrwadley)
Date: 2002-11-25 19:33
Message:
Logged In: YES
user_id=223475
My problem:
ClassCastExceptions on results from finders: $Proxy123
(numbers different per invocation)
- EJB's in .jar, Servlets in .war, all in .ear.
- Hot-deploy or server restart, it didn't matter.
- changed JVM's for server (1.3.1, 1.3.1_01, 1.4.1,
1.4.1_01); didn't matter
My solution:
Stop compiling with Jikes 1.15 and use the same java/javac
that I'm running the server with (Sun JDK 1.4.1).
Now all is well.
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:25
Message:
Logged In: YES
user_id=354157
Ok
I need to redeploy only the ejb-jar, without needing to
redeploy the whole application (ear).
How can i do this?
Thanks
Alvaro
--
Comment By: Scott M Stark (starksm)
Date: 2002-11-25 18:20
Message:
Logged In: YES
user_id=175228
Its not possible which is why these ejbs need to be deployed
together in an ear so that redeployment cycles the classes
consistently.
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:17
Message:
Logged In: YES
user_id=354157
Hi Mr. Scott
--Deployments with explicit references to each other must be
deployed as a unit so that the Java type system remains
consistent.
How is possible to make an unexplicit reference to Entity Local
in another ejb-jar.file(Entity01.jar).?
Session -- Entity
The source code is:
private ECepTituloHome getHome() {
ECepTituloHome home = null;
try {
//Implementar o getHome Local para o JBOSS
InitialContext jndi = new InitialContext();
// delete all organizations
home = (ECepTituloHome)
jndi.lookup(ejb/entityEJB/ECepTituloBeanRef);
}
catch (Exception e) {
System.err.println(e.getMessage());
}
finally {
return home;
}
}
The client lookup source code is:
private SManterTesteHome getHome() {
SManterTesteHome home = null;
try {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
org.jnp.interfaces.NamingContextFactory);
env.put(Context.PROVIDER_URL, alvaro.rededc.com.br:1099);
Context jndi = new InitialContext(env);
Object ref =
jndi.lookup(ejb/statelessEJB/SManterTesteBeanRef);
home = (SManterTesteHome) PortableRemoteObject.narrow(ref,
SManterTesteHome.class);
}
catch (Exception e) {
System.out.println(A + e.getMessage());
e.printStackTrace();
}
finally {
return home;
}
}
Thanks
Alvaro
--
Comment By: Alvaro Mota Goncalves (alvaromota)
Date: 2002-11-25 18:07
Message:
Re: [JBoss-dev] Re: JBoss/CMP Improvements
On Saturday, Nov 23, 2002, at 19:55 Europe/Amsterdam, Dain wrote: On Saturday, November 23, 2002, at 12:20 PM, Stefan Arentz wrote: Dain, what you need is more real use-cases. This is really basic stuff which is used in most applications today. I'll be happy to provide you with more examples of such code that is now performing less optimal in JBoss. I might sound a bit negative but in reality I am *very* positive about JBoss, I just start knowing the code better and start seeing its limitations and strengths. I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. And then create reports similar to the JUnit html output? Say a 'JBench' framework ... ? So, here is my first take at the collection problem. What is needed is something that Hibernate calls Lazy Loading or Lazy Initialization. This means that a call like getUsers() returns a smart collection that knows about the (SQL) query that backs it. I think almost *all* database access can be delayed, maybe even the initial select. Except when it is a SELECT FOR UPDATE statement i guess, I'm not sure about that. Should be fairly easy. The collection is already a smart object. Looking into this ... What kind of access do we have to a Collection? iterator() - should only call the original SELECT query and then fetch a result when Iterator.next() is called or DELETE when remove() is used. add() - should only do a optional SELECT On the PK to prevent duplicates and then INSERT remove() - should only do a SELECT on the PK to find out if the object was part of the collection and then DELETE No... add and remove should (are?) delayed until the context completes (invocation or transaction). They should be preformed as a batch, but that is another story. Is that what the spec says or just good design? All this CMR stuff is really complicated :-) I'm now looking at the code of plugins/cmp/jdbc/bridge/RelationSet.java, which seems like a good starting point for these kinds of optimizations. S. --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: JBoss/CMP Improvements
On Monday, November 25, 2002, at 08:08 PM, Stefan Arentz wrote: I'd kill to have more test cases and especially performance test cases. I would love to have tests the spit out a XML file with timings. Then we could quickly determine the results of a change. And then create reports similar to the JUnit html output? Say a 'JBench' framework ... ? Never heard of it... have you used it What kind of access do we have to a Collection? iterator() - should only call the original SELECT query and then fetch a result when Iterator.next() is called or DELETE when remove() is used. add() - should only do a optional SELECT On the PK to prevent duplicates and then INSERT remove() - should only do a SELECT on the PK to find out if the object was part of the collection and then DELETE No... add and remove should (are?) delayed until the context completes (invocation or transaction). They should be preformed as a batch, but that is another story. Is that what the spec says or just good design? All this CMR stuff is really complicated :-) I'm now looking at the code of plugins/cmp/jdbc/bridge/RelationSet.java, which seems like a good starting point for these kinds of optimizations. Spec doesn't say much about synchronization other then everything must be synchronized at the end of tx. The code is very complex, which means it is poorly written. -dain --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-641740 ] jboss-3.0.4 classloader bug
Bugs item #641740, was opened at 2002-11-21 12:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641740group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: Later Priority: 5 Submitted By: Vladimir Korenev (vkorenev) Assigned to: Scott M Stark (starksm) Summary: jboss-3.0.4 classloader bug Initial Comment: The same bug was submitted against v.3.0.2 (see #606359) and it appeared again in v.3.0.4 -- Comment By: Vladimir Korenev (vkorenev) Date: 2002-11-26 10:25 Message: Logged In: YES user_id=622967 CbUser and CurrentUser classes are not included in client-core-ejb.jar and admin-ejb.jar. They are in dao-common.jar and are referenced from manifest Class-Path attribute. As a workaround I deleted dao-common.jar from ear and placed it in server/default/lib directory. The application began working, but I don't think it is a good solution. -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 22:58 Message: Logged In: YES user_id=175228 Looking more at the server.log I see: 2002-11-21 12:20:28,271 WARN [org.jboss.deployment.MainDeployer] The manifest e ntry in file:/D:/java/jboss- 3.0.4/server/default/tmp/deploy/server/default/deplo y/cboss.ear/66.cboss.ear-contents/client-core-ejb.jar references URL file:/D:/ja va/jboss- 3.0.4/server/default/tmp/deploy/server/default/deploy/cboss.ea r/66.cbos s.ear-contents/client-common.jar which could not be opened, entry ignored Run the attached ListJar class on the cboss.ear so I can see the complete structure and manifest references. You should be able to attach the output to this bug unless your ear is huge. -- Comment By: Scott M Stark (starksm) Date: 2002-11-25 22:39 Message: Logged In: YES user_id=175228 The attached ia.log is a distillation of the server.log and ucl.log sent to me by Vladimir. It shows the CurrentUser class being loaded from the client-core-ejb.jar and the CbUser being loaded from the admin-ejb.jar. Presumably the classes are redundantly included in both of the jars. In order for this to work with the current class loading scheme the common classes that use package protected or protected access must be loaded by the same class loader. This means these utility classes must be factored out into a seperate jar that is referenced by the ejb-jars manifest Class- Path attribute. In 3.2 we will be looking at either transforming the deployment into a canonical set of classes or using a single UnifiedClassLoader for all of the jars in the top level deployment to avoid this. -- Comment By: Vladimir Korenev (vkorenev) Date: 2002-11-21 12:43 Message: Logged In: YES user_id=622967 I have got an IllegalAccessError when accessing a field with package access. IMHO it is a classloader bug. I have attached an archive with logs an 2 source files. P.S. The source files are ugly (they are not mine), but they worked fine on Orion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=641740group_id=22866 --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
