Re: XBean and QDox
Alan D. Cabrera wrote: James Strachan wrote: On 8/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-spring JDK 5 specific. Any thoughts ? We could compile the source with Java 5, use source-only annotations maybe - then generate Java 1.4 compliant code via retrotranslator. Can I debug retrotranslated code in JDK14? Regards, Alan Yes. Dain did a whole bunch of experiments on this if you want to know more details. From what I understand they went quite well. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: [VOTE] Servicemix 3.0 M1
Guillaume Nodet wrote: * Which website is supposed to be the right one? http://servicemix.org/ or http://incubator.apache.org/servicemix/ ? I guess http://incubator.apache.org/servicemix/, we need to fix some links. Can we get servicemix.org to redirect to the incubator site then? One is codehaus, one is apache... Well, the XFire example sources are still available at http://svn.apache.org/repos/asf/incubator/servicemix/trunk/servicemix-assembly/src/sandbox/xfire-binding/ I removed it from the distribution because this is a pure XFire sample and is in no way related to ServiceMix (it may be better to put it in XFire distribution ;) ) Yeah, IIRC, Hiram just copied this from XFire CVS at one point, so I think we have it. I wanted to put together a true example that shows how to do some more stuff with xfire. I guess we could write a pure xfire binding component: there are a couple of enhancements that xfire would need to keep up with servicemix-http ;) like jett6 continuations, accessing directly a stax based jaxp source, use of commons-httpclient pooling on the client side. This would enable to use xfire handlers like the WS-Security one directly. But this deserves another thread ... OK, yeah this does deserve another thread. I'll take a look into some of these issues soon and see what I can do. None of these are necessariliy blockers as its a M1 release, so I am +0. I would like to see SM-393 addressed and the soap binding link fixed, but don't have time to do it myself at the moment. I will fix the link (which is not a bad link actually, the doc has not been written). Ok, cool. Cheers, - Dan -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com
Re: ServiceMix and security
Hiya Guillaume, Some thoughts inlined... Guillaume Nodet wrote: Securing messages is not handled yet, but can be done using WS-Security on soap enabled transports (servicemix-jms and servicemix-http binding components). Is there a need to secure messages within the bus ? Could there be a situation where multiple users are using the bus and they all have different levels of access? And also in that situation could there be a message broadcast where only certain users have access to the information? If so I think there may be some need for encrypted messages. Securing services seems to be the most difficult part. The JMS specs only mention the use of the subject property on a NormalizedMessage http://java.sun.com/integration/1.0/docs/sdk/api/javax/jbi/messaging/NormalizedMessage.html#setSecuritySubject(javax.security.auth.Subject). The main problem is how to set / use this information and how informations about service authorizations. Such security informations may be embedded in the service unit / service assemblies deployment, or may be configured separately on the container. When a component sends a jbi exchange, the container could check the authorizations for the destination endpoint (or service, interface ?). However, I do not have any clue on how this information will be provided by binding components when an external message comes in. HTTP transport could leverage HTTP authentication, but what about the other transports ? I think I see two ways we could set the SecuritySubject: - At the configuration level, i.e. configuring the username/password in the BC configuration - The API of the Binding Component - say we have a BC which access a service on the bus that needs the SecuritySubject. When the user interacts with the API of the BC, they would need to provide their security information. The BC would then be responsible for setting the Subject on the NormalizedMessage - Another option would be to do some sort of ThreadLocal type thing. If a BC doesn't have a way to set the security info, we could always create a custom API along the likes of "SecurityContext.setCurrentSubject(subject)". I also have been doing some thinking about WS-Security/Policy integration. WS-Security is easy enough to hook in, we just need to wire in XFire to listen for requests then pass on the messages to the bus. I'm guess we can use the ws-sec security tokens and put those on the bus as well? XFire But there is the whole problem that ws-sec just sucks and is too damn slow, so I don't really like pushing it as a good option. Also, it'd be really cool to just to write the policy or policy fragments and have the endpoint in servicemix enforce that. So we can require security or RM or whatever else real easily. Guess I need to get off my arse and do some WS-Policy integration with XFire. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
xbean 2.2.1 release?
Are people up for a 2.2.1 XBean release? Guillaume fixed a critical bug with Spring 1.2.7 and XBean which prevent them from working together. I'd like to see it released soon so users can use it... Regards, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: xbean 2.2.1 release?
OK that sounds good. - Dan Guillaume Nodet wrote: I'd like at least http://issues.apache.org/jira/browse/XBEAN-2 to be fixed before the release. Just have to apply the patch. There are also patches for XBEAN-4 (m2 plugin for mapping generation) and XBEAN-6 (bad dependencies scope) pending. Cheers, Guillaume Nodet Dan Diephouse wrote: Are people up for a 2.2.1 XBean release? Guillaume fixed a critical bug with Spring 1.2.7 and XBean which prevent them from working together. I'd like to see it released soon so users can use it... Regards, - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Outstanding XBean Patches...
I was wondering if someone could commit some patches for the XBean project. I just sent in a patch for two issues (XBEAN-8 and XBEAN-9) and would like to see those, and others, integrated in. Here is a summary the outstanding issues with patches that need to get committed: XBEAN-2: XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped XBEAN-4: Create a maven 2 plugin for spring mapping generation XBEAN-6: Fix dependencies scope XBEAN-7: Inconsistent use of classloader when using spring configurations for xbean-server XBEAN-8: Support flat collections XBEAN-9: Support flat properties It'd be great if someone could commit these and then we could get a release out! We at XFire would like to do a 1.1 release soon and really need some of these in there. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: Outstanding XBean Patches...
Woohoo! Thanks Guillaume. - Dan Guillaume Nodet wrote: I have checked in all outstanding patches. I will do a release 2.3 asap, unless someone has any problems with it ... Cheers, Guillaume Nodet Dan Diephouse wrote: I was wondering if someone could commit some patches for the XBean project. I just sent in a patch for two issues (XBEAN-8 and XBEAN-9) and would like to see those, and others, integrated in. Here is a summary the outstanding issues with patches that need to get committed: XBEAN-2: XBean should throw exceptions when a namespace can not be mapped or when an element / attribute can not be mapped XBEAN-4: Create a maven 2 plugin for spring mapping generation XBEAN-6: Fix dependencies scope XBEAN-7: Inconsistent use of classloader when using spring configurations for xbean-server XBEAN-8: Support flat collections XBEAN-9: Support flat properties It'd be great if someone could commit these and then we could get a release out! We at XFire would like to do a 1.1 release soon and really need some of these in there. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: [VOTE] XBean 2.3 release
+1 Guillaume Nodet wrote: I have put some binaries of the new xbean-2.3 release. They are available at http://people.apache.org/~gnodet/xbean-2.3/ [ ] +1 Release the binary as XBean 2.3 [ ] -1 Veto the release (provide specific comments) If the vote passes, I will put the binaries in their official distribution repositories. Cheers, Guillaume Nodet -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: [RTC] XBEAN-13 and XBEAN-14
Guillaume Nodet wrote: http://issues.apache.org/jira/browse/XBEAN-13 is a very minor patch to throw a meaninfull exception instead of an NPE at a later time when the xxx tags are used in a spring configuration file and the specified location is not found. http://issues.apache.org/jira/browse/XBEAN-14 is a major enhancement of xbean-spring to support Spring 2.0-m5. I have created a branch instead of a patch, because of the need to split the existing xbean-spring module into two parts. The branch is available at http://svn.apache.org/viewvc/geronimo/xbean/branches/spring2/trunk/ and the revisions links are availanble in the JIRA. In addition I added integration tests to ensure that xbean-spring is fully compatible with all spring versions >= 1.2.4, which was not the case, despite a modification I made for the latest xbean release. Here's my +1 for applying the XBEAN-13 patch and merging the branch to trunk for XBEAN-14. Please vote. Cheers, Guillaume Nodet Great work Guillaume! definitely looking forward to using XBEAN-14. Here's my +1 (even though I'm not a committer). - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
SwA and JAXB in CXF [was Re: svn commit: r541462....]
I was just talking to Dan Kulp and he mentioned that my latest commit broke
things for Geronimo because G is using JAXB 2.0.2 yet and this commit
depends on an API in JAXB 2.0.5. We're using this JAXB 2.0.5 feature because
we need a way to detect that there might be an attachment being written. The
problem is that we only know that there is an attachment after JAXB calls
AttachmentMarshaller.addSwaRefAttachment() though, which happens while we're
streaming the output message :-\
Short of caching the whole output message every single time and then
checking if an attachment was written (which would be disastorous to
performance) , the options seem to be:
1. Call JAXBContextImpl.hasSwaRef() which is only in JAXB 2.0.5 - This
checks to see if any classes in the context might have attachment references
that will be written.
2. Check to see if there is the SwA WS-I schema around (i.e. we would write
MIME messages if service.getSchema("http://ws-i.org/profiles/basic/1.1/xsd";)
!= null)
The problem with #2 that I see is that I don't think it works for
"code-first" services. Although to be honest I don't 100% understand how
code first SwAs is supposed to work yet (how do we detect that an operation
argument is supposed to be an attachment? Do users always need to put
@XmlAttachmentRef?)
So I think we should stay with #1. If anyone has any better ideas, I'm all
ears.
I will be changing the code inside CXF today to use reflection. If we deploy
on Java6, then this hasSwaRef method won't be there, so we need to fail in a
more friendly manner for JAXB versions less than 2.0.5. While this may help
the G build breakage today, I would encourage the G team to update to
2.0.5for this feature in the future.
- Dan
On 5/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: dandiep
Date: Thu May 24 15:33:40 2007
New Revision: 541462
URL: http://svn.apache.org/viewvc?view=rev&rev=541462
Log:
Get basic SwA working. The SwA tests now ensure that both the swaRef and
the normal attachment mechanisms work.
We still need to do the following:
1. CXF-677
2. Ensure the Content-Types are correct for the messages (i.e. no XOP
content types)
3. Ensure that code first (@XmlAttachmentRef?) attachments are working
4. Translate DataHandlers into Images, OctetStreams, etc and vis a versa
where appropriate.
Others can feel free to pick up any of these pieces, I'll be plugging away
at them more
tomorrow and next week.
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [VOTE] Change ServiceMix version to 3.0-SNAPSHOT
+1 Guillaume Nodet wrote: As we have to change the package names to org.apache.servicemix, i propose that we change the version number of ServiceMix to 3.0 to reflect this, and also the fact that we are focusing on full jbi compliance for both the container and components. [ ] +1 Change version to 3.0-SNAPSHOT [ ] -1 Keep 2.1 version number (provide specific comments) Cheers, Guillaume Nodet -- Dan Diephouse (616) 971-2053 Envoi Solutions LLC http://netzooid.com
Re: ANNOUNCE Geronimo Version 1.0 Available for Download
as a technology preview for both Jetty and Tomcat. See http://wadi.codehaus.org for additional information. Choice of Web container --- Two versions of the Geronimo binary are available for download. There is a version for the Jetty Web container and a version for the Tomcat Web container. Both distributions are fully supported by the Geronimo team. Please download the binary appropriate for your installation. Configuration - Most configuration attributes can be updated in the geronimo/var/config/config.xml file. The attributes most likely to be changed are already included in the supplied config.xml file, while others may need to be added manually. Overall Project Status -- The current version release of 1.0 represents a significant step for the Geronimo project. After a little over two years of effort this distribution is a fully compliant and usable J2EE container suitable for everything from development to Enterprise deployments. The next version of Geronimo is focused on several areas, including: * continue to enhance the performance and usability of the server * improve cross-platform compatibility * improve integration with third-party development tools and server products User feedback is critical for future released to be successful! The Geronimo team is anxious to gather feedback to ensure we are meeting the needs and expectations of the user community. In addition to the goals mentioned above, several specific changes are currently being considered: * Make the Geronimo kernel pluggable, to help ease integration of external components. * Enhance the ability to assemble customized servers (including only the services required by the applications to be run). * Enhance configuration, administration and management tools * Improve clustering support for web containers and ejbs For more information on specific bugs or features, or to help with testing efforts, please visit JIRA, our bug/issue tracking system, at http://issues.apache.org/jira/browse/GERONIMO Certification Status Geronimo 1.0 has passed the J2EE(tm) certification test suite. We will be filing the appropriate certification paperwork with Sun for official J2EE certification. Significant Missing Features * J2EE Application Client that works from a machine other than the server * Full JSR-88 support for DConfig Beans (the current features are somewhat incomplete) * Offline deployment and assembly tools (expected shortly) * Installer program (expected shortly) Known Issues * ActiveMQ (our JMS implementation) is not shut down in the right way and thus tends to generate exceptions to the console during the shutdown process. This does not cause any actual problems as far as we know, but it sure doesn't look nice. * See also outstanding JIRA issues at http://issues.apache.org/jira/browse/GERONIMO -- Dan Diephouse Envoi Solutions LLC http://netzooid.com
Re: [VOTE] accept donation of a business process engine into the ServiceMix project
After some thought about this, I will give it a +1. We're seeing a lot of overlap lately between the WS-* folks and the J2EE folks. Like lots of projects lately, I don't think this code donation fits strictly into one category. And to say that it strictly belongs one place or another is a mistake. I think the Sybase and ServiceMix people have made it clear that they are dedicated to working on this. I know the ws-* people are stretched with the many many specs to implement, so from a practical standpoint I think the ServiceMix location works. Lets closely monitor the community and see where it goes. At a future date we can readdress the location. Regarding other developers and overlapping projects, I would just like to make it clear that we still definitely welcome other people and their involvement. Accepting this donation into ServiceMix does not preclude any involvement with others. If we need to package things different or provide different interfaces or whatever, its all up for discussion and patches - Dan James Strachan wrote: We have received the generous donation of a complete and working BPE engine to the ServiceMix project... http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-dev/200602.mbox/[EMAIL PROTECTED] the contributor has offered to donate to Apache & complete the necessary software grants & IP clearance and to work with us on integrating it into ServiceMix. For those of you maybe not aware; ServiceMIx is an ESB project defined around JBI (JSR 208) the JCP standard API to integration components along with being the standard container model for a BPE. ServiceMix already has the JBI container and has a suite of JBI integration components already for smart routing, transformation, rules, scripting, auditing etc... http://incubator.apache.org/servicemix/Components So it makes complete sense to add a BPE to that component suite. Note that since ServiceMix already has integration components to Apache Axis and Apache Tuscany, the integration of the BPE with ServiceMix should benefit those projects too (with Apache Synapse possibly too via the Axis integration - though we need to work on that one a bit). Also having a BPE fully integrated into Geronimo via the JBI container would mean that we could start to orchestrate pretty much everything in the Geronimo stack! I'm certainly very excited by this move... [ ] +1 accept the donation into the ServiceMix incubator project [ ] 0 don't mind either way [ ] -1 I object because: ... Here's my +1 James --- http://radio.weblogs.com/0112098/ -- Dan Diephouse Envoi Solutions LLC http://envoisolutions.com http://netzooid.com/blog
Re: Message based web services
David Blevins wrote:
On Feb 21, 2006, at 11:20 PM, Manu George wrote:
Hi,
I have a query regarding Axis. In Axis we can deploy message
based web services with a WSDD as shown below
http://xml.apache.org/axis/wsdd/";
xmlns:java=" http://xml.apache.org/axis/wsdd/providers/java";
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance ">
Is it possible to do this in the geronimo axis
implementation? Also is this feature of axis an implementation of
any Java spec?
Also the axis site says that it supports transports other than http.
Is this supported in Geronimo?
Just going to throw out you may want to look at ServiceMix for your
needs. Overall, J2EE Web Services don't sound like what you are
looking for.
-David
If you want to go the non-J2EE route there is always XFire -
http://xfire.codehaus.org/. You can just create a service class like:
public class MyService {
public Document getCatalog();
}
See the docs or ping the mailing list for more detail.
- Dan
--
Dan Diephouse
Envoi Solutions LLC
http://envoisolutions.com
http://netzooid.com/blog
Re: Switching to 3.0-SNAPSHOT and dropping spring 1.x release
+1 as well. Spring (1.x) is dead, long live Spring (2.0)! - Dan On 2/23/07, Hiram Chirino <[EMAIL PROTECTED]> wrote: Sounds good to me. +1 On 2/21/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > What about switching to 3.0-SNAPSHOT > and dropping support for spring < 2.0 release ? > The code of xbean-spring is split into > at least 4 modules, just to keep with the different > milestones and the older 1.x release ... > > -- > Cheers, > Guillaume Nodet > > Architect, LogicBlaze (http://www.logicblaze.com/) > Blog: http://gnodet.blogspot.com/ > -- Regards, Hiram Blog: http://hiramchirino.com -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: Geronimo 2.0 web services support table
Cool - Question, what is meant by " Could use J2SE or J2ME" under the Client section? AFAIK, the JAX-WS client apis won't ever work on J2ME... Cheers, - Dan On 2/20/07, Lin Sun <[EMAIL PROTECTED]> wrote: Hi there, I have created a table for Geronimo web services support. The page is a child page of the Geronimo Java EE 5.0 report card page, but here is a direct link anyway - http://cwiki.apache.org/GMOxPMGT/geronimo-20-web-services-support.html. Tried to break them down to JAX-WS 2.0, JAX-RPC 1.1, EJB and Client and some of them may just mean test items or stuff we won't implement. I invite you (Jarek, Dims, Lasantha, and others) to edit the page and fill in the missing contents. Thanks, Lin -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: JAXB upgrade
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
Re: JAXB upgrade
I think we are all open to input on this particular point. Is there any way we can figure out what the JEE5 requirements are though? Thanks, - Dan On 3/1/07, Jeff Genender <[EMAIL PROTECTED]> wrote: 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. If the JavaEE5 TCK is only JAX-WS 2.0 compliant, this may be a problem. > > 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
Re: JAXB upgrade
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
Re: JAXB upgrade
Yes, I will try to take care of this today (granted it might not get checked in until later today though). Cheers, - Dan On 3/5/07, Jarek Gawor <[EMAIL PROTECTED]> 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 > -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: JAXB upgrade
Well that settles that! Do you know: are they changing the spec? Or are they just pulling their implementation? - 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: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
Re: [Fwd: What do people think about graduation ?]
I would like to see SMX as a TLP. On 3/16/07, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: On Mar 14, 2007, at 11:51 AM, Guillaume Nodet wrote: > It may be time to consider it. > The community is growing and diverse ... > I don't see any issues left. Seems like a good idea to me. Do you guys think we should be a TLP? Regards, Alan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
XPath and Drools routing with SXC?
Hi All, I think I wrote something which may be of use to ServiceMix, but unfortunately I don't have time to integrate it myself - so I'm going to throw it out there for everyone :-) I started a project called SXC - simple xml compiler - which creates optimized xml parsers for various things. There is one for JAXB. But, the one of probably the most interest to this crew is the XPath frontend. SXC can build a streaming xpath parser for you (at runtime). This means you can listen for XPath events as you scan over the document. This allows for very efficient XPath based routing. In my initial performance test it was about 100x faster than Jaxen for locating nodes (although thats a very rough benchmark, real numbers may vary!) We also integrated it with Drools so you can write XPath expressions right in your rules. Check out these links for more information: http://sxc.codehaus.org http://sxc.codehaus.org/XPath http://sxc.codehaus.org/Drools The one caveat is that we support only a limited subset of XPath expressions at the moment. But if you wanted to hack SXC, its easy enough to add more. I'm happy to help where I can or give guidance to anyone who wants to participate as well. Anyone up for hacking it into servicemix? :-) - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
CXF Geronimo Integration
David and I chatted a little bit online this weekend as we tried to bring each other up to speed on the respective areas so we could have a meaningful conversation about this. [1] I thought I'd take a little bit to summarize. As I understand it, we would need to integrate CXF at two points. First, the deployment. We need to support JSR 109 deployment descriptors. Second, we need to support invoking EJBs. For deployment, we can wire in JSR 109 descriptors into the service construction. In CXF we have a Service, which holds a WSDL like service model and information about CXF can invoke the server (like databinding info, interceptors/handlers, etc). Generally you create a Service from a ServiceFactory [2][3]. The base service factory (ReflectionServiceFactoryBean) can actually construct the service from WSDL using the WSDLServiceFactory or from introspection. During this construction, ServiceConfigurations [4] can provide values for the service. There can be many of these. For instance, lets say we want to determine the namespace of the service. We can have a JaxWsServiceConfiguration which takes the namespace from the @WebService attribute. If there is no specified namespace, the service factory will move to the DefaultServiceConfiguration which will create a namespace from the package name. With that all said - its easy to envision how a Jsr109ServiceConfiguration could be created to override values in the JAX-WS attributes. I still don't know enough about JSR109 to say if this will be sufficient though - It would be good to come up with a list of areas that JSR 109 affects. The second area - EJB invocation - is a bit simpler. In CXF we have the concept of Invokers [5][6]. Invokers allow you to control how your object is invoked. You can supply your own object, scopes, etc. XFire had an EJB invoker [7] which I think is similar to what needs to happen here (although I know jack about EJBs, so I could be wrong). While the Invoker interface in CXF is slightly different, all the same information is there. Are there other integration areas that I missed here? Anyone able to provide a more comprehensive view of what exactly we need to do in terms of JSR 109? Cheers, - Dan 1. http://dev.rectang.com/logs/codehaus/%23cxf/20061001.html 2. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/frontend/simple/src/main/java/org/apache/cxf/service/factory/ReflectionServiceFactoryBean.java?r=450267#l287 3. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/support/JaxWsServiceFactoryBean.java?r=450397 4. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/frontend/simple/src/main/java/org/apache/cxf/service/factory/AbstractServiceConfiguration.java?r=450267 5. http://fisheye3.cenqua.com/browse/~raw,r=437862/celtixfire/trunk/api/src/main/java/org/apache/cxf/service/invoker/Invoker.java 6. http://fisheye3.cenqua.com/browse/celtixfire/trunk/rt/core/src/main/java/org/apache/cxf/service/invoker/AbstractInvoker.java?r=447027 7. http://xfire.codehaus.org/Invokers David Jencks wrote: I'm starting to look into jee5 webservices integration in geronimo. So far I've got as far as locating some of the specs and starting to read them :-). If anyone wants to help or take over aspects of this that would be great! Unfortunately I haven't been able to keep up with the dev lists for either axis or cxf so I'm not sure whether anyone has thought about this before nor how much of the appropriate specs are implemented already by either project. I have been pointed to a cxf geronimo builder, but haven't determined how out of date it is, as there have been quite a few builder changes in geronimo since the builder was written. Thanks! david jencks -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: Java EE schema license question
CC'ing cxf-dev and apache legal, as it pertains to Geronimo, but I think it would be good for us (CXF) to hear from legal The part of the license that concerns me is this: No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Does G have prior written authorization to include it as part of the source distro? Does Apache as a whole? Can we as an incubating project redistribute this in our source distribution? If not can we do so temporarily until we're able to obtain authorization? - Dan Bozhong Lin wrote: re-sending with Java EE schema URL links included: [1] http://java.sun.com/xml/ns/javaee/javaee_5.xsd [2] http://java.sun.com/xml/ns/j2ee/j2ee_1_4.xsd Original Message Subject: Java EE schema license question Date: Mon, 30 Oct 2006 12:31:05 +0800 From: Bozhong Lin <[EMAIL PROTECTED]> To: dev@geronimo.apache.org Hi, Apache CXF currently use java EE 5 [1] schema, and would like to include the schema in distribution if that is allowed from copyright perspective. From the copyright statement included in the schema file, it seems to be very strict for redistribution. I found that Geronimo source distribution includes java EE 1.4 schema [2], which has similar copyright statement. I just wonder if this ever was a legal issue for you guys, and how you guys get around of this if so? Thanks for the insight! Cheers, Bo -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
[jira] Created: (SM-408) Migrate common JAXP/StAX code to stax-utils
Migrate common JAXP/StAX code to stax-utils --- Key: SM-408 URL: https://issues.apache.org/activemq/browse/SM-408 Project: ServiceMix Type: Task Reporter: Dan Diephouse Fix For: 3.0-M2 The org.apache.servicemix.jbi.jaxp code is quite common (for instance some of the classes are from XFire). We should move the package to the stax-utils project to share common code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-8) Support flat collections
Support flat collections Key: XBEAN-8 URL: http://issues.apache.org/jira/browse/XBEAN-8 Project: XBean Type: New Feature Components: spring Versions: 2.2 Reporter: Dan Diephouse Assigned to: Dain Sundstrom I would like to be able to do instead of -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-9) Support flat properties
Support flat properties --- Key: XBEAN-9 URL: http://issues.apache.org/jira/browse/XBEAN-9 Project: XBean Type: New Feature Components: spring Versions: 2.2 Reporter: Dan Diephouse Assigned to: Dain Sundstrom Right now in servicemix we have to do: It would be much better if we could do: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-8) Support flat collections
[ http://issues.apache.org/jira/browse/XBEAN-8?page=all ] Dan Diephouse updated XBEAN-8: -- Attachment: flat.diff This patch fixes XBEAN-8 and XBEAN-9 > Support flat collections > > > Key: XBEAN-8 > URL: http://issues.apache.org/jira/browse/XBEAN-8 > Project: XBean > Type: New Feature > Components: spring > Versions: 2.2 > Reporter: Dan Diephouse > Assignee: Dain Sundstrom > Attachments: flat.diff > > I would like to be able to do > > instead of > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (XBEAN-9) Support flat properties
[
http://issues.apache.org/jira/browse/XBEAN-9?page=comments#action_12376539 ]
Dan Diephouse commented on XBEAN-9:
---
I attached a patch for this to XBEAN-8. It can be used by doing:
/**
* @org.apache.xbean.Flat
* @return
*/
public Recipe getTopRecipe() {
return topRecipe;
}
The corresponding syntax will be:
Mash together
Food
> Support flat properties
> ---
>
> Key: XBEAN-9
> URL: http://issues.apache.org/jira/browse/XBEAN-9
> Project: XBean
> Type: New Feature
> Components: spring
> Versions: 2.2
> Reporter: Dan Diephouse
> Assignee: Dain Sundstrom
>
> Right now in servicemix we have to do:
>
>
>
> It would be much better if we could do:
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-8) Support flat collections
[ http://issues.apache.org/jira/browse/XBEAN-8?page=all ] Dan Diephouse updated XBEAN-8: -- Attachment: xbean8.diff The test cases from last time didn't make it in... > Support flat collections > > > Key: XBEAN-8 > URL: http://issues.apache.org/jira/browse/XBEAN-8 > Project: XBean > Type: New Feature > Components: spring > Versions: 2.2 > Reporter: Dan Diephouse > Assignee: Dain Sundstrom > Attachments: flat.diff, xbean8.diff > > I would like to be able to do > > instead of > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-11) JMX notification to SNMP converter
JMX notification to SNMP converter
--
Key: XBEAN-11
URL: http://issues.apache.org/jira/browse/XBEAN-11
Project: XBean
Type: New Feature
Reporter: Dan Diephouse
This patch adds an xbean-snmp module which converts jmx notifications to snmp
messages. Everything is configured via beans. Here is a short sample:
SnmpEmitter em = new SnmpEmitter();
SnmpServer ss = new SnmpServer();
ss.setHost("127.0.0.1");
ss.setPort(162);
ss.setVarBindings(new ArrayList());
/* Bind the JMX notification type
"java.management.memory.threshold.exceeded"
* to the specified OID. The payload of the snmp message will be the
usage
* attribute.
*/
SnmpBinding binding = new SnmpBinding();
binding.setOid("1.3.6.1.2.1.1.3");
binding.setPayload("usage");
binding.setType("java.management.memory.threshold.exceeded");
ss.getVarBindings().add(binding);
Set servers = new HashSet();
servers.add(ss);
em.setServers(servers);
em.start();
Then all you need to do as add the SnmpEmitter as a NotificationListener for
your JMX events.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-11) JMX notification to SNMP converter
[ http://issues.apache.org/jira/browse/XBEAN-11?page=all ]
Dan Diephouse updated XBEAN-11:
---
Attachment: snmp.diff
> JMX notification to SNMP converter
> --
>
> Key: XBEAN-11
> URL: http://issues.apache.org/jira/browse/XBEAN-11
> Project: XBean
> Type: New Feature
> Reporter: Dan Diephouse
> Attachments: snmp.diff
>
> This patch adds an xbean-snmp module which converts jmx notifications to snmp
> messages. Everything is configured via beans. Here is a short sample:
> SnmpEmitter em = new SnmpEmitter();
> SnmpServer ss = new SnmpServer();
> ss.setHost("127.0.0.1");
> ss.setPort(162);
> ss.setVarBindings(new ArrayList());
>
> /* Bind the JMX notification type
> "java.management.memory.threshold.exceeded"
> * to the specified OID. The payload of the snmp message will be the
> usage
> * attribute.
> */
> SnmpBinding binding = new SnmpBinding();
> binding.setOid("1.3.6.1.2.1.1.3");
> binding.setPayload("usage");
> binding.setType("java.management.memory.threshold.exceeded");
> ss.getVarBindings().add(binding);
> Set servers = new HashSet();
> servers.add(ss);
> em.setServers(servers);
> em.start();
> Then all you need to do as add the SnmpEmitter as a NotificationListener for
> your JMX events.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2781) Improved CXF-based POJO WebService support
[ https://issues.apache.org/jira/browse/GERONIMO-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468407 ] Dan Diephouse commented on GERONIMO-2781: - Jarek - is there a way we can make our APIs more extensible so you don't have to redo functionality which is in CXF? Specifically the annotation processor which you refer to? > Improved CXF-based POJO WebService support > -- > > Key: GERONIMO-2781 > URL: https://issues.apache.org/jira/browse/GERONIMO-2781 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0-beta1 >Reporter: Jarek Gawor > Attachments: GERONIMO-2781.patch > > > The attached patch contains numerous improvements to JAX-WS support for POJOs > (via CXF): > 1) Annotation support for the service and handlers. The following annotation > are recognized: @Resource, @EJB, @WebServiceRef, @PreDestroy, @PostConstruct. > The values are injected if the given resource is defined in JNDI. The patch > includes a basic annotation processor. The processor itself is pretty basic > but is generic and pluggable and can be (re)used in other places. It was > necessary to add one because CXF annotation processor only handles @Resource > annotations and it was not very extensible. > 2) WebServicesContext.getUserPricipa() and .isUserInRole() are now properly > implemented by delegating the calls to the Servlet class > 3) Improved webservices.xml file parsing and information passing to the web > container. Information specified in the webservices.xml file can now > overwrite the information specified in the annotations. For example, > @HandlerChain can be overwritten by element. Same with > wsdl-port, wsdl-service, and wsdl-file. > 4) Switched to using Commons Logging API instead of Java Logging API -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-2449) JSR 181 Specs Build
JSR 181 Specs Build Key: GERONIMO-2449 URL: http://issues.apache.org/jira/browse/GERONIMO-2449 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: specs Reporter: Dan Diephouse Geronimo needs a specs build for JSR181 2.0. This issues attaches a patch for it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2449) JSR 181 Specs Build
[ http://issues.apache.org/jira/browse/GERONIMO-2449?page=all ] Dan Diephouse updated GERONIMO-2449: Attachment: jsr181.patch Here is the patch. This also includes the patch for GERONIMO-2450 > JSR 181 Specs Build > --- > > Key: GERONIMO-2449 > URL: http://issues.apache.org/jira/browse/GERONIMO-2449 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: specs > Reporter: Dan Diephouse > Attachments: jsr181.patch > > > Geronimo needs a specs build for JSR181 2.0. This issues attaches a patch for > it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2450) geronimo annotation spec lack a LICENSE/NOTICE in the jar
geronimo annotation spec lack a LICENSE/NOTICE in the jar - Key: GERONIMO-2450 URL: http://issues.apache.org/jira/browse/GERONIMO-2450 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Dan Diephouse The geronimo-annotation_1.0_spec doesn't have a src/main/resources with LICENSE & NOTICE files. I have a patch for this in GERONIMO-2449 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-55) Custom Map values aren't parsed properly
Custom Map values aren't parsed properly Key: XBEAN-55 URL: http://issues.apache.org/jira/browse/XBEAN-55 Project: XBean Issue Type: Bug Components: spring Affects Versions: 2.6 Reporter: Dan Diephouse Attachments: mappatch If you use the custom map syntax that I wrote, it only supports setting values which are Strings. This patch fixes that issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (XBEAN-55) Custom Map values aren't parsed properly
[ http://issues.apache.org/jira/browse/XBEAN-55?page=all ] Dan Diephouse updated XBEAN-55: --- Attachment: mappatch > Custom Map values aren't parsed properly > > > Key: XBEAN-55 > URL: http://issues.apache.org/jira/browse/XBEAN-55 > Project: XBean > Issue Type: Bug > Components: spring >Affects Versions: 2.6 >Reporter: Dan Diephouse > Attachments: mappatch > > > If you use the custom map syntax that I wrote, it only supports setting > values which are Strings. This patch fixes that issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
