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

[Design of POJO Server] - Re: aop-mc-int JAXB classes are invalid in AS 5

by adrian＠jboss.org

In your case it would be something like: | <bean name="AOPMetaDataParser" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> | <constructor> | <parameter>org.jboss.....AOPMetaData</parameter> | </constructor> | <property name="suffix">-aop.xml</property> | </bean> | Or you could use Ales's deployer use case xml if it is in JBossAS? http://jira.jboss.com/jira/browse/JBDEPLOY-26 which has less junk/implementation details exposed to the user. ;-) | <jbossxb-parser xmlns="urn:jboss:deployers:2.0" | name="AOPMetaDataParser" | class="org.jboss....MetaData" | suffix="-aop.xml"/> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150674#4150674 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150674

17 years, 11 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Client cannot connect

by jesper.pedersen

Could you try with 2.0.Beta1 from http://www.jboss.org/jbossprofiler/downloads/ as we fixed a bug in this area. Please, report back with success / failure. TIA ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150670#4150670 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150670

17 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: aop-mc-int JAXB classes are invalid in AS 5

by adrian＠jboss.org

You should use the JBossXB SchemaResolverDeployer NOT the JAXB deployer. The MC parsing uses features only available in JBossXB. You shouldn't even how to write a parsing deployer, e.g. see conf/bootstrap-beans.xml for how this is done for jboss-classloading.xml | <bean name="ClassLoadingMetaDataParser" class="org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer"> | <constructor> | <parameter>org.jboss.classloading.spi.metadata.ClassLoadingMetaData</parameter> | </constructor> | <property name="name">jboss-classloading.xml</property> | <property name="buildManagedObject">true</property> | </bean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150668#4150668 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150668

17 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers in AS

by adrian＠jboss.org

"ALRubinger" wrote : We've previously talked about the deployers being an integration point with AS, and therefore should be placed within the AS source tree. | That is correct. Here's a repeat of the reasons I've stated before in both the aop, tomcat and webservices forums. NOTE: This is an idealisation of where we want to get to, rather how it has actually being done now. 1) DO IT Individual projects should not be making policy decisions. They're job is to "do one thing well". In ejb3's case, its task is to create an EJB container from an EJBMetaData object. The deployers are just a mechanism to construct metadata and then create the MC ControllerContext(s) that will actually instantiate the real objects. The parsing available in the metadata project (from ejb-jar.xml and jboss.xml) should be enough to write your tests (using the same hooks that the deployers use to create the real objects). You don't care how the EJBMetaData gets constructed, that is a policy decision of the appserver. e.g. parsing annotations, programmatically or something else. i.e. Appserver/deployers is: Some artifacts -> metadata ejb3 is: ejbmetadata -> ejb3 container The examples I give are the MC and new classloader. Neither of these projects depend upon the deployers. Instead there are deployers that integrate this code. e.g. when I test unit test the classloaders, I just parse the jboss-classloading.xml (or create it programmatically) and then use the same ClassLoading api that is used by the classloader deployers. 2) Standalone usage The individual projects should not depend upon the appserver's deployers or even the deployment api. Use case: If I want to re-use ejb3 programmatically I should just be able to instantiate the ejb3 metadata and make some call to a factory in the ejb3 project. If I have to mock out deployment api (which I have to do with the current ejb3 api because it wronglg depends upon the deployers api) or otherwise make use of appserver specific stuff there is something wrong. This also reflects the idea that the deployer and runtime are different ideas/artifacts. i.e. the ejb3 deployer(s) are just responsible for creating and manipulating metadata then using the MC to activate it via the runtime component. (See for example the split we did of the Tomcat service). There should be no runtime parameters/service injection etc. onto the deployers that should be injected onto the runtime service. NOTE: There's another reason for this seperation which is we want to be able "bootstrap" an appserver configuration "offline" in a management client to verify it works without actually starting it. i.e. it just goes through the deployers and dependency validation without actually constructing the real services. This is impossible without a proper seperation. 3) Configuration Deployer and runtime configuration is a policy decision of the appserver. If I want to swap out, augment or otherwise change how EJBMetaData gets constructed that is something that is done in the integration project i.e. the AS. The configuration files should therefore live there where they can be easily changed. To make version control easy/managable, it also makes sense for the deployer to live in the same codebase (although obviously not a requirement). But more importantly, there will be many different configurations/implementations. e.g. JBoss Embedded has a totally different mechansim (search the externally constructed "classpath") on how to find ejb deployments to what the appserver does. SUMMARY EJB3's job should be to provide a Runtime service that can be used to construct EJB3 container(s) from EJBMetaData (and others) with other service injections onto that service. The Appserver's job (or any other project) is to create that metadata (currently done using the aspectized deployers) and use that Runtime service (currently done via the MC). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150666#4150666 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150666

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Location of examples

