Potential impact of SpringSource Enterprise Maintenance Policy on CXF
Hi, I am a newbie for CXF. I started exploring it as a potential framework for implementing web service based application. I am ok with most of the stuff with CSX but for its heavy dependency on Spring framework. I am aware about the availability of bus and NonSpringServlet approach and would like to explore it further. The forum says that most of the advanced cases will require spring or doing a lot of low level API programming to get it configured. That means I cannot keep away with Spring if I want to harness the real potential of CXF framework :-(. With the new http://www.springsource.com/products/enterprise/maintenancepolicy SpringSource Enterprise Maintenance Policy , it looks like non subscribed spring developers(I believe there are many of them) are going to have a hard time identifying a stable spring release, as the spring source will issue maintenance updates for three months period after a new major version of Spring is released. My understanding of the policy may not be 100% correct, but if it is correct, then how CXF is planning repository management for Spring versions? The question is more serious for an Ant based project as the dependencies have to be managed manually there. Will CXF bundle a stable Spring release along with the jar distributions for CXF framework in the future or will it rely on Maven to resolve the Spring dependencies for a particular stable release? -- View this message in context: http://www.nabble.com/Potential-impact-of-SpringSource-Enterprise-Maintenance-Policy-on-CXF-tp19833297p19833297.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
By reading the FAQ, it shows that we will always have access to the source code for a particular build, but not just the compiled version after three months. Presumably Apache (as I suspect other projects use Spring) would need to build its own version from their source code and store it in our Maven repositories, and yes, as usual, deliver it along with the CXF download. Keep in mind, removing Spring from CXF is not a victory either. We would have to reinvent the wheel in creating our own framework, and, unlike Spring's, the new framework would not be one readily understood by thousands in the community (hence fewer patches and enhancements from them), nor would it be as well tested and beaten-up as Spring's is, because it would be in use by only one project. Usage of Spring is a major differentiator between Metro and CXF, do you want a web service stack that relies on a tested and proven framework, or do you want one that needs to reinvent the wheel to some degree in order to avoid a Spring dependency? Both approaches have their happy adherents--while you might be happy with (and indeed need) a web service stack that has no org.springframework.* packages within it, others might be equally concerned about relying on one that uses org.glen.* instead. Glen CXF Explorer wrote: > > Hi, > I am a newbie for CXF. I started exploring it as a potential framework for > implementing web service based application. I am ok with most of the stuff > with CSX but for its heavy dependency on Spring framework. I am aware > about the availability of bus and NonSpringServlet approach and would like > to explore it further. The forum says that most of the advanced cases will > require spring or doing a lot of low level API programming to get it > configured. That means I cannot keep away with Spring if I want to harness > the real potential of CXF framework :-(. > > With the new > http://www.springsource.com/products/enterprise/maintenancepolicy > SpringSource Enterprise Maintenance Policy , it looks like non subscribed > spring developers(I believe there are many of them) are going to have a > hard time identifying a stable spring release, as the spring source will > issue maintenance updates for three months period after a new major > version of Spring is released. My understanding of the policy may not be > 100% correct, but if it is correct, then how CXF is planning repository > management for Spring versions? The question is more serious for an Ant > based project as the dependencies have to be managed manually there. > > Will CXF bundle a stable Spring release along with the jar distributions > for CXF framework in the future or will it rely on Maven to resolve the > Spring dependencies for a particular stable release? > -- View this message in context: http://www.nabble.com/Potential-impact-of-SpringSource-Enterprise-Maintenance-Policy-on-CXF-tp19833297p19835875.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
Hi Glen and CXF Community, there's no need to reinvent the wheel. Did you hear about JBoss Microcontainer? It's open well tested MC implementation that is loosely coupled with JBoss AS. Just for your information JBoss MC 2.0 is going to GA state soon. See http://www.jboss.org/jbossmc/ for more information. Richard Glen Mazza wrote: By reading the FAQ, it shows that we will always have access to the source code for a particular build, but not just the compiled version after three months. Presumably Apache (as I suspect other projects use Spring) would need to build its own version from their source code and store it in our Maven repositories, and yes, as usual, deliver it along with the CXF download. Keep in mind, removing Spring from CXF is not a victory either. We would have to reinvent the wheel in creating our own framework, and, unlike Spring's, the new framework would not be one readily understood by thousands in the community (hence fewer patches and enhancements from them), nor would it be as well tested and beaten-up as Spring's is, because it would be in use by only one project. Usage of Spring is a major differentiator between Metro and CXF, do you want a web service stack that relies on a tested and proven framework, or do you want one that needs to reinvent the wheel to some degree in order to avoid a Spring dependency? Both approaches have their happy adherents--while you might be happy with (and indeed need) a web service stack that has no org.springframework.* packages within it, others might be equally concerned about relying on one that uses org.glen.* instead. Glen CXF Explorer wrote: Hi, I am a newbie for CXF. I started exploring it as a potential framework for implementing web service based application. I am ok with most of the stuff with CSX but for its heavy dependency on Spring framework. I am aware about the availability of bus and NonSpringServlet approach and would like to explore it further. The forum says that most of the advanced cases will require spring or doing a lot of low level API programming to get it configured. That means I cannot keep away with Spring if I want to harness the real potential of CXF framework :-(. With the new http://www.springsource.com/products/enterprise/maintenancepolicy SpringSource Enterprise Maintenance Policy , it looks like non subscribed spring developers(I believe there are many of them) are going to have a hard time identifying a stable spring release, as the spring source will issue maintenance updates for three months period after a new major version of Spring is released. My understanding of the policy may not be 100% correct, but if it is correct, then how CXF is planning repository management for Spring versions? The question is more serious for an Ant based project as the dependencies have to be managed manually there. Will CXF bundle a stable Spring release along with the jar distributions for CXF framework in the future or will it rely on Maven to resolve the Spring dependencies for a particular stable release? -- B.Sc. Richard Opalka Senior Software Engineer JBoss, a division of Red Hat Mobile: +420 731 186 942 Mail: [EMAIL PROTECTED]
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
> It's open well tested MC implementation that is loosely coupled with JBoss > AS. ...and is LGPL-licensed, perhaps? It's not clear from the project page, and the Legal Notice in the User Guide merely contains a human-readable address. --oh
Re: WS-SecurityPolicy in CXF 2.1.x, or just 2.2?
On Sunday 05 October 2008, Glen Mazza wrote:
> Hello, having just watched my Buffalo Bills get clobbered,
The AFC east is definitely proving to be quite interesting this year.
The predicted top two teams now have major injury issues, Favre is
resurecting the Jets, and Dolphins are surprisingly good. While things
don't look good for the Pats without Brady, it still should be a fun
season to watch with everything going on.
> I would
> next like to test out the WS-SecurityPolicy configuration that Dan has
> done. Is it supported only on the CXF 2.2 branch or both 2.1.x and
> 2.2?
Just 2.2. It's very "unstable" right now as I kind of move things
around to get it working. Right now, there is pretty much no error
handling (it likely will just printStackTrace and continue with
unpredicatble results), I'll probably refactory the sending into 3 (or
more) interceptors, and the incoming messages are currently not
validated against the policies. Basically, there is still much work to
do, but it's at a state where the basic usecases are working. The MS
InteropFest usecases are now working (except the UsernameToken stuff,
and I'm not sure why yet. Seems MS wants those encrypted, even if the
policy says not to, but I haven't dug into all that yet. Not having a
windows box is slightly hindering that progress.)
> Also, is there any client-side WSDL configuration or is it just
> service-side WSDL config?
Actually, the CLIENT side stuff is MUCH better tested right now. I've
been using the live MS WCF tests at:
http://mssoapinterop.org/ilab/
as my testcases. For the most part, I just run wsdl2java on the wsdls
and have a simple client that calls on them. For each "test case", the
spring config sets the properties that are needed. For example, I
have:
Turn on the policy stuff: (this will probably be the default for 2.2 if
it all works and doesn't affect performance)
Configure the client: (wsssec 1.1 testcases, symetric binding, x509
ProtectionToken)
http://InteropBaseAddress/interop}A_IPingService";
createdFromAPI="true">
Or: (wssec 1.0 testcases, asymetric binding)
http://InteropBaseAddress/interop}MutualCertificate10SignEncryptRsa15TripleDes_IPingService";
createdFromAPI="true">
There is a SecurityConstants.java file in the ws/security module that
defines the various constants that the runtime will look for. They can
be configured into the client (or endpoint on the server side) via
spring config like above, but you can also use the JAX-WS request
context. For example:
binding.getRequestContext().put("ws-security.encryption.username",
"Bob");
Thus, other than turning on the Policy stuff on the bus, it's quite
usable without any configuration at all.
> I would think it is just service-side,
> because we use normal WSS4J config files for the client-side (and
> service-side) key/password info, if I'm not mistaken.
For the crypto stuff, yea. We use the normal Merlin config files, but
thats for both server and client side. Not quite sure what the best way
to deal with that. Feel free to offer suggestions. :-)
HOWEVER, the runtime for the sending side (not the incoming side yet),
will grab a Crypto object out of the message context if available.
Thus, if you build up a Crypto object somehow else, (feature, other
interceptor, stick in the RequestContext, etc...), it will use it.
Thus, if you have some really good ideas, we can implement it ahead of
the Policy out interceptors.
Dan
>
> Thanks,
> Glen
--
J. Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
The license is LGPL Cheers, Richard It's open well tested MC implementation that is loosely coupled with JBoss AS. ...and is LGPL-licensed, perhaps? It's not clear from the project page, and the Legal Notice in the User Guide merely contains a human-readable address. --oh -- B.Sc. Richard Opalka Senior Software Engineer JBoss, a division of Red Hat Mobile: +420 731 186 942 Mail: [EMAIL PROTECTED]
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
I'm not sure if there would be any major impact on CXF. We already ship a version of Spring with CXF that we've tested with and such. We try to keep semi-up-to-date with what Spring releases so we have whatever bug fixes they provide, just like we try to update as many of the other dependencies as we can as well. Also, once the Spring releases are in the maven repo, they are there. That includes the sources jars for that release. Thus, once we find a version we like, it will be there. Anyway, I'm not sure what impact it will have. My gut feeling says "not too much" for CXF here at Apache. That said, for "Enterprise" users that use an enterprise version of CXF as provided from a third party (like the FUSE branded stuff from IONA/Progress), you would need to ask them. We don't have control over that. Dan On Monday 06 October 2008, CXF Explorer wrote: > Hi, > I am a newbie for CXF. I started exploring it as a potential framework > for implementing web service based application. I am ok with most of > the stuff with CSX but for its heavy dependency on Spring framework. I > am aware about the availability of bus and NonSpringServlet approach > and would like to explore it further. The forum says that most of the > advanced cases will require spring or doing a lot of low level API > programming to get it configured. That means I cannot keep away with > Spring if I want to harness the real potential of CXF framework :-(. > > With the new > http://www.springsource.com/products/enterprise/maintenancepolicy > SpringSource Enterprise Maintenance Policy , it looks like non > subscribed spring developers(I believe there are many of them) are > going to have a hard time identifying a stable spring release, as the > spring source will issue maintenance updates for three months period > after a new major version of Spring is released. My understanding of > the policy may not be 100% correct, but if it is correct, then how CXF > is planning repository management for Spring versions? The question is > more serious for an Ant based project as the dependencies have to be > managed manually there. > > Will CXF bundle a stable Spring release along with the jar > distributions for CXF framework in the future or will it rely on Maven > to resolve the Spring dependencies for a particular stable release? -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
On Monday 06 October 2008, Richard Opalka wrote: > The license is LGPL Which isn't useful for us. We cannot ship LGPL jars. If we HAD to change, we'd probably have to pull all the container stuff out into some sort of Abstract notion and then allow Spring/Plexus/Etc.. to be plugged in. Either that or enhance the non-spring stuff to make it completely usable without spring. Dan > Cheers, > > Richard > > >> It's open well tested MC implementation that is loosely coupled > >> with JBoss AS. > > > > ...and is LGPL-licensed, perhaps? It's not clear from the project > > page, and the Legal Notice in the User Guide merely contains a > > human-readable address. > > > > --oh -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: customEditorConfigurer in cxf-extension-soap.xml being used?
On Sunday 05 October 2008, Glen Mazza wrote: > Hello, it could be that I'm not reading the Spring bean wiring code > correctly, but AFAICT the "org.apache.cxf.binding.soap. > customEditorConfigurer" bean defined at the bottom of [1] is not being > used/activated anywhere. Does anyone know this bean's purpose/whether > it is actually being used today? > > Thanks, > Glen > > [1] http://tinyurl.com/4zwpse It IS used, but it didn't work correctly in < 2.0.8/2.1.2. If you look in: rt/frontend/jaxws/src/test/java/org/apache/cxf/jaxws/spring/clients.xml you see something like: http://localhost:9000/foo"; serviceName="s:SOAPService" xmlns:s="http://apache.org/hello_world_soap_http";> The customEditorConfigurer thing converts the version="1.2" part of that into a SoapVersion object that is needed for the soap binding object. -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
Which makes it unfortunately most useless for Apache--but still, although I'm sure it's a fine product, we would have the same headaches, with users next complaining about the dependency on *your* project. Can't please everyone I guess... Glen Richard Opalka wrote: > > The license is LGPL > > Cheers, > > Richard >>> It's open well tested MC implementation that is loosely coupled with >>> JBoss >>> AS. >>> >> >> ...and is LGPL-licensed, perhaps? It's not clear from the project page, >> and >> the Legal Notice in the User Guide merely contains a human-readable >> address. >> >> --oh >> > > > -- > B.Sc. Richard Opalka > Senior Software Engineer > JBoss, a division of Red Hat > > Mobile: +420 731 186 942 > Mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Potential-impact-of-SpringSource-Enterprise-Maintenance-Policy-on-CXF-tp19833297p19837249.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Proposal for a new JMS configuration for CXF
I completely agree with MUCH of this. I'd love it if the jaxws:client
and jaxws:endpoint/server things had a:
type thing that would configure that. It's SLIGHTLY more complicated by
the presence of the conduit selector things in the client which allows
load balancing and such. However, that could be made even more
configurable with something like:
(default would be the current "Upfront" selector.)
Dan
On Sunday 05 October 2008, Christian Schneider wrote:
> Hi Willem,
>
> if I understand it right there is always one conduit for each client
> or endpoint. So I would not try to reference a conduit config via the
> endpoint name like it is done now. The conduit can as well be
> described as a parameter of client or endpoint. I really do not like
> the way the old JMSConduit configured itself. Extracting the
> configuration should be outside of the object to be configured.
>
> The way camel does this is ok. But instead of referencing a jms
> configuration in the address line I would simply set it as a parameter
> in client or endpoint. If you want to centralize certain parts of the
> config spring still has the ref="" to reference a central config bean.
> Additionally we can use abstract config beans so several jms
> configurations can share some common parts.
>
> By simply being a property of the client or endpoint they can simply
> add it to the endpointInfo. So the TransportFactory can extract it and
> set the Conduit or Destination with it.
>
> Greetings
>
> Christian
>
> Willem Jiang schrieb:
> > You could take a look at the configuration of camel transport for
> > CXF. we inject the camel context (which could be an extension of
> > TransportConfig) into the CamelTransportFactory or the
> > {CamelConduit|CamelDestion}.
> >
> > Endpoint can find the CamelTransportFactory by using the transport
> > id or transport perfix like 'camel:'. Each Conduit or Destination
> > configuration has its own id, when the endpoint find the transport
> > factory and create the conduit or destination, current CXF
> > configuration will call the 'configure' method which will seach the
> > spring context and configure the conduit or destination according
> > the bean id.
> >
> > If you want to add the TransportConfig into the endpoint , we need
> > to hack the code of endpoint looking up the transport factory, and
> > set the TransportConfig into the transport factory or the
> > {conduit|destination}.
> >
> > Any thoughts?
--
J. Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Release manager for 2.1.3 and/or 2.0.9.....
Willem, Thanks for volunteering to do this. That's great. I think it would be good to do 2.0.9 late this week and probably 2.1.3 middle of next week. (need to do 2.0.x first due to an "issue" with the maven stage plugin which will update the "latest" tag in the metadata with 2.0.9 so 2.0.9 would get picked up instead of 2.1.2. Thus, we would want 2.1.3 shortly thereafter to restore a 2.1.x version as latest). I have a couple of fixes I'm going to try and get in to 2.1.x this week. We also should update to bouncycastle 140 and xalan 2.7.1 for both 2.1.3 and 2.0.9. With those versions, we can actually distribute bouncycastle and thus ws-security can work "out of the box" and not require downloading additional jars. Dan On Thursday 02 October 2008, Willem Jiang wrote: > Hi Dan, > > I'd like to take charge of this CXF release. > Since you and me met a year before, I will send you my key for signing > :) > > Cheers, > > Willem > > On Fri, Oct 3, 2008 at 12:49 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases. > > It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2. We > > have 33 issues resolved for 2.0.9, and 38 for 2.1.3. Thus, we > > probably should consider doing some releases shortly. > > > > HOWEVER, my hard drive crashed this week and part of recovering from > > that, I kind of realized that someone else really should try doing a > > release to make sure the knowledge is spread out a bit and isn't all > > bottled up in my head.Thus, I'd like to ask for volunteers for > > doing the releases. If no one jumps up, I'll be happy to do it, > > but it would definitely be good to get someone else involved. > > > > Requirements: > > 1) The release process is MUCH easier and more reliable on a Linux > > or OSX box. Things like gpg and ssh/scp "just work". If someone > > want to try Windows, I'm not sure how much I can help. > > > > 2) gpg installed and a gpg key generated and available in the public > > key servers. Ideally, it would be signed by other apache folks, > > but that's not a requirment. Anyone near Boston, we could meet for > > lunch and sign keys if you want. > > > > 3) Time - before building the release, you need a few hours to > > review release notes, notice/license files, rat reports, etc > > Post release, there is syncing to the maven repo, updating > > confluence, some JIRA admin things, etc Basically, a few hours > > ahead of the build, an hour to build, three days for the vote, and a > > few hours afterword. > > > > Anyway, if anyone is interested, speak up. I'd be happy to look > > over your virtual shoulder while you do the stuff to make sure it's > > all done right. Not a problem. > > > > Thanks! > > > > -- > > J. Daniel Kulp > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
RE: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
So it sounds like for communities such as Fuse, after the 3 month period during which fixes will be made available in compiled releases, they will have to maintain their own copy of Spring and fold in any changes that are made available to enterprise customers and folded into the Spring trunk. -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2008 8:55 AM To: dev@cxf.apache.org Cc: CXF Explorer Subject: Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF I'm not sure if there would be any major impact on CXF. We already ship a version of Spring with CXF that we've tested with and such. We try to keep semi-up-to-date with what Spring releases so we have whatever bug fixes they provide, just like we try to update as many of the other dependencies as we can as well. Also, once the Spring releases are in the maven repo, they are there. That includes the sources jars for that release. Thus, once we find a version we like, it will be there. Anyway, I'm not sure what impact it will have. My gut feeling says "not too much" for CXF here at Apache. That said, for "Enterprise" users that use an enterprise version of CXF as provided from a third party (like the FUSE branded stuff from IONA/Progress), you would need to ask them. We don't have control over that. Dan On Monday 06 October 2008, CXF Explorer wrote: > Hi, > I am a newbie for CXF. I started exploring it as a potential framework > for implementing web service based application. I am ok with most of > the stuff with CSX but for its heavy dependency on Spring framework. I > am aware about the availability of bus and NonSpringServlet approach > and would like to explore it further. The forum says that most of the > advanced cases will require spring or doing a lot of low level API > programming to get it configured. That means I cannot keep away with > Spring if I want to harness the real potential of CXF framework :-(. > > With the new > http://www.springsource.com/products/enterprise/maintenancepolicy > SpringSource Enterprise Maintenance Policy , it looks like non > subscribed spring developers(I believe there are many of them) are > going to have a hard time identifying a stable spring release, as the > spring source will issue maintenance updates for three months period > after a new major version of Spring is released. My understanding of > the policy may not be 100% correct, but if it is correct, then how CXF > is planning repository management for Spring versions? The question is > more serious for an Ant based project as the dependencies have to be > managed manually there. > > Will CXF bundle a stable Spring release along with the jar > distributions for CXF framework in the future or will it rely on Maven > to resolve the Spring dependencies for a particular stable release? -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
Hi all, does anyone know if it is possible to put the spring jars into the central maven repository? If springsource does not do it. Will it be possible that someone from apache could build and upload the jars? Are there any legal issues with this? Would the policies in the maven repo allow this? I think if the releases would be provided by a open source project then there would be almost no technical issues. What we should avoid is that every project builds it´s own version eventually giving them different group names. This would wreck any dependency management. Greetings Christian Soltysik, Seumas schrieb: So it sounds like for communities such as Fuse, after the 3 month period during which fixes will be made available in compiled releases, they will have to maintain their own copy of Spring and fold in any changes that are made available to enterprise customers and folded into the Spring trunk. -- Christian Schneider --- http://www.liquid-reality.de
Re: Potential impact of SpringSource Enterprise Maintenance Policy on CXF
Looks like a project has already popped up to support spring: http://freespring.org/ Dan On Monday 06 October 2008, Christian Schneider wrote: > Hi all, > > does anyone know if it is possible to put the spring jars into the > central maven repository? If springsource does not do it. Will it be > possible that someone from apache could build and upload the jars? > Are there any legal issues with this? Would the policies in the maven > repo allow this? > > I think if the releases would be provided by a open source project > then there would be almost no technical issues. > What we should avoid is that every project builds it´s own version > eventually giving them different group names. This would wreck any > dependency management. > > Greetings > > Christian > > Soltysik, Seumas schrieb: > > So it sounds like for communities such as Fuse, after the 3 month > > period during which fixes will be made available in compiled > > releases, they will have to maintain their own copy of Spring and > > fold in any changes that are made available to enterprise customers > > and folded into the Spring trunk. -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
[DOSGi] Patch attached to JIRA CXF-1811
Hi all, I attached a further patch for CXF-1811 to this bug: https://issues.apache.org/jira/secure/attachment/12391563/property_rename2.patch The patch is called 'property_rename2.patch'. A direct link to the patch: https://issues.apache.org/jira/secure/attachment/12391563/property_rename2.patch In addition to fixing the service property names, the patch includes: * When an intent is on the osgi.remote.requires.intents list and cannot be satisfied, the service is not exposed remotely. * All satisfied intents are added to an osgi.intents publication property. * New unit tests added for the above. * Also, added extra unit tests for intent map overriding and merging. Would greatly appreciate if someone could apply the patch. Best regards, David IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Bizarre mvn error building on this Mac I just got
If you type mvn -version it usually spits out the java version it has found. Dan On Friday 03 October 2008, Benson Margulies wrote: > Hmm. How can I tell if mvn has, for some reason, decided to favor 1.6? > > On Fri, Oct 3, 2008 at 6:51 AM, David Bosschaert <[EMAIL PROTECTED]> wrote: > > Hi Benson, > > > > FWIW - I got similar errors before and they seem to be caused in the > > situation where you have two things compiling into the same location > > using different versions of the JDK. > > > > In my case I had Eclipse projects for my maven modules (created > > using mvn eclipse:eclipse) compiling into target/classes - the same > > target directory as Maven uses. However my eclipse used Java 6 while > > Maven was using Java 5. So my target/classes ended having a mixture > > of Java 5 and Java 6 compiled .class files. Thats whenI got the > > error. > > > > In my case closing Eclipse then doing a mvn clean fixed the > > problem... > > > > Cheers, > > > > David > > BTW this was on Windows. > > > > Benson Margulies wrote: > >> ??? This isn't in eclipse! > >> > >> --- > >> T E S T S > >> --- > >> Running org.apache.cxf.tools.wsdlto.javascript.WSDLToJavaScriptTest > >> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: > >> 0.045 sec <<< FAILURE! > >> > >> testGeneration(org.apache.cxf.tools.wsdlto.javascript.WSDLToJavaScr > >>iptTest) Time elapsed: 0.005 sec <<< ERROR! > >> java.lang.Error: Unresolved compilation problems: > >>The type java.net.URISyntaxException cannot be resolved. It is > >> indirectly referenced from required .class files > >>The import java.io.File cannot be resolved > >>The import java.io.FileInputStream cannot be resolved > >>The hierarchy of the type WSDLToJavaScriptTest is inconsistent > >>Exception cannot be resolved to a type > >>The constructor JavaScriptContainer(ToolSpec) refers to the > >> missing type > >> Exception > >>String cannot be resolved to a type > >>The method getLocation(String) from the type ProcessorTestBase > >> refers to > >> the missing type String > >>String cannot be resolved to a type > >>File cannot be resolved to a type > >>String cannot be resolved to a type > >>String cannot be resolved to a type > >>String cannot be resolved to a type > >>File cannot be resolved to a type > >>File cannot be resolved to a type > >>File cannot be resolved to a type > >>FileInputStream cannot be resolved to a type > >>FileInputStream cannot be resolved to a type > >>String cannot be resolved to a type > >> > >>at > >> > >> org.apache.cxf.tools.wsdlto.javascript.WSDLToJavaScriptTest.( > >>WSDLToJavaScriptTest.java:1) at > >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > >> Method) > >>at > >> > >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstru > >>ctorAccessorImpl.java:39) at > >> > >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Delegatin > >>gConstructorAccessorImpl.java:27) at > >> java.lang.reflect.Constructor.newInstance(Constructor.java:494) at > >> > >> org.junit.internal.runners.JUnit4ClassRunner.createTest(JUnit4Class > >>Runner.java:72) at > >> > >> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit > >>4ClassRunner.java:79) at > >> > >> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4Class > >>Runner.java:51) at > >> > >> org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunne > >>r.java:44) at > >> org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.j > >>ava:27) at > >> org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.jav > >>a:37) at > >> > >> org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner. > >>java:42) at > >> > >> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSe > >>t.java:62) at > >> > >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeT > >>estSet(AbstractDirectoryTestSuite.java:140) at > >> > >> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute( > >>AbstractDirectoryTestSuite.java:127) at > >> org.apache.maven.surefire.Surefire.run(Surefire.java:177) at > >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > >> > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp > >>l.java:39) at > >> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc > >>essorImpl.java:25) at > >> java.lang.reflect.Method.invoke(Method.java:585) > >>at > >> > >> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess( > >>SurefireBooter.java:345) at > >> > >> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter > >>.java:1009) > >> > >> > >> Results : > >> > >> Tests in error: > >> > >> > >> testGeneration(org.apache.cxf.tools.wsdlto.javascript.WSDLToJavaScr > >>iptTest) > >> > >> Tests run: 1, Failures:
Re: [DOSGi] Patch attached to JIRA CXF-1811
Thanks for the patch David, now applied. /Eoghan David Bosschaert wrote: Hi all, I attached a further patch for CXF-1811 to this bug: https://issues.apache.org/jira/secure/attachment/12391563/property_rename2.patch The patch is called 'property_rename2.patch'. A direct link to the patch: https://issues.apache.org/jira/secure/attachment/12391563/property_rename2.patch In addition to fixing the service property names, the patch includes: * When an intent is on the osgi.remote.requires.intents list and cannot be satisfied, the service is not exposed remotely. * All satisfied intents are added to an osgi.intents publication property. * New unit tests added for the above. * Also, added extra unit tests for intent map overriding and merging. Would greatly appreciate if someone could apply the patch. Best regards, David IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Proposal for a new JMS configuration for CXF
Hi Dan,
that´s interesting I had never seen any other ConduitSelector than the
Upfront conduitelector in practice. But I see it can be handy with http.
What about the following proposal:
We already have the conduitSelector element. So we simply would have to
add a property TransportConfig config to UpfrontConduitSelector. A
RoundRobin Conduitselector would
of course need a list of configs.
Greetings
Christian
Daniel Kulp schrieb:
I completely agree with MUCH of this. I'd love it if the jaxws:client
and jaxws:endpoint/server things had a:
type thing that would configure that. It's SLIGHTLY more complicated by
the presence of the conduit selector things in the client which allows
load balancing and such. However, that could be made even more
configurable with something like:
(default would be the current "Upfront" selector.)
Dan
On Sunday 05 October 2008, Christian Schneider wrote:
Hi Willem,
if I understand it right there is always one conduit for each client
or endpoint. So I would not try to reference a conduit config via the
endpoint name like it is done now. The conduit can as well be
described as a parameter of client or endpoint. I really do not like
the way the old JMSConduit configured itself. Extracting the
configuration should be outside of the object to be configured.
The way camel does this is ok. But instead of referencing a jms
configuration in the address line I would simply set it as a parameter
in client or endpoint. If you want to centralize certain parts of the
config spring still has the ref="" to reference a central config bean.
Additionally we can use abstract config beans so several jms
configurations can share some common parts.
By simply being a property of the client or endpoint they can simply
add it to the endpointInfo. So the TransportFactory can extract it and
set the Conduit or Destination with it.
Greetings
Christian
Willem Jiang schrieb:
You could take a look at the configuration of camel transport for
CXF. we inject the camel context (which could be an extension of
TransportConfig) into the CamelTransportFactory or the
{CamelConduit|CamelDestion}.
Endpoint can find the CamelTransportFactory by using the transport
id or transport perfix like 'camel:'. Each Conduit or Destination
configuration has its own id, when the endpoint find the transport
factory and create the conduit or destination, current CXF
configuration will call the 'configure' method which will seach the
spring context and configure the conduit or destination according
the bean id.
If you want to add the TransportConfig into the endpoint , we need
to hack the code of endpoint looking up the transport factory, and
set the TransportConfig into the transport factory or the
{conduit|destination}.
Any thoughts?
--
Christian Schneider
---
http://www.liquid-reality.de
Re: Proposal for a new JMS configuration for CXF
Hi Dan,
Dan Diephouse made a similar proposal about 18 months ago, and I was
opposed at the time as it didn't accomodate what was trying to acheive
with ConduitSelectors.
That discussion was also conflated with a bunch of other proposed
changes, but in retrospect I think the bean had the
essence of a really good idea.
So as long as support for the flexible conduit selection is maintained,
I think this proposal would have potential.
Possible wrinkles would include things like:
- ensuring that the choice of conduit selector is validated against the
presence or absence of fine-grained conduit beans, e.g. it wouldn't make
sense to wire in any conduit beans at all when the deferred conduit
selector is in use, as the whole idea here is to ensure that a conduit
isn't created until we're sure we really need it (as we would never do
so in the coloc case)
- ensuring the multiplicity of conduit beans configured alongside a
failover selector is consistent with the set of ports defined in the
WSDL, as the CXF static failover strategy is based on burning the
alternate ports into a multi-port service definition in the WSDL.
Cheers,
Eoghan
Daniel Kulp wrote:
I completely agree with MUCH of this. I'd love it if the jaxws:client
and jaxws:endpoint/server things had a:
type thing that would configure that. It's SLIGHTLY more complicated by
the presence of the conduit selector things in the client which allows
load balancing and such. However, that could be made even more
configurable with something like:
(default would be the current "Upfront" selector.)
Dan
On Sunday 05 October 2008, Christian Schneider wrote:
Hi Willem,
if I understand it right there is always one conduit for each client
or endpoint. So I would not try to reference a conduit config via the
endpoint name like it is done now. The conduit can as well be
described as a parameter of client or endpoint. I really do not like
the way the old JMSConduit configured itself. Extracting the
configuration should be outside of the object to be configured.
The way camel does this is ok. But instead of referencing a jms
configuration in the address line I would simply set it as a parameter
in client or endpoint. If you want to centralize certain parts of the
config spring still has the ref="" to reference a central config bean.
Additionally we can use abstract config beans so several jms
configurations can share some common parts.
By simply being a property of the client or endpoint they can simply
add it to the endpointInfo. So the TransportFactory can extract it and
set the Conduit or Destination with it.
Greetings
Christian
Willem Jiang schrieb:
You could take a look at the configuration of camel transport for
CXF. we inject the camel context (which could be an extension of
TransportConfig) into the CamelTransportFactory or the
{CamelConduit|CamelDestion}.
Endpoint can find the CamelTransportFactory by using the transport
id or transport perfix like 'camel:'. Each Conduit or Destination
configuration has its own id, when the endpoint find the transport
factory and create the conduit or destination, current CXF
configuration will call the 'configure' method which will seach the
spring context and configure the conduit or destination according
the bean id.
If you want to add the TransportConfig into the endpoint , we need
to hack the code of endpoint looking up the transport factory, and
set the TransportConfig into the transport factory or the
{conduit|destination}.
Any thoughts?
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
How to handle a configuration problem generally in CXF code
Hi all, when there is a problem with the configuration i currently throw a simple RuntimeException. I think this can be handled better. I have found a class ConfigurationException but it only accepts a message as i18 Message. Should this class be used? I do not like that much that it always needs a resource definition. Is internationalization for config errors that usefull? Whenever I got a german exception I had much problems trying to google for it. So I personally like english exceptions. Another possibility would be to throw an AssertionError. As it is for example an assertion that a certain property is not null. Any ideas? Greetings Christian -- Christian Schneider --- http://www.liquid-reality.de
Re: Proposal for a new JMS configuration for CXF
On Monday 06 October 2008, Eoghan Glynn wrote:
> - ensuring that the choice of conduit selector is validated against
> the presence or absence of fine-grained conduit beans, e.g. it
> wouldn't make sense to wire in any conduit beans at all when the
> deferred conduit selector is in use, as the whole idea here is to
> ensure that a conduit isn't created until we're sure we really need it
> (as we would never do so in the coloc case)
I think Christian's latest proposal covers this. In the "Upfront" case,
the Upfront bean can only contain a single conduit. The "RoundRobin"
would have a List of conduits, etc... Each selector would have it's
own configuration requirements. Spring could validate that the
requirements are met.
> - ensuring the multiplicity of conduit beans configured alongside a
> failover selector is consistent with the set of ports defined in the
> WSDL, as the CXF static failover strategy is based on burning the
> alternate ports into a multi-port service definition in the WSDL.
Well, this COULD actually remove that limitation. A FailoverSelector
could have a bunch of conduits configured via configuration (like
roundrobin) and failover from one to the other. Thus, the failover
stuff would work for code first cases much better. If the
FailoverSelector doesn't have any conduits coming in from spring, it
could use the multi-port strategy it currently uses.
Dan
>
> Cheers,
> Eoghan
>
> Daniel Kulp wrote:
> > I completely agree with MUCH of this. I'd love it if the
> > jaxws:client and jaxws:endpoint/server things had a:
> >
> >
> >
> >
> >
> > type thing that would configure that. It's SLIGHTLY more
> > complicated by the presence of the conduit selector things in the
> > client which allows load balancing and such. However, that could
> > be made even more configurable with something like:
> >
> >
> >
> >
> >
> >
> >
> >
> > (default would be the current "Upfront" selector.)
> >
> >
> >
> > Dan
> >
> > On Sunday 05 October 2008, Christian Schneider wrote:
> >> Hi Willem,
> >>
> >> if I understand it right there is always one conduit for each-
ensuring the multiplicity of conduit beans configured alongside a
failover selector is consistent with the set of ports defined in the
WSDL, as the CXF static failover str
> >> client or endpoint. So I would not try to reference a conduit
> >> config via the endpoint name like it is done now. The conduit can
> >> as well be described as a parameter of client or endpoint. I really
> >> do not like the way the old JMSConduit configured itself.
> >> Extracting the configuration should be outside of the object to be
> >> configured.
> >>
> >> The way camel does this is ok. But instead of referencing a jms
> >> configuration in the address line I would simply set it as a
> >> parameter in client or endpoint. If you want to centralize certain
> >> parts of the config spring still has the ref="" to reference a
> >> central config bean. Additionally we can use abstract config beans
> >> so several jms configurations can share some common parts.
> >>
> >> By simply being a property of the client or endpoint they can
> >> simply add it to the endpointInfo. So the TransportFactory can
> >> extract it and set the Conduit or Destination with it.
> >>
> >> Greetings
> >>
> >> Christian
> >>
> >> Willem Jiang schrieb:
> >>> You could take a look at the configuration of camel transport for
> >>> CXF. we inject the camel context (which could be an extension of
> >>> TransportConfig) into the CamelTransportFactory or the
> >>> {CamelConduit|CamelDestion}.
> >>>
> >>> Endpoint can find the CamelTransportFactory by using the transport
> >>> id or transport perfix like 'camel:'. Each Conduit or Destination
> >>> configuration has its own id, when the endpoint find the transport
> >>> factory and create the conduit or destination, current CXF
> >>> configuration will call the 'configure' method which will seach
> >>> the spring context and configure the conduit or destination
> >>> according the bean id.
> >>>
> >>> If you want to add the TransportConfig into the endpoint , we need
> >>> to hack the code of endpoint looking up the transport factory, and
> >>> set the TransportConfig into the transport factory or the
> >>> {conduit|destination}.
> >>>
> >>> Any thoughts?
>
>
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
--
J. Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: How to handle a configuration problem generally in CXF code
I try to get rid of naked RuntimeExceptions whenever I can. If a problem can be caused by user error or system config, it should throw a class of ours, and it should support I18N, as far as I've understood our conventions. On Mon, Oct 6, 2008 at 6:24 PM, Christian Schneider <[EMAIL PROTECTED] > wrote: > Hi all, > > when there is a problem with the configuration i currently throw a simple > RuntimeException. I think this can be handled better. > I have found a class ConfigurationException but it only accepts a message > as i18 Message. Should this class be used? I do not like that much that it > always needs a resource definition. > Is internationalization for config errors that usefull? Whenever I got a > german exception I had much problems trying to google for it. So I > personally like english exceptions. > Another possibility would be to throw an AssertionError. As it is for > example an assertion that a certain property is not null. > > Any ideas? > > Greetings > > Christian > > -- > > Christian Schneider > --- > http://www.liquid-reality.de > >
Re: Release manager for 2.1.3 and/or 2.0.9.....
Hi Dan, I just deployed a new snapshot of CXF 2.0.9 according the wiki page for testing my box's ssh and scp setting. Every thing is working, I am ready for cutting CXF 2.0.9 this week :) Willem Daniel Kulp wrote: Willem, Thanks for volunteering to do this. That's great. I think it would be good to do 2.0.9 late this week and probably 2.1.3 middle of next week. (need to do 2.0.x first due to an "issue" with the maven stage plugin which will update the "latest" tag in the metadata with 2.0.9 so 2.0.9 would get picked up instead of 2.1.2. Thus, we would want 2.1.3 shortly thereafter to restore a 2.1.x version as latest). I have a couple of fixes I'm going to try and get in to 2.1.x this week. We also should update to bouncycastle 140 and xalan 2.7.1 for both 2.1.3 and 2.0.9. With those versions, we can actually distribute bouncycastle and thus ws-security can work "out of the box" and not require downloading additional jars. Dan On Thursday 02 October 2008, Willem Jiang wrote: Hi Dan, I'd like to take charge of this CXF release. Since you and me met a year before, I will send you my key for signing :) Cheers, Willem On Fri, Oct 3, 2008 at 12:49 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases. It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2. We have 33 issues resolved for 2.0.9, and 38 for 2.1.3. Thus, we probably should consider doing some releases shortly. HOWEVER, my hard drive crashed this week and part of recovering from that, I kind of realized that someone else really should try doing a release to make sure the knowledge is spread out a bit and isn't all bottled up in my head.Thus, I'd like to ask for volunteers for doing the releases. If no one jumps up, I'll be happy to do it, but it would definitely be good to get someone else involved. Requirements: 1) The release process is MUCH easier and more reliable on a Linux or OSX box. Things like gpg and ssh/scp "just work". If someone want to try Windows, I'm not sure how much I can help. 2) gpg installed and a gpg key generated and available in the public key servers. Ideally, it would be signed by other apache folks, but that's not a requirment. Anyone near Boston, we could meet for lunch and sign keys if you want. 3) Time - before building the release, you need a few hours to review release notes, notice/license files, rat reports, etc Post release, there is syncing to the maven repo, updating confluence, some JIRA admin things, etc Basically, a few hours ahead of the build, an hour to build, three days for the vote, and a few hours afterword. Anyway, if anyone is interested, speak up. I'd be happy to look over your virtual shoulder while you do the stuff to make sure it's all done right. Not a problem. Thanks! -- J. Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
