November 2008 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: Maven Dependencies Real Problem

by richard.opalka＠jboss.com

Thanks for opinions Scott. >From my understanding of the problem reusing the deployment macro isn't nice idea because it's magic and we don't have the control over the integration process with the AS now. I'm thinking about removing the JBossWS deployment macro call from AS build process and reuse the JBossAS build distribution logic instead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189095#4189095 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189095

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Maven Dependencies Real Problem

by scott.stark＠jboss.org

The first thing I would suggest is that the webservices integration layer not be trying to do the install of its dependencies. If it does not fully contain the dependency, the dependency has to be installed by the layer that is bringing webservices into itself. If there are dependencies that do need to be installed into the webservices deployment, the wildcard patterns need to be replaced with integration target specific properties files that can be set to the correct location of each dependency reference by the project that is integrating webservices. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189091#4189091 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189091

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Maven Dependencies Real Problem

by richard.opalka＠jboss.com

To don't it be such an easy problem many of JBossWS deployed jars are overwritten by JBossAS build distribution process. Hence we really have no control over the files that will get to the AS once we're integrated to the AS :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4189086#4189086 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4189086

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Upgrading Scout/JUDDI combo

by anil.saldhana＠jboss.com

"tcunning" wrote : https://issues.apache.org/jira/browse/SCOUT-43 | | represents the change from xmlbeans -> JAXB. I'll start looking into it but I think this involves changing the entire JAXR stub which is not a small change. It is probably 10 mins to generate the JAXB2 code from UDDIv2 schema and maybe 1-2 days work, if you put your head into it. JAXR is deprecated for EE6 for removal in the future which means we will remove scout/juddi combo (maybe for JBoss7). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188874#4188874 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188874

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Upgrading Scout/JUDDI combo

by alessio.soldano＠jboss.com

OK, thank you Tom and Anil. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188872#4188872 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188872

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Upgrading Scout/JUDDI combo

by tcunning

https://issues.apache.org/jira/browse/SCOUT-43 represents the change from xmlbeans -> JAXB. I'll start looking into it but I think this involves changing the entire JAXR stub which is not a small change. What Anil is saying sounds right for now - that AS should use the scout 0.72rc2 version, upgrade jUDDI to 2.0rc5, and we'll work on supporting JAXB so that we can move scout to the latest version. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188867#4188867 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188867

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Upgrading Scout/JUDDI combo

by anil.saldhana＠jboss.com

Check with tcunning also. He has experience in scout/juddi. Any custom implementation of the IRegistry interface of scout can be done in the JBoss JAXR project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188783#4188783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188783

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Maven Dependencies Real Problem

by richard.opalka＠jboss.com

We're reusing deployment macros because of: * easily integration * native stack integration changes gets to the AS without need for review and patching the different build process (if such would be introduced) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188750#4188750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188750

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Maven Dependencies Real Problem

by richard.opalka＠jboss.com

Relates to: JBWS-2376 Current Solution: JBossWS allows to deploy multiple SOAP stacks (Metro, CXF and Native) to multiple JBossAS servers (4.2.x and 5.0.x). To easily integrate different SOAP stacks with different AS versions we have a deploy magic implemented in each stack. This deployment magic consists of two steps: * deploy-artifacts directory creation (containing jar files and other artifacts that will be deployed) * deploy procedure using the artifacts created in previous step that integrates SOAP stack to particular AS We also reuse this integration magic in AS code base: * where step 1 is omited there because deploy-artifacts directory is AS/thirdparty directory in such case * step 2 is slightly modified to don't deploy container integrations jars (these are created in JBossAS webservices module build process) Identified problem: We have to emulate AS/thirdparty directory structure to have full control of the jars that will get deployed to AS (because of reused macro). AS/thirdparty dir is created by maven-buildmagic-thirdparty-plugin that copies all dependencies to thirdparty dir. This leads to multiple artifacts with the same name present in different directories (e.g. jaxb-api.jar). Thus our deployment macro is error prone because: * we need to watch for changes in AS/thirdparty/pom.xml and any new mappings introduced there must be applied to all three stacks deploy macros (because we have to emulate AS thirdparty directory structure) * deployment macro have to use groupId/artifactId includes instead of wildcars **/artifactId (to match particular artifact and to allow us to have the control over the jars that will get really deployed) Questions: How to do it properly? Any opinions or suggestions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188749#4188749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188749

15 years, 6 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Upgrading Scout/JUDDI combo

by alessio.soldano＠jboss.com

Richard, I asked Anil for any comments/suggestions about what to do to update to the latest Scout because of https://jira.jboss.org/jira/browse/JBPAPP-937. Anil, thanks, I'll read your posts carefully and let you know. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188671#4188671 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188671

15 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev November 2008