Angry Bill

tech talk radio

Archive for the 'opensource' Category


Resteasy JAX-RS 1.0 Beta 2 Released!

Posted by billburke on April 7, 2008

I finally got around to creating a new release for the next rev of our JAX-RS, Java RESTful Web Services, implementation. This release targets the 0.7 release of the JAX-RS specification. There’s a still a few features I haven’t implemented yet, but hope to get them out soon as the spec starts to solidify. Especially new in this release is a new embeddable container so you can run things within junit tests, or just serve up a small restful web service from your classpath. We’ve been using this embeddable container to unit test our implementation and finally made it available to the masses.

Check out our project page or download the new release.

Release Notes - Resteasy - Version Beta2

Bug

  • [RESTEASY-1] - DefaultPlainText.MessageBodyWriter should not write anything (arrays especially)
  • [RESTEASY-2] - If Response has set Content-Type, then that content type should be used
  • [RESTEASY-9] - Subresources erroneously considered as root resources
  • [RESTEASY-17] - Spec mandates supporting MultivaluedMap for form-urlencoded media types
  • [RESTEASY-18] - @QueryParam should not return x-www-form-urlencoded parameters
  • [RESTEASY-24] - WebApplicationException and http status codes

Feature Request

Task

  • [RESTEASY-4] - Implement variants
  • [RESTEASY-13] - Support @Context field injection
  • [RESTEASY-14] - Support @Context injeciton of HttpServletRequest/Response
  • [RESTEASY-16] - Support injection of javax.ws.rs.core.SecurityContext
  • [RESTEASY-19] - Support for StreamingOutput
  • [RESTEASY-23] - Integration test for SecurityContext

Posted in JAX-RS, REST, Webservices, java, opensource | 2 Comments »

Radiohead and Open Source

Posted by billburke on November 7, 2007

Let me preface by saying I’m an old man. I have never ripped and burned music CDs. I don’t have any music on my iPod (only TV shows and movies). And if you’ve read Why Angry Bill? you know that I don’t listen to music on the radio. So, if this blog is old news to you, then apologies.

Was on Google news today and saw discussion on the band Radiohead’s attempt to give away a free album with fans deciding how much they wanted to pay (if at all). The article said that only 38% of downloaders decided to pay anything and marked it as a failure. I was scratching my head at this. A failure? A disappointment? Are you bleepin crazy? I don’t know what the ratio is now, I’m out of the loop on such discussions, but pre-acquistion, I know JBoss’s percentage of paying users was something like 5%, and they got 38%? IMO, that’s a huge success! If JBoss had had that ratio of paying users we would have gone public in 2004 instead of getting bought-out in 2006. The article then went on to say that the band must average $1.50 per download to break even (they’re currently averaging $6.50 per download, pretty good margin!).

Most of the articles on the subject questioned whether the Radiohead model would work with smaller bands since Radiohead already had a strong brand and a fanbase of millions. I think the business model could parallel the evolution of an open source business model. Really, all it is is establishing a trademark and cross-selling your ‘free’ offering to what value-add you are selling.

In the beginning of an open source business, your main value-add is usually consulting and training. This is business that brings in easy revenue, but that you can’t scale effectively because of the amount of people that is required to drive this. For the music world, maybe a band could cross-sell on-site gigs. Yeah, maybe this is unrealistic to expect a fan to want to book a particular band, so something more creative is needed. Maybe the music download would require the fan to solely enter in their age and zipcode. Then the band could know where they are popular. For instance, if they were very popular in the Greater Boston area, they could call up nightclubs in the area and say “Hey, 100 people downloaded our album in Boston. There’s a good chance we’d be able to fill the place.” As the band gained a small following, this information could be used to drive up their fee.

Another way JBoss bootstrapped themselves was through documentation sales. At the height of this these sales totally funded the salary of Scott Stark, and subsidized the salaries of me, Dain, and Sacha. For a band, it could be as simple as selling a professional PDF of their song lyrics. Would you be willing to pay $1 for a printable PDF of your favorite band’s song lyrics? Then there is of course always band merchandise of t-shirts, mugs, towels, posters, etc. All this stuff is so easy and cheap to set up to sell online. We did it at JBoss.

