September 2007 - jboss-dev-forums

[Design of POJO Server] - Re: Unifying metadata

by wolfc

The problem for EJB 3 is meta data translation and meta data repository. For example defining a stateful bean with a remove method: <enterprise-beans> | <session> | <description>A stateful bean</description> | <ejb-name>StatefulBean</ejb-name> | <local>org.jboss.ejb3.test.stateful.Stateful</local> | <ejb-class>org.jboss.ejb3.test.stateful.StatefulBean</ejb-class> | <remove-method> | <bean-method> | <method-name>removeBean</method-name> | </bean-method> | </remove-method> | </session> | </enterprise-beans> is the same as: package org.jboss.ejb3.test.stateful; | | @Stateful(description="A stateful bean") | @Local(Stateful.class) | public class StatefulBean implements Stateful | { | ... | @Remove | public void remove() { } | } or: package org.jboss.ejb3.test.stateful; | | @Stateful(description="A stateful bean") | public class StatefulBean implements Stateful | { | ... | public void remove() { } | } | | @Local | public interface Stateful | { | @Remove | void remove(); | } You can see that a Description annotation never even enters the picture. Secondly we use the class container as meta data repository, so we can do this: <bind pointcut="execution(public * *->@javax.ejb.Remove(..))"> | <interceptor-ref name="org.jboss.ejb3.stateful.StatefulRemoveFactory"/> | </bind> Again the public API annotations are leading. Another problem: we can't use the API annotations to express all meta data, because they're not conclusive. Not everything can be expressed in annotations. So I would rather have the unified meta data as the base, which is conclusive and un-ambiguous and some translator on top. So if you ask for getAnnotation(@Remove) it will look it up in the right meta data repository in the right meta data. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087888#4087888 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087888

18 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Status of EJB3-785 and EJB3-786

by wolfc

Both are failing in trunk. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087875#4087875 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087875

18 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotating KernelDeployment with management info

by alesj

The overrides only come after the bean's classloader is resolved - which is in PreInstall state. See KernelScopeInfo.addMetaData, which gets invoked with | KernelMetaDataRepository repository = controller.getKernel().getMetaDataRepository(); | repository.addMetaData(context); | in PreInstallAction class. That's where annotations from xml get into metadata repo. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087868#4087868 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087868

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Exception propagation for one way messaqges

by adinn

Oh man, I should not have trusted the preview The specific case I have in mind is one where an @OneWay web method interface is generated from WSDL. The corresponding operation is specified with a single input message and no output or fault messages and is bound to a port and service using a SOAP binding. Obviously, I would be inetrested to hear opinions regarding what should happen in other related cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087845#4087845 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087845

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Exception propagation for one way messaqges

by adinn

Apologies, the second paragraph should read The specific case I have in mind is one where an @OneWay web method interface is generated from WSDL. The corresponding operation is specified with a single message and no or > messages and is bound to a port and service using a SOAP binding. Obviously, I would be inetrested to hear opinions regarding what should happen in other related cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087842#4087842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087842

18 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Exception propagation for one way messaqges

by adinn

Can anyone clarify the intention of the WS 2.0 specification regarding the propagation of exceptions from server to client for messages whicih are tagged @OneWay. It is not clear to me whether an exeception generated by the web method implementation is supposed to be caught and handled by generating a corresponding exception for the client call. The specific case I have in mind is one where an @OneWay web method interface is generated from WSDL. The corresponding operation is specified with a single message and no or messages and is bound ot a port and service using a SOAP binding. Obviously, I would be inetrested to hear opinions regarding what should happen in other related cases. I have tested the case mentioned above on JBossWS 2.0.1GA (with AS5.0.0.Beta3), generating either a SOAPFaultException or a WebServiceException. The test invokes the one way method via a client proxy obtained from the generated soap service class. In both cases a client exception was not thrown. However, I'll note that neither is this definitive of what the spec intends nor does it necessarily indicate that this is the behaviour desired by the implementation. The latter point is explained below. An HTTP error was returned to the invoking client and a SOAP fault containing the generated exception details was serialised into the response stream and dispatched back to the client. Affter I patched a bug in the remoting code the soap envelope was read from the http connection response stream as a String. This format was employed because the unmarshaller installed on the connection before invocation was an HTTP unmarshaller, not a SOAP unmarshaller. This appears to explain why the fault was not thrown in the client context. Given all the work involved in returning the SOAP fault I wonder if this was really what was meant to happen? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087841#4087841 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087841

18 years, 6 months

1
0
0 / 0

[Design of JBoss Tools (dev)] - Re: Profile server

by max.andersen＠jboss.com

report in jira please. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087837#4087837 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087837

18 years, 6 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Issues with connection creating using JMSContainerInvoke

by ramazanyich

Is there any progress on this issue ? We are really need clustered factories for MDBs View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087812#4087812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087812

18 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotating KernelDeployment with management info

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : I checked in just enough changes to allow the default AbstractManagedObjectFactory to build a ManagedObject set for a KernelDeployment. | | In reality the BeanDeployer should be implementing the ManagedObjectCreator.build method as the deployer has the metadata and understands things like annotation overrides. Its not clear to me that the BeanInfo beanInfo = configuration.getBeanInfo(clazz) call used by the AbstractManagedObjectFactory is going to have the beans.xml annotations/overrides applied. Would it? | No. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087784#4087784 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087784

18 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Next step in ServiceController Lifecycle

by kabir.khan＠jboss.com

More or less the same | <aop:lifecycle-configure xmlns:aop="urn:jboss:aop-beans:1.0" | name="JMXAdvice" | class="org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback" | classes="@org.jboss.aop.microcontainer.aspects.jmx.JMX" | manager-bean="AspectManager" | manager-property="aspectManager"> | <property name="serviceController"><inject bean="JMXKernel" property="serviceController"/></property> | </aop:lifecycle-configure> | | Substitute lifecycle-configure for *lifecycle-create *lifecycle-describe *lifecycle-install *lifecycle-instantiate *lifecycle-preinstall *lifecycle-start View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4087783#4087783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4087783

18 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2007