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

[Design of Messaging on JBoss (Messaging/JBoss)] - Removed strictTCK

by timfox

I have removed the strictTCK flag since it is no longer necessary View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154069#4154069 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154069

17 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Handling Non Container References in java:comp/env

by anil.saldhana＠jboss.com

The web.xml can define |  | <env-entry> | <description>Integer0</description> | <env-entry-name>Ints/i0</env-entry-name> | <env-entry-type>java.lang.Integer</env-entry-type> | <env-entry-value>0</env-entry-value> | </env-entry> | <env-entry> | <description>Integer1</description> | <env-entry-name>Ints/i1</env-entry-name> | <env-entry-type>java.lang.Integer</env-entry-type> | <env-entry-value>1</env-entry-value> | </env-entry> | <env-entry> | <description>Float0</description> | <env-entry-name>Floats/f0</env-entry-name> | <env-entry-type>java.lang.Float</env-entry-type> | <env-entry-value>0.0</env-entry-value> | </env-entry> | This is a ToDo in the MappedReferenceMetaDataResolverDeployer. This was previously handled in JBoss 4.2 with the bindEnvEntry method http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/server/src/mai... I am going to make an attempt at solving this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154064#4154064 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154064

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Feature: MC Equivalent of @Service

by ALRubinger

And to go full-circle (though not related to the implementation of this topic), we should also be providing a mechanism to inject MC Beans into EJBs. This would enable services to remain mere POJOs, wrappable in EJB. @Stateless | public class MyBean{ | @InjectMcBeanAnnotation("McBeanName") | private McBean bean; | } S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154063#4154063 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154063

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Feature: MC Equivalent of @Service

by ALRubinger

Thanks for pointing out EJBTHREE-655. "wolfc" wrote : What is easily possible is a MC view on an EJB. This should not require any new container and should be applicable to both SLSB and Service/Singleton. This was actually my last thought before bed last night. :) "wolfc" wrote : As for the actual life cycle callbacks, these are @PostConstruct and @PreDestroy. | Although create, start, stop and destroy will probably also be called by MC (in about the same way we now call the @Management interface). @PostConstruct and @PreDestroy are different; that's per bean instance. I'm looking to get Annotations for "create/start/stop/destroy" at the Container level, much like MC has for POJOs. We already have these within the container itself; I want to also provide a hook for a bean provider to specify methods as callbacks to be invoked along the Container lifecycle, not the instance lifecycle. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154057#4154057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154057

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

Another option might be to use scoped kernels, but I don't think they are being used yet? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154040#4154040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154040

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

Another problem when attempting to run the scoped aop tests is that both deployments try to install an interceptor with the same name. | Caused by: java.lang.IllegalStateException: Factory$org.jboss.test.aop.scoped.ScopedInterceptor is already installed. | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:577) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:443) | at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:88) | Once I have got the domains set up this should be fine at the aop level, but I need to resolve this somehow on the MC level. The following "nice" xml | <aop xmlns="urn:jboss:aop-beans:1.0"> | <interceptor class="org.jboss.test.aop.scoped.ScopedInterceptor" scope="PER_INSTANCE"/> | <bind pointcut="all(org.jboss.test.aop.scoped.POJO)"> | <interceptor-ref name="org.jboss.test.aop.scoped.ScopedInterceptor"/> | </bind> | will resolve to something along the lines of |  | <beanfactory name="Factory$org.jboss.test.aop.scoped.ScopedInterceptor" class="org.jboss.test.aop.scoped.ScopedInterceptor"/> | |  | <bean name="org.jboss.test.aop.scoped.ScopedInterceptor" class="org.jboss.aop.microcontainer.beans.Aspect"> | <property name="advice"><inject bean="Factory$org.jboss.test.aop.scoped.ScopedInterceptor"/></property> | <property name="manager"><inject bean="AspectManager" property="manager"/></property> | </bean> | |  | <bean name="TestAspectBinding" class="org.jboss.aop.microcontainer.beans.AspectBinding"> | <property name="pointcut">execution(* org.jboss.test.microcontainer.beans.POJO->*(..))</property> | <property name="manager"><inject bean="AspectManager" property="manager"/></property> | <property name="advices"> | <list> | <inject bean="TestAspectBinding$1"/> | </list> | </property> | </bean> | | <bean name="TestAspectBinding$1" class="org.jboss.aop.microcontainer.beans.InterceptorEntry"> | <property name="manager"><inject bean="AspectManager" property="manager"/></property> |  | <property name="aspect"><inject bean="org.jboss.test.aop.scoped.ScopedInterceptor"/></property> | <property name="binding"><inject bean="TestAspectBinding" state="Instantiated"/></property> | </bean> | I could give each deployment it's own prefix or something for the names used, but that will cause problems if the interceptor is declared in one -aop.xml and used in another. One option might be to maintain my own registry in the AOP BeanMetaDataFactory layer, but I don't see how this will work for scoped deployments, since the BMDF is ignorant of scoping at parsing time? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154037#4154037 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154037

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: Integrating aop-mc-int bean metadata with AS5

by kabir.khan＠jboss.com

"kabir.khan(a)jboss.com" wrote : Disabling the AnnotationMetaDataDeployer, I am able to run some basic tests I have created http://jira.jboss.com/jira/browse/JBAS-5558 assigned to Scott for now View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154018#4154018 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154018

17 years, 7 months

1
0
0 / 0

[Design of JBoss ESB] - How to disable redelivery for sync message call?

by lihui_pang

Hi, Can anyone tell me how to disable redelivering message for sync call ? I want the client to get the response or error instead of redelivering message again. My client code: deliveryAdapter.deliverSync(requestMessage, 50000); I find if the message is failed to be delivered at the first time, it will be redelivered to DLQ. The later will deliever message again. Thanks for your help. Lihui View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4154002#4154002 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4154002

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Serializable DeploymentSummary

by emuckenhuber

by chance i saw this failure in the deployers test in the AS testsuite, when getting the deploymentUnit in the test - for example in o.j.t.deployers.ejb.test.EJBDeploymentUnitTestCase.testEJBDeployment | java.io.NotSerializableException: org.jboss.metadata.ejb.jboss.jndipolicy.spi.DeploymentSummary | at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) | at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) | at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) | at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) | at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) | at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) | at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1380) | at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917) | at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339) | at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) | at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) | at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) | at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) | at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) | at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) | at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) | at org.jboss.deployers.plugins.attachments.AttachmentsImpl.writeExternal(AttachmentsImpl.java:145) | Does the DeploymentSummary need to be Serializable or can we just define it as transient ? Emanuel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153997#4153997 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153997

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: profile service, farming

by bstansberry＠jboss.com

anonymous wrote : So I think we need to look at a FarmServiceUnitTestCase that uses the profile service DeploymentManager to validate the various types of things that can happen with a two node deployment say, and figure out what will/won't work for the initial release. I've added infrastructure for clustered profile service tests (i.e. start two AS instances configured for clustering and the full profile service, execute set of tests). ./build.sh tests-clustered-profileservice Currently this target isn't part of the overall testsuite run, as right now there's no real point. Only test right now is o.j.t.cluster.defaultcfg.profileservice.test.ClusteredDeployUnitTestCase. Right now this is 98% just a copy of your DeployUnitTestCase that uses DeploymentPhase.APPLICATION_CLUSTERED with a couple extra assertions thrown in (i.e.. any DeploymentProgress.getDeploymentTargets() returns a list with 2 targets.) As we go along I'll fill this out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153992#4153992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153992

17 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums May 2008