The last step in the evolution of an pure open source business is selling subscriptions. This is where I’m at a loss of how a music band could push such an offering. There is always the possibility of going un-pure. Radiohead seems to be doing it by cross-selling their $80 dollar deluxe box set. JBoss did much of the same with JBoss ON. I know other open source companies are taking similar tacts.

All and all, it might be hard to break even on the Radiohead “honesty box” model for small startup bands, but there’s a lot of creative different ways I think bands could make money off of free IP. I really think open source business models could be applied to other forms of IP. It will be interesting to see how this evolves in the music industry and kudos to Radiohead for thinking out of the box.

Posted in business, opensource | 2 Comments »

Websphere Children’s Edition

Posted by billburke on August 9, 2007

Its funny to see Novell re-hash a 10 month old press release that it is bundling Websphere Children’s Edition with Suse. My favorite quote from this newsclip is:

Users looking for more advanced features are steered towards paid WebSphere products, which offer more advanced features.

This is why we will never take Apache Geranium seriously.  As long as IBM is the major contributor to the project, they’ll never be interested in elevating Geranimo to the feature set of JBoss.   It will always be a hobbled platform.  This is why you should always read the fine print in vendor friendly open source projects.  If the project is dominated by a vendor which has a competing closed-source, expensive product, the project will never get anywhere.

Posted in business, flame bait, opensource | 4 Comments »

Apache Business Model failure

Posted by billburke on July 17, 2007

I recently read on TSS how Iona is rebranding their ServiceMix acquisition. This is what sucks about the Apache model. If you ever want to build a business upon an Apache project, you’d have to spend your own time and money to create your own brand. It begs the question, what did Iona get from purchasing LogicBlaze? Since they are rebranding ServiceMix anyways, why not just hire away great developers like James Strachan instead of ponying up all this money to LogicBlaze’s VCs?

Your only value as an Apache.org based business is your people and your customer list. This is why I would never ever start a project at Apache.org. They own the brand. Its harder for you to cross-sell without competition. Without a strong brand, what incentive does a company have to acquire your business as a whole? Why not just hire away your developers and sales people instead? Its hard enough to build a successful business with a brand, why make it harder by hosting yourself at Apache?

I’m not saying that Apache isn’t a great organization. It is in many respects. But as a OSS developer, you have to really think about the pros and cons before starting up shop there.

If you’re looking for a different opinion, Savio Rodrigues has some great contrary opinions on business effect of the Apache model both on companies and users. You’ll have to dig around in his archives though.

Posted in business, opensource | 1 Comment »

Co-existence with Hibernate, JPA, and EJB3

Posted by billburke on July 6, 2007

How can you slowly migrate existing Hibernate apps to JPA? How can you use Hibernate features and unique mapping capabilities with a JPA deployment? How can you take advantage of EJB3 injection and persistence context management with Hibernate? In this blog I want to show how Hibernate, JPA, and EJB 3.0 can co-exist and compliment one another. This information is fully documented between the Hibernate and JBoss EJB3 projects, but I thought I’d highlight them in this blog to make the community aware that they exist.

Mixing and matching JPA annotations within Hibernate

Using the standard JPA annotations helps out greatly in cutting down the amount of XML metadata you have to type. This annotation metadata is an exact replacement for much of the metadata in hbm.xml. Using them does not require you to use the JPA EntityManager interface. You may still use SessionFactory and Session objects to interact with your database. After downing the Hibernate Anotations project, setting things up is fairly easy:

SessionFactory sessionFactory =
                  new AnnotationConfiguration().buildSessionFactory();

You use hibernate.cfg.xml to specify which exact classes you want mapped by this SessionFactory:

<hibernate-configuration>
 <session-factory>
    <mapping class="com.acme.Flight"/>
    <mapping class="org.jboss.Sky"/>
    <mapping resource="org.acme.orm.xml"/>
 </session-factory>
