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

[Design the new POJO MicroContainer] - Re: 2.0.0.CR2?

by kabir.khan＠jboss.com

It is ready View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180327#4180327 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180327

15 years, 7 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - New artifacts from mavenised AOP build

by kabir.khan＠jboss.com

The JBoss AOP build has been mavenised (http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180040#4180040[...), and as part of this and modularising the as bootstrap ([url]http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142379) some of the artifacts have been renamed in 2.0.0.CR18. The following no longer exist -jboss-aop-as4-deployer -jboss-aop-deployer-jdk50 -jboss-aop-jboss4-jdk50 and have been replaced by -jboss-aop-asintegration-core -jboss-aop-asintegration-jmx -jboss-aop-asintegration-mc jboss-aop-jdk50 is now replaced by jboss-aop (until the mavenisation both were generated) jboss-standalone-aspect-library-jdk50 is now called jboss-aop-aspects The client is now part of the jboss-aop artifact | <dependency> | <groupId>org.jboss.aop</groupId> | <artifactId>jboss-aop</artifactId> | <version>${version.org.jboss.aop}</version> | <classifier>client</classifier> | </dependency> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180318#4180318 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180318

15 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-classload*.xsd appears to be broken

by david.lloyd＠jboss.com

Thanks, sorry. Have been a bit distracted by other things. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180307#4180307 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180307

15 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Creating (JMS) Destinations automatically for MDBs

by adrian＠jboss.org

"wolfc" wrote : Isn't this just an activation config property? No, but it could be if the rar supports the feature natively. This feature is a JBoss value add on if the rar doesn't support it. i.e. our generic jms rar can't support it because it doesn't know the api for different jms backends. Somebody could also write a version of the deployer/bean for WSMQ using whatever admin api WSMQ provides. I'm just going to provide the JBoss Messaing version. All that's required within the EJB3 layer (beyond what has already been done in the xml) is being able to annotate the message driven bean to trigger the behaviour with something like: | @org.jboss.ejb3.annotations.CreateDestination | public class MyMDB extends ... | So what needs doing to handle that, i.e. scan the mdb for the annotation and update the new metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180299#4180299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180299

15 years, 7 months

1
0
0 / 0

[Design of the JBoss EJB Container] - Re: Container artifacts should have symmetric lifecycles

by emuckenhuber

I've commited some test cases and the tests are passing for Session and MessageDriven beans. There are two tests still failing regarding to CMP (which are disabled in the normal test runs atm) org.jboss.test.ejb.lifecycle.test.CmpLifeCycleUnitTest org.jboss.test.ejb.lifecycle.test.UserTransactionLifeCycleUnitTest Those tests are failing with this exception: | Error checking if entity exists:java.sql.SQLException: S1000 General error java.lang.RuntimeException: prepared statement is no longer valid | javax.ejb.CreateException: Error checking if entity exists:java.sql.SQLException: S1000 General error java.lang.RuntimeException: prepared statement is no longer valid | at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertPKCreateCommand.beforeInsert(JDBCInsertPKCreateCommand.java:105) | at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractCreateCommand.execute(JDBCAbstractCreateCommand.java:150) | at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createEntity(JDBCStoreManager.java:587) | at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:237) | at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:223) | at org.jboss.ejb.EntityContainer.createHome(EntityContainer.java:783) | at org.jboss.invocation.Invocation.performCall(Invocation.java:386) | at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1130) | at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:106) | at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203) | at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:187) | at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:106) | at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:137) | at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76) | at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:45) | at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56) | at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125) | at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350) | at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161) | at org.jboss.ejb.plugins.SecurityInterceptor.process(SecurityInterceptor.java:224) | at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:199) | at org.jboss.ejb.plugins.security.PreSecurityInterceptor.process(PreSecurityInterceptor.java:100) | at org.jboss.ejb.plugins.security.PreSecurityInterceptor.invokeHome(PreSecurityInterceptor.java:88) | at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132) | at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107) | at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:525) | at org.jboss.ejb.Container.invoke(Container.java:1045) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) | at org.jboss.invocation.unified.server.UnifiedInvoker.invoke(UnifiedInvoker.java:232) | at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908) | at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742) | at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695) | at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:549) | at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230) | at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:206) | at org.jboss.remoting.Client.invoke(Client.java:1708) | at org.jboss.remoting.Client.invoke(Client.java:612) | at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:162) | at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:244) | at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:181) | at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) | at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:87) | at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184) | at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:101) | | As mentioned before - moving the code which starts/stops the associated persistenceManager to the EjbModule makes those tests pass. I've attached a patch showing those changes to the related JIRA issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180297#4180297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180297

15 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Creating (JMS) Destinations automatically for MDBs

by wolfc

Isn't this just an activation config property? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180294#4180294 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180294

15 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Creating (JMS) Destinations automatically for MDBs

by emuckenhuber

added a simple boolean field <create-destination> to the jboss_5_0.xsd. Is that enough or do you need more ? We can also change the name if you want ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180289#4180289 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180289

15 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: 2.0.0.CR2?

by alesj

"kabir.khan(a)jboss.com" wrote : I'll be releasing another AOP CR today, and update AS + MC to use that OK, I'll wait for your changes, and then proceed with my releases. Let me know when you're done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180270#4180270 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180270

15 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: jboss-classload*.xsd appears to be broken

by alesj

"alesj" wrote : | You should also port this to Branch_2_0: | - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/branches/Branch_... | Ported. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180265#4180265 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180265

15 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Abstractions, reuse and bad examples

by alesj

"adrian(a)jboss.org" wrote : | This is actually from the tests so its not too bad, but see below. | | This could obviously be made more useful to others with the following changes; | This deployer is only there to trigger Classpath::search w/o the real usage of facelets. It shouldn't even be considered as a true deployer test/example. Hence the only good/proper change would be to the javadocs, stating its purpose, 'warning' against reuse. ;-) "adrian(a)jboss.org" wrote : | This argument is further enhanced because if you look at what | ClassPath.search() it is wrong, | it isn't making reference to the ClassLoadingMetaData/Module | so it will ignore any filters. | | Has this code been copied somewhere else? | It's the Classpath class we're interested in. And the fix to understand vfs and nested jars / resources. This patch was ported to main facelets code. So, there is no way to know anything about CLMD. I agree with you that it's wrong, but tell this to n external frameworks that make bad url assumptions. :-) "adrian(a)jboss.org" wrote : | It's generally a bad idea to show the wrong way to do things in tests | because people copy what they find thinking that's the way it is supposed to work. :-) I'll fix the javadocs on this. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180256#4180256 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180256

15 years, 7 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 October 2008