March 2008 - jboss-dev-forums - Jboss List Archives

[Design of EJB 3.0] - Runtime CP Requires Metadata/Microcontainer SPI

by ALRubinger

Who can I nag about the following error, showing a dependency on the metadata/microcontainer SPI from the Client CP? I can't put this class in any client JAR, or on the Test CP. >From our "mdbtransactions" suite: java.lang.NoClassDefFoundError: org/jboss/metadata/spi/signature/Signature | at org.jboss.aop.AdvisorFactory.getClassAdvisor(AdvisorFactory.java:157) | at org.jboss.aop.AdvisorFactory.getClassAdvisor(AdvisorFactory.java:100) | at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:664) | at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.<clinit>(ClientConnectionFactoryDelegate.java) | at sun.misc.Unsafe.ensureClassInitialized(Native Method) | at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917) | at java.lang.reflect.Field.getFieldAccessor(Field.java:898) | at java.lang.reflect.Field.getLong(Field.java:527) | at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1586) | at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52) | at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408) | at java.security.AccessController.doPrivileged(Native Method) | at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:400) | at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297) | at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531) | at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) | at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) | at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) | at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) | at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) | at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) | at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) | at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) | at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) | at java.rmi.MarshalledObject.get(MarshalledObject.java:135) | at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:712) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629) | at javax.naming.InitialContext.lookup(InitialContext.java:351) | at org.jboss.ejb3.test.mdbtransactions.unit.MDBUnitTestCase.testSimpleQueue(MDBUnitTestCase.java:76) | at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) | at junit.extensions.TestSetup$1.protect(TestSetup.java:23) | at junit.extensions.TestSetup.run(TestSetup.java:27) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139519#4139519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139519

16 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: migrating TransactionManager and Invokers to POJO

by bstansberry＠jboss.com

The CachedConnectionManager is moved. http://jira.jboss.com/jira/browse/JBAS-5346 I read the rest of this thread and know what you're talking about with invokers now. :-) The issue there is probably that once the invokers are out of conf/jboss-service.xml, deploy/ services that have an implicit dependency on them are no longer certain to deploy after them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139509#4139509 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139509

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: New jBPM Console

by mark.proctor＠jboss.com

"fady.matar" wrote : The application will be built on top of JBoss Seam + Richfaces I've made this point before. The web technologies used for jBPM should be aligned with what we are doing with Drools. Mic has proven his stack works and has had great success. I really would recommend you don't go down the RichFaces route. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139508#4139508 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139508

16 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: New jBPM Console

by kukeltje

Yes you are aware of the need, so am I but not everybody. Maybe we (I?, you reviewing) should write an article/blog about some future directions besides the PVM. Regarding the community task, Yes we did..ehhhh do, but not up to date any more... I'll try to revive it and maybe even try to 'promote' it in other JBoss projects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139506#4139506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139506

16 years, 3 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Features of JBoss Messaaging Message Bridge present in E

by dsmiley

Kevin, Dan, setting the ACK mode on the JMS session for a particular endpoint (producer and/or consumer) is not the same thing as implementing a QoS level across the service as a whole, which is what the message bridge supports and that the ESB currently does not. http://jira.jboss.org/jira/browse/JBESB-1629 I should probably create another issue for batching support. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139500#4139500 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139500

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Determine whether an invocation is local or remote

by anil.saldhana＠jboss.com

The logic to determine remote/local call is at many places in the ejb3 codebase such as: http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/trunk/core/src/main/... Eventually this needs to be cleaned up (as Carlo said). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139491#4139491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139491

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Determine whether an invocation is local or remote

by bdecoste

That way Anil just grabs the flag from the metadata like he is doing now and you can remove ILI without any impact. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139488#4139488 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139488

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Determine whether an invocation is local or remote

by bdecoste

"Do it right, do it once" is why we are constantly late. At some point you just need to "Get it to work, ship it". My 2 cents is to just move the same flag from ILI to the proxy and leave the container alone. Then ILI just has the marshalling logic for local @Remote calls. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139487#4139487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139487

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Determine whether an invocation is local or remote

by ALRubinger

"wolfc" wrote : As an interim I don't mind having a static method isLocalVMInvocation in IsLocalInterceptor. That at least centralizes the logic. Unless this saves us significant time, I'd mind. :) We've got enough TODOs sprinkled about, we'll never have dedicated time to refactor for cleanliness, so "do it right, do it once". S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139486#4139486 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139486

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Determine whether an invocation is local or remote

by wolfc

Remove the logic from IsLocalInterceptor. This also eliminates the dependency of the proxies on IsLocalInterceptor. The proxy itself already has (almost) all the knowledge to make the decision, so it can set the flag itself. Make sure this flag is accessed via a strong typed api where we control the key name for that piece of invocation metadata. As an interim I don't mind having a static method isLocalVMInvocation in IsLocalInterceptor. That at least centralizes the logic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139484#4139484 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139484

16 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008