Re: To spring 3 or not to spring 3
+1 for upgrading to Spring 3 and Jetty 7. Cyrille On Fri, Jul 16, 2010 at 11:14 PM, Daniel Kulp wrote: > > Since we are getting close to having 2.3 ready to release, I'm kind of looking > at the various deps to see if there are updates we should grab or not. > Things like woodstox and abdera and such are pretty much no-brainers. > > The two main contention points are: > 1) Jetty from 6 to 7- Benson has started investigating this. This DOES > involve some code changes as the Jetty packages and stuff have changed. > Thus, the http-jetty transport would be incompatible with Jetty 6. However, > it would give us some potential new features such as support for continuations > on HTTPs. (I think) > > 2) Spring - should we use 3.0.0 instead of 2.5.6? I think the answer for > this is "go ahead". We've already have profiles to test this and the same > code seems to work OK with 2.5.6 and 3.0.0. Just want to double check with > folks though. > > I'd like to hear peoples thoughts on those. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog
Re: DOSGI: Update to CXF 2.2.9
> I think we're ready for a release! Great! > Eoghan would you have some cycles? Yeah. A couple of things before I go ahead and cut the release: - can you update the release notes[1] with a summary of what's new in this release? - does this TimeoutException[2] in TestExportService.testAccessEndpoint() ring any bells? Cheers, Eoghan [1] distribution/sources/src/main/release/release_notes.txt [2] --- Test set: org.apache.cxf.dosgi.systests2.single.TestExportService --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 123.83 sec <<< FAILURE! testAccessEndpoint [felix](org.apache.cxf.dosgi.systests2.single.TestExportService) Time elapsed: 123.427 sec <<< ERROR! java.util.concurrent.TimeoutException at org.apache.cxf.dosgi.systests2.common.AbstractTestExportService.waitPort(AbstractTestExportService.java:129) at org.apache.cxf.dosgi.systests2.common.AbstractTestExportService.baseTestAccessEndpoint(AbstractTestExportService.java:45) at org.apache.cxf.dosgi.systests2.single.TestExportService.testAccessEndpoint(TestExportService.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134) at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) at sun.rmi.transport.Transport$1.run(Transport.java:159) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:155) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) On 16 July 2010 13:53, David Bosschaert wrote: > I spent a little while debugging this today and found that the issue > was that the bundles internally used by the system tests didn't have > the proper startlevel set which meant that they would get assigned > level 5 and be started way before any of the other bundles, nailing > the jaxws package to the one from the JRE again (0.0.0). > I've changed the start level of these bundles and now everything is > working correctly. > > I've committed this in r964787. > > I think we're ready for a release! Eoghan would you have some cycles? > > Cheers, > > David > > On 30 June 2010 18:16, Daniel Kulp wrote: > > On Tuesday 29 June 2010 3:24:55 am David Bosschaert wrote: > >> It troubles me that if people want to use CXF-DOSGi they would have to > >> fiddle with the org.osgi.framework.system.packages. This is a major > >> usability drawback from where we were before. > >> > >> > A more long-term option might to ship an entire distro of karaf with > >> > dOSGi, > >> > >> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf > >> distro as OSGi is all about reusable components that can be used in > >> any compliant OSGi Framework. We shouldn't have to ship a tweaked > >> runtime for people to be able to use it. > >> > >> >> I'm just curious, why was the CXF import updated to include 0.0.0 ? > >> > > >> > So it works with an "out of the box" setup of Equinox without > requiring > >> > the user to update funky setup things like the system.packages thing. > >> > >> Depending on version 0.0.0 is potentially dangerous because you have > >> no idea
Re: To spring 3 or not to spring 3
I think +1 for Spring 3, if a company is going to make the leap to CXF 2.3, they are probably willing to make the jump to Spring 3.0. Would there actually be any @since 3.0 features you'd use from Spring? Or would it be possible they could still operate with 2.5.6 by doing maven excludes on the 3.0 transient deps? No comment on Jetty, I only use Jett for testing purposes and not for actually deploying too so I think even if there was something with Jetty 7 which was screwing me up I could still continue BAU with say Tomcat. Craig. On 2010-07-17, at 6:23 AM, Cyrille Le Clerc wrote: > +1 for upgrading to Spring 3 and Jetty 7. > > Cyrille > > On Fri, Jul 16, 2010 at 11:14 PM, Daniel Kulp wrote: >> >> Since we are getting close to having 2.3 ready to release, I'm kind of >> looking >> at the various deps to see if there are updates we should grab or not. >> Things like woodstox and abdera and such are pretty much no-brainers. >> >> The two main contention points are: >> 1) Jetty from 6 to 7- Benson has started investigating this. This DOES >> involve some code changes as the Jetty packages and stuff have changed. >> Thus, the http-jetty transport would be incompatible with Jetty 6. However, >> it would give us some potential new features such as support for >> continuations >> on HTTPs. (I think) >> >> 2) Spring - should we use 3.0.0 instead of 2.5.6?I think the answer for >> this is "go ahead". We've already have profiles to test this and the same >> code seems to work OK with 2.5.6 and 3.0.0. Just want to double check with >> folks though. >> >> I'd like to hear peoples thoughts on those. >> >> >> -- >> Daniel Kulp >> dk...@apache.org >> http://dankulp.com/blog
Re: To spring 3 or not to spring 3
On Saturday 17 July 2010 11:11:03 am Craig Tataryn wrote: > I think +1 for Spring 3, if a company is going to make the leap to CXF 2.3, > they are probably willing to make the jump to Spring 3.0. > > Would there actually be any @since 3.0 features you'd use from Spring? Or > would it be possible they could still operate with 2.5.6 by doing maven > excludes on the 3.0 transient deps? Right now, we default to Spring 2.5.6, but we have a profile for testing with 3.0. We most likely would just reverse that. Thus, at THIS point, you could easily exclude 3 and use 2.5.6.We could probably setup a build in Hudson to use the spring 2 profile to make sure it would work. > No comment on Jetty, I only use Jett for testing purposes and not for > actually deploying too so I think even if there was something with Jetty 7 > which was screwing me up I could still continue BAU with say Tomcat. That would be the goal.The one "tricky" thing is that I might need to update the servlet-api to 3.0 for Jetty, but I need to test to make sure that won't break things when running in a 2.5 container. I'll comment more about this in Benson's thread about jetty 7 in a bit. Dan > > Craig. > > On 2010-07-17, at 6:23 AM, Cyrille Le Clerc wrote: > > +1 for upgrading to Spring 3 and Jetty 7. > > > > Cyrille > > > > On Fri, Jul 16, 2010 at 11:14 PM, Daniel Kulp wrote: > >> Since we are getting close to having 2.3 ready to release, I'm kind of > >> looking at the various deps to see if there are updates we should grab > >> or not. Things like woodstox and abdera and such are pretty much > >> no-brainers. > >> > >> The two main contention points are: > >> 1) Jetty from 6 to 7- Benson has started investigating this. This > >> DOES involve some code changes as the Jetty packages and stuff have > >> changed. Thus, the http-jetty transport would be incompatible with > >> Jetty 6. However, it would give us some potential new features such > >> as support for continuations on HTTPs. (I think) > >> > >> 2) Spring - should we use 3.0.0 instead of 2.5.6?I think the answer > >> for this is "go ahead". We've already have profiles to test this and > >> the same code seems to work OK with 2.5.6 and 3.0.0. Just want to > >> double check with folks though. > >> > >> I'd like to hear peoples thoughts on those. > >> > >> > >> -- > >> Daniel Kulp > >> dk...@apache.org > >> http://dankulp.com/blog -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: jetty 7: CXF-2898
On Thursday 15 July 2010 9:53:28 pm Benson Margulies wrote: > The continuation code is very different. I attached a first pass > patch. It does not pass unit tests because I am completely flummoxed > by mock, and I may not understand what's going on with the > continuations. Digging into this a bit, it definitely gets a bit complicated. In Jetty 7, the continuations will only work if you have the Jetty6 continuation support jar OR if you have Servlet API 3.0 available. I'm leaning toward changing our servlet api jar from 2.5 to 3.0. However, if I do that , it would make sense to rip all the continuation stuff out of the Jetty module and promote it up to the AbstractHttpDestination (providing I can detect if servlet 3 is avail and bypass on a 2.5 container. Doing that would allow the continuations to work with any Servlet 3 container such as the newer tomcats and such.That's obviously a bit more work, but I think there is some value in it. Long term, there are some other interesting things that can be done with Servlet 3. One example is a password handler for ws-sec that would authenticate with the Servlet container. It could make UsernamePassword a bit easier to use on certain containers. Dan > > On Thu, Jul 15, 2010 at 9:13 PM, Willem Jiang wrote: > > Daniel Kulp wrote: > >> On Thursday 15 July 2010 2:33:26 pm Benson Margulies wrote: > >>> The first part of the JIRA I filed above is easy: make a new project > >>> that depends on jetty 7 instead of 6. > >>> > >>> I'm somewhat rusty after that. A profile in systests to use it? Where > >>> is the default transport established (which I don't propose to change) > >>> but what else is called for? > >> > >> Well, I guess there is a question of whether is makes sense to make 2.3 > >> use Jetty 7 and have 2.2 remain at 6.I would actually be OK with > >> that. How much would the CODE change? Is it just the dependencies or > >> does it require a lot of code changes as well? > > > > Jetty 7 changed its package name to start with org.eclipse, so the code > > could be changed a bit. > > > > Willem -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: To spring 3 or not to spring 3
On 2010-07-17, at 11:00 AM, Daniel Kulp wrote: > On Saturday 17 July 2010 11:11:03 am Craig Tataryn wrote: >> I think +1 for Spring 3, if a company is going to make the leap to CXF 2.3, >> they are probably willing to make the jump to Spring 3.0. >> >> Would there actually be any @since 3.0 features you'd use from Spring? Or >> would it be possible they could still operate with 2.5.6 by doing maven >> excludes on the 3.0 transient deps? > > Right now, we default to Spring 2.5.6, but we have a profile for testing with > 3.0. We most likely would just reverse that. Thus, at THIS point, you > could easily exclude 3 and use 2.5.6.We could probably setup a build in > Hudson to use the spring 2 profile to make sure it would work. > >> No comment on Jetty, I only use Jett for testing purposes and not for >> actually deploying too so I think even if there was something with Jetty 7 >> which was screwing me up I could still continue BAU with say Tomcat. > > That would be the goal.The one "tricky" thing is that I might need to > update the servlet-api to 3.0 for Jetty, but I need to test to make sure that > won't break things when running in a 2.5 container. I'll comment more about > this in Benson's thread about jetty 7 in a bit. > Now *that* I could see being a problem because of "legacy" containers which might be running CXF. *cough* WAS 6.1 *cough* Craig. > Dan > > > >> >> Craig. >> >> On 2010-07-17, at 6:23 AM, Cyrille Le Clerc wrote: >>> +1 for upgrading to Spring 3 and Jetty 7. >>> >>> Cyrille >>> >>> On Fri, Jul 16, 2010 at 11:14 PM, Daniel Kulp wrote: Since we are getting close to having 2.3 ready to release, I'm kind of looking at the various deps to see if there are updates we should grab or not. Things like woodstox and abdera and such are pretty much no-brainers. The two main contention points are: 1) Jetty from 6 to 7- Benson has started investigating this. This DOES involve some code changes as the Jetty packages and stuff have changed. Thus, the http-jetty transport would be incompatible with Jetty 6. However, it would give us some potential new features such as support for continuations on HTTPs. (I think) 2) Spring - should we use 3.0.0 instead of 2.5.6?I think the answer for this is "go ahead". We've already have profiles to test this and the same code seems to work OK with 2.5.6 and 3.0.0. Just want to double check with folks though. I'd like to hear peoples thoughts on those. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog
