[jira] [Updated] (XBEAN-297) xbean-blueprint shall not import org.apache.aries.blueprint.ext.impl in its manifest
[ https://issues.apache.org/jira/browse/XBEAN-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated XBEAN-297: -- Affects Version/s: 4.4 > xbean-blueprint shall not import org.apache.aries.blueprint.ext.impl in its > manifest > > > Key: XBEAN-297 > URL: https://issues.apache.org/jira/browse/XBEAN-297 > Project: XBean > Issue Type: Bug >Affects Versions: 4.4, 4.5 >Reporter: Charlie Mordant >Priority: Blocker > > org.apache.aries.blueprint.ext.impl isn't exported by aries-blueprint (as it > is an internal package), but xbean-blueprint imports it. > So its impossible to bootstrap this jar. > Either tell the aries community to export this package, either fix this > issue... > Best Regards, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (XBEAN-297) xbean-blueprint shall not import org.apache.aries.blueprint.ext.impl in its manifest
[ https://issues.apache.org/jira/browse/XBEAN-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15654428#comment-15654428 ] Daniel Kulp commented on XBEAN-297: --- 4.2 works fine as it doesn't import this. > xbean-blueprint shall not import org.apache.aries.blueprint.ext.impl in its > manifest > > > Key: XBEAN-297 > URL: https://issues.apache.org/jira/browse/XBEAN-297 > Project: XBean > Issue Type: Bug >Affects Versions: 4.4, 4.5 >Reporter: Charlie Mordant >Priority: Blocker > > org.apache.aries.blueprint.ext.impl isn't exported by aries-blueprint (as it > is an internal package), but xbean-blueprint imports it. > So its impossible to bootstrap this jar. > Either tell the aries community to export this package, either fix this > issue... > Best Regards, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] release Apache Geronimo XBean-4.2
FYI:
This also fixes XBEAN-278 and XBEAN-279 which are impacting for ActiveMQ users
using blueprint.
Dan
On Mar 26, 2015, at 5:38 AM, Mark Struberg strub...@yahoo.de wrote:
+1
builds fine, md5 ok, rat ok, sha1 and cert fine.
txs and LieGrue,
strub
Am 25.03.2015 um 11:22 schrieb Romain Manni-Bucau rmannibu...@gmail.com:
Hi!
I'd like to release XBean 4.2 to be able to integrate it ASAP in the coming
tomee releases.
It fixes 2 impacting bugs: recursive algorithm (just fails for big jars) and
linkParent loosing parent annotations (regression in 4.0 release I think)
The staging repo is
https://repository.apache.org/content/repositories/orgapachegeronimo-1015/
The source jar can be found here:
https://repository.apache.org/content/repositories/orgapachegeronimo-1015/org/apache/xbean/xbean/4.2/
My key can be found at
https://svn.apache.org/repos/asf/geronimo/KEYS
please VOTE
[+1] all fine, ship it
[+0] don't care
[-1] stop, because ${reason}
here is my +1
Romain Manni-Bucau
@rmannibucau | Blog | Github | LinkedIn | Tomitriber
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: State of JAX-RS 2.0 spec
On Mar 24, 2015, at 10:24 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi bundle manifest is surely not correct - think nobody tested it in osgi yet Most likely cause those using JAX-RS 2.0 in OSGi are using the servicemix bundle: org.apache.servicemix.specs.jsr339-api-2.0 which is based on the reference impl jar. At least that’s what CXF is using. Dan but for other use cases it should be fine. Sources were written @apache (and just compared to the spec, not copied from the spec) so we shouldnt need to add the RI in the notice AFAIK. Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-24 13:18 GMT+01:00 Bernd e...@zusammenkunft.net: Hello, I noticed that the JAX-RS Spec Pom is not listed on the Maven site (http://geronimo.apache.org/maven/specs/index.html under Modules). When I look into the source repository I see in the POM that it puts 1.1 in the Bundle manifest and OSGi exports. So I wonder if this project is already production ready or abandoned. Another question, the NOTICE file does not mention anything about the source of the code. Is it typically decided that there is no need to mention the license of the spec PDFs or the RI files? Gruss Bernd -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Created] (XBEAN-278) Blueprint Namespace Handler improperly parsed flat-collections
Daniel Kulp created XBEAN-278: - Summary: Blueprint Namespace Handler improperly parsed flat-collections Key: XBEAN-278 URL: https://issues.apache.org/jira/browse/XBEAN-278 Project: XBean Issue Type: Bug Affects Versions: 4.1 Reporter: Daniel Kulp When parsing a flat collections, the fist item is processed correctly creating the MutableColectionMetadata and setting the childeMetadata to the listMeta which is then added to the bean. For subsequent items, item is added to the list correctly. However, the childeMetadata remains null (which is likely proper). However, at the end of the 'if/else' chain in XBeanNamespaceHandler, if childMeta is null, it creates another childMeta with the value of the element (likely an empty string). This causes beans to fail to be created. Patch coming soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (XBEAN-279) PropertyEditors called too soon
Daniel Kulp created XBEAN-279: - Summary: PropertyEditors called too soon Key: XBEAN-279 URL: https://issues.apache.org/jira/browse/XBEAN-279 Project: XBean Issue Type: Bug Affects Versions: 4.1 Reporter: Daniel Kulp In the Blueprint namespace handler, the PropertyEditors are called at parse time. This is different than Spring where the PropertyEditors are called at bean creation time. This is a problem as it prevents using PropertyPlaceholders for valued that would go through the PropertyEditors. Patch coming. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISUCSS] release alpha-1 versions of a few EE7 artifacts?
We currently do not have any current license agreement or other document/contract placing any such restriction on version numbers or releases. Feel free to release them as whatever version number you want or feel is appropriate. Dan On Aug 26, 2014, at 6:22 AM, Mark Struberg strub...@yahoo.de wrote: Hi! The JavaEE license allows to release preliminary versions of spec artifacts as long as they are appropriately marked. We need those in a public repo to continue our work on OpenWebBeans-2.x, BVal-1.1.x and TomEE-2.x. And of course probably Geronimo4 ;) I've now identified the following candidates: * geronimo-annotation_1.2_spec * geronimo-jcdi_1.1_spec * geronimo-interceptor_1.2_spec * geronimo-concurrent_1.0_spec what postfix shall I take? -RC-1 -alpha-1 ? LieGrue, strub -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release stax-api-1.2 spec v 1.2
+1 (non-binding) This is a big problem as underlying causes (like IOExceptions and such) are lost which makes various issues hard to debug and resolve. Dan On Nov 27, 2013, at 11:04 AM, Guillaume Nodet gnodet.apa...@gmail.com wrote: I've uploaded a release at https://repository.apache.org/content/repositories/orgapachegeronimo-014/ to fix the following issue: https://issues.apache.org/jira/browse/GERONIMO-6509 Please review and vote, Cheers, Guillaume -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Created] (GERONIMO-6509) XMLStreamException not calling super(th) in constructors
Daniel Kulp created GERONIMO-6509: - Summary: XMLStreamException not calling super(th) in constructors Key: GERONIMO-6509 URL: https://issues.apache.org/jira/browse/GERONIMO-6509 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: specs Reporter: Daniel Kulp The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or super(msg, th) for the constructors that take a throwable. There are two problems this causes: 1) The cause is never set so the exception.getCause() always returns null and potentially important information in the cause is discarded. 2) For the super(th) one, no message is set at all.Thus, all information that could be useful is lost unless I specifically cast the exception to an XMLStreamException and call the getNestedException(). Any generic exception handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (GERONIMO-6509) XMLStreamException not calling super(th) in constructors
[ https://issues.apache.org/jira/browse/GERONIMO-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833856#comment-13833856 ] Daniel Kulp commented on GERONIMO-6509: --- FactoryConfigurationError has the same problem XMLStreamException not calling super(th) in constructors -- Key: GERONIMO-6509 URL: https://issues.apache.org/jira/browse/GERONIMO-6509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Reporter: Daniel Kulp The XMLStreamException in spec stax-api 1.2 is not calling the super(th) or super(msg, th) for the constructors that take a throwable. There are two problems this causes: 1) The cause is never set so the exception.getCause() always returns null and potentially important information in the cause is discarded. 2) For the super(th) one, no message is set at all.Thus, all information that could be useful is lost unless I specifically cast the exception to an XMLStreamException and call the getNestedException(). Any generic exception handling mechanism would not be able to provide a useful error message. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: migration of web site to svnpubsub
On Jan 2, 2013, at 5:25 PM, Jarek Gawor jga...@gmail.com wrote: Dan, Yes, I was planning to do that once I had a bit more confidence in the modified export code. Btw, do you know how to deal with static files that are not exported from wiki? We have some additional files such as schema files, etc. that we need to publish on the web site. Just checkout the target area and add them. Things like javadocs, schemas, images, css files, etc… would all need to be handled that way. Dan Thanks, Jarek On Tue, Dec 18, 2012 at 2:38 PM, Daniel Kulp dk...@apache.org wrote: Jarek, I would highly suggest that we try and keep all the changes to the exporter together someplace (currently in CXF's repo, but we could move it, although since you are a committer there, likely not needed to move).If/when infrastructure updates the confluence version from 3.4 to 4.x, the exporter WILL need to be updated as the SOAP API's that we use have changed quite a bit in 4.x.If we keep all the changes together in one place, we'll only need to update it in one place instead of scattered throughout all the projects. Dan On Dec 18, 2012, at 2:26 PM, Jarek Gawor jga...@gmail.com wrote: I did some experiments with both approaches: 1) convert to Apache CMS, and 2) use Dan's site-export tool. I got a lot further with Dan's tool. I modified his code a bit so that it works with our existing templates (no need to modify our templates). However, there are at least two things that don't work right (yet): a) exporting news items / blogs, and b) cross wiki space links. I think I can fix b) but I'm not sure about a). Anyway, I just checked the wiki exporter code into https://svn.apache.org/repos/asf/geronimo/site/trunk/wiki-export. There is a README file that explains how to get things going. You will also need the templates from https://svn.apache.org/repos/asf/geronimo/site/trunk/template Jarek On Fri, Dec 14, 2012 at 10:16 AM, Jarek Gawor jga...@gmail.com wrote: I think we need a short and long term solution. For the short term solution let's try Dan's approach and see if that can work for us. Otherwise, we will loose web site updates on the 1st. For the long term solution we can consider switching to CMS or at least getting a clarification from the infra team if we can continue to use the cwiki for the website. We do have a lot of pages so switching to CMS might be challenging but we might have no choice (sooner or later). Jarek On Fri, Dec 14, 2012 at 2:37 AM, Mark Struberg strub...@yahoo.de wrote: I suggest using the new CMS. You can still use svnpubsub for static content. There is now even a maven plugin in the making for automated svnpubsub. We've now moved over quite some pages using bootstrap. http://openwebbeans.staging.apache.org/ http://bval.staging.apache.org/ http://incubator.apache.org/deltaspike/ http://tomee.apache.org/ Still trying to figure how doing things like 'News' teasers on the landing page, etc... LieGrue, strub From: Shawn Jiang genspr...@gmail.com To: dev@geronimo.apache.org Sent: Friday, December 14, 2012 3:46 AM Subject: Re: migration of web site to svnpubsub I would like to use method described here[1] to render the confluence pages locally and then publish them to svnpubsub . So that we can still work with confluence without learning a new CMS system. [1]http://www.dankulp.com/blog/2012/03/svnpubsub-for-confluence-sites/ On Mon, Dec 10, 2012 at 11:36 PM, Kevan Miller kevan.mil...@gmail.com wrote: All, rsync-based updates of the geronimo web site will be frozen in January (very soon). We must migrate to svnpubsub (and optionally CMS) in order to have a website that we can change (seems like something we'd like to have). For more information, see -- http://www.apache.org/dev/project-site.html I'm going to have very limited time to do any work on this. Any volunteers? --kevan -- Shawn -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: migration of web site to svnpubsub
Jarek, I would highly suggest that we try and keep all the changes to the exporter together someplace (currently in CXF's repo, but we could move it, although since you are a committer there, likely not needed to move).If/when infrastructure updates the confluence version from 3.4 to 4.x, the exporter WILL need to be updated as the SOAP API's that we use have changed quite a bit in 4.x.If we keep all the changes together in one place, we'll only need to update it in one place instead of scattered throughout all the projects. Dan On Dec 18, 2012, at 2:26 PM, Jarek Gawor jga...@gmail.com wrote: I did some experiments with both approaches: 1) convert to Apache CMS, and 2) use Dan's site-export tool. I got a lot further with Dan's tool. I modified his code a bit so that it works with our existing templates (no need to modify our templates). However, there are at least two things that don't work right (yet): a) exporting news items / blogs, and b) cross wiki space links. I think I can fix b) but I'm not sure about a). Anyway, I just checked the wiki exporter code into https://svn.apache.org/repos/asf/geronimo/site/trunk/wiki-export. There is a README file that explains how to get things going. You will also need the templates from https://svn.apache.org/repos/asf/geronimo/site/trunk/template Jarek On Fri, Dec 14, 2012 at 10:16 AM, Jarek Gawor jga...@gmail.com wrote: I think we need a short and long term solution. For the short term solution let's try Dan's approach and see if that can work for us. Otherwise, we will loose web site updates on the 1st. For the long term solution we can consider switching to CMS or at least getting a clarification from the infra team if we can continue to use the cwiki for the website. We do have a lot of pages so switching to CMS might be challenging but we might have no choice (sooner or later). Jarek On Fri, Dec 14, 2012 at 2:37 AM, Mark Struberg strub...@yahoo.de wrote: I suggest using the new CMS. You can still use svnpubsub for static content. There is now even a maven plugin in the making for automated svnpubsub. We've now moved over quite some pages using bootstrap. http://openwebbeans.staging.apache.org/ http://bval.staging.apache.org/ http://incubator.apache.org/deltaspike/ http://tomee.apache.org/ Still trying to figure how doing things like 'News' teasers on the landing page, etc... LieGrue, strub From: Shawn Jiang genspr...@gmail.com To: dev@geronimo.apache.org Sent: Friday, December 14, 2012 3:46 AM Subject: Re: migration of web site to svnpubsub I would like to use method described here[1] to render the confluence pages locally and then publish them to svnpubsub . So that we can still work with confluence without learning a new CMS system. [1]http://www.dankulp.com/blog/2012/03/svnpubsub-for-confluence-sites/ On Mon, Dec 10, 2012 at 11:36 PM, Kevan Miller kevan.mil...@gmail.com wrote: All, rsync-based updates of the geronimo web site will be frozen in January (very soon). We must migrate to svnpubsub (and optionally CMS) in order to have a website that we can change (seems like something we'd like to have). For more information, see -- http://www.apache.org/dev/project-site.html I'm going to have very limited time to do any work on this. Any volunteers? --kevan -- Shawn -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Created] (GERONIMO-6394) saaj factories swollow the exceptions
Daniel Kulp created GERONIMO-6394:
-
Summary: saaj factories swollow the exceptions
Key: GERONIMO-6394
URL: https://issues.apache.org/jira/browse/GERONIMO-6394
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: specs
Reporter: Daniel Kulp
Attachments: patch.txt
The various factories in the SAAJ specs jar do something like:
{code}
throw new SOAPException(exception.getMessage());
{code}
which causes just the message to propagate and not the full exception. If the
cause is something like an NPE, it's very hard to diagnose and fix. Would
suggest using:
{code}
throw new SOAPException(exception.getMessage(), exception);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-6394) saaj factories swollow the exceptions
[
https://issues.apache.org/jira/browse/GERONIMO-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated GERONIMO-6394:
--
Attachment: patch.txt
saaj factories swollow the exceptions
-
Key: GERONIMO-6394
URL: https://issues.apache.org/jira/browse/GERONIMO-6394
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: specs
Reporter: Daniel Kulp
Attachments: patch.txt
The various factories in the SAAJ specs jar do something like:
{code}
throw new SOAPException(exception.getMessage());
{code}
which causes just the message to propagate and not the full exception. If
the cause is something like an NPE, it's very hard to diagnose and fix.
Would suggest using:
{code}
throw new SOAPException(exception.getMessage(), exception);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-152) xbean-blueprint should use version range for slf4j import
xbean-blueprint should use version range for slf4j import -- Key: XBEAN-152 URL: https://issues.apache.org/jira/browse/XBEAN-152 Project: XBean Issue Type: Improvement Affects Versions: 3.7 Reporter: Daniel Kulp The latest xbean-blueprint snapshot uses an exact version of 1.5 for org.slf4j. It would be nice to change that to [1.5,2) so that slf4j 1.6 will work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (XBEAN-150) OSGI imports for xbean-blueprint need some updates to better support equinox
OSGI imports for xbean-blueprint need some updates to better support equinox Key: XBEAN-150 URL: https://issues.apache.org/jira/browse/XBEAN-150 Project: XBean Issue Type: Bug Affects Versions: 3.7 Reporter: Daniel Kulp The imports for xbeans-blueprint has two issues: javax.script is required. I believe this can and should be marked optional. org.osgi.service.cm is marked as requiring version 1.3.0. However, I THINK this could be changed to [1.2,1.4) or similar. The main issue is that the version that equinox provides for Helios is 1.2.1. Thus, xbeans-blueprint won't really work with equinox without adding additional/new/updated osgi system level stuff which people may be hesitant to do. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Does Geronimo support JSON binding?
On Friday 02 July 2010 11:21:49 pm LinGong wrote: Hi, I've add @Webservice annotation on the stateless session bean. But I need to use JSON as the transport format. So I add @BindingType(JSONBindingID.JSON_BINDING) on the same session bean(I add the jaxws-json-1.2.jar to the lib dir for the server.). But this will cause error when deploy to the server. It certainly wouldn't work that way with Geronimo. The JSONBindingID.JSON_BINDING and jaxws-json-1.2.jar is very specific to the JAX-WS RI stuff from Sun with Geronimo doesn't use. With geronimo, you would either be using Axis2 or CXF and how you would enable JSON for either of those would be very different. I know with CXF, outside of Geronimo, you can configure in the Jettison Stax stuff to support JSON. There is some info at: http://cxf.apache.org/docs/json-support.html I'm not sure how that would apply to the way CXF is integrated into Geronimo. Dan RestaurantBean did not start because Could not resolve a binding for https://jax-ws-commons.dev.java.net/json/ Does any one know whether Geronimo support JSON format or not. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: [Question] Why SAAJ RI in trunk?
On Tuesday 01 June 2010 9:23:54 am Jack Cai wrote: We depend on SAAJ RI instead of axis2-saaj. I think axis2-saaj implements SAAJ 1.3, which are used in Geronimo 2.1 (Java EE 5). And I thought Java EE 6 still requires SAAJ 1.3. Can someone shed some light here? Doesn't trunk require Java6? If so, why depend on SAAJ at all? Just use the version built into the JDK. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Web services in G 3.0-M1
On a related note, but not to influence this at all, I just wanted to mention that CXF has been making pretty good progress on getting JAX-WS 2.2 working. The wsdl2java and java2wsdl things are now pretty solid and over 90% of the remaining failures are related to WS-Addressing stuff. I'm hoping to have much of those working next week. It would be good if someone could get the J2EE webservices TCK's up and running with it to see how things look there. We know from experience that the J2EE TCK's are significantly different from the standalone TCK's so having some validation would be great. Dan On Friday 21 May 2010 6:07:27 am Rick McGuire wrote: Jarek Gawor brought to my attention that the web services support in 3.0 has not yet gotten any testing or attention. While it builds, it is in a state where it doesn't really work. Since the focus of the M1 release is on the new Aries support and the Java EE 6 Web Profile, I think it makes sense to remove the web services components from the M1 release. Web services are not part of the Web Profile, so including them in the 3.0 Web Profile release was a bit of a stretch goal to begin with. Since this support might not be in the 3.0 final release and isn't really functional at this point anyway, I'm going to be removing the web services support from the M1 branch. Rick -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Maven compiler endorsed libraries
On Friday 02 April 2010 2:08:44 pm Jarek Gawor wrote: Hi, We need to find a way to make the compiler in Maven to load certain libraries as endorsed libraries. I know this has been discussed before but do we have some specific solutions for this problem? We will need to deal with this fairly soon now - for example to implement the @Resource.lookup support. Not that I know of. I never got around to actually working on it. :-( -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Remove Stax API or wstx-asl ?
On Wednesday 24 March 2010 9:44:12 pm Ivan wrote: Hi, Just trying the latest Geronimo 3.0 build, get a CNF exception for the XMLInputFactory, seems that wstx-asl shipped is not a bundle. I am thinking that since JRE 1.6 contains the API and the default implementation, do we still need to ship another one ? Well, I would say get rid of stax-api, but keep wstx. I think the 4.x versions of woodstox are bundles. If not, ServiceMix has bundles for them. The parser in the JDK sucks from a performance standpoint. We recently tried to use the JDK parser in CXF and the complete test run took nearly 25% longer. Adding woodstox back in brought it right back down to the normal times. Testing on real web services backed that up. Basically, the in JDK Stax parser will work, but woodstox is so much faster. If you aren't doing anything performance critical with XML, not using woodstox might be OK. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
[jira] Commented: (GERONIMO-5095) Create JAX-RS spec jar
[ https://issues.apache.org/jira/browse/GERONIMO-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12840132#action_12840132 ] Daniel Kulp commented on GERONIMO-5095: --- It's being done in the CXF sandbox which every Apache committer has access to. If you want to jump in and help, that would be great! http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxrs_1.0_spec/ Create JAX-RS spec jar --- Key: GERONIMO-5095 URL: https://issues.apache.org/jira/browse/GERONIMO-5095 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: javaee6, specs Affects Versions: 3.0 Reporter: Rick McGuire Assignee: Rex Wang Fix For: 3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5097) Integrate CXF JAX-RS implementation into Geronimo.
Integrate CXF JAX-RS implementation into Geronimo. -- Key: GERONIMO-5097 URL: https://issues.apache.org/jira/browse/GERONIMO-5097 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: Daniel Kulp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: cxf bundles
On Thu January 14 2010 3:25:23 am David Jencks wrote: On Jan 13, 2010, at 11:44 PM, David Jencks wrote: 1. is there a need for the 2 tools jars to be in the same bundle as the minimal bundle? Maybe we could use minimal + the other two jars individually bundleized. 2. do the other jars in the minimal bundle provide generally useful functionality? 3. how much is exposed unnecessarily if the individual jars were bundleized? this would be nothing if we had a core bundle with everything else fragment bundles. When we started doing OSGi related stuff in CXF, we DIDN'T go down the route of bundles fragments because, at the time, Felix didn't support them at all and the support in Equinox was only partially there. Basically, not something we could rely on. Since we already had the big bundle jar (users wanted that), we just added the OSGi stuff to there. I would LOVE some help doing the fragment thing if that is now working in the various OSGi containers. Dan thanks david jencks 4. Have we approached cxf about creating the appropriate bundles there? Its pretty unlikely we will be ready to release g 3 before they do another release. thanks david jenkcs On Jan 13, 2010, at 7:30 PM, Rex Wang wrote: Hi I am looking into GERONIMO-5016 Enable cxf in Geronimo 3.0. There is an issue I think need discuss first before I drive further. Not like axis, the cxf community did not release their jars as a bundle. Instead they made 2 separate distributions named cxf- bundle and cxf-bundle-minimal to contain the different set of their components. For instance: The cxf-bundle-minimal bundle contains 17 components: cxf-common-utilities cxf-common-schemas cxf-api cxf-rt-core cxf-rt-transports-http cxf-rt-transports-http-jetty cxf-rt-transports-jms cxf-rt-bindings-soap cxf-rt-databinding-aegis cxf-rt-databinding-jaxb cxf-rt-frontend-jaxws cxf-rt-frontend-simple cxf-rt-databinding-xmlbeans cxf-rt-ws-security cxf-rt-ws-policy cxf-rt-ws-addr cxf-rt-ws-rm but what we need are just following 13: cxf-api cxf-common-utilities cxf-rt-core cxf-rt-bindings-xml cxf-rt-bindings-soap cxf-rt-databinding-jaxb cxf-rt-frontend-jaxws cxf-rt-frontend-simple cxf-rt-transports-http cxf-rt-ws-addr cxf-rt-ws-security cxf-tools-common cxf-tools-java2ws You can see the cxf-tools-common cxf-tools-java2ws are not included by cxf-bundle-minimal. The cxf-bundle contains all the 13 components we need, but it will import a great many other components, which will not only bring a lot of jobs to exclude un-necessary jars when build our cxf plugins, but also increase the size of new G3.0. So I see 2 ways to pull cxf bundles in: 1. Use the cxf-bundle-minimal and make a new private bundle that contains cxf-tools-common cxf-tools-java2ws in Geronimo. 2. Make a private cxf bundle customized by ourselves which only contains the above 13 packages I suggest the approach #2. Any comments? Thanks -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: cxf bundles
On Thu January 14 2010 2:44:51 am David Jencks wrote: 1. is there a need for the 2 tools jars to be in the same bundle as the minimal bundle? Maybe we could use minimal + the other two jars individually bundleized. I'm trying to figure out why the two tool jars are even needed in the osgi runtime at all. Those are for the command line tooling so I'm really at a loss as to why they would be needed in the container. 2. do the other jars in the minimal bundle provide generally useful functionality? IMO. Yes, especially with CXF 2.3 which we hope to get out this quarter. 1) cxf-rt-ws-policy - you really don't want cxf-rt-ws-security without this one. Doing ws-security with SecurityPolicy is much easier and the policy stuff requires this jar. 2) cxf-rt-transports-jms - with 2.3, this will bring full SOAP over JMS spec compliance. 3) cxf-common-schemas - I personally thought this was required for anything in CXF to work. The fact that you have something working without it actually surprises me. :-)It's certainly needed in some cases if schema validation is turned on. 4) http-jetty - you're probably correct in that this wouldn't be required for you. It's small though. I believe the osgi imports for stuff it needs are marked optional. I think with 2.2.6, there is also http-osgi which uses the OSGi http stuff. 5) cxf-rt-databinding-xmlbeans/aegis - not required for JAX-WS compliance. Semi useful though. With 2.3, changing from JAXB to one of the others is just a matter of adding a @DataBinding annotation. No config or anything. That said, I'm not sure why xmlbeans is in the minimal bundle. Probably shouldn't be. Aegis is needed for DOSGi which uses the minimal bundle. 2.3 also adds an SDO databinding, but again, shouldn't be in minimal. 6) ws-rm - I'm honestly not sure why this is in the minimal bundle at all. It shouldn't be. In anycase, fragments would be good if someone knowledgeable in the area would like to help out with that. 3. how much is exposed unnecessarily if the individual jars were bundleized? Unfortunately, they cannot be until we completely refactor things which would break compatibility and not something we can really do until 3.0. Bundle fragments are a possibility. 4. Have we approached cxf about creating the appropriate bundles there? Its pretty unlikely we will be ready to release g 3 before they do another release. We definitely could. I really need to start a discussion about the minimal bundle though. It's growing with each release and it's now not much different than the full bundle.2.2.6 actually adds JAX-RS in there as well. Not really minimal anymore. :-( Dan thanks david jenkcs On Jan 13, 2010, at 7:30 PM, Rex Wang wrote: Hi I am looking into GERONIMO-5016 Enable cxf in Geronimo 3.0. There is an issue I think need discuss first before I drive further. Not like axis, the cxf community did not release their jars as a bundle. Instead they made 2 separate distributions named cxf-bundle and cxf-bundle-minimal to contain the different set of their components. For instance: The cxf-bundle-minimal bundle contains 17 components: cxf-common-utilities cxf-common-schemas cxf-api cxf-rt-core cxf-rt-transports-http cxf-rt-transports-http-jetty cxf-rt-transports-jms cxf-rt-bindings-soap cxf-rt-databinding-aegis cxf-rt-databinding-jaxb cxf-rt-frontend-jaxws cxf-rt-frontend-simple cxf-rt-databinding-xmlbeans cxf-rt-ws-security cxf-rt-ws-policy cxf-rt-ws-addr cxf-rt-ws-rm but what we need are just following 13: cxf-api cxf-common-utilities cxf-rt-core cxf-rt-bindings-xml cxf-rt-bindings-soap cxf-rt-databinding-jaxb cxf-rt-frontend-jaxws cxf-rt-frontend-simple cxf-rt-transports-http cxf-rt-ws-addr cxf-rt-ws-security cxf-tools-common cxf-tools-java2ws You can see the cxf-tools-common cxf-tools-java2ws are not included by cxf-bundle-minimal. The cxf-bundle contains all the 13 components we need, but it will import a great many other components, which will not only bring a lot of jobs to exclude un-necessary jars when build our cxf plugins, but also increase the size of new G3.0. So I see 2 ways to pull cxf bundles in: 1. Use the cxf-bundle-minimal and make a new private bundle that contains cxf-tools-common cxf-tools-java2ws in Geronimo. 2. Make a private cxf bundle customized by ourselves which only contains the above 13 packages I suggest the approach #2. Any comments? Thanks -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
[jira] Commented: (GERONIMO-5023) jaxws spec jar has wrong version number for its package exports.
[ https://issues.apache.org/jira/browse/GERONIMO-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799212#action_12799212 ] Daniel Kulp commented on GERONIMO-5023: --- IMO, the osgi stuff should be removed from the geronimo specs jaxws jars as the resulting bundles are not usable in OSGi due to the SPI provider lookup mechanism. ServiceMix has had to rebundle the jaxws-api jar (and a couple others) with a different lookup mechanism that is compatible with OSGi. I would recommend either: 1) Using the ServiceMix versions 2) Merge the ServiceMix changes into the geronimo-specs versions to actually make them usable. jaxws spec jar has wrong version number for its package exports. -- Key: GERONIMO-5023 URL: https://issues.apache.org/jira/browse/GERONIMO-5023 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Rick McGuire Priority: Critical The current version of the geronimo-jaxws_2.1_spec jar implements the 2.1.1 version of the APIs but the package exports are for the 2.1 release. This is causing a problems for OSGi projects that wish to use this API (e.g., the OSGi RFC 66 reference implementation). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Remove those specs and impl which are shipped by JRE 1.6
On Thu December 3 2009 10:51:18 am Jarek Gawor wrote: Actually, Java EE 6 dictates which version of the specs we will need to support. For example, Java EE 6 requires JAX-WS 2.2 and JAXB 2.2 but Sun JDK 6 ships with JAX-WS 2.1 and JAXB 2.1 at this point. And it used to be that Sun JDK 6 (_03 and less) shipped with JAX-WS 2.0 and JAXB 2.0. So we can't really rely on the JVM to provide the right set of APIs and instead we need to go with what EE spec requires. All of which, BTW, is going to be a huge pain to get setup correctly due to the newer versions that JEE needs having to be endorsed. This is tricky to do in maven right now. I started a conversation last month about it: http://mail-archives.apache.org/mod_mbox/maven-dev/200911.mbox/200911091655.17311.dk...@apache.org but haven't had any time to start working on the maven side of things. Dan Jarek On Thu, Dec 3, 2009 at 1:25 AM, Ivan xhh...@gmail.com wrote: Hi, Since Geronimo 3.0 could only run 1.6+, I think we do not need to keep those spec APIs and impl which are shipped by JRE, including JAXB API, JAXB Impl, JAXWS, etc. If no objection, I would try to remove them from our dependency tree. Any comment ? -- Ivan -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Where do the javax.wsdl classes come from?
On Thu October 22 2009 8:23:00 am Rick McGuire wrote: Yep, found the answer about 30 seconds ago myself. Looks like this is another package where we need to switch to a bundlized version. A bundlized version of 1.6.2 is being voted on in servicemix right now. Dan Rick Davanum Srinivas wrote: they are in the wsdl4j jar -- dims On 10/22/2009 08:13 AM, Rick McGuire wrote: The tomcat plugin has a dependency on the webservices plugin. I've managed to get the webservices plugin to build cleanly, but when building tomcat, I'm getting the following resolution error: [INFO] did not find geronimo-plugin.xml for bundle [80] [WARN] Could not start bundle: org.apache.geronimo.modules.geronimo-webservices [79] org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.g eronimo.modules.geronimo-webservices [79]: package; (package=javax.wsdl) org.apache.felix.framework.Felix.resolveBundle(Felix.java:3263) org.apache.felix.framework.Felix.startBundle(Felix.java:1597) org.apache.felix.framework.BundleImpl.start(BundleImpl.java:915) org.apache.felix.framework.BundleImpl.start(BundleImpl.java:902) org.apache.geronimo.system.configuration.DependencyManager.installed(Dep ende ncyManager.java:102) org.apache.geronimo.system.configuration.DependencyManager.bundleChanged (Dep endencyManager.java:70) org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCall back (EventDispatcher.java:800) Where do we pick up the javax.wsdl classes from? I'm not finding them anywhere in specs. Are these picked up from the jre also and require a something similar to the fix for javax.transaction? Rick -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: svn commit: r805830 - bouncycastle depend added?
eronimo/cxf/client/CXFPortMethodInterceptor.java Wed Aug 19 15:05:31 2009
@@ -41,6 +41,10 @@
private static final String IN_PREFIX = wss4j.in.;
private static final String OUT_PREFIX = wss4j.out.;
+private static final String[] ACTIONS = {
WSHandlerConstants.USERNAME_TOKEN, +
WSHandlerConstants.SIGNATURE, +
WSHandlerConstants.ENCRYPT }; +
public CXFPortMethodInterceptor(MapObject, EndpointInfo
seiInfoMap) { super(seiInfoMap);
}
@@ -98,20 +102,27 @@
private static void updateSecurityProperties(MapString, Object
properties) { String action = (String)
properties.get(WSHandlerConstants.ACTION); -if
(containsValue(action, WSHandlerConstants.USERNAME_TOKEN) +if
(containsValue(action, ACTIONS)
!properties.containsKey(WSHandlerConstants.PW_CALLBACK_CLASS)) { -
String password = (String) properties.get(password); -
properties.put(WSHandlerConstants.PW_CALLBACK_REF,
- new CXFPasswordHandler(password));
+CXFPasswordHandler handler = new CXFPasswordHandler();
+handler.addPassword( (String) properties.get(user),
+ (String) properties.get(password) );
+handler.addPassword( (String)
properties.get(signatureUser), +
(String) properties.get(signaturePassword) ); +
handler.addPassword( (String) properties.get(encryptionUser), +
(String) properties.get(encryptionPassword) );
+properties.put(WSHandlerConstants.PW_CALLBACK_REF, handler);
}
}
-private static boolean containsValue(String property, String value)
{ +private static boolean containsValue(String property, String[]
values) { if (property != null) {
String[] entries = property.split( );
-for (String entry : entries) {
-if (value.equals(entry)) {
-return true;
+for (String value : values) {
+for (String entry : entries) {
+if (value.equals(entry)) {
+return true;
+}
}
}
}
Modified: geronimo/server/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=805830r1=
805829r2=805830view=diff
=
= --- geronimo/server/trunk/pom.xml (original)
+++ geronimo/server/trunk/pom.xml Wed Aug 19 15:05:31 2009
@@ -754,7 +754,13 @@
dependency
groupIdxalan/groupId
artifactIdxalan/artifactId
-version2.7.0/version
+version2.7.1/version
+exclusions
+exclusion
+groupIdxml-apis/groupId
+artifactIdxml-apis/artifactId
+/exclusion
+/exclusions
/dependency
dependency
@@ -1876,17 +1882,9 @@
artifactIdsaaj-api/artifactId
/exclusion
exclusion
-groupIdbouncycastle/groupId
-artifactIdbcprov-jdk15/artifactId
-/exclusion
-exclusion
groupIdorg.opensaml/groupId
artifactIdopensaml/artifactId
/exclusion
-exclusion
-groupIdxalan/groupId
-artifactIdxalan/artifactId
-/exclusion
/exclusions
/dependency
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: [soap:Fault] faultstringpwd == null but a password is needed/faultstring
(ClientImpl.java:469) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:299) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:251) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) ... 28 more Can you please let me know or correct me, why this is happening?, I think if password is set correctly in the pwcb.setPassword(passwd); then client should be able to access the secure web service. I am getting the correct password manager (as seen in the logs) and setting the same but I dont know why I am getting this fault. Second thing is, I am not sure what to do with subject? Am I missing something in the above code? Please correct me and help me in this. Many Thanks in advance for your response. Regards, Rahul -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: javax.ws.xml.Holder not serializable
On Tue June 30 2009 11:38:35 am Kurt T Stam wrote: Thanks for going to test this Jarek. It sounds like I would need to being this up with JCP-224 then. I'm pretty sure you won't like the answer. :-) Basically, the jcp224/jaxws folks (and the jaxb folks), at one point long ago, specifically decided against making things Serializable since the Serializable symantics are not honored by the XML serialization. (example: field marks transient would still be written to XML) Anyway, for the most part, it was a conscious decision. While that decision may or may not apply to the Holder objects, it wouldn't surprise me at all if they say something along those lines. In anycase, it's definitely not something that would change for JAX-WS 2.0/2.1/2.2 so you would be looking at something at LEAST a year away, probably more, which probably doesn't help you now. Dan --Kurt Jarek Gawor wrote: Kurt, I'm pretty sure that's what the spec mandates. I can test this out to see if it breaks the TCK signature tests but even if it doesn't you might still run into that problem on Java 6 or later since the javax.xml.ws API are now provided by the JVM. However, I think you could override these JVM API by placing the Geronimo spec jar into the JVM's lib/endorsed directory. I'll test this out and let you know. Jarek On Mon, Jun 29, 2009 at 7:56 PM, Kurt T Stamkurt.s...@gmail.com wrote: Hi guys, On the jUDDI project one of our APIs uses the javax.ws.xml.Holder class (which contains jUDDI specific data classes). We have a requirement to send the entire Holder class over RMI, but Holder is not Serializable. I think this is a short coming of the implementation. http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxws_2.2_ spec/src/main/java/javax/xml/ws/Holder.java If you agree can this be fixed? Or do you believe that the spec dictates this? Thx, --Kurt kstam at apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Need Help: WS-Security Support for CXF in Geronimo (UsernameToken property setting)
)
at
org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:600) at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte
rceptor.handleMessage(MessageSenderInterceptor.java:62) at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai
n.java:226) at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:469) at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:299) at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:251) at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
... 29 more
2009-06-28 17:11:14,685 INFO [XSRFHandler] Removed destroyed
sessionId=jm4124n35l4g
2009-06-28 17:11:14,687 INFO [XSRFHandler] Removed destroyed
sessionId=jm4124n35l4g
Here is the send/receive messages (caught by tcpmonitor tool) - expected
with ws-security usertoken header
soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodyns2:sayH
i xmlns:ns2=http://service.web/
arg0Rahul/arg0/ns2:sayHi/soap:Body/soap:Envelope
soap:Envelope
xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;soap:Bodysoap:Fau
ltfaultcode xmlns:ns1=
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1
.0.xsdns1:InvalidSecurity/faultcodefaultstringAn error was discovered
processing the lt;wsse:Security
header/faultstring/soap:Fault/soap:Body/soap:Envelope
- I have set the usernameToken property in
org.apache.geronimo.jaxws.client.EndpointInfo and
org.apache.geronimo.jaxws.builder.EndpointBuilder.
- I have put some usertoken specific code in the PortMethodInterceptor
class (org.apache.geronimo.jaxws.client.PortMethodInterceptor) to set the
username and password.
org.apache.geronimo.jaxws.client.PortMethodInterceptor.java
...
String username = info.getUserName();
if (username != null) {
proxy.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, username);
LOG.debug(Set username property: + username);
}
String password = info.getPassword();
if (password != null) {
proxy.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, password);
LOG.debug(Set username property: + password);
}
...
and here is my cxf specific CXFPortMethodInterceptor, I am not sure its
well written. I need help in this, about how to use the cxf specific apis
to set the properties.
org.apache.geronimo.cxf.CXFPortMethodInterceptor
public class CXFPortMethodInterceptor extends PortMethodInterceptor {
private static final Logger LOG =
LoggerFactory.getLogger(CXFPortMethodInterceptor.class);
public CXFPortMethodInterceptor(MapObject, EndpointInfo seiInfoMap) {
super(seiInfoMap);
LOG.debug(View the seiInfoMap.values() ! + seiInfoMap.values());
}
public Object intercept(Object target, Method method, Object[]
arguments, MethodProxy methodProxy) throws Throwable {
LOG.debug(I am in intercept method of CXFPortMethodInterceptor!);
Object proxy = super.intercept(target, method, arguments,
methodProxy);
BindingProvider cxfProxy = (BindingProvider) proxy;
//To cast a client proxy to a CXF client:
org.apache.cxf.endpoint.Client client =
org.apache.cxf.frontend.ClientProxy.getClient(cxfProxy);
// testiing : used due to No security action was defined. error
org.apache.cxf.binding.soap.interceptor.SoapPreProtocolOutInterceptor
soapInterceptor =
new
org.apache.cxf.binding.soap.interceptor.SoapPreProtocolOutInterceptor();
org.apache.cxf.endpoint.Endpoint cxfEndpoint =
client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(soapInterceptor);
cxfEndpoint.getOutInterceptors().add(new
org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor());
LOG.debug(Am I doing right!);
return proxy;
}
}
I am 100% sure, I am making some (or lot of) mistakes in the above code and
I need help to get it fix.
Can you please guide me in this? I apologize if its a trivial problem.
I am stuck here. I think if i get thru with this then i wil have good idea
about usage of cxf specific apis and can easily set other properties (like
X.509 etc)
Many Thanks in advance for your help.
PS: sorry for long email.
Best Regards,
Rahul
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: jaxws 2.2 spec jar....
Jarek, I don't think I'm going to have any more time to add javadocs or anything. Thus, it's current state is probably the best that will be there for a while. Could you go ahead and move it back to G and do whatever updates are needed for a alpha release? Major thanks! Dan On Mon June 15 2009 10:40:43 am Jarek Gawor wrote: Dan, Let me know when you think you are done with it and I'll move it to Geronimo. Thanks for working on this, btw. Jarek On Fri, Jun 12, 2009 at 9:58 PM, Daniel Kulpdk...@apache.org wrote: On Fri June 12 2009 5:23:42 pm David Jencks wrote: What would your thought be on moving it to the geronimo spec project once it isn't having daily changes? Actually, with Dims' help, we're now there. I ran the tool Harmony used to compare API's and we're now 100% compatible with the jaxws 2.2 api jar. Now, that is not the same as running the TCK (which we don't have yet), but definitely a promising sign.I think I want to spend a little time early next week adding some javadoc, but then it would be good to move it back to geronimo-specs and do an alpha release. (wouldn't call it a 1.0 release until we have a tck to test it). Dan I'm planning to release the jaxb 2.1 spec jar soon for geronimo 2.2. thanks david jencks On Jun 12, 2009, at 12:51 PM, Daniel Kulp wrote: On Fri June 12 2009 3:42:23 pm Davanum Srinivas wrote: Thanks Dan, we need it for axis2 as well. Looks like we need 2.2 of JAXB as well. I'm slightly less concerned about JAXB for right now for three reasons: 1) It's available in the Sun maven repos already (and now central ;-) ) 2) We never have had a JAXB 2.1 version released yet. We've always used the Sun version anyway. 3) We don't have an Apache implementation of JAXB so we need the Sun implementation anyway. Yes, a JAXB 2.2 version would be nice, but not critical right now. JAX-WS 2.2 is slightly critical as there isn't a version deployed in maven that we can start using as a starting point. We need SOMETHING that we can use pretty much ASAP. Dan -- dims On 06/12/2009 03:35 PM, Daniel Kulp wrote: Just to let everyone know, I've started working on creating a specs jar for jaxws 2.2 in the CXF sandbox: http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxws_2.2_spec/ All apache committers can commit there so if anyone wants to help out... ;-) Mostly just wanted to let folks know I've started it so someone else doesn't go off and start it as well. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: jaxws 2.2 spec jar....
On Tue June 16 2009 12:21:08 pm David Jencks wrote: I bundlized it. I had kind of removed it as there really isn't a way for it to work as a bundle. It requires searching for stuff in META-INF/services which does not work well at all in OSGi. ServiceMix will create a real usable bundle out of it with it's BundleActivator and stuff in it that would work. It will be part of their specs: http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/ That said, if you DO want it to be a bundle, I'll work with gnodet to get a BundleActivator setup in it so it would work. That would save them from having to do any work. Your call. See http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jaxb- api-2.1/pom.xmlfor an example of how that would look. Dan Are you happy with snapshots getting pushed or do you need a M! type release with a vote and everything? thanks david jencks On Jun 16, 2009, at 6:39 AM, Daniel Kulp wrote: Jarek, I don't think I'm going to have any more time to add javadocs or anything. Thus, it's current state is probably the best that will be there for a while. Could you go ahead and move it back to G and do whatever updates are needed for a alpha release? Major thanks! Dan On Mon June 15 2009 10:40:43 am Jarek Gawor wrote: Dan, Let me know when you think you are done with it and I'll move it to Geronimo. Thanks for working on this, btw. Jarek On Fri, Jun 12, 2009 at 9:58 PM, Daniel Kulpdk...@apache.org wrote: On Fri June 12 2009 5:23:42 pm David Jencks wrote: What would your thought be on moving it to the geronimo spec project once it isn't having daily changes? Actually, with Dims' help, we're now there. I ran the tool Harmony used to compare API's and we're now 100% compatible with the jaxws 2.2 api jar. Now, that is not the same as running the TCK (which we don't have yet), but definitely a promising sign.I think I want to spend a little time early next week adding some javadoc, but then it would be good to move it back to geronimo-specs and do an alpha release. (wouldn't call it a 1.0 release until we have a tck to test it). Dan I'm planning to release the jaxb 2.1 spec jar soon for geronimo 2.2. thanks david jencks On Jun 12, 2009, at 12:51 PM, Daniel Kulp wrote: On Fri June 12 2009 3:42:23 pm Davanum Srinivas wrote: Thanks Dan, we need it for axis2 as well. Looks like we need 2.2 of JAXB as well. I'm slightly less concerned about JAXB for right now for three reasons: 1) It's available in the Sun maven repos already (and now central ;-) ) 2) We never have had a JAXB 2.1 version released yet. We've always used the Sun version anyway. 3) We don't have an Apache implementation of JAXB so we need the Sun implementation anyway. Yes, a JAXB 2.2 version would be nice, but not critical right now. JAX-WS 2.2 is slightly critical as there isn't a version deployed in maven that we can start using as a starting point. We need SOMETHING that we can use pretty much ASAP. Dan -- dims On 06/12/2009 03:35 PM, Daniel Kulp wrote: Just to let everyone know, I've started working on creating a specs jar for jaxws 2.2 in the CXF sandbox: http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxws_2.2_spec / All apache committers can commit there so if anyone wants to help out... ;-) Mostly just wanted to let folks know I've started it so someone else doesn't go off and start it as well. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: jaxws 2.2 spec jar....
On Tue June 16 2009 1:07:48 pm Jarek Gawor wrote: David J., I was thinking (one we're done with all the changes) to release it as 1.0-EA (with vote and everything). Yea. 1.0-EA or 1.0-alpha1 or similar would be perfect. Dan Jarek On Tue, Jun 16, 2009 at 12:21 PM, David Jencks david_jen...@yahoo.com wrote: I bundlized it. Are you happy with snapshots getting pushed or do you need a M! type release with a vote and everything? thanks david jencks On Jun 16, 2009, at 6:39 AM, Daniel Kulp wrote: Jarek, I don't think I'm going to have any more time to add javadocs or anything. Thus, it's current state is probably the best that will be there for a while. Could you go ahead and move it back to G and do whatever updates are needed for a alpha release? Major thanks! Dan On Mon June 15 2009 10:40:43 am Jarek Gawor wrote: Dan, Let me know when you think you are done with it and I'll move it to Geronimo. Thanks for working on this, btw. Jarek On Fri, Jun 12, 2009 at 9:58 PM, Daniel Kulpdk...@apache.org wrote: On Fri June 12 2009 5:23:42 pm David Jencks wrote: What would your thought be on moving it to the geronimo spec project once it isn't having daily changes? Actually, with Dims' help, we're now there. I ran the tool Harmony used to compare API's and we're now 100% compatible with the jaxws 2.2 api jar. Now, that is not the same as running the TCK (which we don't have yet), but definitely a promising sign.I think I want to spend a little time early next week adding some javadoc, but then it would be good to move it back to geronimo-specs and do an alpha release. (wouldn't call it a 1.0 release until we have a tck to test it). Dan I'm planning to release the jaxb 2.1 spec jar soon for geronimo 2.2. thanks david jencks On Jun 12, 2009, at 12:51 PM, Daniel Kulp wrote: On Fri June 12 2009 3:42:23 pm Davanum Srinivas wrote: Thanks Dan, we need it for axis2 as well. Looks like we need 2.2 of JAXB as well. I'm slightly less concerned about JAXB for right now for three reasons: 1) It's available in the Sun maven repos already (and now central ;-) ) 2) We never have had a JAXB 2.1 version released yet. We've always used the Sun version anyway. 3) We don't have an Apache implementation of JAXB so we need the Sun implementation anyway. Yes, a JAXB 2.2 version would be nice, but not critical right now. JAX-WS 2.2 is slightly critical as there isn't a version deployed in maven that we can start using as a starting point. We need SOMETHING that we can use pretty much ASAP. Dan -- dims On 06/12/2009 03:35 PM, Daniel Kulp wrote: Just to let everyone know, I've started working on creating a specs jar for jaxws 2.2 in the CXF sandbox: http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxws_2.2_spe c/ All apache committers can commit there so if anyone wants to help out... ;-) Mostly just wanted to let folks know I've started it so someone else doesn't go off and start it as well. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
IMO, if we can release a single jar that has the OSGi mechanism in it that would also pass the TCK, then, to me, that is preferred.Thus, my suggestion would be to take something that we DO have the tck for (jaxws 2.1 or saaj or something), add the OSGi stuff to it, and run the tck's to see what happens. Dan On Tue June 16 2009 1:38:49 pm David Jencks wrote: It's been a year IIUC servicemix has done something so the specs that have this discovery pattern solve the problem somehow. Now we have a jaxws 2.2 spec with the same problem. I think its silly to have the osgi-usable version of the spec far away from the spec source code. Can we revisit this discussion? I'd need to review what the servicemix bundles actually do but I'm pretty much in favor of having the geronimo spec jars work in osgi unchanged. If that's really unacceptable I'd suggest releasing two artifacts, one a working osgi bundle the other a non-osgi plain jar. thanks david jencks On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
jaxws 2.2 spec jar....
Just to let everyone know, I've started working on creating a specs jar for jaxws 2.2 in the CXF sandbox: http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxws_2.2_spec/ All apache committers can commit there so if anyone wants to help out... ;-) Mostly just wanted to let folks know I've started it so someone else doesn't go off and start it as well. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: jaxws 2.2 spec jar....
On Fri June 12 2009 3:42:23 pm Davanum Srinivas wrote: Thanks Dan, we need it for axis2 as well. Looks like we need 2.2 of JAXB as well. I'm slightly less concerned about JAXB for right now for three reasons: 1) It's available in the Sun maven repos already (and now central ;-) ) 2) We never have had a JAXB 2.1 version released yet. We've always used the Sun version anyway. 3) We don't have an Apache implementation of JAXB so we need the Sun implementation anyway. Yes, a JAXB 2.2 version would be nice, but not critical right now. JAX-WS 2.2 is slightly critical as there isn't a version deployed in maven that we can start using as a starting point. We need SOMETHING that we can use pretty much ASAP. Dan -- dims On 06/12/2009 03:35 PM, Daniel Kulp wrote: Just to let everyone know, I've started working on creating a specs jar for jaxws 2.2 in the CXF sandbox: http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxws_2.2_spec/ All apache committers can commit there so if anyone wants to help out... ;-) Mostly just wanted to let folks know I've started it so someone else doesn't go off and start it as well. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: jaxws 2.2 spec jar....
On Fri June 12 2009 5:23:42 pm David Jencks wrote: What would your thought be on moving it to the geronimo spec project once it isn't having daily changes? I'm planning to release the jaxb 2.1 spec jar soon for geronimo 2.2. That's the plan. I just don't have commit rights there so I forked it over to someplace I do. It's just easier then a bunch of patches. Dan thanks david jencks On Jun 12, 2009, at 12:51 PM, Daniel Kulp wrote: On Fri June 12 2009 3:42:23 pm Davanum Srinivas wrote: Thanks Dan, we need it for axis2 as well. Looks like we need 2.2 of JAXB as well. I'm slightly less concerned about JAXB for right now for three reasons: 1) It's available in the Sun maven repos already (and now central ;-) ) 2) We never have had a JAXB 2.1 version released yet. We've always used the Sun version anyway. 3) We don't have an Apache implementation of JAXB so we need the Sun implementation anyway. Yes, a JAXB 2.2 version would be nice, but not critical right now. JAX-WS 2.2 is slightly critical as there isn't a version deployed in maven that we can start using as a starting point. We need SOMETHING that we can use pretty much ASAP. Dan -- dims On 06/12/2009 03:35 PM, Daniel Kulp wrote: Just to let everyone know, I've started working on creating a specs jar for jaxws 2.2 in the CXF sandbox: http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxws_2.2_spec/ All apache committers can commit there so if anyone wants to help out... ;-) Mostly just wanted to let folks know I've started it so someone else doesn't go off and start it as well. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: jaxws 2.2 spec jar....
On Fri June 12 2009 5:23:42 pm David Jencks wrote: What would your thought be on moving it to the geronimo spec project once it isn't having daily changes? Actually, with Dims' help, we're now there. I ran the tool Harmony used to compare API's and we're now 100% compatible with the jaxws 2.2 api jar. Now, that is not the same as running the TCK (which we don't have yet), but definitely a promising sign.I think I want to spend a little time early next week adding some javadoc, but then it would be good to move it back to geronimo-specs and do an alpha release. (wouldn't call it a 1.0 release until we have a tck to test it). Dan I'm planning to release the jaxb 2.1 spec jar soon for geronimo 2.2. thanks david jencks On Jun 12, 2009, at 12:51 PM, Daniel Kulp wrote: On Fri June 12 2009 3:42:23 pm Davanum Srinivas wrote: Thanks Dan, we need it for axis2 as well. Looks like we need 2.2 of JAXB as well. I'm slightly less concerned about JAXB for right now for three reasons: 1) It's available in the Sun maven repos already (and now central ;-) ) 2) We never have had a JAXB 2.1 version released yet. We've always used the Sun version anyway. 3) We don't have an Apache implementation of JAXB so we need the Sun implementation anyway. Yes, a JAXB 2.2 version would be nice, but not critical right now. JAX-WS 2.2 is slightly critical as there isn't a version deployed in maven that we can start using as a starting point. We need SOMETHING that we can use pretty much ASAP. Dan -- dims On 06/12/2009 03:35 PM, Daniel Kulp wrote: Just to let everyone know, I've started working on creating a specs jar for jaxws 2.2 in the CXF sandbox: http://svn.apache.org/repos/asf/cxf/sandbox/geronimo-jaxws_2.2_spec/ All apache committers can commit there so if anyone wants to help out... ;-) Mostly just wanted to let folks know I've started it so someone else doesn't go off and start it as well. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: [WS-Security] JAXWS webservice client without using cxf specific apis
) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage (CheckFaultInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai n.java:226) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:641) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons eInternal(HTTPConduit.java:2131) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRespons e(HTTPConduit.java:2010) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPCon duit.java:1935) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:626) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInte rceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChai n.java:226) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:469) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:299) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:251) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) ... 2 more Can anyone correct me? Am I missing something? Thanks in advance for your help. Regards, Rahul -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Stuff I really want in 2.2
On Wed May 27 2009 12:55:29 pm David Jencks wrote: Here are some things I really really want in 2.2. Since my main focus at the moment is getting the incipient 3.0 more osgi-ready if I have to do all of them 2.2 will be a long time coming... so hopefully others will become inspired and want to help :-) - in no particular order - 1. upgrade to maven 2.1 I would pause on this. You cannot do releases with 2.1 as the gpg plugin doesn't work with it. We're still discussing what to do about it. 2.0.10 is OK and a fix is in place for 2.2, but I'm not sure if the fix is going to be pulled back into 2.1.x. Dan 2. upgrade to latest apache pom (6?) 3. upgrade to latest assembly plugin to help with source distros (I don't think it's released yet) 4. reexamine genesis and trim it (probably means genesis 2) 5. use the release plugin 6. get all our private dependencies into maven central. This probably means releasing with our groupId unless we can get the projects to do a release 7. When we deploy, write the plan into the plugin something like the car-maven-plugin does. Same with the default geronimo-plugin.xml (GERONIMO-4628) 8. We need some way to override/configure/set javaee env-entry values from something other than the original spec dd or annotation (GERONIMO-4630) 9. In the console, provide a uniform way to completely specify the artfiact ID for a plan being created. Save the groupId and version as config-substitutions or something persistent. 10. Provide a way to edit artifact-aliases in the console. Include a way to specify artifact-alias when installing a jar. thanks david jencks -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: WS-Security support for JAX-WS Web Services
On Mon May 11 2009 7:16:46 pm David Jencks wrote: On May 11, 2009, at 3:24 PM, rahul.soa wrote: Hello everyone, As you know I am working on the support of ws-security module, so I did some research about integrating the modules in Apache Geronimo for the same. For the integrating/enabling WS-Security support, I think we need to have the following jars and modules in Geronimo: Apache CXF: For WS-Security support we need to have following jar files from the CXF: - bcprov-jdk15.jar Previously when we used some bouncy castle classes the jar included some classes that may well have infringed some us patents. I think I saw somewhere that bouncy castle had finally released a jar without thses classes. We should verify that this jar does not contain these classes. Also, we have copies of a bunch of the bc classes we need for other purposes in the geronimo-crypto module, so we should check that we don't already have the needed classes. Version 140 and later in maven have the patent covered algorithms removed. Not an issue anymore. - xalan.jar really? I'd like to know why the xml transform support in the jdk is not sufficient. xmlsec uses some of the internal xalan classes. I could never get a good reason as to why. - serializer.jar This goes with Xalan. - wss4j.jar - xmlsec.jar Note: all of those jars will be required for Axis2 as well. Apache Axis2 1. We need to integrate Rampart* module of axis2, 2. for step 1, need to download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files corresponding to JDK version and extract the jar files local_policy.jar and US_export_policy.jar to $JAVA_HOME/jre/lib/security These are not something we can include, right? they'd have to be installed by the end user? Correct. However, for unit tests and such, we can PROBABLY use less secure algorithms. I have someone looking into the same issue for the CXF test cases. We don't want to make every developer have to install the strong crypto libraries. Basically, if the user needs the strong crypto stuff, they WILL need to download and install the strong crypto libs from Sun. Dan 3. for step 1, need to download bouncycastle according to java version separately *Rampart is the security module of Axis2 Please let me know if I am missing something and please also guide me how can I get them in Geronimo. That depends partly on the classloader relationships needed between the main cxf/axis2 jars and these new ones. If appropriate cxf/axis2 jars and these jars can be in a classloader that is a child of the cxf/ axis2 main plugin classloaders, you should probably make cxf-wss and axis2-wss plugins with all the security related jars as dependencies. If this doesn't work and the classes need to be in the main cxf/axis2 plugin classloader then you probably need to just add these as dependencies. thanks david jencks Thanks in advance. Regards, Rahul -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: gsoc [WS-Security support for JAX-WS Web Services]
On Wed April 22 2009 11:39:14 pm Jarek Gawor wrote: CXF has all the security modules within it (AFAIK). Not REALLY true with the way CXF is pulled into Geronimo. Geronimo doesn't include those modules.For the most part, getting them added in would just be adding a maven dependency on cxf-rt-ws-security (and cxf-rt-ws-policy to make the SecurityPolicy stuff work). Maven should then grab those and get them included into Geronimo. As long as it ends up in the same classloader as all the rest of the cxf stuff, cxf should auto-detect it and enable it. Once you do that (and upgrade to CXF 2.2.x), all the WS-SecurityPolicy stuff should just work if the policy is in the wsdl. Thus, that part of you project could be as simple as that. (obviously, that's a small part of the project) You could probably even grab the CXF versions of the Microsoft PlugFest stuff and try running them in Geronimo: https://svn.apache.org/repos/asf/cxf/trunk/distribution/src/main/release/samples/ws_security/interopfest/ (As an aside: too late now, but getting the MS PlugFest stuff running in G would have been a good addition to the proposal from a testing standpoint. Wish I would have thought of that earlier.) I'm really not sure how much you really want to dig into WSS4J. That's very low level security stuff which is pretty complex and may not be worth your time. Rampart and CXF's SecurityPolicy implementations do an excellent job of abstracting that stuff out and driving it by interpretting the policies. About the only thing you need to know about wss4j when going the policy route is how to setup the Merlin properties files for the keystores and such. Dan Rahul, In terms of Geronimo here are some docs that might be helpful (some info might be out of date): 1) Some basic GBean information - you will see/work with them a lot: http://cwiki.apache.org/GMOxDOC22/developing-and-deploying-a-geronimo-gbean .html http://cwiki.apache.org/confluence/display/GMOxDEV/GBean+Annotations 2) Basic classloading and plugin information in Geronimo. http://cwiki.apache.org/GMOxDOC22/classloading.html http://cwiki.apache.org/confluence/display/GMOxDEV/Plugin+Guide In terms of code you will probably be working with the following modules: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/axis2/ http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/cxf/ http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/jaxws/ http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/webservices/ I trust you to find the basic Axis2 and CXF info :) I believe both use WSS4J project for WS-Security (http://ws.apache.org/wss4j/). Axis2 has a separate project that provides web services security features: Rampart (http://ws.apache.org/rampart/). CXF has all the security modules within it (AFAIK). Hope this helps you get started. Jarek On Tue, Apr 21, 2009 at 3:33 PM, rahul.soa rahul@googlemail.com wrote: Hello everyone, I want to start with some reading and understanding with the geronimo's components which will be involved in this project. So can you please point me to the appropriate documentation for the same. If you want to know more about the proposal then feel free to look at the descriptive project proposal on the below link: http://wiki.apache.org/general/rahulsoa Thanks in advance. Best Regards, Rahul -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Accepted Gsoc [WS-Security support for JAX-WS Web Services]
That's really great. I'm glad the project proposal worked out for you. Now: first task... work with Geronimo to start convincing them to upgrade to CXF 2.2.1 (I'll be doing the release builds today, hopefully released the end of the week).That will make the CXF based security stuff much easier. :-) Dan On Tue April 21 2009 6:39:40 am rahul.soa wrote: Hello Everyone, My gsoc application for the WS-Security support for JAX-WS Web Services project has been accepted. Thanks to everyone for their support in making my application robust. Jarek Gawor will be mentoring me for this project. Of course, you can also guide me as I will be on the developer mailing list and will post my questions to the community. I am sure I will have good working time with you. Thanks again. Best Regards, Rahul -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Initial Draft for gsoc [WS-Security support for JAX-WS Web Services] project
argument and/or a method that will allow the web service developer to set the enabled property. The meaning of enabled or disabled is determined by each individual WebServiceFeature. It is important that web services developers be able to enable/disable specific features when writing their web applications. [2] [1] http://e-docs.bea.com/workshop/docs81/doc/en/core/index.html [2] http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html //Unquote Any suggestion will be appreciable. * Please put my email id in cc if you reply to mailing list only as I am not on the mailing list at this time. I have sent requests many times but could not get the confirmation reply for joining the mailing list so far. Many Thanks. Best Regards, Rahul [1] http://wiki.apache.org/general/SummerOfCode2009#cxf-project -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
[jira] Commented: (GERONIMO-4500) Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
[
https://issues.apache.org/jira/browse/GERONIMO-4500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12661635#action_12661635
]
Daniel Kulp commented on GERONIMO-4500:
---
This seems to be a bug at the oasis web site.
http://www.oasis-open.org/committees/entity/release/
only shows the files for the 1.0 release. The 1.1 release files are not
there.If you switch to the 1.0 DTD, it probably will work.
Jetty/CXF fails to parse jax-ws-catalog.xml including a DOCTYPE declaration
---
Key: GERONIMO-4500
URL: https://issues.apache.org/jira/browse/GERONIMO-4500
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Affects Versions: 2.2
Environment: Geronimo 2.2-SNAPSHOT, Jetty/CXF assembly
Reporter: Janko Heilgeist
Attachments: geronimo-wsdllocation-jetty_cxf-1.0-SNAPSHOT.jar,
geronimo-wsdllocation-jetty_cxf.tar.gz
I've built an EJB-JAR packaging a web service. The JAR contains all classes,
SEI and service stub generated from an existing WSDL (which is also inside
this JAR). Additionally, it contains the actual EJB implementing the web
service.
I tried to annotate the web service implementation with
{code:java}
@WebService( ..., wsdlLocation=http://example.com/myservice.wsdl;)
{code}
and add a META-INF/jax-ws-catalog.xml:
{code:xml}
?xml version=1.0 encoding=UTF-8?
!DOCTYPE catalog PUBLIC -//OASIS//DTD XML Catalogs V1.1//EN
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd;
catalog xmlns=urn:oasis:names:tc:entity:xmlns:xml:catalog
system
systemId=http://example.com/myservice.wsdl;
uri=wsdl/myservice.wsdl/
/catalog
{code}
During deployment, the following exception is thrown:
{noformat}
2009-01-07 17:33:53,087 WARN [OASISCatalogManager] Error loading
META-INF/jax-ws-catalog.xml catalog files
java.io.FileNotFoundException:
http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:905)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:872)
at
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:282)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:1021)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at
org.apache.xml.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:251)
at org.apache.xml.resolver.Catalog.parseCatalog(Catalog.java:681)
at
org.apache.cxf.catalog.OASISCatalogManager.loadCatalogs(OASISCatalogManager.java:108)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:93)
at
org.apache.cxf.catalog.OASISCatalogManager.loadContextCatalogs(OASISCatalogManager.java:89)
at
org.apache.cxf.catalog.OASISCatalogManager.register(OASISCatalogManager.java:81)
...
{noformat}
As a workaround the DOCTYPE declaration can be removed. Without the
declaration the exception is gone and the wsdlLocation URL is correctly
resolved.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4460) Upgrade Spring plugin to 2.5.6 artifacts
[ https://issues.apache.org/jira/browse/GERONIMO-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655279#action_12655279 ] Daniel Kulp commented on GERONIMO-4460: --- CXF can use 2.5.x as well. We have a profile that tests CXF with 2.5.5. Also, the FUSE version of CXF (from Progress) does ship with 2.5.5 and is built/tested with it. Upgrade Spring plugin to 2.5.6 artifacts Key: GERONIMO-4460 URL: https://issues.apache.org/jira/browse/GERONIMO-4460 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ, console, dependencies Affects Versions: 2.2 Reporter: Donald Woods Assignee: Donald Woods Priority: Minor Fix For: 2.2 ActiveMQ was using springframework 2.5.5 at build time, so upgrading plugins/spring to 2.5.6 allows us to use the same level for pluto and activemq. This also fixes the build pulling in commons-logging-1.0.3. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: private repo in svn questions...
On Thursday 04 December 2008 1:14:46 pm Kevan Miller wrote: On Dec 1, 2008, at 8:12 PM, David Jencks wrote: I also wonder if our policy of patching apache projects and coming up with our own psuedo releases is really the best idea or if we should just copy their code over in svn and build it more directly. Not sure that it's *necessary*, but it's a good idea. Although patches give a better idea of the intent of these private builds -- they're patches, not forks... At one point we discussed renaming these artifacts as geronimo artifacts (e.g. org/apache/geronimo/patched/jasper/6.0.18-G678601/ jasper-6.0.18-G678601.jar ). Would this be a better technique for solving the issue? To me, yes. The Maven PMC recently decided that the official policy will be that we'll only sink stuff to central for projects that make a best effort to get all the dependencies into central. Projects that insist on having private repos and such may get cut off if they actually decide to enforce it.If the artifacts are in org/apache/geronimo/patched, they could also go to central. -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
[jira] Commented: (GERONIMO-4439) Add MTOM feature testing in the webservice testsuite
[ https://issues.apache.org/jira/browse/GERONIMO-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12653148#action_12653148 ] Daniel Kulp commented on GERONIMO-4439: --- Jarek, We get those same errors with JAX-WS TCK if we use a version of the RI newer than 2.1.1. I THINK the latest version of the TCK fixes that issue, but haven't had the time to try it. For now, we just use the older version of the RI. My suggestion would be to try a newer version of the tck or an older version of the RI. Add MTOM feature testing in the webservice testsuite Key: GERONIMO-4439 URL: https://issues.apache.org/jira/browse/GERONIMO-4439 Project: Geronimo Issue Type: Test Security Level: public(Regular issues) Components: webservices Affects Versions: 2.2 Environment: Windows XP JDK 1.5 Reporter: Ivan Assignee: Jarek Gawor Priority: Minor Fix For: 2.2 Attachments: Geronimo-4439-2.5spec.patch, Geronimo-4439.patch I try to write some testcases about MTOM features in the webservice testsuite. Please help to review it, and thanks for any comment ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: java.util.concurrent.ExecutorService changes between Java 5 and 6
Just dug into CXF's workqueue as I know it implements ExecutorService to see what we did. We actually just extend AbstractExecutorService (actually ThreadPoolExecutor, but AES would work) which implements all the methods that take generics. All that needs to be implemented is void execute(Runnable command); Thus, it probably doesn't help you at all, but thought I'd pass along the info anyway. Dan On Monday 24 November 2008 4:15:43 pm Jarek Gawor wrote: What do you mean exactly? The problem is not with calling the API but with extending/implementing the API. Jarek On Thu, Nov 20, 2008 at 4:14 AM, Juergen Weber [EMAIL PROTECTED] wrote: What about some abominable reflection hacks? Juergen Jarek Gawor-2 wrote: The java.util.concurrent.ExecutorService interface was slightly changed between Java 5 and Java 6: Here's an example: Java 5: invokeAll(CollectionCallableT tasks) Java 6: invokeAll(Collection? extends CallableT tasks) Here's more info on the change: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6267833 This change causes problems in the concurrent module. The code in the concurrent module extends and implements the Java 5 ExecutorService interface. However, since the interface was changed in Java 6, the concurrent module will not build on Java 6. The compiler complains that these changed methods are not implemented. And you can't define both style of these methods in the same class because they have the same erasure. Given our recent discussion on supporting Java 5 and 6, I think I will need to make the concurrent module Java 5 or Java 6 specific. That is, for example, the module would be built on Java 6 but not built on Java 5. I was wondering if somebody had a better idea how to deal with this and/or how to support both Java versions. Thanks, Jarek -- View this message in context: http://www.nabble.com/java.util.concurrent.ExecutorService-changes-betwee n-Java-5-and-6-tp20594884s134p20597470.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
Re: [DISCUSS] Only Support Java SE 6 with Geronimo 2.2
On Monday 17 November 2008 4:19:45 pm Donald Woods wrote: Sorry, I was away on vacation last week. Does anyone know of technical reason why we can't move to Java SE 6 and use the JAXB/JAX-WS implementation provided in the JDK? Yes. There are parts of CXF that won't work without the non-mungled versions JAXB. (the versions in the JDK are package mungled.) I've STARTED going down the route of using ASM and other trickery to get it working on cxf's trunk, but that's not on the 2.1.x branch. Dan -Donald Jason Warner wrote: Have we come to a consensus on this yet? Perhaps we should put it to a vote? The discussion has died down, but there doesn't seem to be a clear winner. On Sat, Nov 8, 2008 at 7:53 AM, Donald Woods [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I'm not proposing that we put any checks or hard stops in the server to prevent starting on Java SE 5, but I would like to remove JAXB/JAXWS 2.1 as it comes in Java SE 6 and use the wsgen in the JDKs instead of shipping some CXF code for Axis2 users. Free Java SE 5 support/updates end next year, so I don't see why you'd want to continue supporting it in a 2.2 release that is targeted as a main release stream for 2009. -Donald Kevan Miller wrote: On Nov 7, 2008, at 12:04 AM, Donald Woods wrote: The time has come to make the hard decision - Do we only build and certify Geronimo 2.2 on the Sun 1.6.0 JDK and drop support for running on Java SE 5? Um. What do you mean drop support? We've only announced certification on a particular Java SE level, in the past. We've documented minimum SE platform (e.g. Java EE 5 is hard to do on 1.4). I would be against some sort of explicit Java SE 5 runtime check that would fail server startup. If a user shows up with a Java SE 5 issue, I'd expect that we'd be trying to fix their problem, regardless of our support statement I have no issue with performing certification testing, only, on Java Se 6 (but would also be happy to see some Java SE 5 runs...). However, I don't see any reason to discourage users from using Java SE 5, if that's what they want... Pros: - Reduce testing effort to one version of Java Fine, but w/ testing hardware, may not be a big issue to test on both... - Allows us to use the JAXB 2.1, JAX-WS 2.1 and wsgen tools in the JDK, instead of shipping those jars in our assemblies (and removes some more Sun RI from our assemblies) :-) I thought we were going to be picking up tools from CXF -- https://issues.apache.org/jira/browse/GERONIMO-4351 Would that resolve your issues with Java SE 5? --kevan -- ~Jason Warner -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
Re: [DISCUSS] Only Support Java SE 6 with Geronimo 2.2
On Monday 17 November 2008 8:22:21 pm Kevan Miller wrote: On Nov 17, 2008, at 4:35 PM, Daniel Kulp wrote: On Monday 17 November 2008 4:19:45 pm Donald Woods wrote: Sorry, I was away on vacation last week. Does anyone know of technical reason why we can't move to Java SE 6 and use the JAXB/JAX-WS implementation provided in the JDK? Yes. There are parts of CXF that won't work without the non- mungled versions JAXB. (the versions in the JDK are package mungled.) I've STARTED going down the route of using ASM and other trickery to get it working on cxf's trunk, but that's not on the 2.1.x branch. Thanks for the info, Dan. For collective awareness, could I ask you to be a bit more specific about the packaged mungled versions of JAXB? --kevan When Sun puts things into the JDK, they tend to mangle the package name from their standalone versions to something else. In the case of JAXB, they changed the com.sun.xml.bind package to com.sun.xml.internal.bind. That's fine if you JUST need to use the public API's in javax.xml.bind, but to do a bunch of more advanced things, you need to interact directly with stuff in the the com.sun packages. In particular, there are several area's that we need to do so: 1) Namespace mapping - to customize the namespace mapping, you have to subclass a class in the com.sun.xml.bind package. Thus, if you subclass the version for external jaxb, that class doesn't work for the internal jaxb (class cast exception) since the parent is diffent. (and vice versa) 2) Do to some advanced Map/interface mapping WITHOUT generating wrapper types first, you need to use the JAXB bridge things that are in com.sun. However, this isn't normal for CXF anymore. If you have ASM on the classpath, we generate wrapper classes in memory. That solve this without the bridges. However, if you don't have asm, you still need the bridges. 3) The default namespace mapping, while just a string property name, also changed. What's worse, if you pass the other property in a context creation time, it throws an exception. Thus, you kind of have to try one, catch any exception, try the other. 4) For code generation time (wsdl-java) even more problems come up. First, NONE of XJC is in javax.xml. It's all in com.sun.xml.bind packages. So all of that changes. Plus, XJC plugins have the same superclass has changed problem. XJC plugins written for external JAXB won't work with internal jaxb. In fact, if you have the external plugins even on the classpath, the internal xjc won't even run at all. On trunk, I've tackled 1 - 3. 4 is a ton of work that I haven't had time to complete. The XJC plugin stuff is also something I have absolutely no idea how to handle. :-( -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
Re: [DISCUSS] Moving the JAXB specification apis to Geronimo Specs
On Wednesday 05 November 2008 9:43:28 pm Donald Woods wrote: These are clean room implementations, right? Right. There were some bugs in a couple of the earlier versions where Guillaume didn't read the spec carefully enough. As a couple of people have used it, we've kind of ironed them out, but a full TCK run would be great and would be a huge confidence builder. At the very least, run the API tests. Also, does this provide the API and IMPL for JAXB? Just the API jar. You would still need the jaxb-impl from sun. Dan -Donald Guillaume Nodet wrote: I've copied the jaxb 2.0 and 2.1 api to: https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxb_2.0_s pec/ https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jaxb_2.1_s pec/ Everything looks ok (legal stuff, osgi manifest, etc...). Would it be possible to use them to run a tck test and see if they are ready to be released ? On Fri, Oct 24, 2008 at 7:29 AM, Guillaume Nodet [EMAIL PROTECTED] wrote: In ServiceMix we have rewritten the JAXB specs jars (2.0 and 2.1) because we needed to be able to do some modifications for OSGi. We'd like to move them to the Geronimo Specs subproject as it would be more consistent and would allow them to pass the TCK. The code base are available at: https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jaxb-api-2. 0/ https://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jaxb-api-2. 1/ I'm quite confident that passing the TCK should not be a major problem because they check the compliance with the Sun jars using a maven plugin that use introspection to detect signature changes between two jars. Anyway, feedback welcome. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
Re: JSR 311
On Sunday 26 October 2008 11:38:57 am Matthias Wessendorf wrote: Hi, I was wondering if you guys know about an Apache licensed JSR 311 implementation ? Apache CXF has a JSR311 implementation. CXF 2.1.3 released last week is at 0.8 level. There is some work going on on trunk to get it to 1.0 level. We've asked for the TCK for it, but it's not yet available. The goal is to get it to pass the TCK. Of course, any help to get it along that path would be more than welcome. :-) Dan -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
Re: Axis2: Using CXF tooling instead of Sun tooling to generate WSDL
Deepal, I hope you realize that generating wsdl from JSR181 stuff is a small part of a full JAX-WS compliant tooling story. If you look at the two tools: wsgen (java2ws in CXF): this tool requires generation of not just WSDL and Schema, but also various JAX-WS beans such as fault beans, wrapper beans, etc... This has also become slightly more complicated in JAX-WS 2.1 due to the requirement to support a subset of the JAXB annotations on the SEI as well, but not too major. wsimport (wsdl2java in CXF): Obviously, this needs to output JAX-WS compliant code (mostly the JSR181 annotations and JAXB). However, it also has to support all the jax-ws and jaxb customization binding files. Anyway, as Jarek pointed out, the CXF tools are completely JAX-WS compliant and DO pass the TCK. They are named differently than the RI tools (serious, what's up with wsimport/wsgen? wsdl2java/java2ws seems to make more sense to me), but they do meet all the requirements. Dan On Thursday 14 August 2008 7:04:54 pm Deepal Jayasinghe wrote: Hi, Do we have a feel about how stable is the CXF wsdl generation code, besides tck? I remember way back we decided we could not use Axis2's wsdl generation code as it didn't support annotation. Should we also look into where Axis2's wsdl generation code is now and assess if we should use Axis2's or CXF's? Axis2 does support for WSDL generation with annotation (JSR181). We added that a long time back. Thank you! Deepal -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: branches/2.1 - 72 hour notice for 2.1.2 release processing
Just FYI: once we get validation that the snapshots fix the tck problems, I'm ready to roll the CXF 2.0.8 release. I just need the go-ahead signal. Dan On Jul 22, 2008, at 11:05 AM, Joe Bohn wrote: The issue with the tck tests ended up being a bug in cxf 2.0.6. CXF has a fix that is currently included in 2.0.8-SNAPSHOT. If we give them the green light they will push a release soon. At this point I'm trying to decide the best course of action. If you have an opinion please speak up: 1) Delay a 2.1.2 release until we verify CXF 2.0.8-SNAPSHOT with the tck and get a CXF 2.0.8 release 2) Revert back to cxf 2.0.2-incubator that we shipped with in Geronimo 2.1.1 3) Revert to CXF 2.0.5 which should work and not have the problem that just discovered. We would have to verify this. I'm currently building new images to verify cxf 2.0.8-SNAPSHOT for #1. At the moment I'm thinking this is our best option. If there are problems I'll attempt #3. #2 would be the quickest path to a release but IMO is the least desirable. Joe Joe Bohn wrote: Joe Bohn wrote: I know it's a little bit more than the usual 24 hours but since a weekend is involved I figured I'd give a bit more advanced notice so that nobody is caught unaware. As we've previously discussed, I plan to create a branch for 2.1.2 release processing on Monday, 7/21 around 10:00 ET. Joe FYI ... I'm stalling a little on the branch. A potential issue has arisen with TCK and I'm waiting until we understand it a little better prior to branching. Joe --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: branches/2.1 - 72 hour notice for 2.1.2 release processing
OK. The vote for the 2.0.8 release is up: http://www.nabble.com/-VOTE--Release-CXF-2.0.8-td18602257.html Hopefully I can find some time this weekend to finish the vote and get it synced to central. (assuming the vote passes) Dan On Jul 22, 2008, at 3:24 PM, Joe Bohn wrote: Hi Dan, First, thanks again for your help with this! I think you can go ahead and start the CXF 2.0.8 release process. I've still got some more tests to go ... but so far things are looking good and most of the tests have completed. If we do happen to find a problem we'll discover it soon. Joe Daniel Kulp wrote: Just FYI: once we get validation that the snapshots fix the tck problems, I'm ready to roll the CXF 2.0.8 release. I just need the go-ahead signal. Dan On Jul 22, 2008, at 11:05 AM, Joe Bohn wrote: The issue with the tck tests ended up being a bug in cxf 2.0.6. CXF has a fix that is currently included in 2.0.8-SNAPSHOT. If we give them the green light they will push a release soon. At this point I'm trying to decide the best course of action. If you have an opinion please speak up: 1) Delay a 2.1.2 release until we verify CXF 2.0.8-SNAPSHOT with the tck and get a CXF 2.0.8 release 2) Revert back to cxf 2.0.2-incubator that we shipped with in Geronimo 2.1.1 3) Revert to CXF 2.0.5 which should work and not have the problem that just discovered. We would have to verify this. I'm currently building new images to verify cxf 2.0.8-SNAPSHOT for #1. At the moment I'm thinking this is our best option. If there are problems I'll attempt #3. #2 would be the quickest path to a release but IMO is the least desirable. Joe Joe Bohn wrote: Joe Bohn wrote: I know it's a little bit more than the usual 24 hours but since a weekend is involved I figured I'd give a bit more advanced notice so that nobody is caught unaware. As we've previously discussed, I plan to create a branch for 2.1.2 release processing on Monday, 7/21 around 10:00 ET. Joe FYI ... I'm stalling a little on the branch. A potential issue has arisen with TCK and I'm waiting until we understand it a little better prior to branching. Joe --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: CXF 2.0.7 for G 2.1.2? - [Fwd: Re: Re: Re: Using WS-Security with Geronimo 2.1.1]
Was 2.0.6 OK or did it have the same TCK issues? Dan On Jul 14, 2008, at 4:21 PM, Joe Bohn wrote: FWIW, I did a quick check with CXF 2.0.7 and hit some issues with the TCK tests under Geronimo. There must be some Geronimo changes necessary for this upgrade. We'll hold-off upgrading to 2.0.7 for 2.1.2 unless someone has a chance to look into the tck issues before out branch. Joe Joe Bohn wrote: Should we be considering CXF 2.0.7 for Geronimo 2.1.2? Does anybody know of specific reasons to move to 2.0.7 or hold at 2.0.6? Joe Reference this portion of post by Dan Kulp on the user list: Original Message Subject: Re: Re: Re: Using WS-Security with Geronimo 2.1.1 Date: Tue, 8 Jul 2008 11:10:07 -0700 (PDT) From: Daniel Kulp [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: OFFAC5A3FD.692CBA0E-ONC1257474.003F56EE- [EMAIL PROTECTED] [EMAIL PROTECTED] OF80AFEB70.45376D71-ONC1257475.002E6337- [EMAIL PROTECTED] [EMAIL PROTECTED] OF48817414.1A6C6BC0-ONC1257475.005266C9- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Geronimo pretty much includes just the parts of CXF that are needed to pass the JAX-WS parts of the TCK. It doesn't include the extra things like ws-addressing, ws-security, ws-rm, aegis databinding, etc Geronimo didn't need them so they didn't pull them in. When adding the jar like that, keep in mind that you may need other dependencies like wss4j, xml-sec, etc.. that ws-security requires that might not be shipped with Geronimo. One thing to keep in mind is that the CXF ws-security implementation (and the Axis2/Rampart implementation as well) is based on WSS4J which isn't up to WS-Security 1.1 level yet. Some of the profiles it supports are close to 1.1 levels, but for the most part, it's 1.0. A note to the wss4j dev list ([EMAIL PROTECTED]) would probably a good start to figure out what wss4j supports. That said, it would be great if Geronimo could update to CXF 2.0.7 (non-incubator) for a 2.1.2 release. snip/ --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Geronimo v2.2 discussion
- Axis2 1.4 - JAX-WS 2.1 CXF 2.1.x (current release is 2.1.1) The three of these really are one item as they have to be done together. Upgrading to JAX-WS 2.1 would require updating to the latest CXF and Axis2 versions. Likewise, updating either Axis2 or CXF to the latest (non-patch) release would require updating to JAX-WS 2.1 which would require updating all three. Dan On Jul 2, 2008, at 8:46 PM, Donald Woods wrote: Items I've seen mentioned so far for 2.2 - - Java SE 6 support - Derby 10.4.1.3 - Dojo 1.1.1 (minimal for console usage and plugins for user apps) - Possible reorg of the Admin Console (if we enable collapsible tree) - JMS Portlet improvements - EJB Portlet improvements - Axis2 1.4 - JAX-WS 2.1 Hernan Cunico wrote: Hi All, We kinda started to have some discussion some time ago but couldn't find any hit on nabble so not sure were we left it. I added a Geronimo v2.2 Roadmap ../GMOxDEV/geronimo-v22- roadmap.html page at the top of the Development section in the wiki front page, http://cwiki.apache.org/geronimo/ so we can resume the discussion and collect all our thoughts in one place. (edit access is limited to committers/contributors though) Does anybody already have a list? Cheers! Hernan --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: svn commit: r669363 - in /geronimo/devtools/eclipse-plugin/trunk/plugins: org.apache.geronimo.st.core/ org.apache.geronimo.st.ui/ org.apache.geronimo.st.v20.core/ org.apache.geronimo.st.v20.ui/ or
On Jun 20, 2008, at 11:49 AM, Donald Woods wrote:
brnaches/2.1 doesn't use the m-r-r-p plugin, so it has the
LICENSE.txt nd NOTICE.txt files in every subdir where an artifact
gets genereated.
For trunk, the m-r-r-p uses these LICENSE/LICENSE.vm files to add
additional license/notices to the default Apache ones.
Not sure which filename is correct (LICENSE vs. LICENSE.vm) as the
Specs project (like servlet-2.5) uses LICENSE w/o the .vm.
The LICENSE.vm files are treated as velocity templates by m-r-r-p
instead of just text. Thus, any velocity things in them would be
run. Thinks like variable expansions, etc...
Dan
-Donald
Ted Kirby wrote:
Interestingly, I did come across
framework\modules\geronimo-crypto\src\main\appended-resources\META-
INF\{NOTICE,LICENSE}.vm
in trunk, but branches\2.1 doesn't have them.
On Thu, Jun 19, 2008 at 8:04 PM, Donald Woods [EMAIL PROTECTED]
wrote:
Yep, trunk needs some more love to get it back into compliance.
Don't
remember who removed all of the License/Notice files, but they
forgot to
create the new src/main/appended-resources/META-INF/NOTICE and
src/main/appended-resources/META-INF/LICENSE files that the m-r-r-p
needs
-Donald
Ted Kirby wrote:
On Wed, Jun 18, 2008 at 11:42 PM, Kevan Miller [EMAIL PROTECTED]
wrote:
On Jun 18, 2008, at 10:13 PM, [EMAIL PROTECTED] wrote:
Author: tkirby
Date: Wed Jun 18 19:13:06 2008
New Revision: 669363
URL: http://svn.apache.org/viewvc?rev=669363view=rev
Log:
GERONIMODEVTOOLS-397 Bouncy Castle License and Notice needs proper
exposure
in GEP files
add more missed files: notice and license files for each plugin
Added:
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.core/LICENSE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.core/NOTICE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.ui/LICENSE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.ui/NOTICE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v20.core/LICENSE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v20.core/NOTICE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v20.ui/LICENSE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v20.ui/NOTICE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v21.core/LICENSE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v21.core/NOTICE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v21.ui/LICENSE.txt
(with props)
geronimo/devtools/eclipse-plugin/trunk/plugins/
org.apache.geronimo.st.v21.ui/NOTICE.txt
(with props)
Hi Ted,
Moving forward, definitely want to start using the
maven-remote-resources-plugin to automatically install the
default LICENSE/NOTICE files. See framework/modules/geronimo-
crypto for
an
example of how you handle the non-default cases.
I am not seeing what is going on here. In g211, everything seems
to
have their own NOTICE.txt file, and geronimo-crypto has the extra
Bouncy Castle notice. In trunk, nothing has NOTICE.txt file, and I
see nothing in geronimo-crypto that inserts a notice.
In terms of applicability to GEP, it seems this could apply to
org.apache.geronimo.runtime.* plugins.
They seem to be built differently now.
Tim, do you know if the current approach is becuase of eclipse,
and if
the new approach Kevan is suggesting will work with eclipse?
Thanks,
Ted
So that I understand, all of these plugins are including the
geronimo-crypto
jar?
--kevan
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: [DISCUSS] Web Service support in GEP
I just want to point out that if the generated stuff is properly standards compliant, it should work fine for the CXF stack as well. It would be good to make JAX-WS compliance the target for WTP so it would be usable for both stacks. Dan On Jun 12, 2008, at 6:33 AM, Sainath Chowdary wrote: Hi, I am also very interested in improving GEP to support spec compliant web services deployment. Currently, the WTP Web Services Wizard packs a lot of jar files with every web service deployed and this burdens project with a lot of generated files. As Geronimo has inbuilt axis2 container running, all we need to do for deploying a web service is place the WSDL file in WEB-INF if using it as a Servlet or placing it in META-INF if using EJB Service endpoint, and magically Geronimo creates all necessary stubs required for accessing the service. So, if we are able to create WSDL file according to Java and WS-* standards, I assume that we can have JAX-WS compliant web services deployed onto Geronimo. As pointed by this link http://cwiki.apache.org/GMOxDOC21/developing-a-simple-calculator-web-service.html . I have successfully deployed the web service though most of the steps are not necessary in the deployment process. I have also prepared sample applications and How-To's for Building a POJO web service and building JAX-WS stateless session EJB web services. I would also like to have access to submit new documentation. As in Geronimo all we need to do is create a WSDL file compliant to standards, we can use jaxws-tools.bat from server installation directory. I am also working on developing a new wizard which works on the lines of Eclipse WTP Web Services Wizard for creating Geronimo web services without depending on WTP. Comments and feedback are welcome. Thanks, On Thu, Jun 12, 2008 at 7:53 AM, Davanum Srinivas [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FYI, Axis2 does support JAXWS 2.1. thx. - -- dims Tim McConnell wrote: | Hi, One of the more obvious deficiencies in the current GEP is the lack | of support for the JAX-WS compliant Web Services. I hope that we can | rectify this in the next major release. Unfortunately, WTP does support | Axis2 but although Axis2 supports many of the WS-* standards, it does | not necessarily support the Java standards (e.g., JSR-224). So it seems | to me that we have these three considerations: | | 1. Determine if and when WTP will provide support for JAX-WS | | 2. If WTP will provide support for JAX-WS in the next release (i.e., WTP | 3.0) still assume some customization to support Geronimo (in the GEP) | | 3. If WTP will not provide support for JAX-WS in the next release (i.e., | WTP 3.0) extend the existing Web Service wizards in WTP to support both | JAX-WS and Geronimo (in the GEP) | | Am I missing anything obvious ?? | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIUIi2gNg6eWEDv1kRAvmZAJ4idBNBAdUiOpxke1IVJkdqcDDk6ACg6ERc fUuNfJs4it0JVrQVjt7VhAE= =xcUa -END PGP SIGNATURE- -- Sainath Chowdary B.Tech III yr, Spring Semester Electronics Communication Engg Indian Institute of Technology Roorkee --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [DISCUSS] Web Service support in GEP
This is actually where the eclipse STP project probably comes in. It does have some support for the JAX-WS/JWS annotation things via the CXF tooling.I'm not sure on the current state of it though. Dan On Jun 12, 2008, at 11:21 AM, Jarek Gawor wrote: This is not a problem with Axis2. Axis2 supports everything that we need for Java EE 5. The problem is that support for web services in the current WTP is very Axis2 specific (e.g. generates Axis2 specific deployment descriptors) and is not very JAX-WS aware (e.g. does not rely on annotations to generate proper wsdl). So, yes, we'll need to determine if and when WTP will provide support for JAX-WS but we will also need to know if it will become more Java EE 5 aware. That is, instead of generating proprietary deployment descriptors it generate Java EE 5 deployment descriptors (web.xml, webservices.xml) so that web services developed with WTP can be deployed on any app server that supports Java EE 5. But maybe that's something we will need to do. Jarek On Wed, Jun 11, 2008 at 9:56 PM, Tim McConnell [EMAIL PROTECTED] wrote: Hi, One of the more obvious deficiencies in the current GEP is the lack of support for the JAX-WS compliant Web Services. I hope that we can rectify this in the next major release. Unfortunately, WTP does support Axis2 but although Axis2 supports many of the WS-* standards, it does not necessarily support the Java standards (e.g., JSR-224). So it seems to me that we have these three considerations: 1. Determine if and when WTP will provide support for JAX-WS 2. If WTP will provide support for JAX-WS in the next release (i.e., WTP 3.0) still assume some customization to support Geronimo (in the GEP) 3. If WTP will not provide support for JAX-WS in the next release (i.e., WTP 3.0) extend the existing Web Service wizards in WTP to support both JAX-WS and Geronimo (in the GEP) Am I missing anything obvious ?? -- Thanks, Tim McConnell --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: svn commit: r658264 - in /geronimo/samples/trunk/samples: ./ CustomerService/ bank/ calculator-stateless-pojo/ dbtester/ inventory/ jaxws-calculator/ jms-mdb-sample/ ldap-sample-app/ myphonebook/
/samples/trunk/samples/servlet-examples/pom.xml Tue May 20 07:47:33 2008 @@ -43,22 +43,4 @@ moduleservlet-examples-jetty/module moduleservlet-examples-tomcat/module /modules - -repositories -repository -idapache-snapshots/id -nameApache Snapshots Repository/name -urlhttp://people.apache.org/repo/m2-snapshot-repository /url -layoutdefault/layout -snapshots -enabledtrue/enabled -updatePolicydaily/updatePolicy -checksumPolicyignore/checksumPolicy -/snapshots -releases -enabledfalse/enabled -/releases -/repository -/repositories - /project Modified: geronimo/samples/trunk/samples/timereport/pom.xml URL: http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/timereport/pom.xml?rev=658264r1=658263r2=658264view=diff = = = = = = = = = = --- geronimo/samples/trunk/samples/timereport/pom.xml (original) +++ geronimo/samples/trunk/samples/timereport/pom.xml Tue May 20 07:47:33 2008 @@ -56,22 +56,4 @@ /plugin /plugins /build - -repositories -repository -idapache-snapshots/id -nameApache Snapshots Repository/name -urlhttp://people.apache.org/repo/m2-snapshot-repository /url -layoutdefault/layout -snapshots -enabledtrue/enabled -updatePolicydaily/updatePolicy -checksumPolicyignore/checksumPolicy -/snapshots -releases -enabledfalse/enabled -/releases -/repository -/repositories - /project --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
On Thursday 17 April 2008, Jacek Laskowski wrote: On Wed, Apr 16, 2008 at 5:20 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. Just to ensure I'm following, you are about to create a activator that would be a bundle listener (o.o.f.BundleListener) and whenever a bundle is registered the activator will scan it for provided services? Can you explain how osgi works now without these META-INF/services-based services? Doesn't it use them at all? I'll provide an example that I'm running into In my OSGi app, if I do something like MessageFactory.newInstance() to create a new SAAJ MessageFactory, the current spec implementations check the contextClassLoader for the META-INF/services/javax.xml.soap.MessageFactory file. Outside of OSGi, that would be properly picked up from the implementation jar. Inside OSGi, the file isn't available, so it defaults to whatever version is hardcoded into the saaj-api jar, which may not even be available. Basically, in OSGi, you cannot have multiple jars/bundles export the META-INF/services directory. That won't work. Thus, the whole META-INF/services thing that all the specs rely on just doesn't work. (IMO: this is a big deficiency in the OSGi spec, but that's my opinion) The goal is to allow the default that is hard coded into the saaj-api jar to be replaced/augmented at runtime based on information the bundle listener finds in the other bundles that are available. Thus, when we call MessageFactory.newInstance(), it would probably still check META-INF/services/javax.xml.soap.MessageFactory (so someone COULD put that in their application bundle and possibly get it), but if not found, use a default value that can actually have a chance of succeeding. Dan The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? Unless I'm mistaken it shouldn't cause any troubles on non-osgi environments and big +1 for the upcoming changes. Jacek -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Geronimo specs jars in OSGi
On Thursday 17 April 2008, Alan D. Cabrera wrote: On Apr 17, 2008, at 7:19 AM, Guillaume Nodet wrote: I've thought about this. The main problem is that you end up having two different jars for the spec, one being a plain jar and another one being an OSGi bundle. Both would not be compatible if the bundle embeds the spec jar, because non osgi environment would not be able to load the jar inside the bundle. Imho, creating two different jars would confuse the users and be more error prone. Non OSGi environments use the vanilla jar as they currently do. OSGi environments load the spec bundle. Doesn't seem confusing to me. Well, it IS confusing when you have projects that are required to work in both OSGi and non-OSGi environments. Suddenly, they have to ship two versions of the same jar so downloads are bigger. They have to document when they can use one versus the other. You have to deal with users that don't read the docs and try to do something with the wrong one, etc... Not fun. There are also issues with maven and dependencies (must depend on the non-osgi for compiling, but the non-osgi for testing/shipping?), but that's a completely different issue. Dan On Thu, Apr 17, 2008 at 4:10 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Apr 16, 2008, at 8:20 AM, Guillaume Nodet wrote: In the past months, I've been working on making the specs jars from Geronimo working in an OSGi environment. All these jars have been published and work great :-) However, lots of these spec jars define factories (stax, saaj for example) that use the META-INF/services/ discovery mechanism to find an implementation of the spec and load it. This mechanism does not fit well in OSGi (really, it does not), mainly because usually, the classloader containing the spec jar will not contain the implementation. I'd like to work on these spec jars so that they will contain an OSGi BundleActivator that would change the behavior of these factories when deployed in an OSGi environment (without changing the behavior in other case). The idea is that the activator would scan OSGi bundles when they are started to find META-INF/services and populate a map that would be used by the factory when creating an object before using the standard mechanism. The only real difference compared to what we currently have would be the addition of a package named org.apache.geronimo.specs.stax (for example) that would contain the needed classes (i suppose two classes), and the modification of the factories to delegate to one of these class before using the standard behavior (the class would do nothing if not deployed in an OSGi environment). Has anyone any objection with such an enhancement in the specs jar ? I would prefer to have a virgin spec jar wrapped inside an OSGi bundle. Here the virgin factories would be overshadowed by the OSGi specific factories. I feel strongly about this but am willing to discuss it. Regards, Alan -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Generated NOTICE files.... a solution
Quick update To get this working correctly for CXF, I need to release new versions of three things: 1) apache-jar-resource-bundle - contains the new resources. (thanks David) 2) maven-shade-plugin (1.0.1) - very minor bug fix to the transformer that merges the NOTICE files together. 3) maven-remote-resources-plugin (1.0) - I updated a few things to allow the appended resources to also be velocity processed. Example: src/main/appended-resources/META-INF/NOTICE.vm would get processed and appended to NOTICE. I need to do a bit more testing this afternoon/evening, but it looks like I'll need to do all three. Dan On Friday 14 March 2008, David Jencks wrote: On Mar 13, 2008, at 6:51 PM, Daniel Kulp wrote: David, I deployed a new snapshot, can you give that a try and make sure it's all OK? Looks great to me! - I can't get a blank line in between the project name and the notice Fixed I'm sure I tried that and it didn't work when I did it :-) - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. In the configuration for the remote-resources plugin, add something like: properties projectNameApache CXF/projectName /properties Aha! that works too many thanks david jencks Dan On Thursday 13 March 2008, David Jencks wrote: As I noted in a previous thread the current NOTICE files generated by the apache-jar-resource-bundle 1.3 are not consistent with apache policy. After some discussion on legal-discuss I've come up with a bundle that no one seems to be able to find anything seriously wrong with: we're starting to use it in geronimo. Aside from possible use by other projects I'd like to use this in an upcoming ApacheDS release, so getting it quickly into a more neutral location would be desirable. I've opened http://jira.codehaus.org/ browse/MRRESOURCES-32 and attached a patch. The basic idea is that the NOTICE file contains only the required apache notice, with no extra text, explanation, horizontal rules, or anything else. Additional required notices can be put in a NOTICE file in appended-resources and automatically appended. Dependencies are listed in an additional generated DEPENDENCIES file, by organization, and listing the license. Note that NOTICE files apply only to the exact contents of the jar in question, not to any dependencies that might be necessary to actually use the jar. For work at apache the normal situation is that the minimal NOTICE is all that is required, and if more is needed its going to be because of some special historical circumstances that can't plausibly be tracked by maven, so explicitly recording this information in a human-written additional NOTICE file is quite appropriate. There is certainly scope for some kind of aggregating bundle for assemblies that do actually contain stuff from other artifacts, such as wars, ears, tar.gzs, etc, but these are pretty clearly an entirely separate use case and likely to require considerably more work to get right. I think starting work on a separate bundle for these might be appropriate. I know of two problems in the patch, both in NOTICE.vm, and I haven't been able to figure out solutions to either: - I can't get a blank line in between the project name and the notice - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. Despite these problems I think this proposal is clearly more in line with apache policy and hope it can be accepted and released quickly. Many thanks david jencks --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Generated NOTICE files.... a solution
David, I deployed a new snapshot, can you give that a try and make sure it's all OK? - I can't get a blank line in between the project name and the notice Fixed - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. In the configuration for the remote-resources plugin, add something like: properties projectNameApache CXF/projectName /properties Dan On Thursday 13 March 2008, David Jencks wrote: As I noted in a previous thread the current NOTICE files generated by the apache-jar-resource-bundle 1.3 are not consistent with apache policy. After some discussion on legal-discuss I've come up with a bundle that no one seems to be able to find anything seriously wrong with: we're starting to use it in geronimo. Aside from possible use by other projects I'd like to use this in an upcoming ApacheDS release, so getting it quickly into a more neutral location would be desirable. I've opened http://jira.codehaus.org/ browse/MRRESOURCES-32 and attached a patch. The basic idea is that the NOTICE file contains only the required apache notice, with no extra text, explanation, horizontal rules, or anything else. Additional required notices can be put in a NOTICE file in appended-resources and automatically appended. Dependencies are listed in an additional generated DEPENDENCIES file, by organization, and listing the license. Note that NOTICE files apply only to the exact contents of the jar in question, not to any dependencies that might be necessary to actually use the jar. For work at apache the normal situation is that the minimal NOTICE is all that is required, and if more is needed its going to be because of some special historical circumstances that can't plausibly be tracked by maven, so explicitly recording this information in a human-written additional NOTICE file is quite appropriate. There is certainly scope for some kind of aggregating bundle for assemblies that do actually contain stuff from other artifacts, such as wars, ears, tar.gzs, etc, but these are pretty clearly an entirely separate use case and likely to require considerably more work to get right. I think starting work on a separate bundle for these might be appropriate. I know of two problems in the patch, both in NOTICE.vm, and I haven't been able to figure out solutions to either: - I can't get a blank line in between the project name and the notice - I can't configure projectName in a suitable place so it shows up in the generated NOTICE. Despite these problems I think this proposal is clearly more in line with apache policy and hope it can be accepted and released quickly. Many thanks david jencks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
[jira] Commented: (GERONIMO-3792) Requesting result from a @WebService fails with NoClassDefFoundError using CXF
[ https://issues.apache.org/jira/browse/GERONIMO-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563046#action_12563046 ] Daniel Kulp commented on GERONIMO-3792: --- This problem is specific to running on the IBM JDK.Three fixes: 1) Switch to a Sun JDK 2) Add suns parser jar to the classpath. Download: https://maven-repository.dev.java.net/nonav/repository/com.sun.xml.parsers/jars/jaxp-ri-1.4.2.jar 3) Switch to a different SAAJ implementation that will work on the IBM JDK. The Axiom SAAJ impl may work, but CXF hasn't been tested with it. Requesting result from a @WebService fails with NoClassDefFoundError using CXF -- Key: GERONIMO-3792 URL: https://issues.apache.org/jira/browse/GERONIMO-3792 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: webservices Affects Versions: 2.0.2, 2.0.x Environment: Windows XP x86-32, IBM J9 1.5.0 SR5, Geronimo w/ Tomcat+OpenEJB+CXF Reporter: Cedric Hurst Attachments: geronimo.log, HelloWorldServiceEAR.ear I'm attempting to create a very simple Hello World web service using CXF as the JAX-WS provider. Whenever I make a call to the web service, I get the following error in the server log: 20:01:15,906 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.NoClassDefFoundError: com.sun.org.apache.xerces.internal.dom.DocumentImpl at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:228) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:148) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200(JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFileClassLoader.java:308) at java.security.AccessController.doPrivileged(AccessController.java:275) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(JarFileClassLoader.java:260) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:422) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:573) at com.sun.xml.messaging.saaj.soap.SOAPPartImpl.init(SOAPPartImpl.java:88) at com.sun.xml.messaging.saaj.soap.ver1_1.Message1_1Impl.getSOAPPart(Message1_1Impl.java:78) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:85) at org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessage(SAAJInInterceptor.java:63) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73) at org.apache.geronimo.cxf.GeronimoDestination.invoke(GeronimoDestination.java:115) at org.apache.geronimo.cxf.CXFWebServiceContainer.processPOST(CXFWebServiceContainer.java:107) at org.apache.geronimo.cxf.CXFWebServiceContainer.invoke(CXFWebServiceContainer.java:83) at org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:180) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:801) I will attach both the EAR and geronimo.log. I've tested against both the latest 2.0.3-SNAPSHOT and the TCK-certified build for jee5-2.0-M6-rc1. Also, I don't seem to encounter this problem when using Axis2 as the JAX-WS provider. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [YOKO] premature tools deletion?
By the time we release it, it will be renamed to o.a.cxf.something. Right now, I'm leaving the package name alone as I merge in some patches that IONA has internally to update it to work with the latest CXF (and latest CXF dependencies like the newer XmlSchema and such). If the package names change, those patches won't apply cleanly. Once it all builds and tests cleanly, the package names will change. Dan On Friday 18 January 2008, Lars Kühne wrote: I assume tools will also live in CXF for the IDL-WSDL compilers. If we keep our own copy (which I think is a good idea) we need to make sure that our package name is different from theirs. I assume they will eventually use o.a.cxf.something, but currently they are not: http://svn.apache.org/viewvc/incubator/cxf/trunk/tools/corba/src/main/ java/org/apache/yoko/tools/ On Jan 17, 2008 7:47 PM, Matt Hogstrom wrote: Keep 'em around, we can always whack them later. On Jan 17, 2008, at 1:51 AM, Alan D. Cabrera wrote: I was wondering if we prematurely deleted tools. It would be nice to have our own IDL compiler. I was thinking that we could move tools to a dir in the sandbox for someone to pick up. Thoughts? Regards, Alan -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: svn commit: r601048 [1/5] - in /geronimo/specs/trunk: ./ geronimo-jsp_2.1_spec/src/main/resources/javax/servlet/jsp/resources/ geronimo-saaj_1.1_spec/ geronimo-saaj_1.3_spec/ geronimo-saaj_1.3_spe
I agree with Guilllaume. I'd prefer a single place to look for spec jars. There is already a 1.1 version of saaj in geronimo-specs, why shouldn't there be a 1.3 version? Dan On Tuesday 04 December 2007, you wrote: Actually, this *is* the axis2 saaj 1.3 spec. I've done that for two reasons: * the spec jar becomes an osgi bundle (along with all the other specs) * it provides a single location for all specs I guess this is the same problem as the stax api which is available in public repo with an ASL license. If these reasons do not seem sufficient, I can easily remove it though. On Dec 4, 2007 8:33 PM, Jarek Gawor [EMAIL PROTECTED] wrote: In Geronimo we use Axis2 SAAJ 1.3 API... I would rather not introduce yet another version of this spec API. Why is this necessary? Jarek On Dec 4, 2007 2:25 PM, [EMAIL PROTECTED] wrote: Author: gnodet Date: Tue Dec 4 11:25:44 2007 New Revision: 601048 URL: http://svn.apache.org/viewvc?rev=601048view=rev Log: Add missing jsp resources, upgrade saaj to 1.3 spec Added: -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: How to compile without Checkstyle
Add -Pnochecks to turn off the checkstyle/pmd checks. -Pfastinstall will skip all the checks as well as skip the tests. Dan On Saturday 20 October 2007, Andreas Schaefer wrote: - gpg control packet Hi Geeks I tried to change some stuff in the ServiceMix trunk in order to resolve a problem. For now I cannot contribute and so I don't care about the layout of my changes. Sure enough I have a quite different opinion on how good code should look like and the compilation fails therefore. So I was wondering if there is a way to compile the trunk without have to bother with Checkstyle making the compilation fail. rant Personally, I have to say that I hate Checkstyle for most part because if a developer cannot read some else's code then he/she should look for another job. Every open-source project has a little bit different format and so one should better deal with it. Checkstyle can be used to prevent coding practices that are prone to cause problems like a single line block without curly brackets but layout is a waste of time, IMHO. /rant I am not a contributor and so you, the contributors, can do whatever you want but I would appreciate if you wouldn't bug me as long as I am not contributing code. Thank you - Andy -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [VOTE] Release ServiceMix 3.1.2
On Tuesday 25 September 2007, Guillaume Nodet wrote: I think we should add a section to the release guide with all the checks we need to do to verify the release: * artifacts are signed * KEYS file present with key inside * check this bug of the gpg plugin This one will be gone soon. I started the vote for the GPG plugin yesterday. Hopefully, by the end of the week, you can update the version of GPG you use to 1.0-beta-4 and that issue will go away. Dan * ... On 9/24/07, Daniel Kulp [EMAIL PROTECTED] wrote: OK. New issue (very minor) Due to a bug in the GPG plugin (I have it fixed, am starting a new release shortly), some of your asc files have the wrong name. Example: http://people.apache.org/~ffang/maven_staging_graduate/org/apache/se rvicemix/samples/loan-broker/loan-broker-lw-su/3.1.2/ loan-broker-lw-su-3.1.2-.zip.asc should just be: loan-broker-lw-su-3.1.2.zip.asc Just rename it and you should be all set. Probably a find for -. should find all of them. Dan On Monday 24 September 2007, Freeman Fang wrote: Hi Dan, You can find my public key from http://pgp.mit.edu:11371/pks/lookup?search=Freeman+Fangop=vindex now, signed by Bo. Also I put it into KEYS. Since I generate new private and public key to sign and deploy it again, so to verify the signature, you need download the kit and its .asc again. Best Regards Freeman Daniel Kulp wrote: On Friday 21 September 2007, Guillaume Nodet wrote: In theory, the public key should be in the web of trust. See http://people.apache.org/~henkp/trust/ Well, yes. But I need to see the key first to see if its been signed by anyone. Right now, we cannot even get that far Freeman: I assume you are sitting pretty close to Bo. The two of you should have a quick key signing party and get your keys signed. Then get the public key into the public keyservers and into the KEYS file. That would be a start (since Bo's key has been signed by other apache folks). Dan On 9/21/07, Daniel Kulp [EMAIL PROTECTED] wrote: Minor issue: Your GPG public key is not in the KEYS file. I also could not find it in the public keyserver at pgp.mit.edu. Thus, I could not verify the signatures. Dan Freeman Fang wrote: Hi All, I have uploaded a version of ServiceMix 3.1.2 for you to review. See http://cwiki.apache.org/confluence/display/SM/ServiceMix+3.1. 2 for all the links and release notes. [ ] +1 Release ServiceMix 3.1.2 [ ] ± 0 [ ] -1 Do not release ServiceMix 3.1.2 Cheers Freeman -- View this message in context: http://www.nabble.com/-VOTE--Release-ServiceMix-3.1.2-tf449161 7s12 04 9.html#a12824617 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Problems with service mix dependencies using maven
://people.apache.org/repo/m2-incubating-repository/org/apache/se rvicemix/servicemix-soap/3.1.2/servicemix-soap-3.1.2.jar Downloading: http://www.ibiblio.org/maven2/org/apache/servicemix/servicemix-soap/ 3.1.2/servicemix-soap-3.1.2.jar Downloading: http://svn.apache.org/repos/asf/incubator/servicemix/m2-repo/org/apa che/servicemix/servicemix-soap/3.1.2/servicemix-soap-3.1.2.jar [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.servicemix:servicemix-common:jar:3.1.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix-DartifactId=servicemix-common \ -Dversion=3.1.2 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix-DartifactId=servicemix-common \ -Dversion=3.1.2 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.servicemix.tutorial:tutorial-file-su:jbi-service-unit:1.0 -SNAPSHOT 2) org.apache.servicemix:servicemix-file:jar:3.1.2 3) org.apache.servicemix:servicemix-shared:jar:3.1.2 4) org.apache.servicemix:servicemix-common:jar:3.1.2 2) org.apache.servicemix:servicemix-shared:jar:3.1.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix-DartifactId=servicemix-shared \ -Dversion=3.1.2 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix-DartifactId=servicemix-shared \ -Dversion=3.1.2 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.servicemix.tutorial:tutorial-file-su:jbi-service-unit:1.0 -SNAPSHOT 2) org.apache.servicemix:servicemix-file:jar:3.1.2 3) org.apache.servicemix:servicemix-shared:jar:3.1.2 3) org.apache.servicemix:servicemix-soap:jar:3.1.2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix-DartifactId=servicemix-soap \ -Dversion=3.1.2 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix-DartifactId=servicemix-soap \ -Dversion=3.1.2 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.servicemix.tutorial:tutorial-file-su:jbi-service-unit:1.0 -SNAPSHOT 2) org.apache.servicemix:servicemix-file:jar:3.1.2 3) org.apache.servicemix:servicemix-shared:jar:3.1.2 4) org.apache.servicemix:servicemix-soap:jar:3.1.2 -- 3 required artifacts are missing. for artifact: org.apache.servicemix.tutorial:tutorial-file-su:jbi-service-unit:1.0 -SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-incubating (http://people.apache.org/repo/m2-incubating-repository ), apache.incubating (http://people.apache.org/repo/m2-incubating-repository ), jboss-http-repository (http://repository.jboss.com/maven2/) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 40 seconds [INFO] Finished at: Tue Sep 25 12:57:56 CEST 2007 [INFO] Final Memory: 8M/254M [INFO] -- Eduardo de Vera -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [VOTE] Release ServiceMix 3.1.2
Minor issue: Your GPG public key is not in the KEYS file. I also could not find it in the public keyserver at pgp.mit.edu. Thus, I could not verify the signatures. Dan Freeman Fang wrote: Hi All, I have uploaded a version of ServiceMix 3.1.2 for you to review. See http://cwiki.apache.org/confluence/display/SM/ServiceMix+3.1.2 for all the links and release notes. [ ] +1 Release ServiceMix 3.1.2 [ ] ± 0 [ ] -1 Do not release ServiceMix 3.1.2 Cheers Freeman -- View this message in context: http://www.nabble.com/-VOTE--Release-ServiceMix-3.1.2-tf4491617s12049.html#a12824617 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release ServiceMix 3.1.2
On Friday 21 September 2007, Guillaume Nodet wrote: In theory, the public key should be in the web of trust. See http://people.apache.org/~henkp/trust/ Well, yes. But I need to see the key first to see if its been signed by anyone. Right now, we cannot even get that far Freeman: I assume you are sitting pretty close to Bo. The two of you should have a quick key signing party and get your keys signed. Then get the public key into the public keyservers and into the KEYS file. That would be a start (since Bo's key has been signed by other apache folks). Dan On 9/21/07, Daniel Kulp [EMAIL PROTECTED] wrote: Minor issue: Your GPG public key is not in the KEYS file. I also could not find it in the public keyserver at pgp.mit.edu. Thus, I could not verify the signatures. Dan Freeman Fang wrote: Hi All, I have uploaded a version of ServiceMix 3.1.2 for you to review. See http://cwiki.apache.org/confluence/display/SM/ServiceMix+3.1.2 for all the links and release notes. [ ] +1 Release ServiceMix 3.1.2 [ ] ± 0 [ ] -1 Do not release ServiceMix 3.1.2 Cheers Freeman -- View this message in context: http://www.nabble.com/-VOTE--Release-ServiceMix-3.1.2-tf4491617s1204 9.html#a12824617 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: removal of spring dependencies from cxf module
Kevan, On Monday 27 August 2007, Kevan Miller wrote: On Aug 25, 2007, at 5:44 PM, Daniel Kulp wrote: From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. OK. First I've heard of loss of functionality... Is there loss of functionality? Or things become harder without Spring? For the most part, it's things become much harder, mostly because we really only document the Spring way of doing things. Doing things non-spring requires a bunch of casting of JAX-WS things into proprietary things, calling semi-hidden API's, etc... The spring way is very clean, documented, etc... See: http://cwiki.apache.org/CXF20DOC/configuration.html particularly the sub-pages listed at the bottom. One area that definitely doesn't work without spring is the ws-policy stuff. Turning on policy requires some spring stuff right now. I think that's logged as a bug. If things become harder, an important question is who pays the price? The embedder (i.e. us)? Or the user? Definitely the user IF they need something outside the normal soap/http cases. For just straight JAX-WS TCK compliance stuff, it doesn't matter one way or the other. One example: lets say your using a JAX-WS client in your application that needs to talk to an OLD .NET service. The older .NET stuff sometimes doesn't like HTTP chunking.There are docs at: http://cwiki.apache.org/CXF20DOC/client-http-transport.html to describe how to configure the client to not use chunking. There's also a bunch of things there for configuring the SSL connections, etc... I have no real issue with our CXF server module requiring Spring. I'm less happy if we're requiring that Spring be accessible from a client application module to configure CXF web services client capabilities. Can it be optional? Set some filtering thing so if they want/need the spring stuff, they can get it? That all said, I DON'T know if Geronimo current exposes a spring context or anything that would currently allow any of that to work. My gut feeling says no, but I'm not really sure. It's quite possible that it doesn't work in Geronimo right now anyway. It's probably that the spring stuff in Geronimo is on a more global basis and wouldn't allow per-application configuration anyway. Probably Jarek would need to weigh in how that currently works as I don't really know. Ideally to me, if the app has a META-INF/cxf.xml or similar (some other key or something), the spring stuff would allow configuring of a bunch of the things specific for that application. Dan I'm way less happy if we require the same Spring instance be accessible from the CXF server module and the client application module. This is the case, at the moment. I think this needs to be changed. I suppose one option might be to document how to put spring back in if someone needs it. We could then add more advanced thing to those docs like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS transports, etc Kind of an Advanced WebServices with CXF type docs. Can you point me to documentation on how a user configures this functionality currently? --kevan -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: removal of spring dependencies from cxf module
From my standpoint, it would be greatly preferred if you could find a way to leave spring for CXF. There is definitely a lot of functionality that would be lost if spring is not available. In particular, if a user want to configure various things like message logging or WS-Addressing/WS-RM, https SSL keys, keep-alives and chunking, etc..., without the spring config, it becomes quite a bit harder. For very basic usage, spring is optional. But once you want some customizations, you really need it. I suppose one option might be to document how to put spring back in if someone needs it. We could then add more advanced thing to those docs like where to get the additional jars for WS-RM/WS-A/WS-Security, JMS transports, etc Kind of an Advanced WebServices with CXF type docs. Dan On Saturday 25 August 2007, Kevan Miller wrote: On Aug 25, 2007, at 10:53 AM, Jeff Genender wrote: Kevan Miller wrote: On Aug 24, 2007, at 5:35 PM, Jeff Genender wrote: Kevan, IIU the reason you are asking, removal of the Spring dependencies from CXF would appear to be a band aid and temporary fix to the real issue. Is this about the Spring versioning and different versions getting loaded? (If not then never mind) I wouldn't characterize this as a band-aid. And I doubt that I would advocate a different approach to solving this problem in a 2.0.x release. Umm...why wouldn't you characterize this as a band aid? The problem is our class loaders. You still have this problem if someone integrates something that uses Spring...right? Sorry. I must not be explaining things very well... At present our CXF integration requires access to the same instance of Spring in both the cxf module as well as the client application module. This means that the client application module cannot have a unique instance of Spring and work with CXF -- this must be fixed regardless of our ClassLoader structure. I'm pretty sure that you would agree with this? In addition, I would not advocate a significant change to our ClassLoader behavior in a 2.0.x release (although I may be about to advocate for a change to our EAR classloading structure -- more on this in a different thread). At best this type of change would belong in a 2.x release, IMHO, since client applications are likely to be reliant on our current classloading behavior. FYI, at present, cxf-based web services client code requires access to Spring classes from the application's ClassLoader. So, even if you wanted to completely isolate the application ClassLoader from system ClassLoaders, this must be changed. I probably could have narrowed my request a bit by saying can we just fix this web services client code dependency -- better, I think to remove the spring dependency all together from our cxf module. So what would happen if I integrate another 3rd party component that uses Spring...say...Terracotta DSO? Or...ServiceMix? What happens then? At present, these components can be integrated into Geronimo. Depending on their module-level dependencies, there might be some intra-server spring versioning problems. I assume that we would resolve those. Currently, client applications that want to run their own Spring instance would need the following in their deployment plan environment: hidden-classes filterorg.springframework./filter filterMETA-INF/spring/filter /hidden-classes Until the above CXF-Spring requirement is fixed, this filtering may cause problems in some client applications using web services. Geronimo used to hide these Spring classes/resources from client applications automatically. However, this automatic hiding of Spring was removed because of the CXF-Spring issue that is currently being discussed. So, IMO: 1. We need to break the requirement for the sharing of a single instance of Spring betweeen the cxf module and a client application module. This can be via removal of the CXF Spring dependency all together, or by some alternate means (e.g. reworking of the web services client code)... Sorry to be vague, here. I'm not currently familiar with the details of the client code... 2. Once 1 is addressed, reinstate the automatic filtering of Spring classes/resources. 3. For a 2.x release, discuss alternate/preferred behavior. --kevan -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Could we use the maven-remote-resources plugin to install the legal files?
On Wednesday 15 August 2007, Jason Dillon wrote: Yup, this should work... assuming the plugin functions. I just tried to hook it up from use in the Groovy m2 stuff and it puked up some NPE crapo. That's not good. Sure you grabbed the latest version? Also, I'm not sure that the LICENSE.txt and NOTICE.txt generation stuff is going to fit our needs ASIS, but we can always get it fixed. Yep. You can either publish your own resource bundle or we can get a new apache-jar-resource-bundle version pushed if you need stuff there or a new version of remote-resources pushed if that's needed. On Aug 15, 2007, at 4:39 PM, David Jencks wrote: It normally gets stuff from a resource bundle such as org.apache:apache-jar-resource-bundle:1.0 which has the standard apache license and notice files in it. It installs them into at least normal and test jars, I haven't checked about source jars. Yep. It does source jars and javadoc jars as well. (providing you are using the latest versions of the javadoc plugin). I think you can configure it to add local files as well but I haven't figured out exactly how. I don't think that works. It requires a full maven module name (groupid:artifactid:version) in order to work. If worst came to worst we could publish jars of our unusual notice files. It might aggregate stuff from the depenency's notice files, I'm not quite sure what the documentation is saying. No, it doesn't do that. Basically, it can go through all the runtime dependencies and produces something like: This product includes/uses software, JTA 1.0.1B (http://geronimo.apache.org/specs/geronimo-jta_1.0.1B_spec), developed by Apache Software Foundation (http://www.apache.org) License: The Apache Software License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0.txt) in the NOTICE file that gets put in the META-INF dir. However, that's really just driven by the velocity template in the apache-jar-resource-bundle.If you want your own format, you can create your own resource bundle. The remote-resources plugin just adds all the dependencies as a List into the properties that are fed to velocity and velocity can do whatever it needs to do. There are two advanced things that may be required: 1) Appending - the remote resources supports the ability to append local snippets (default location is src/main/appended-resources) to the stuff generated from velocity. For CXF we use this to add some extra disclaimers and such like: This product also includes schemas and specification developed by: - the W3C consortium (http://www.w3c.org) (http://www.w3.org/XML/1998/namespace) 2) Fixing bad poms - there a lot of crappy poms out there that generate junk in the NOTICE files. Poms that don't include the organization, license, or sometimes even a real name. RemoteResources does support the ability to merge in some corrected data. CXF does this to workaround the fact that most of Sun's poms are very minimal. Enjoy! Dan I think using a single standard copy of the license/notice files would be a lot more pleasant than having a copy in each dir, and unusual modules would be easier to spot. thanks david jencks -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: tooling for web services
On Tuesday 14 August 2007, Lin Sun wrote: I think it would be great to provide some .sh/.bat files to expose these tools so that people can use them directly without going through sun's website and installing the tooling from Sun (which is what we recommend our users to do in our jaxrpc web service example on the wiki.). Just FYI: if you want some apache licensed tooling for JAX-WS, the Apache CXF stuff does generate code that properly passes the reverse tests for the TCK. (at least for standalone) That said, for eclipse, keep an eye on the STP project at eclipse. It supports some extra tooling in eclipse for doing JAX-WS annotations and such. Dan Lin Jarek Gawor wrote: I'm wondering what people think about exposing tools such as wsdl2java or java2wsdl in Geronimo. Geronimo already contains and uses these tools internally but they are not exposed as command line clients. This could make developing web services on Geronimo a little bit easier. I see that such tools were not exposed before in Geronimo 1.1 so maybe the recommendation is to use the eclipse plug-in? Does the eclipse plug-in support JAX-WS services? Jarek -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Checkstyle and PMD
Yep. When you specifically activate a profile via the command line, all the activeByDefault profiles are deactivated. Thus, if you have the checks in an activeByDefault profile, they will run when you just type mvn, but when you run -Pnochecks, the nochecks profile activates instead of the checks profile and the checks don't run. In this case, the nochecks profile is empty in that it doesn't configure anything. CXF does it that way and it works really well. The hard core developers know about -Pnochecks and -Pfastinstall (fastinstall also skips the tests) and use them. However, the getting starting people run mvn which executes the checks. This makes sure patches that they submit are formatted correctly and such which makes applying the patches easier. For CXF, we also have a -Psetup.eclipse profile that REALLY gets things setup in eclipse. (goes way beyond eclipse:eclipse) It injects the CXF checkstyle rules into the workspace, sets the workspace warning levels appropriately, injects the code format template, import order, etc For each project, it also sets up Checkstyle and PMD (assumes you have the checkstyle and PMD plugins installed). Thus eclipse does all the code format checks for me.Thus, I usually run with -Pnochecks. Dan On Thursday 26 July 2007 04:29, Guillaume Nodet wrote: I'm sure Dan Kulp can comment on that but it seems that the profile which contains the checks is disabled when the empty one is activated. On 7/26/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 7/26/07, Guillaume Nodet [EMAIL PROTECTED] wrote: As the profile is empty it simply means that the checks wont be configured and activated :-) How does an empty profile prevent the invocation of Checkstyle and PMD? Sounds like Maven voodoo. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/ -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Cleaning up the snapshots....
The infrastructure folks were complaining on IRC about the size of the snapshot repository. However, over 1 third of the size is in servicemix snapshots.Could someone take some time and clean out some of the old ones? Maybe do things like: find . -name 3.0-incubating-SNAPSHOT | xargs rm -rf or something to cleanout the snapshots for the stuff that was already released. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Two steps build
On Wednesday 25 July 2007 15:52, Guillaume Nodet wrote: Yes it should. The main problem comes from the servicemix maven plugin: it relies ou maven extensions plugins which can not be built and used in the same run :-( Other ways include fixing maven (if possible), splitting the release cycles as discussed in an earlier thread, using an ant file or batch for the main build... Umm you can build and use maven plugins in the same run. That's not a problem. CXF does it in several places. Dan On 7/25/07, Gert Vanthienen [EMAIL PROTECTED] wrote: Guillaume, What is causing the two step build in the first place? Shouldn't Maven take care of building everything in the right order automatically, based on the interdependencies of the subprojects? Gert Guillaume Nodet wrote: I was wondering if someone knows a way to spawn a maven build from within maven. Maybe this would be a way to remove the two steps build needed the first time (and when releasing too). -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: SNAPSHOT dependencies that need to be released.
On Tuesday 10 July 2007 22:42, Prasad Kashyap wrote: The following Geronimo dependencies uses SNAPSHOT versions. Can we please chase these projects and get them to release the artifacts, whatever it takes; contacts, muscles, bribes, favors, etc :-) openejbVersion3.0-incubating-SNAPSHOT/openejbVersion groupIdorg.apache.cxf/groupId artifactIdcxf-api/artifactId version2.0-incubator-SNAPSHOT/version CXF was officially released last week. The 2.0-incubator release version should be available in the incubator maven repository. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Error formatting macro: snippet
I just checked the confluence snippet macro config and it looks ok. It
has a mapping of:
prefix: servicemix/
to url: http://svn.apache.org/repos/asf/incubator/servicemix/
Thus, on your page, it should just be:
{snippet:id=expression|lang=xml|
url=servicemix/trunk/common/servicemix-components/src/test/resources/org/apache/servicemix/components/net/ftp.xml}
Dan
On Tuesday 10 July 2007 10:25, Gert Vanthienen wrote:
L.S.,
Some of our documentation pages use Confluence's snippet macro to
include code sample (e.g.
http://incubator.apache.org/servicemix/ftp.html). Currently, this
macro doesn't seem to work any more:
Error formatting macro: snippet:
java.lang.IllegalArgumentException: Invalid url: must begin with a
configured prefix.
We're not alone, apparently the Struts team has the same problem (e.g.
http://struts.apache.org/2.0.5/docs/conversion-validator.html). A
quick search on the web seems to indicate that this is some kind of
confguration problem with the snippet macro. Who can administer the
Confluence instance that hosts our website to resolve this issue?
Gert
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
[jira] Commented: (GERONIMO-3265) Spring stale version in 2.0-M6-rc1
[ https://issues.apache.org/jira/browse/GERONIMO-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509873 ] Daniel Kulp commented on GERONIMO-3265: --- CXF does use spring. However, we pull in 2.0.4 (and work fine with 2.0.5). I'm not sure where the 2.0 version would be coming from. Spring stale version in 2.0-M6-rc1 -- Key: GERONIMO-3265 URL: https://issues.apache.org/jira/browse/GERONIMO-3265 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.0-M6 Environment: Windows XP SP2, Sun JSDK 1.5.07, Geronimo (2.0-M6-rc1) obtained from: http://people.apache.org/~hogstrom/2.0-M6-rc1/geronimo-tomcat6-jee5-2.0-M6-rc1-bin.zip (2.0-M6-rc1) Reporter: Alexei Kozich 1. This Geronimo build includes spring-beans.jar, spring-context.jar and spring-core.jar of version 2.0. So as far as we know, version 2.0 does not fully support integration with JPA implementations. 2. We developed an enterprise application (ear) which utilizes Spring 2.0.2 and OpenJPA. OpenJPA comes with Geronimo. Deployment and start of this application fails, because of different versions of Spring (our application expects spring-beans.jar, spring-context.jar and spring-core.jar to be at least of version 2.0.2 but Geronimo contains libs of version 2.0 (the lack of some methods in version 2.0 is the problem here). 3. If we try to use inverse-classloading or hidden classes (org.springframework) in geronimo-web.xml and include all necesary libs in WEB-INF/lib following Exception is thrown during deployment and start of the application (see below). 4. We found temporary workaround: to replace spring-beans.jar, spring-context.jar and spring-core.jar of version 2.0 with jars of version 2.0.2 in Geronimo repository without using of inverse-classloading and hidden classes and everything looks fine. 5. So as far as I understand this out-of-the-box Geronimo build could not be used as Server for Spring-OpenJPA appications. At least Spring libs upgrade could solve this problem. 6. Another problem is following Exception when using hidden classes or inverse-classloading to load application jars first. ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/springAppContext.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface Caused by: java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:119) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:96) at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:526) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:515) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:495) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340) at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:317) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:125) at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:141) at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:123) at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:91) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:94) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:292
Re: Can we conclude the Vote on WS-META-Data early? --- Please resond if you object
On Thursday 14 June 2007 17:08, David Jencks wrote: Alternatively, we can use the release plugin but the release plugin means we can't vote on the final jars since it automatically publishes to the final repository. I just wanted to jump in and correct this misconception The release plugin doesn't publish anything anywhere. All is does is update poms, do some scm things, and re-invoke maven.It's the deploy plugin that actually does the deploy. By default, the deploy plugin will deploy to the distributionManagement stuff specified in the pom. However, it does support a altDeploymentRepository flag to deploy to a different location. That all said, a LOT of work was put into various maven plugins in the last couple of months of 2006 and the first few of this year to get things setup to be able to do the normal: mvn release:prepare; mvn release:perform steps and have it do it in a way acceptable to normal apache rules. That includes deploying to a staging area, GPG signing everything, injecting LICENSE and NOTICE files into the jars (including source and javadoc jars), etc... At this point, it does require a little extra configuration in the pom, but not a lot. The main thing that's still missing is a tool to merge the staged area into the final repository. (straight copies may not end up with the correct metadata.xml files) There is another maven plugin that does this, but it hasn't been released yet. You kind of have to check it out from svn and build it yourself to use it. Some of us release managers are pretty lazy. If all I have to do is type the above command and answer a few questions (tag names and such), I'm happy. More than that and I'm not. :-) Anyway, thanks for all the effort to get the metadata jar out to us. Thanks! -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [VOTE] Release ServiceMix 3.1.1 (2nd try)
+1 from me. This build looks much better than the earlier builds. Dan On Tuesday 22 May 2007 03:03, Guillaume Nodet wrote: I have uploaded a version of ServiceMix 3.1.1 in the standard repo for you to review. See http://incubator.apache.org/servicemix/servicemix-311.html for the future download page and release notes (these are also included in the distribution). The distribution have been uploaded to http://people.apache.org/~gnodet/servicemix-3.1.1-incubating/org/apach e/servicemix/apache-servicemix/3.1.1-incubating/ I send this mail both to the dev list and [EMAIL PROTECTED], as a first vote has been conducted on the ServiceMix dev list and some issues have been fixed since that, so hopefully this one will be fine. [ ] +1 Release ServiceMix 3.1.1 [ ] +/- 0 [ ] -1 Do not release ServiceMix 3.1.1 The rat log is available at http://people.apache.org/~gnodet/rat-servicemix-3.1.1-incubating.txth ttp://people.apache.org/%7Egnodet/rat-servicemix-3.1.1-incubating.txt Here's my +1 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [VOTE] Release ServiceMix 3.1.1
Umm... the sources jars still don't have the LICENSE/DISCLAIMER/NOTICE files in them. The sigs look OK though. They validated fine. Dan On Friday 18 May 2007 10:13, Guillaume Nodet wrote: I have uploaded a new release that should solve the last two problems. I agree we will have to address the first one before next release. I think due to this new upload, the vote period should be extended by 24 hours. On 5/17/07, Daniel Kulp [EMAIL PROTECTED] wrote: On Tuesday 15 May 2007 10:28, Guillaume Nodet wrote: [ X ] -1 Do not release ServiceMix 3.1.1 I will upload a rat report asap. I figure I'll -1 this before it gets to [EMAIL PROTECTED] Issues: 1) Procedural: you published these into the release repository. Thus, they are already released. They should be staged into a staging area, voted on there, then if the vote passes, moved into the release repository. As it stands right now, it's technically already released without a vote. 2) The sources jars and javadoc jars don't have the disclaimer, notice, or license files in them. Thus, they are not releasable. (look into the remote-resources plugin, the cxf/trunk/parent pom is an example.) 3) Nothing has been gpg signed. All release artifacts must be gpg signed. A release profile with the gpg plugin would solve this. (you can use the cxf/trunk pom as an example) Anyway, IMO, it's not ready to go.If you have problems with the maven stuff, feel free to ping me. I'd be glad to help out. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [VOTE] Release ServiceMix 3.1.1
On Tuesday 15 May 2007 10:28, Guillaume Nodet wrote: [ X ] -1 Do not release ServiceMix 3.1.1 I will upload a rat report asap. I figure I'll -1 this before it gets to [EMAIL PROTECTED] Issues: 1) Procedural: you published these into the release repository. Thus, they are already released. They should be staged into a staging area, voted on there, then if the vote passes, moved into the release repository. As it stands right now, it's technically already released without a vote. 2) The sources jars and javadoc jars don't have the disclaimer, notice, or license files in them. Thus, they are not releasable. (look into the remote-resources plugin, the cxf/trunk/parent pom is an example.) 3) Nothing has been gpg signed. All release artifacts must be gpg signed. A release profile with the gpg plugin would solve this. (you can use the cxf/trunk pom as an example) Anyway, IMO, it's not ready to go.If you have problems with the maven stuff, feel free to ping me. I'd be glad to help out. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: [VOTE] Release ServiceMix 3.1.1
One of the problem is to be able to test it. Archetypes depends on the repository where the artifacts are deployed, so if you deploy to a staging repo, there's no way to test them. The problem only happen because we are in incubation, How is this an incubation problem? Once you graduate, you DEFINITELY don't want to be deploying to the release area before the vote. They would automatically get synced to central within 4 hours and you run into a very bad situation of artifacts going out without being properly endorsed. thus artifacts are not available through public repository. Btw, the maven incubating repo is not completely endorsed by the ASF, Everything in that repo is supposed to be endorsed by the Incubator PMC. If they haven't said its OK, it's not OK. so I don't think they should be considered released as soon as they are there. Anyway, the main problem is the former and I don't see any simple solution to it unfortunately. You'll need to work with the Maven folks to find a solution. Deploying potential releases to the release area before a vote is not a viable option. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: JAXB upgrade
I'll pull the JAX-WS 2.1 stuff now. I just received word from Sun that they are pulling JAX-WS 2.1 anyway. (they are respinning it to address some issues with the WS-A stuff)Thus, it will be removed from the maven repository ASAP and our builds will fail. Give my 1/2 hour or so. Dan On Monday 05 March 2007 11:21, Jarek Gawor wrote: Would it be possible for CXF folks to decide this issue soon? In Geronimo land we are kind of stuck right now (we have CXF disabled from the build because of the JAX-WS/JAXB issues) we are not making a lot of progress now in terms of intergration and testing. Thanks, Jarek On 3/2/07, Dan Diephouse [EMAIL PROTECTED] wrote: I'm OK with rolling back for now. However the spec itself is final and the RI impl is already out: https://jax-ws.dev.java.net/2.1/ Everyone else ok with it? Cheers, - Dan On 3/2/07, David Jencks [EMAIL PROTECTED] wrote: At this time Geronimo can only certify with JAXB 2.0 and JAXWS 2.0. We're hoping that sun will update the tck to allow supporting the 2.1 specs, but as far as we can tell this has not yet happened. Getting information out of sun about this stuff can be difficult, but perhaps if we started now and now and are sufficiently persistent we will eventually find out something useful. Are the 2.1 spec versions officially released? Meanwhile we'd certainly appreciate it at Geronimo if you went back to the 2.0 spec versions for now. thanks david jencks On Mar 1, 2007, at 7:43 AM, Jarek Gawor wrote: Oh... I didn't even realize you guys are targeting JAX-WS 2.1. Now, I'm not sure how that affects things. Jarek On 3/1/07, Dan Diephouse [EMAIL PROTECTED] wrote: I'm happy to revert the change, but I think that we ultimately need it. I believe we're targeting JAX-WS 2.1 (we switched the API jar the other day), and that requires JAXB 2.1. There are many benefits from a user perspective in 2.1. For isntance it has a lot better functionality for things like WS-A and also makes it easier for people to use substitution types, which requires all sorts of hacks right now. Is Geronimo just looking to release JAX-WS 2.0 support or 2.1? Any idea if its possible to certify Geronimo with 2.1? Or does certification require 2.0? I'm not sure what the status is of the JAX-WS 2.1 TCK either. - Dan (I CC'd [EMAIL PROTECTED] in, hope thats ok) On 2/28/07, Jarek Gawor [EMAIL PROTECTED] wrote: Hi again, CXF code was recently upgraded to JAXB 2.1 and so I tired to figure out what sort of implications that might have on Geronimo. First of all, JAXB is one of those libraries that is shared by all applications in the Geronimo server. We also have a bunch of different components using JAXB to do deployment descriptor parsing, etc. So if we upgrade JAXB in G, we have to retest all these subcomponents to make sure they are ok. And I think in general that should be ok but potentially time consuming. Another potential issue that somebody raised was TCK testing. We don't know what happens if for example TCK expects JAXB 2.0 API but gets JAXB 2.1 API/implementation. Maybe nothing (as things supposed to be backwards compatible) but maybe it blows up. That's another thing for us to worry about. So, if this JAXB upgrade is not a critical issue for CXF would it be possible to switch back to JAXB 2.0? Thanks, Jarek -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: JAXB upgrade
On Monday 05 March 2007 12:01, Dan Diephouse wrote: Well that settles that! Do you know: are they changing the spec? Or are they just pulling their implementation? They are changing it slightly. It has something to do with the Last Call Working Draft of the Web Services Addressing 1.0 - Metadata http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202/ having some changes in it. They didn't want 2.1 out there that's incompatible with it, or something like that. I don't think it's API changes, but it may be. Just javadoc, docs, and possibly spec compliance (optional vs required type changes). Not really sure at this point. In anycase, I'm removing it from our builds. Tests are running now. Dan - Dan On 3/5/07, Daniel Kulp [EMAIL PROTECTED] wrote: I'll pull the JAX-WS 2.1 stuff now. I just received word from Sun that they are pulling JAX-WS 2.1 anyway. (they are respinning it to address some issues with the WS-A stuff)Thus, it will be removed from the maven repository ASAP and our builds will fail. Give my 1/2 hour or so. Dan On Monday 05 March 2007 11:21, Jarek Gawor wrote: Would it be possible for CXF folks to decide this issue soon? In Geronimo land we are kind of stuck right now (we have CXF disabled from the build because of the JAX-WS/JAXB issues) we are not making a lot of progress now in terms of intergration and testing. Thanks, Jarek On 3/2/07, Dan Diephouse [EMAIL PROTECTED] wrote: I'm OK with rolling back for now. However the spec itself is final and the RI impl is already out: https://jax-ws.dev.java.net/2.1/ Everyone else ok with it? Cheers, - Dan On 3/2/07, David Jencks [EMAIL PROTECTED] wrote: At this time Geronimo can only certify with JAXB 2.0 and JAXWS 2.0. We're hoping that sun will update the tck to allow supporting the 2.1 specs, but as far as we can tell this has not yet happened. Getting information out of sun about this stuff can be difficult, but perhaps if we started now and now and are sufficiently persistent we will eventually find out something useful. Are the 2.1 spec versions officially released? Meanwhile we'd certainly appreciate it at Geronimo if you went back to the 2.0 spec versions for now. thanks david jencks On Mar 1, 2007, at 7:43 AM, Jarek Gawor wrote: Oh... I didn't even realize you guys are targeting JAX-WS 2.1. Now, I'm not sure how that affects things. Jarek On 3/1/07, Dan Diephouse [EMAIL PROTECTED] wrote: I'm happy to revert the change, but I think that we ultimately need it. I believe we're targeting JAX-WS 2.1 (we switched the API jar the other day), and that requires JAXB 2.1. There are many benefits from a user perspective in 2.1. For isntance it has a lot better functionality for things like WS-A and also makes it easier for people to use substitution types, which requires all sorts of hacks right now. Is Geronimo just looking to release JAX-WS 2.0 support or 2.1? Any idea if its possible to certify Geronimo with 2.1? Or does certification require 2.0? I'm not sure what the status is of the JAX-WS 2.1 TCK either. - Dan (I CC'd [EMAIL PROTECTED] in, hope thats ok) On 2/28/07, Jarek Gawor [EMAIL PROTECTED] wrote: Hi again, CXF code was recently upgraded to JAXB 2.1 and so I tired to figure out what sort of implications that might have on Geronimo. First of all, JAXB is one of those libraries that is shared by all applications in the Geronimo server. We also have a bunch of different components using JAXB to do deployment descriptor parsing, etc. So if we upgrade JAXB in G, we have to retest all these subcomponents to make sure they are ok. And I think in general that should be ok but potentially time consuming. Another potential issue that somebody raised was TCK testing. We don't know what happens if for example TCK expects JAXB 2.0 API but gets JAXB 2.1 API/implementation. Maybe nothing (as things supposed to be backwards compatible) but maybe it blows up. That's another thing for us to worry about. So, if this JAXB upgrade is not a critical issue for CXF would it be possible to switch back to JAXB 2.0? Thanks, Jarek -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog -- J. Daniel Kulp Principal Engineer IONA P