</hibernate-configuration>

You can mix hbm.xml mapping files with new annotated classes. XML resources can also either be JPA-based XML or Hibernate based. This mixing and matching allows you to quickly prototype new mappings using JPA, but allows these mappings to co-exist with older Hibernate 3 applications.

There are a few more options for configuration. Check out the Hibernate Annotations documentation for more information.

Use Hibernate to configure JPA

If you want to use the JPA Entity Manager API to code a portable application, you may still want to use Hibernate metadata to map your beans. Although the JPA orm mapping is pretty rich, it is still a subset of Hibernate’s functionality. The Hibernate Annotations project provides additional Hibernate-specific annotations to elaborate a persistence mapping where JPA leaves off. If you prefer XML, you can use hbm.xml files to define the mappings for your entity beans. When loading a persistence archive, Hibernate Entity Manager will automatically scan the .jar file for any *hbm.xml files and add them to its mapping information.

Hibernate specific configuration is defined in the properties element of the persistence.xml file. You can configure any hibernate property within this XML blob

<persistence>
 <persistence-unit name="manager1" transaction-type="JTA">
    <jta-data-source>java:/DefaultDS</jta-data-source>
    <properties>
       <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
 </persistence-unit>
</persistence>

You may also define all your hibernate configuration in the usual Hibernate way: within a hibernate.xfg.xml file. You must tell the JPA implementation to use this configuration file through the hibernate.ejb.cfgfile property.

<persistence>
 <persistence-unit name="manager1" transaction-type="JTA">
    <jta-data-source>java:/DefaultDS</jta-data-source>
    <properties>
       <property name="hibernate.ejb.cfgfile" value="/hibernate.cfg.xml"/>
    </properties>
 </persistence-unit>
</persistence>

EJB 3.0 managed persistence sessions

EJB 3.0 has some nice integration with JPA. You can have your EJB session beans manage persistent sessions for you, freeing you from having to create, destroy, and clean up your persistence sessions. It can manage your persistent sessions in two ways:

Transaction-scoped persistence contexts

Transaction-scoped persistence contexts can be injected into your stateful, stateless, or message driven beans. These transaction-scoped contexts only live for the duration of the JTA transaction they are invoked within. When you first interact with an injected transaction-scoped EntityManager within a transaction, an underlying persistence context (in other words, a Hibernate session) is transparently created and associated with the transaction. This associated context is propagated automatically to an nested EJBs that invoke on entity managers of the same persistent unit type. This means that any EJB that invokes on an entity manager will be using the same underlying Hibernate Session.

@Statelesspublic class MyBean implements MyInterface {

 @PersistenceContext(unitName="custDb") EntityManager manager;

...

Extended persistence contexts

In Hibernate terminology, an extended persistence context is one particular Hibernate session. This session may live beyond the duration of a JTA transaction. In EJB 3.0, you can inject an extended persistence context into a stateful session bean. Unlike transaction-scoped entity managers, these persistence contexts are not created and destroyed in a transaction, but instead have their lifecylce tied to that of the SFSB session. This allows you to have conversations with your database that span multiple JTA transactions.

@Statefulpublic class ShoppingCartBean implements ShoppingCart {
{
 @PersistenceContext(unitName="custDb", type=EXTENDED) EntityManager manager;
...
}

Using EJB 3.0 injection annotations with Hibernate

The JBoss EJB 3.0 implementation allows you to use Hibernate Session and SessionFactory as types for targets of the @PersistenceContext and @PersistenceUnit annotations. The injected Session or SessionFactory will behave exactly as if you were instead using the JPA counterparts EntityManager or EntityManagerFactory:

@Statelesspublic class MyBean implements MyInterface
{
 @PersistenceContext(unitName="custDb") org.hibernate.Session session;
 @PersistenceUnit(unitName="custDb") SessionFactory factory;
...
}

Just like with the EJB 3.0/JPA integration, the Hibernate Session will be associated with the JTA transaction and propagated to nested EJB invocations within the same transaction. It is also ok if these nested calls use the EntityManager API instead. The same underlying Hibernate session will still be used for both.

Hiberate Sessions can also represent extended persistence contexts:

@Statefulpublic class ShoppingCartBean implements ShoppingCart
{
 @PersistenceContext(type=EXTENDED) org.hibernate.Session session;
...
}

Again, the EJB container will manage this Hibernate Session the same way it would manage an EntityManager instance.

Obtaining Hibernate objects programmatically

You can always get access to a Hibernate Session object from an EntityManager instance through the standard EntityManager.getDelegate() method. This is a JPA specification feature.

