Re: D-OSGi and REST
Even if you were able to solve the class file version, there's probably bigger problems with J2ME as AFAIK it doesn't support any of the Java 5 features yet (e.g. annotations) and is missing chunks of JSE 5 libraries that CXF uses. You can theoretically get CXF working on J2ME by retroweaving it (see http://www.osgi.org/wiki/uploads/CommunityEvent2007/OSGiCommunity-Roelofsen.pdf) but I'm not sure this is really suitable for an embedded device with constrained memory... Cheers, David 2009/9/28 Demetris demet...@ece.neu.edu Hi Sergey - no problem at all. Regarding the test I got the following exception once I started the single distribution on a J2ME-CDC device - equinox (as well as Knopflerfish_ run fine under J2ME but the dosgi throws java.lang.UnsupportedClassVersionError exceptions (showing only the small trace below) Thanks Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.5.0.v20090520 11 ACTIVE org.eclipse.osgi.services_3.2.0.v20090520-1800 12 RESOLVEDcxf-dosgi-ri-singlebundle-distribution_1.0.0 13 ACTIVE org.eclipse.osgi.util_3.2.0.v20090520-1800 osgi start 12 org.osgi.framework.BundleException: The activator org.apache.cxf.dosgi.singlebundle.AggregatedActivator for bundle cxf-dosgi-ri-singlebundle-distribution is invalid at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(Unknown Source) at java.lang.Thread.run(Unknown Source) at java.lang.Thread.startup(Unknown Source) Caused by: java.lang.UnsupportedClassVersionError: org/apache/cxf/dosgi/singlebundle/AggregatedActivator (Unsupported major.minor version 49.0) Sergey Beryozkin wrote: Hi no problems at all - your questions are welcome. I know DOSGi does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same lines. If you have any advice on this I would greatly appreciate it. Thanks and regards Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am
Default namespace and xsi:schemaLocation in response
Hi I am trying out a CXF sample. I need to ensure that the content in the SOAP response is valid as per an XSD. The response I get now looks like soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body Abcd xmlns:ns2=http://www.example.com/Schemas/myspace; ns2:Efgh kjml=1234 ... What I really need is as below. The addition being the xmlns, xmlns:xsi and xsi:schemaLocation attributes. soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Body Abcd xmlns:ns2=http://www.avienttech.com/Schemas/myspace xmlns=http://www.avienttech.com/Schemas/myspace; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation= http://www.avienttech.com/Schemas/myspace mysample.xsd ns2:Efgh kjml=1234 ... Any idea on how I can put in 1. The default namespace (xmlns) or ensure that the namespace prefix ns2 is applied on the root element also Eg: ns2:Abcd ...? 2. How can I specify the xmlns:xsi and xsi:schemaLocation attributes ? Thanks Sreejith DISCLAIMER: The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly contact the sender and destroy all copies of the original communication. IBS makes no warranty, express or implied, nor guarantees the accuracy, adequacy or completeness of the information contained in this email or any attachment and is not liable for any errors, defects, omissions, viruses or for resultant loss or damage, if any, direct or indirect.
Re: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup
I can't open the JIRA due to a timeout. Yes, I've seen Josh reporting a similar issue and I did verify I could start the cleanly build DOSGi distribution in Equinox 3.5. I'm just thinking, can it be an ordering issue ? In the bundles list you posted a JAXRS bundle is listed after a CXF DSW bundle. That probably should not make a difference but apparently java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) causes some early resolution ? Can you please uninstall CXF-DSW bundle and then install it again, so that it definitely has JAXRS classes available to it ? Another possibility is that some of the system bundles have say Jersey embedded ? thanks, Sergey - Original Message - From: Aaron Zeckoski (JIRA) j...@apache.org To: iss...@cxf.apache.org Sent: Tuesday, September 29, 2009 3:39 PM Subject: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup [ https://issues.apache.org/jira/browse/CXF-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated CXF-2452: Description: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); was: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup --- Key: CXF-2452 URL: https://issues.apache.org/jira/browse/CXF-2452 Project: CXF Issue Type: Bug Components: Distributed-OSGi Affects Versions: dOSGi-1.1 Environment: adz20:~ azeckoski$ java -version java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) Reporter: Aaron Zeckoski Priority: Critical Fix For: dOSGi-1.1 One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup
Actually, can you please reinstall [ 27] [Active ] [4] Apache CXF Bundle Jar (2.3.0.SNAPSHOT) and [ 29] [Resolved ] [4] CXF Distributed Software Bundle (1.1.0.SNAPSHOT) Oh...Apache CXF Bundle Jar (2.3.0.SNAPSHOT). It actually depends on jaxrs-api 1.1 now. I'm presuming you've replaced CXF-2.2.3 with the latest one. So then please uninstall [ 45] [Active ] [2] Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0) and install http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.1/ it should make a difference. cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Sent: Tuesday, September 29, 2009 3:52 PM Subject: Re: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup I can't open the JIRA due to a timeout. Yes, I've seen Josh reporting a similar issue and I did verify I could start the cleanly build DOSGi distribution in Equinox 3.5. I'm just thinking, can it be an ordering issue ? In the bundles list you posted a JAXRS bundle is listed after a CXF DSW bundle. That probably should not make a difference but apparently java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) causes some early resolution ? Can you please uninstall CXF-DSW bundle and then install it again, so that it definitely has JAXRS classes available to it ? Another possibility is that some of the system bundles have say Jersey embedded ? thanks, Sergey - Original Message - From: Aaron Zeckoski (JIRA) j...@apache.org To: iss...@cxf.apache.org Sent: Tuesday, September 29, 2009 3:39 PM Subject: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup [ https://issues.apache.org/jira/browse/CXF-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated CXF-2452: Description: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); was: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup --- Key: CXF-2452 URL: https://issues.apache.org/jira/browse/CXF-2452 Project: CXF Issue Type: Bug Components: Distributed-OSGi Affects Versions: dOSGi-1.1 Environment: adz20:~ azeckoski$ java -version java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) Reporter: Aaron Zeckoski Priority: Critical Fix For: dOSGi-1.1 One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Gmail thinks we're spam
Some JIRA emails are getting flagged as phishing due, I guess, to discrepancies between from and reply-to? Anyone else seeing this?
2.2.4 and 2.1.7
It's been just over 8 weeks since 2.2.3 and 2.1.6 went out. Thus, according to or normal schedule, we should be thinking about getting 2.2.4 and 2.1.7 out the door.August was kind of a slow month so the JIRA list is a bit smaller than normal, but there definitely have been a lot of good fixes and such that have gone in. I know Sergey has a few JAX-RS related issues he's looking into. I have a couple OSGi things I'm looking into. There are a couple JIRA bugs I'd like to get to as well if I get some time, but nothing too major so if I don't get to them, they can wait (unless someone attaches a patch hint hint :-). (If I can get the Open count down to 320, currently at 325, we'll have a net gain of 0 between 2.2.3 and 2.2.4. This would be the first time that has ever happened.) Are there any other major things that would be considered a hold up? Anyway, I'm thinking of doing the builds around the middle of next week. Probably Tuesday afternoon or Wednesday. Does that work for everyone? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: 2.2.4 and 2.1.7
Daniel Kulp wrote: It's been just over 8 weeks since 2.2.3 and 2.1.6 went out. Thus, according to or normal schedule, we should be thinking about getting 2.2.4 and 2.1.7 out the door.August was kind of a slow month so the JIRA list is a bit smaller than normal, but there definitely have been a lot of good fixes and such that have gone in. I know Sergey has a few JAX-RS related issues he's looking into. I have a couple OSGi things I'm looking into. There are a couple JIRA bugs I'd like to get to as well if I get some time, but nothing too major so if I don't get to them, they can wait (unless someone attaches a patch hint hint :-). (If I can get the Open count down to 320, currently at 325, we'll have a net gain of 0 between 2.2.3 and 2.2.4. This would be the first time that has ever happened.) Are there any other major things that would be considered a hold up? Anyway, I'm thinking of doing the builds around the middle of next week. Probably Tuesday afternoon or Wednesday. Does that work for everyone? Fine for me. Alessio -- Alessio Soldano Web Service Lead, JBoss
Re: JAXRS : moving to JAX-RS 1.1 api
I meant to send this message earlier on. I've updated the 2.3-SNAPSHOT (trunk only) to depend on the jax-rs api 1.1 two weeks ago. I'll create JIRA subtasks later on, but the 3 JAX-RS requirements have already been implemented earlier on (sorting of message body providers by type, support for a 'fromString' method plus new Request method). Should have it all supported in time for 2.3 (not sure about the optional EJB requirement though - will welcome contributions). More updartes to come later on. If you're playing with multi-bundle DOSGI distributions and replacing a shipped 2.2.3 bundle with 2.3-SNAPSHOT then please make sure http://repository.apache.org/snapshots/org/apache/servicemix/specs/org.apache.servicemix.specs.jsr311-api-1.1/1.4-SNAPSHOT/ is installed instead of org.apache.servicemix.specs.jsr311-api-1.0 A corresponding Maven dependency is here : dependency groupIdorg.apache.servicemix.specs/groupId artifactIdorg.apache.servicemix.specs.jsr311-api-1.1/artifactId version1.4-SNAPSHOT/version /dependency Sergey Hi, Now that we have CXF JAX-RS passing TCK for jax-rs 1.0 api, it's time to start thinking about updating the jax-rs api dependency to 1.1. The following changes might affect existing users : 1. javax.ws.rs.core.Response.Status.Family class has been removed and instead javax.ws.rs.core.Response.StatusType javax.ws.rs.core.Response.StatusType.Family have been added 2. As a result of 1, - public static javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response.status(javax.ws.rs.core.Response.Status) - public javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response.ResponseBuilder.status(javax.ws.rs.core.Response.Status) - public final javax.ws.rs.core.Response.Status.Family javax.ws.rs.core.Response.Status.getFamily() have been removed and instead - public static javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response.status(javax.ws.rs.core.Response.StatusType) - public javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response$ResponseBuilder.status(javax.ws.rs.core.Response.StatusType) - public final java.lang.String javax.ws.rs.core.Response.Status.getReasonPhrase() - public final javax.ws.rs.core.Response.StatusType.Family javax.ws.rs.core.Response.Status.getFamily() have been added. 3. new method javax.ws.rs.core.Response$ResponseBuilder javax.ws.rs.core.Request.evaluatePreconditions() has been added to Request interface So in summary: if you haven't used javax.ws.rs.core.Response.Status.Family or Response.status(Response.Status) or ResponseBuilder.status(Response.Status) then your application code won't be affected. If you have used Request helper befor then you'd only need to recompile but not change the code. Let me know please, by replying to this thread or pinging me on #cxf or directly if the above changes will affect you. If no users will have their (production) code affected then I see no reasons in postponing the move to jax-rs 1.1 api Thanks, Sergey [1] https://jsr311.dev.java.net/drafts/changelog.1.1.html
CXF-2275, CXF-2276, and the new sample.....
Christian, I've gone ahead and merged the changes for CXF-2275 and CXF-2276 onto 2.2.x since the changes are completely additive (shouldn't break anything) and I don't expect 2.3 to be ready for a little while (I know I don't have time to finish the stuff I was working on right now).These are great new things with little impact so getting them out is good, IMO. Are those JIRA's now resolvable or is there more work required? Mostly just curious. I'm also interested in hearing peoples thoughts about merging the new wsdl_first sample to 2.2.x. I know it will be a bit more work for me (Progress has some internal tests that test some of the samples to make sure they don't break and these changes will break those tests. Not a big deal.), but I have to make those changes for trunk testing anyway so not a big deal. The new sample really is MUCH nicer than the old one. I think getting it out there is probably a good thing.Thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Gmail thinks we're spam
No problem here. It's only some of the JIRA emails that get the big red bar. A certain percentage of emails from dkulp get marked as spam by gmail, from my experience. --oh
Re: Gmail thinks we're spam
On Tue September 29 2009 1:34:38 pm Oisin Hurley wrote: No problem here. It's only some of the JIRA emails that get the big red bar. A certain percentage of emails from dkulp get marked as spam by gmail, from my experience. Well, just goes to prove that I have nothing useful to say. :-) Hmm Maybe I'll need to subscribe my gmail address for a little while and see what it says. Never really used gmail much. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
