dmServer plans and osgi services

SpringSource dmServer is very nice piece of equipment. One of the major additions to the OSGi arsenal is concept of plans. Plans are deployment descriptors that allow for composition of application assemblies and provided added capabilities like scoping. You can think of scoped plan as a pseudo bundle that shades all included artifacts and creates a concept of a nested classloader. Very similar to jee concept of nesting wars and ejb-jars in ear. This is very useful addition that allows normal use of ORM libraries like hibernate that use TCCL (thread context class loader) and expect all classes to be found by classpath scanning. Scoping also hides services published within a scoped plan. No service gets out from a scope into a global service registry.
This is all nice and dandy, but what if you do want to "jail break" a service from a plan? Well there is a very simple way to do it. As Glyn describes in this thread on SpringSource dmServer forums, it's as simple as adding a service property.

Example:

<service id="publishIntoGlobal" interface="java.lang.CharSequence">
<service-properties>
    <beans:entry key="com.springsource.service.scope" value="global" />
</service-properties>
<beans:bean class="java.lang.String">
 <beans:constructor-arg value="foo"/>
</beans:bean>
</service>

Is JSR294 Active or Inactive?

I was surprised to find out that JSR 294 was marked inactive (here). Is it really inactive? It depends on who you ask. From Alex Buckley email for JSR 294 mail list, 294 is still alive:

The PMO has a new rule: a JSR that doesn't produce an EDR for 18 months is marked inactive. Nothing else happens, just the marker.

Officially, 294's last EDR was December 2007. However, as per the agreement with 277 and 294 EG members in December 2008, 294 was revived ain January 2009.

Materials for an EDR were presented privately to the 294 EG in June 2009. You and BJ sent useful comments. Just about the time I was ready to file the EDR, the Simple Module System proposal showed up. I can only imagine the complaints had I proceeded with the EDR at that time.

So, I will file an EDR this month based on the materials from June, along the following lines:

- Module accessibility is a JLS concept; runtime module is a JVMS concept.

- Module compilation unit is a JLS concept; it defines a module name + version; it is annotatable; its contents are implementation-defined.

- java.* APIs are limited to representing runtime modules and (the runtime form of) module compilation units.

Direct link here

Good bye S3Browse. It was fun...

While browsing springsource s3 repo noticed Important News.

Slight panic, but Google came to the rescue again and pointed to http://shrub.appspot.com/

Much relief and rejoicing followed.

SpringSource + VMWare == Couple

VMware will acquire SpringSource for approximately $362 million in cash and equity plus the assumption of approximately $58 million of unvested stock and options.

There is nothing bad in getting paid for the work you do. It is even better to get paid a lot. Congratulations!

On innovation within comfort zones

This is brilliant!!! Perfect example of why innovation happens elsewhere!





That huge process chart on a wall is classic!

All too often technology/hi-tech companies succumb to a top heavy bureaucratic management. Everyone is comfortable, paid well, got a well lubricated 401k. Why rock the boat? Because that well lubricated job will go by a way of a dodo bird if your organization stops to innovate. There is simply no chance that any single product can continue to monopolize the market in a day of open source and web everywhere. A pimpled faced kid working from his dorm room can single handed revolutionize a way any problem is solved or approached. Examples are abound! Napster, Microsoft (in early days), Google, Apple, Linux, many many others. There can't be a lull, no time to milk a product, no time to rest. That is why rocking the boat is good and much needed practice.

Great thought

From Why Scripting Languages Matter

The reason why dynamic languages like Perl, Python, and PHP are so important is key to understanding the paradigm shift. Unlike applications from the previous paradigm, web applications are not released in one to three year cycles. They are updated every day, sometimes every hour. Rather than being finished paintings, they are sketches, continually being redrawn in response to new data.

The quote is great. What a fantastic perspective to present when choosing a technology stack for your next project!

The great write/compile/package/deploy does not work that well for the web apps. There is a need for agile/scripting approaches even in "enterprise" (non Web2.0ish) environment. There will come a time when waiting 3 weeks for a fix and re-deploy will not work for anyone.

Would love to build an app with groovy/grails or ruby/rails on the front and Java back end. Fully asynchronous, even-based, ESB/SOA... I think I may just get a chance.