Re: [jbossws-dev] Multi Component Fixes

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(a)lists.jboss.org >>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> jbossws-dev mailing list >>>>>>>>>>>>> jbossws-dev(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jbossws-dev mailing list >>>>>>>>> jbossws-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> jbossws-dev mailing list >>>> jbossws-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev >>> >>> _______________________________________________ >>> jbossws-dev mailing list >>> jbossws-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbossws-dev >> >