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

[Design of JBossXB] - Re: JBossSessionBeanMetaData / using embedded Java bean prop

by alex.loubyansky＠jboss.com

Have a look at the DescriptionGroupMetaData. If I understood you right, what you need is @JBossXmlModelGroup annotation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095641#4095641 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095641

18 years, 5 months

1
0
0 / 0

[Design of JBossXB] - JBossSessionBeanMetaData / using embedded Java bean properti

by wolfc

I'm trying to create the JBossSessionBeanMetaData. It basicly is a SessionBeanMetaData combined with JBossSessionBeanMetaData, so I've got it extending JBossSessionBeanMetaData. Now how can I reuse SessionBeanMetaData so that the binding is complete? In other words, how can I have use the properties of an embedded Java bean as xml element bindings on the master Java bean? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095639#4095639 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095639

18 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: @XmlElement(defaultValue=

by alex.loubyansky＠jboss.com

But the element must still be present in the XML. "jaxb20 spec" wrote : Element defaulting | The default value is derived from the element declaration?s {value | constraint} property?s value. Unlike attribute defaulting, an element only | defaults when there is an empty element tag in an xml document. The | element?s default value is captured by mapping annotation | @XmlElement.defaultValue(). The unmarshaller sets the | property to this default value when it encounters an empty element tag. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095590#4095590 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095590

18 years, 5 months

1
0
0 / 0

[Design of JBossXB] - Re: Too much resolution?

by alex.loubyansky＠jboss.com

Maybe we can have a switch whether to call resolveSystemIDasURL(). I.e. resolve entities only locally: registered and in the classpath. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095583#4095583 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095583

18 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Instance annotations from Object Models

by adrian＠jboss.org

FYI: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095575#4095575 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095577#4095577 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095577

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Instance annotations from Object Models

by adrian＠jboss.org

I've written two simple examples of how to load instance annotations from Object Models (xml). PREPOPULATE The first one works the same way as the MC and as I understand it the EJB3 container https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/deploye... It explicitly adds the annotations to the mutable metadata context of the component instance https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/deploye... METADATA LOADER The second takes a more lazy approach [url]https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/dep...] instead of populating the context up front, it installs a MetaDataLoader [url]https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/dep...] that will retrieve the annotations from the Object Model on the fly https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/deploye... THE TESTS: The tests are fairly trivial, they both do the same thing. There is one test that uses an annotated class and another that uses an unannotated class but supplies the annotation via the instance metadata. An AOP proxy is created for each to show AOP can read both the class metadata and the instance metadata when applying pointcuts and at runtime. https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/deploye... The tests then check that an aspect based on the annotation is being used with the aspect retrieving the annotation in question. METADATA POPULATION DEPLOYERS The two alternate deployers that populate the instance metadata both do two steps. 1) They add an AnnotatedElementMetaDataLoader for the class of the deployment component, this is the class scope that is also added to the deployment unit's scopeKey so it appears in the full contextual metadata retrieved from DeploymentUnit.getMetaData() and passed to AOP. 2) They maintain the instance metadata using one of the two mechanisms described above. FOR THE REAL THING On the MetaDataLoader approach, I've cheated in the test by making the object model just have a list of class annotations. In practice, it would need to be more complex in that it will have to navigate the object model in a less trivial way. It would also need to implement Method and Field annotation retrieval, an example of how to do this can be found in the "Class" MetaDataLoader: https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/contain... Obviously, the MetaDataLoader can do what it likes to create the annotations (even if the underlying model is not annotations). See the AnnotationCreator https://svn.jboss.org/repos/jbossas/projects/microcontainer/trunk/contain... e.g. | MyAnnotation annotation = (MyAnnotation) AnnotationCreator.createAnnotation("@com.acme.MyAnnocation(value=\"" + fromXML() + "\")", unit.getClassLoader()); | A BUG Finally, I found a bug in the AbstractDeploymentContext where the getMutableMetaData() wasn't finding the metadata correctly. The MemoryMetaDataLoader was wrapped in a MetaDataContext so it didn't recognise it. I've fixed this problem, but it will need an update of the snapshot if you want to use the prepopulate annotations approach. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095575#4095575 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095575

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: [Productivity] Level 2 - Development

by richard.opalka＠jboss.com

"alessio.soldano(a)jboss.com" wrote : | At the same time, we might focus on tools supporting the development phase of webservices. I'm thinking about a way to easily generate tests (JUnit or TestNG) for the users' services in a given project as far as an Eclipse project configuration with an Ant build file to run them all. | It would be nice if our eclipse configuration would work this way: 1) User will define env. variables such as ANT_HOME, JAVA_HOME, JBOSS_HOME, etc. in its shell environment 2) User will import preconfigured eclipse project that will use these env. variables for classpath, sourcepath and other definitions View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095565#4095565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095565

18 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: [Productivity] Level 1 - Start from scratch

by richard.opalka＠jboss.com

"alessio.soldano(a)jboss.com" wrote : | Regarding the IDE setup, we might provide a basic Eclipse project configuration that users might use as a starting point for each of their ws-enabled projects. I agree. When we write the JBossWS test we're always doing the same things. If we would provide eclipse project configuration it would help us too. And as bonus, when we'll use these preconfigured configurations we'll test them too. This is a good idea. "alessio.soldano(a)jboss.com" wrote : | Otherwise we could create a simple presentation / movie showing users how to setup the environment the right way. This is the NICE feature for us, but not SHOULD or MUST. "alessio.soldano(a)jboss.com" wrote : We might also ask the Red Hat Developer Studio team to support the latest jbossws features (at least the wsprovide and wsconsume tools). RHDS is based on JBoss IDE so our eclipse configurations should work there too ;-) "alessio.soldano(a)jboss.com" wrote : | Then we should link the documentation and the samples more tightly. This means that most of the samples and tests will be enriched with a brief description (a scenario) in the documentation. Then wherever the documentation covers a particular feature backed up by a sample or test case, there will be a link to the test-suite. Finally we could make the test-suite run easier providing an Eclipse project configuration with the tests only and a simplified Ant script to run each of them. No comment on this. I fully agree. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095563#4095563 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095563

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: So what does unification mean for the ejb containers

by scott.stark＠jboss.org

"wolfc" wrote : What is considered to be valid state when there is no ejb-jar.xml? | My assumption is that the annotation scanning deployer should have build up an EjbJarMetaData, so in real life we don't encounter this problem? | The jboss.xml parsing deployer just creates an empty EjbJarMetaData if there is not one to use as the JBossMetaData overriden value, so that is what the test should do as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095506#4095506 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095506

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: So what does unification mean for the ejb containers

by scott.stark＠jboss.org

"wolfc" wrote : Why isn't EnterpriseBeanMetaData.getTransactionType()'s return type javax.ejb.TransactionManagementType? Just because the jboss-metadata project does not import this type by depending on the jboss-javaee.jar. It should as there will be other annotations we need. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4095505#4095505 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4095505

18 years, 5 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 October 2007