February 2010 - jboss-dev-forums - Jboss List Archives

[JBoss Build System Development] New message: "Re: AS build - Overriding the versions in component-matrix/pom.xml through version ranges"

by Paul Gier

JBoss development, A new message was posted in the thread "AS build - Overriding the versions in component-matrix/pom.xml through version ranges": http://community.jboss.org/message/526621#526621 Author : Paul Gier Profile : http://community.jboss.org/people/pgier Message: -------------------------------------------------------------- I would think the Maven Ant Tasks would not have a problem with version ranges. I have a feeling this has to do with the communication of the properties between the maven antrun plugin and the ant tasks. Are your command line properties being passed from Maven to the Ant build correctly? Can you try just echoing one of the properties that you are passing? I started working on some improvements to the antrun plugin that should simplify things a bit and possibly resolve this issue, but I probably won't be finished for a few more weeks. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526621#526621

14 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526590#526590 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- In order for testing this, apart from manually running jaxrpc/**/*TestCase from Native stack against a CXF/Metro stack, we need some kind of basic jaxrpc coverage in the jbossws-framework. So I copied some of the jaxrpc samples from the native testsuite to framework and removed native stack specific stuff from them (we have some kind of extensions to the standard jaxrpc interfaces which are used extensively in the native testsuite). This was the framework is still stack independent and simply uses the jaxrpc-api.jar too. >From a client configuration point of view, using the added jaxrpc features with CXF/Metro stacks simply implies adding jbossws-native-core.jar, netty.jar and jaxrpc-api.jar to the classpath. The jbossws testsuites are currently passing. Before writing this posts I also wanted to try the jaxrpc related modules of the Java EE 5 TCK. For doing that I manually retro-fitted the changes to AS 5.1.0.GA. jaxrpc and webservice modules all green, webservices12 has some other issues (JBWS-2935) preventing a clean run, but the mix jaxrpc-jaxws test there is passing. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526590#526590

14 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526583#526583 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- The deployment processing issue has been solved basically leveraging the current architecture of ws deployers in AS trunk. The webservice processing in the deployers is currently splitted in a quite fine-grained group of AS real deployers. In few words, adding a couple of flags (attributes) to both stacks' deployers for marking them as being able to deal with jaxrpc/jaxws deployements, we've been able to make them run just for the deployements they're meant for (the deployment type is detected early in the real phase). Thanks to the AS deployers' inputs/outputs and the current JBWS deployers' modularity, there's been no need to provide implementation of new deployers, a proper combination of the already existing one is fine. So, the JBossWS-CXF and JBossWS-Metro stacks now come with a -jboss-beans.xml descriptor that is added to jbossws-jaxrpc.deployer folder (see below) and that basically pulls in the chain 6 deployers normally used by JBossWS-Native. Those are marked forJaxWs=false in this case and hence used for jaxrpc only. The next step has been to properly factor our all the non-jaxrpc / non-jbws-native-specific META-INF/services/... from the jbossws-native-core.jar module. This allows that jar to always stay in $JBOSS_HOME/client and $JBOSS_HOME/common/lib regardless of what WS stack is installed. As a side effect, it also goes in the direction of moving most of the ws related jars out of the deployers/jbossws.deployer dir, which reduce the AS distro size ;-) Those service configuration are moved to a descriptor only jar (jbossws-native-services.jar) and that jar is installed by default in the new deployers/jbossws-jaxrp.deployer dir, along with the factories configuration (working the same way) we already have in jbossws-native-factories.jar. A separate classloader is specified through a jboss-classloading.xml file for that jbossws-jaxrpc.deployer, to prevent those services configuration from interfering with the other deployed jbws stack. Of course those descriptor only are included in $JBOSS_HOME/client and $JBOSS_HOME/common/lib as usual when the native stack is installed instead. The following step has been to ensure the proper classpath is setup when creating the classloader that will be used at runtime for a given endpoint deployment. I took inspiration from the Seam/Weld integration into AS 5 here. We provide a deployer that extends the org.jboss.deployers.vfs.plugins.classloader.UrlIntegrationDeployer for adding classpath entries to the DeploymentUnit during the describe phase. JAX-RPC deployments only are touched here: the jbossws-native-services.jar and jbossws-native-factories.jar are added on top of the classpath. This basically results in the Native stack implementations being configured for serving requests to jaxrpc deployements. There're actually 4 slightly different deployers of this kind, to deal with server deployments and client deployments (service-ref through servlet, ejb or standalone client). Something I've had problem with here is how to detect jaxrpc deployments at describe phase; as I mentioned before, we already do that, but in real phase. The reason for doing that at real phase is simply that jaxws endpoint can be specified through annotations hence the classes need to be loaded first. For server side the problem is easily solved setting org.jboss.wsf.spi.metadata.webservices.WebservicesMetadata.class as input to the new deployer, as that's attached to the DeploymentUnit only when a webservices.xml is included in the deployment (ie. we have a jaxrpc endpoint). Considering annotations are not part of the game for JAXRPC, the service-ref deployement (client side) currently works by checking the ServiceReferencesMetaData from EjbJarMetaData/WebMetaData/ApplicationClientMetaData for the existence of references to a jaxrpc-mapping. Suggestions are welcome here, if any. Finally, the already available StackConfig bean is injected into the new deployers, to allow them to actually run just when a non-native stack is installed, while always being provided in the AS though a -jboss-beans.xml file in jbossws-jaxrpc.deployer (since they're container specific). -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526583#526583