by ataylor

I agree, the only reason i did this was to be consistent with JBoss AS. I'll move them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150665#4150665 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150665

17 years, 11 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Location of examples

by timfox

I'm thinking we should place the examples in their own top level directory /examples rather than /docs/examples. It seems to me, although they're related, examples are not "owned" by the documentation so would be more natural to have them in their own dir. wdyt? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150663#4150663 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150663

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Scope of the Proxy Component

by wolfc

We have a requirement that states: 'Given deployment X proxies must show up in global JNDI under x/y.' Clearly it is the responsibility of the proxy component to satisfy this requirement, so the test is a post condition for the component. The fact that proxy has delegated the JNDI naming function to jboss-metadata for integration with client is a low level detail. It does not absolve proxy of its responsibility. As long as the above requirement is not met (/ test fails) proxy is at fault and because of the delegation jboss-metadata might be at fault as well. So we must have tests in jboss-metadata to ascertain its correctness and the same goes for proxy. The only discussion point I see is that it's not an unit test. In this I say that we want to have incremental integration, so that faults are spotted earlier than the full integration test (which also takes a bit more time). Ergo proxy must pass this test. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150657#4150657 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150657

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: @Service and @Consumer in metadata

by alex.loubyansky＠jboss.com

Once again, are there reasons not to process spec and jboss annotations at once? The JBoss5Creator would do it anyway. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150639#4150639 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150639

17 years, 11 months

1
0
0 / 0

[Design of POJO Server] - Re: aop-mc-int JAXB classes are invalid in AS 5

by kabir.khan＠jboss.com

THe stack trace gets truncated here no matter what I try, I have attached it to http://jira.jboss.com/jira/browse/JBMICROCONT-287 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150628#4150628 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150628

17 years, 11 months

1
0
0 / 0

[Design of POJO Server] - aop-mc-int JAXB classes are invalid in AS 5

by kabir.khan＠jboss.com

I am attempting to create a JAXBDeployer for -aop.xml files using the AOPDeployment and related classes I wrote in the MC/aop-mc-int project. My deployer looks like | package org.jboss.aop.asintegration.jboss5.temp; | | import org.jboss.aop.microcontainer.beans.metadata.AOPDeployment; | import org.jboss.deployers.spi.deployer.DeploymentStages; | import org.jboss.deployers.vfs.spi.deployer.JAXBDeployer; | | /** | * Parses the AOP information contained in the -aop.xml file | * | * @author <a href="kabir.khan(a)jboss.com">Kabir Khan</a> | * @version $Revision: 1.1 $ | */ | public class AspectJAXBDeployer extends JAXBDeployer<AOPDeployment> | { | | public AspectJAXBDeployer() | { | super(AOPDeployment.class); | setSuffix("-aop.xml"); | setStage(DeploymentStages.DESCRIBE); | } | } | Now when I add this deployer to bootstrap-beans.xml in AS 5 I get the huge error message shown below. Before trying to resolve all the things it mentions, I am curious why this works in the mc testsuite and not in the JAXBDeployer? anonymous wrote : | 09:38:20,138 ERROR [AbstractKernelController] Error installing to Create: name=AspectJAXBDeployer state=Configured | com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 56 counts of IllegalAnnotationExceptions | org.jboss.aop.microcontainer.beans.metadata.AOPDeployment#beanFactories has mutually exclusive annotations @javax.xml.bind.annotation.XmlElements and @javax.xml.bind.annotation.XmlAnyElement | this problem is related to the following location: | at @javax.xml.bind.annotation.XmlElements(value=[(a)javax.xml.bind.annotation.XmlElement(namespace=##default, defaultValue= View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4150625#4150625 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4150625

17 years, 11 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 May 2008