  @PersistenceContext EntityManager manager;
  ...
{      org.hibernate.Session session = (Session)manager.getDelegate();  }

The specification, however, does not provide a way to get at the underlying implementation of a Query. Hibernate should provide most of its extended functionality through JPA query hints. For example, lets say you wanted to enable a query cache:

  javax.persistence.Query query = manager.createQuery(...);
  query.setHint("org.hibernate.cacheable", true);

Conclusion

Hibernate and the JBoss EJB 3.0 project provide multiple ways in which you can mix and match Hibernate and JPA annotations and XML metadata. JBoss EJB 3.0 can manage Hibernate typed objects the same way it can manage JPA objects. Finally the specification provides programmatic ways to get at the underlying Hibernate connection. With the features you should have the flexibility to get at the HIbernate features you need while staying as portable as possible under the JPA specification. Or conversely, you can use well-defined JPA mapping annotations within your Hibernate deployments to make coding simpler and easier.

Disclaimer ;-) This blog was meant to make you aware of certain integration features that exist between JPA, Hibernate, and JBoss EJB 3.0. You should not use it as a reference guide, but rather dive down deeper into each project’s docoumentation. Have fun.

Posted in JPA, ejb3, hibernate, jboss, opensource | 4 Comments »

Participate or STFU Rod

Posted by billburke on July 6, 2007

I got a few people pissed at me for being a little rough with Rod Johnson on a TSS thread on how Rod feels that EE 6 is “Getting it right”. Here’s what I wrote:

So, since Java EE 6 “Gets it Right” does this mean you’re going to bring Spring to a standards body so that its not controlled by one vendor? Until then, who cares what you think. This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome. Put your money where your mouth is or STFU.

I later added:
Bringing pure IoC into EE 6 and getting somebody like Rod and Interface 21 behind it and supporting it would be a huge step in lengthening the viability of the EE platform. But I don’t think Rod and company believe it is in their best business interest to do so. I hope they prove me wrong. We did it with Hibernate and now with Seam and we found that really embracing standards instead of giving them lip service is a great business enabler.

Some were skeptical that Interface 21 could even work together with JBoss in EE 6. Aligning EE 6 with pure IoC is definately where JBoss wants to go for EE 6, so I don’t think there would be a problem working together. I actually think JBoss and Interface 21 would make pretty good partners in pushing EE 6 in the right direction.

So what was the underlying cause of my original emotional outburst? Rod and company have built a framework and business around tearing down various pieces of EE and replacing it with their own stuff. JBoss has taken a different approach and engaged the JCP process to improve the specifications rather than fight against them. Until Rod and company actually implement a JSR (even one!) or integrate into the JCP process, their opinions on EE 6 direction really mean nothing to me and is just a bunch of posturing. Many of us on EE 6 already know where EE 6 is “Getting it Right” because we’re the ones who pushed a lot of the bullet points in Rod’s “Getting it Right” blah blah blah.

Finally, its easy to smell like shit when you’re knee deep in it. Easier to criticize and tout how much you can do it better when you’re not involved. This is why I wish Rod would STFU, join the JCP, and actually try and fix some of the broken things. If after he’s tried, and it doesn’t work out, then fine, I’ll STFU then. I’m sure with the popularity of the Spring framework, Bill Shannon and company would welcome Rod with open arms. Such a move would have the support of JBoss and I’m sure other vendors.

Posted in business, flame bait, opensource, spring | 14 Comments »