14 years, 4 months

1
0
0 / 0

[JBoss XML Binding Development] New message: "Re: Removing dependency of JBossXB on xerces"

by Alexey Loubyansky

JBoss development, A new message was posted in the thread "Removing dependency of JBossXB on xerces": http://community.jboss.org/message/526566#526566 Author : Alexey Loubyansky Profile : http://community.jboss.org/people/alex.loubyansky@jboss.com Message: -------------------------------------------------------------- Because we won't do better parsing of XSD and its Java represetation than Xerces. I am sure that's one of the reasons you are using it as well. And JBoss WS, BTW, is one of those projects using XSD-based bindings, at least it used to. Otherwise, there might be uses in the AS. In any way, I can binary-separate the XSD-based binding part (which should be done anyway) and try running the AS to see what fails, if anything. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526566#526566

14 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526564#526564 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- Implementing the idea highlighted above basically implies being able to install multiple webservice stacks at the same time in the AS. JBossWS-Native and JBossWS-CXF/Metro need to coexist at runtime and deal with requests depending on the kind of endpoint those are meant for. In order to deploy multiple stacks on JBoss AS, we needed to: * fx the deployment process: JAXRPC deployments need to go through JBossWS-Native deployers, while JAXWS ones need to be dealt with by JBossWS-CXF deployers. There's also some kind of intersection between the two groups, as JBossWS comes with some common features that need to stay centralized (the endpoint registry, for instance) * ensure libs from the two deployed stacks can live together: this quite important speaking of WS as a *lot* of things depends on Service API loading: apart from JBossWS itself using that system for selecting the right stack implementation for things like the RequestHandler, the WebServiceContextFactory, the ServiceRefBinderFactory, etc. (which are different on different stacks), the META-INF/service/... is looked up at runtime for selecting the SOAPFactory, MessageFactory, JAXWS spi provider, etc. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526564#526564

14 years, 4 months

1
0
0 / 0

[JBoss XML Binding Development] New message: "Removing dependency of JBossXB on xerces"

by Richard Opalka

