gettin all zoidal on ya
Let the new appserver war begin.
Is there any standard way to package up applications for OSGi? Spring has PARs now. Equinox seems to have their way. There is also P2 for remote access.
I don’t confess to be an OSGi expert, but I’m wondering - does it make sense to find a way to package applications up for OSGi appservers in a standard fashion? Or is it really something that needs to be server specific?
I’ve recently started using the Maven Eclipse plugin that was started by Sonatype and I have to say -wow, this rocks.
I went to start a Maven plugin today. Normally I would’ve googled around until I found an example. Then I would copied that example and started tweaking it.
With m2eclipse it was dead easy to just do New->Maven Project, then select the Maven plugin archetype.
Next I needed to add a dependency. Previously I would’ve searched around the maven repo manually or use mvnrepository.com. Now I just do right click->Maven->Add Dependency. Then I can type in something, like say “groovy” and it will present me all the versions that match. Its great.
Next I needed to test my plugin. Normally I would have to intsall the plugin then test it from another project. The m2eclipse plugin allows me to test the plugin “in-situ”. I don’t have to go through the time consuming phase of installing the plugin first anymore!
There’s a whole host of other features too:
This is really going to help bring Maven to the masses. My only gripe is their ugly red icon 
Update: fixed the mvnrepository.com url.
Spring Security 2.0 final is out. It looks like a great step forward! I’m looking forward to upgrading Galaxy to it when I get chance.
Guess I’ll have to talk about other projects killing fairies now.
(Also, thanks to Ben Alex and the other Spring guys for having a good sense of humor about my original post. I didn’t expect the meme to live quite this long…)
This week I put the finishing touches on the first version of a Jersey connector for Mule. It makes it really easy to drop in JAX-RS services into a Mule application.
For the non-Mule users out there - you’re probably asking, why would I need Mule and JAX-RS?
Imagine this scenario: you receive messages over HTTP. You wish to process these messages asynchronously with your backend servers. With Mule its pretty easy to set up an HTTP listener and connect it to a JMS queue. You can then have pull messages off the queue and process them asynchronously within a transaction. JAX-RS makes it very easy to map your Java class to resources with it’s simple annotations.
While you could piece this together all yourself, Mule is like integration glue - it makes connecting all these things easier. </marketing>
Thanks to the great work of Dejan Bosanac, Jettison 1.0 final has been released! He popped on the mailing list the other day willing to fix things; before I knew it he had SVN access and was fixing everything he could get his hands on. This is looking a high quality release and should greatly reduce the number of problems people have with Jettison.
Thanks again Dejan, and enjoy the 1.0 release of Jettison everyone.
Now that Galaxy is announced, I can unleash my fury of blogging again. Or, as we all know will probably happen, I can blog just slightly less sporadically again.
One of the recent posts I’ve wanted to comment on is Atom is the New JCR (prompted by Sam Ruby). Adrian Sutton writes:
When the Java Content Repository (JCR) standard first came out it was supposed to bring in a new era of compatibility between content repositories and put an end to the content silo. There was, and still is, a lot of talk about it and just about everyone added JCR compliance to their marketing materials. Unfortunately, that’s mostly where things stopped - the implementation work that followed was generally done was buggy or incomplete and the only viable JCR implementations that I’ve seen have come out of Day Software, who lead the JCR spec effort.
We use JCR inside Galaxy for all our storage needs at the moment. Using it has been an interesting experience to say the least. One of my favorite “features” of JCR has been the fact that you can not have two seperate threads create a child node with the same name at the same time. Which means in our activity log, we can’t add two nodes called “/activity” to “/activities” at the same time.
The main reason we decided to go with JCR is that it supports both simple database type data and file type data via the same interface transparently. I’m not 100% sure it was the right choice though. I had to write an ORM like framework as the one in Jackrabbit seemed pretty immature and I didn’t have time to delve into the rabbit hole of the jcr-mapping module in Jackrabbit. Mine is limited but as least I could figure out how to use it. We’ll be reevaluating this for the future though now that Jackrabbit 1.4 is nearly out.
Adrian continues:
Then along came Atom which is all about remote access and manipulation of data and missing probably 90% of the functionality that JCR offers. It really isn’t a competitor to JCR at all and yet it’s doing more to break down content silos than JCR ever has. Atom support isn’t just being added to the marketing materials, it’s actually shipping and is usable in a lot of places - IBM’s Lotus Connections has Atom APIs to everything and, as best I can tell, only Atom APIs to it’s repository.
I completely agree that JCR isn’t very worthwhile as something that will break down content silos. It does have value as an API to work with data though. Atom is quite limited in the granularity it can work with data (which coincidentally is one of the reasons Web3S exists as well). And you still need to store your data somewhere.
Atom has not replaced JCR it has supplemented it. We use JCR as a content store for Galaxy. I’ve also written a generic JCR content store for AtomPub inside of Abdera. Sure, the vendor promises are probably wrong about the content-silos, but it sure simplifies some things when writing applications - which is what really counts!
Update: David Nuescheler has written a great follow up to this whole discussion.
Also, Jackrabbit 1.4 is out.
I’m in Oslo this week for Javazone 2007. And while I missed the 8 AM heavy metal band suspending themselves unfortunately, it still has managed to be quite a good conference. Partly because I get to see lots of my European friends whom I may not see that often.
Oslo is a beautiful city. (With a disproportionate amount of beautiful women too!) Its very clean and friendly. Really the only bad thing I have to say about Oslo is that it is insanely expensive. Our cab ride last night which took us a .5 mile cost about $100 ($20 basically from the moment we stepped in the door)!!! And beers are about $10! Its nuts.
I gave an updated version of my Building Scalable, Reliable, and Secure RESTful services talk yesterday. I think it went pretty well - I got a fair amount of good feedback at least. It was the first time I thought I might have actually explained REST coherently to people. (Have you ever tried explaining REST to someone who knows nothing about it?
I attended Ryan Heaton’s presentation on Enunciate today. He’s written some really cool stuff to package up and maintain web services. In particular I love the ability to document your services really easily and have it presented via a pretty UI to the user. You should check it out if you haven’t already.
For now, I’m headed off to the Spring/OSGi presentation shortly so I can pretend I understand OSGi when I talk to people.
Someone is blathering on again about how Spring sucks, and so startup performance came up in the conversation. CXF uses Spring under the covers by default (it’s optional, don’t worry). Initially there was some major slowness, but I’ve spent a lot of time profiling/improving CXF’s startup time. I thought I’d share what I learned so you can improve your startup time as well:
If all goes well, you should be able to get the Spring startup time pretty low. At this point its probably other things, like your ORM layer (*cough* Hibernate *cough*), that are slowing things down.
Random tidbit: I was profiling the CXF startup the other day. About 33% of the time is in Introspector.getBeanInfo(), so its really not all Spring’s fault IMO :-). Maybe someone can hack the JDK to be faster there?
Have any more Spring performance tips? Add them to the comments!
Well, its been about one year since we began and today we’ve finally reached our 2.0 release! From the announcement:
The Apache Incubator CXF team is proud to announce the availability of the 2.0 release!
Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These
services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.CXF includes a broad feature set, but it is primarily focused on the following areas:
- Web Services Standards Support: CXF supports a variety of web service standards including SOAP, the Basic Profile, WSDL, WS-Addressing, WS-Policy, WS-ReliableMessaging, and WS-Security.
- Frontends: CXF supports a variety of “frontend” programming models. CXF provides a JAX-WS Compliant frontend. It also includes a “simple frontend” which allows creation of clients and endpoints without annotations. CXF supports both contract first development with WSDL and code first development starting from Java.
- Ease of use: CXF is designed to be intuitive and easy to use. There are simple APIs to quickly build code-first services, Maven plug-ins to make tooling integration easy, JAX-WS API support, Spring 2.0 XML support to make configuration a snap, and much more.
- Binary and Legacy Protocol Support: CXF has been designed to provide a pluggable architecture that supports not only XML but also non-XML type bindings, such as JSON and CORBA, in combination with any type of transport.
For those who aren’t up on things, CXF is the merge of the XFire and Celtix projects. As such, CXF is really a continuation of the XFire project and can be thought of as XFire 2.0. For all the XFire users out there: have no fear, your services should deploy just fine in CXF. You’ll just need to change your deployment code/xml. Check out our migration guide if you’re interested in more details.
For more information on CXF check out:
Many thanks to all those involved in the whole process. Its been a pleasure to work with so many talented people. Thanks to Debbie Moynihan for helping the whole CXF project get rolling and getting IONA involved. Dan Kulp for continually making CXF more coherent, his incredible eye for detail, TCK work, build maintenance and patience with my build breakage. Andrea Smyth for the great Policy/ReliableMessaging work. Jervis Liu for his work on everything, like the SAAJ stuff which was a giant PITA. Eoghan Glynn for putting up with me and the superb WS-A layer. James Mao for making CXF tooling rock. Christopher Moesel for his MTOM integration. Willem Jiang for fixing things all over and the JCA work. Guillaume Nodet for using XFire, showing me how many things were wrong with it when using it with JBI and then helping develop the CXF JBI code. Freeman Fang for the JBI work. Jeff Genender and Jarek Gawor for their awesome work on the TCK and Geronimo. Jim Ma for the work on the tooling and frontends. Thanks to all the incubator folks for reviewing our releases. Our mentors who guided us in the Apache process, especially Jim Jagielski. (*whew* - I probably missed some people, apologies!)
A special thanks to Tomek Sztelak who has been helping maintain the XFire code more than I have lately and answering a ton of questions on the XFire list. Not only that, but he’s also found time to contribute a set of Maven archetypes to CXF. All this while he’s been working full time AND been in and out of the hospital! Heroic!
The CXF community welcomes involvement and feedback. For more information see how to get involved or the mailing lists.
Thomas just announced that JBoss has been working on making their WS layer pluggable. In addition to supporting the native JBossWS framework, CXF and Metro (the project formerly know as the JAX-WS RI + Tango) integration code will be added for the 2.1.0 release as well. Among other things, this should help make it easier for CXF/Metro users to deploy services and create EJB backed web services inside JBoss.
I’m very happy to see this. Its not uncommon for me to visit a customer who is mixing different stacks together. Its part of the promise of open source, you can pick the best technologies (dare I use the marketing term - best of breed), and integrate them together.
Its great to see JBoss/RedHat support this approach.
<horn-tooting>
Coincidentally, why might you want to use CXF within JBoss [1][2]?
</horn-tooting>
1. Important: this is not to imply that the JBossWS Native or Metro does not have any particular one of these features, I just think it is this combination that makes CXF unique.
2. Disclaimer: The JBossWS code is an ongoing effort and the CXF code still isn’t quite ready yet AFAIK. I would encourage you to get involved though if this interests you. Also, CXF can still be run standalone inside JBoss in the mean time - many users do that already.