[jbossws-dev] Multi Component Fixes
Alessio Soldano
asoldano at redhat.com
Wed Jul 16 12:12:15 EDT 2008
It gets pulled in by jaxws-api which is pulled in by jaxws-rt, both in
Stack Metro Runtime Server and Stack Metro Runtime Client
[INFO]
------------------------------------------------------------------------
[INFO] Building JBoss Web Services - Stack Metro Runtime Server
[INFO] task-segment: [dependency:tree]
[INFO]
------------------------------------------------------------------------
...
[INFO] +- com.sun.xml.ws:jaxws-rt:jar:2.1.3:compile
[INFO] | +- javax.xml.ws:jaxws-api:jar:2.1:compile
[INFO] | | +- (javax.xml.bind:jaxb-api:jar:2.1:compile - omitted for
duplicate)
[INFO] | | +- (javax.xml.soap:saaj-api:jar:1.3:compile - omitted for
duplicate)
[INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile
[INFO] | | \- javax.jws:jsr181-api:jar:1.0-MR1:compile
Alessio
Darran Lofthouse ha scritto:
> Maybe a pom.xml in my repository is not updated as it should be.
>
> Would it be possible for you to run 'mvn dependency:tree -Dverbose' so
> I can see where it gets pulled in in your set-up.
>
> Regards,
> Darran Lofthouse.
>
>
> Alessio Soldano wrote:
>> Hi Darran,
>> I tried a mvn clean; mvn package on Metro stack and got no errors.
>> Anyway, I have the javax.jws.Handler chain in
>> /home/alessio/.m2/repository/javax/jws/jsr181-api/1.0-MR1/jsr181-api-1.0-MR1.jar
>>
>> Cheers
>> Alessio
>>
>> Darran Lofthouse ha scritto:
>>> Trying to build Metro to run my tests and I am getting this failure: -
>>>
>>> [exec] [INFO] Compilation failure
>>>
>>> [exec]
>>> /home/darranl/src/jbossws/jbossws-metro/modules/client/src/main/java/org/jboss/wsf/stack/metro/client/ServiceRefBinderJAXWS.java:[33,17]
>>> package javax.jws does not exist
>>>
>>> [exec]
>>> /home/darranl/src/jbossws/jbossws-metro/modules/client/src/main/java/org/jboss/wsf/stack/metro/client/ServiceRefBinderJAXWS.java:[155,9]
>>> cannot find symbol
>>> [exec] symbol : class HandlerChain
>>> [exec] location: class
>>> org.jboss.wsf.stack.metro.client.ServiceRefBinderJAXWS
>>>
>>> [exec]
>>> /home/darranl/src/jbossws/jbossws-metro/modules/client/src/main/java/org/jboss/wsf/stack/metro/client/ServiceRefBinderJAXWS.java:[155,63]
>>> cannot find symbol
>>> [exec] symbol : class HandlerChain
>>> [exec] location: class
>>> org.jboss.wsf.stack.metro.client.ServiceRefBinderJAXWS
>>>
>>>
>>> Any ideas where javax.jws.HandlerChain should be comming from?
>>> Scanning my local mvn repo I can't see this in any of the declared
>>> dependencies.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>>
>>> Darran Lofthouse wrote:
>>>> Excelent, that makes things easier so the SNAPSHOT versions will
>>>> just be within the JBossWS codebase.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>> Richard Opalka wrote:
>>>>> There's no need to update AS trunk code. We will do it for you on
>>>>> next JBossWS release ;)
>>>>>
>>>>> Richard
>>>>>
>>>>> Darran Lofthouse wrote:
>>>>>> Ok I am going to go ahead and do this in two stages - if you
>>>>>> could just confirm if this will be compatible with the Hudson
>>>>>> testing set up.
>>>>>>
>>>>>> First I will commit to the 4 JBossWS projects: -
>>>>>> SPI
>>>>>> Framework
>>>>>> Container
>>>>>> Native
>>>>>> Metro
>>>>>> CXF
>>>>>>
>>>>>> The first three will upload a snapshot release that the three
>>>>>> stacks will use.
>>>>>>
>>>>>> If we get no regressions in Hudson caused by this we can then
>>>>>> copy the container code to AS5 trunk and update to the Framework
>>>>>> and SPI snapshots.
>>>>>>
>>>>>> Do you see any reason to also use a Native snapshot in AS5 trunk?
>>>>>>
>>>>>> Regards,
>>>>>> Darran Lofthouse.
>>>>>>
>>>>>> Richard Opalka wrote:
>>>>>>> OK, you can commit now ;)
>>>>>>>
>>>>>>> Richard
>>>>>>>
>>>>>>> Darran Lofthouse wrote:
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> Any information on when I can start committing the changes? My
>>>>>>>> development environment is deadlocked now as I have changes in
>>>>>>>> about 5 different projects that all need to go in at once.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Darran Lofthouse.
>>>>>>>>
>>>>>>>>
>>>>>>>> Darran Lofthouse wrote:
>>>>>>>>> Do you know when you will be tagging it?
>>>>>>>>>
>>>>>>>>> Once I commit my changes it will enable a test that will start
>>>>>>>>> to fail without all the changes in place.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Darran Lofthouse.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Richard Opalka wrote:
>>>>>>>>>> Darran,
>>>>>>>>>>
>>>>>>>>>> create a separate user branch from container integration
>>>>>>>>>> trunk and do your job there.
>>>>>>>>>> Later we will tell you where to merge it. We need to tag the
>>>>>>>>>> trunk first.
>>>>>>>>>>
>>>>>>>>>> Richard
>>>>>>>>>>
>>>>>>>>>> Darran Lofthouse wrote:
>>>>>>>>>>> Thanks Richard, I see where you mean.
>>>>>>>>>>>
>>>>>>>>>>> I will send an e-mail when I start committing the changes -
>>>>>>>>>>> it should take no more than 30 minutes but it might break a
>>>>>>>>>>> few things in that time due to some bi-directional
>>>>>>>>>>> dependencies.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Richard Opalka wrote:
>>>>>>>>>>>> See inlined comments below:
>>>>>>>>>>>>
>>>>>>>>>>>> Darran Lofthouse wrote:
>>>>>>>>>>>>> Right I have the code ready now but I am unsure how to
>>>>>>>>>>>>> handle what appears to be a circular dependency in the build.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Within SPI I have modified one interface to get and set
>>>>>>>>>>>>> the list of virtual hosts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Within Framework I have implemented the additional methods
>>>>>>>>>>>>> on the DefaultService implementation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Within Framework I have added a new DeploymentAspect
>>>>>>>>>>>>> similar to the ContextRootDeploymentAspect to check for
>>>>>>>>>>>>> virtualHosts and set accordingly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Within AS I have added the new DeploymentAspect for EJB3
>>>>>>>>>>>>> deployments. I have also taken the virtual hosts list
>>>>>>>>>>>>> from the Service implementation and pass them to JBoss Web
>>>>>>>>>>>>> for deployment.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And then finally within the framework testsuite I have
>>>>>>>>>>>>> re-enabled the test to test that the deployment is
>>>>>>>>>>>>> deployed to a virtual host.
>>>>>>>>>>>> Sounds good to me
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem I now have is that jbossws-native (and I think
>>>>>>>>>>>>> the other two) pull in the container integration code and
>>>>>>>>>>>>> deploy it to JBoss. Now that we have the SPI seperated
>>>>>>>>>>>>> out should JBossWS really be pulling in AS code like this?
>>>>>>>>>>>>> The name within the pom.xml in the webservices project of
>>>>>>>>>>>>> AS does not match the name as it is pulled back into WS
>>>>>>>>>>>> We will discuss this problem on next JBossWS meeting that
>>>>>>>>>>>> is scheduled to 22-nd and 23-rd of July.
>>>>>>>>>>>> Till now we used to modify both AS webservices module and
>>>>>>>>>>>> AS integration module.
>>>>>>>>>>>> Both source code bases are almost the same.
>>>>>>>>>>>>
>>>>>>>>>>>>> how are the snapshot versions of this code released?
>>>>>>>>>>>> Modify AS integration code base (e.g.
>>>>>>>>>>>> jbossws/container/jboss50/trunk)
>>>>>>>>>>>> Do `mvn deploy` after modification.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Alessio Soldano wrote:
>>>>>>>>>>>>>> OK, thanks Darran.
>>>>>>>>>>>>>> Btw of course I should have written JBossWS 3.0.3, not
>>>>>>>>>>>>>> 3.0.2 (which is already out).
>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>> Alessio
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Darran Lofthouse ha scritto:
>>>>>>>>>>>>>>> Ok that works for me - so from a JBoss AS perspective we
>>>>>>>>>>>>>>> will consider re-enabling support for virtual hosts just
>>>>>>>>>>>>>>> a JBoss 5 fix.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When I re-enable the test I will add it to the excludes
>>>>>>>>>>>>>>> list of the JBoss 4.x versions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Alessio Soldano wrote:
>>>>>>>>>>>>>>>> OK, this said, I would do as you wrote in the first
>>>>>>>>>>>>>>>> email, i.e. change the AS to use snapshot versions of
>>>>>>>>>>>>>>>> jbossws. Imho this is fine for the AS5 trunk, as we can
>>>>>>>>>>>>>>>> be quite comfortable we'll be able to release jbossws
>>>>>>>>>>>>>>>> 3.0.2 before 5.0.0.CR2. Not sure about the Branch_4_2
>>>>>>>>>>>>>>>> instead (honestly I think it will ship with
>>>>>>>>>>>>>>>> jbossws-native 2.0.4 forever).
>>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>>> Alessio
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Darran Lofthouse ha scritto:
>>>>>>>>>>>>>>>>> Backwards compatibility shouldn't be an issue as this
>>>>>>>>>>>>>>>>> would be new methods on the SPI to make the list of
>>>>>>>>>>>>>>>>> virtual hosts available.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Unfortunately this does touch the container
>>>>>>>>>>>>>>>>> integration code as this needs to pass the list of
>>>>>>>>>>>>>>>>> virtual hosts to JBoss Web (as appropriate for each
>>>>>>>>>>>>>>>>> branch).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I could add the container integration code and comment
>>>>>>>>>>>>>>>>> it out until the next WS update happens.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Finally once the container integration code is updated
>>>>>>>>>>>>>>>>> we will then need to go round another pass to
>>>>>>>>>>>>>>>>> re-enable the test in framework!!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Alessio Soldano wrote:
>>>>>>>>>>>>>>>>>> Hi Darran,
>>>>>>>>>>>>>>>>>> if I understand you, you need to do changes in
>>>>>>>>>>>>>>>>>> jbossws-spi and jbossws-framework, don't you?
>>>>>>>>>>>>>>>>>> Generally speaking, you perform the changes (please
>>>>>>>>>>>>>>>>>> be careful about backward compatibility when touching
>>>>>>>>>>>>>>>>>> the SPI) and update the component versions in the
>>>>>>>>>>>>>>>>>> jbossws pom.xml files, so that the new versions of
>>>>>>>>>>>>>>>>>> spi and framework are picked up. You need to create
>>>>>>>>>>>>>>>>>> snapshots of jbossws-spi and jbossws-framework of
>>>>>>>>>>>>>>>>>> course, using mvn deploy.
>>>>>>>>>>>>>>>>>> Once the next jbossws release is ready, we'll take
>>>>>>>>>>>>>>>>>> care of installing it into the current jboss AS
>>>>>>>>>>>>>>>>>> (4.2.x and 5.0.x), including the new spi and framework.
>>>>>>>>>>>>>>>>>> This assumes you don't need to change the container
>>>>>>>>>>>>>>>>>> integration code...
>>>>>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>>>>>> Alessio
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Darran Lofthouse ha scritto:
>>>>>>>>>>>>>>>>>>> I am currently looking for some advice for the
>>>>>>>>>>>>>>>>>>> following issue: -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://jira.jboss.com/jira/browse/JBWS-981
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> As the deployment code has moved back to the AS
>>>>>>>>>>>>>>>>>>> codebase it is dependent on the APIs made available
>>>>>>>>>>>>>>>>>>> by JBossWS.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This fix is first going to require an addition to
>>>>>>>>>>>>>>>>>>> the SPI to expose the virtual hosts information.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I will then need to update the framework code to
>>>>>>>>>>>>>>>>>>> populate this value.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And then the jbossas trunk and Branch_4_2 will need
>>>>>>>>>>>>>>>>>>> to be updated to utilise the new values on the SPI.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> To be able to update the code in AS it would need to
>>>>>>>>>>>>>>>>>>> use snapshot releases for JBossWS and we would need
>>>>>>>>>>>>>>>>>>> to be sure a JBossWS release was coming before the
>>>>>>>>>>>>>>>>>>> next AS release (JBoss AS 4.2.3.GA and 5.0.0.CR2).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Or is the process to get the SPI and Framework
>>>>>>>>>>>>>>>>>>> updated first and then wait until the AS branches
>>>>>>>>>>>>>>>>>>> have the WS version increased to implement the final
>>>>>>>>>>>>>>>>>>> fix there?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>> jbossws-dev mailing list
>>>>>>>>>>>>>>>>>>> jbossws-dev at lists.jboss.org
>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> jbossws-dev mailing list
>>>>>>>>>>>>> jbossws-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jbossws-dev mailing list
>>>>>>>>> jbossws-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> jbossws-dev mailing list
>>>> jbossws-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>>
>>> _______________________________________________
>>> jbossws-dev mailing list
>>> jbossws-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>
>
More information about the jbossws-dev
mailing list