JBoss development, A new message was posted in the thread "Removing dependency of JBossXB on xerces": http://community.jboss.org/message/526559#526559 Author : Richard Opalka Profile : http://community.jboss.org/people/richard.opalka@jboss.com Message: -------------------------------------------------------------- Cross reference: https://jira.jboss.org/jira/browse/JBXB-238 Alexey Loubyansky wrote: *XB-wise it means all XB users must be on Java annotation-based binding, XSD-based bindings won't be supported in the AS.* Dependency on xerces may cause a lot of problems to us in the future. Moreover we want to use Java API only to be portable Which projects are using JBossXB XSD based binding for configuration purposes? Why cannot we provide our own classes/interfaces for XSD based binding and we are using xerces instead? BTW, we have the same non trivial problem in JBossWS -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526559#526559

14 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Providing JAX-RPC functionalities with CXF and Metro stacks"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526556#526556 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- First of all, the prototype is available here: Native stack: http://anonsvn.jboss.org/repos/jbossws/stack/native/branches/jaxrpc-cxf/ CXF stack: http://anonsvn.jboss.org/repos/jbossws/stack/cxf/branches/jaxrpc-cxf/ Metro stack: http://anonsvn.jboss.org/repos/jbossws/stack/metro/branches/jaxrpc-cxf/ Framework: http://anonsvn.jboss.org/repos/jbossws/framework/branches/jaxrpc-cxf Common: http://anonsvn.jboss.org/repos/jbossws/common/branches/jaxrpc-cxf Spi: http://anonsvn.jboss.org/repos/jbossws/spi/branches/jaxrpc-cxf AS trunk integration: http://anonsvn.jboss.org/repos/jbossas/branches/jaxrpc-cxf/ There's currently no container integration for already released AS versions and there's probably not going to be, as that can't be done properly for released container without breaking the JBossWS abstraction. The net result is that we'd have jaxrpc support with CXF/Metro starting from AS 6. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526556#526556

14 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Providing JAX-RPC functionalities with CXF and Metro stacks"

by Alessio Soldano

JBoss development, A new message was posted in the thread "Providing JAX-RPC functionalities with CXF and Metro stacks": http://community.jboss.org/message/526552#526552 Author : Alessio Soldano Profile : http://community.jboss.org/people/alessio.soldano@jboss.com Message: -------------------------------------------------------------- As you all know, Apache CXF and Glassfish Metro do not include JAX-RPC functionalities. While this is not a major issue considering users should be moving to JAXWS for many reasons, Java EE 6 still include jaxrpc and JBoss AS needs to be certified. In the direction of further improving the JBossWS integration layer for running different WS stacks on top of our AS, we need to provide a way of supporting jaxrpc deployments when JBossWS-CXF or JBossWS-Metro is installed in the AS. During a F2F meeting at end of January, the JBossWS team discussed possible solutions for this issue and the most viable one appeared to be leveraging the JBossWS-Native stack for providing JAXRPC functionalities, while leaving JAXWS processing to the other installed stack. I've been prototyping an implementation for this in the last weeks and since it's basically maching my expectations, I'm describing it a bit here below along with the results before thinking about merging it upstream. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526552#526552

14 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Parallel invocations of JaxWS services and getPort"

by Andrew Dinn

JBoss development, A new message was posted in the thread "Parallel invocations of JaxWS services and getPort": http://community.jboss.org/message/526541#526541 Author : Andrew Dinn Profile : http://community.jboss.org/people/adinn Message: -------------------------------------------------------------- Nice one, Richard. Thanks very much for the prompt fix. regards, Andrew Dinn -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526541#526541

14 years, 4 months

1
0
0 / 0

[JBoss Web Services Development] New message: "Re: Parallel invocations of JaxWS services and getPort"

by Richard Opalka

JBoss development, A new message was posted in the thread "Parallel invocations of JaxWS services and getPort": http://community.jboss.org/message/526538#526538 Author : Richard Opalka Profile : http://community.jboss.org/people/richard.opalka@jboss.com Message: -------------------------------------------------------------- https://jira.jboss.org/jira/browse/JBWS-2934 have been fixed in JBossWS trunk and verified with all three supported stacks and covers both EJB3 and POJO usecases. Will be available in AS trunk next week. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/526538#526538

14 years, 4 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 February 2010