Re: [jbossws-dev] Multi Component Fixes

Thanks my '.m2/repository/javax/xml/ws/jaxws-api' was corrupt - deleting it fixed the error. Alessio Soldano wrote: > 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 >>> >> > _______________________________________________ jbossws-dev mailing list jbossws-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbossws-dev