It Depends™

How to use Gemini Naming with Eclipse Virgo (Part 1)

2010-11-10T14:29:00.006-05:00

First, let me get some definitions down.

What is Gemini Naming? It is a bridge to use JNDI in OSGi runtime. More information is available on the gemini naming site. You can also read up in OSGi Enterprise Specification section 126

What is Eclipse Virgo? This is a donated SpringSource dmServer. A really nice modular OSGi runtime/app server.

Now let me explain why would I, being in sound state of mind would try to use JNDI in OSGi.

Long version: I am very lazy and I also like to use other peoples stuff. That stuff is usually not OSGi aware and I am currently trying to use it in Virgo. Most of the time other peoples stuff also needs to be configured with a database connection information. Well, at least stuff that I wanted to use. That configuration can be conveniently provided with 5 to 10 entries in the property file or a single JNDI location string. I already have 5 to 10 entries in the property file to maintain, so I did not want to duplicate it to another property file to be missed during deployment.

Short version: Because I can and hacking/learning stuff is fun.

So without further delay, lets me explain how to deploy Gemini Naming and use it to look up entries from a traditional java app in the Virgo Web Server.

Some preparation is needed:

1. Download Virgo Web Server

2. Unzip that bad boy to a location that we will call $VIRGO_HOME

3. Download Gemini Naming (M1 at the time of the post - so artifact names might change)

4. Unzip that bad boy as well.

5. Copy org.eclipse.gemini.naming.impl-1.0.0.M01-incubation.jar to $VIRGO_HOME/lib/kernel

6. Download APIs for OSGi enterprise bundle from the maven repo and save them to $VIRGO_HOME/lib/kernel

Now we need to modify a few files. Use your editor of choice and modify $VIRGO_HOME/lib/org.eclipse.virgo.kernel.launch.properties to add the OSGi enterprise api bundle to the list of launcher bundles:

launcher.bundles =\
....
file:lib/kernel/org.osgi.enterprise-4.2.0.jar@start,\
file:lib/kernel/org.apache.felix.configadmin-1.2.4.jar@start,\
....

This takes care of the kernel region (Read on for more info on Virgo regions more info on Virgo regions). Now lets take care of user region.

We need to modify $VIRGO_HOME/config/org.eclipse.virgo.kernel.userregion.properties.

1. Let's add Gemini naming to the list of baseBundles in user region

baseBundles = \
... ,\
file:lib/kernel/org.eclipse.gemini.naming.impl-1.0.0.M01-incubation.jarr@start

2. We need to import a package into the user region from the kernel and that is done by modifying the packageImports property:

packageImports =\
..... ,\
org.osgi.service.jndi;version="0"

This package comes from the osgi enterprise bundle deployed in the kernel region and allows us to keep a single version of the bundle deployed in both regions vs. each having an individual copy.

3. Let's enable osgi console at the same time so we can examine the list of services:

osgi.console=2401

Now you can start the server and see the JNDI services deployed.

cd $VIRGO_HOME/bin/
./startup.sh -clean

Connect to telnet console:

$ telnet localhost 2401
osgi> vsh service list

You should see entries:

....
51 javax.naming.spi.ObjectFactory                                    4
52 javax.naming.spi.InitialContextFactoryBuilder                     4
53 org.osgi.service.jndi.JNDIContextManager                          4
54 org.osgi.service.jndi.JNDIProviderAdmin                           4

That is it. Now you can use JNDIContextManager and JNDIProviderAdmin to get a reference to InitialContext or look up services with "osgi:service/" schema name.

Well... You almost can. But that is topic for part 2. Stay tuned. Hint Tomcat gets in the way (see here)

Mule says no thanks to OSGi.

2010-11-09T20:39:00.011-05:00

Ross Mason of MuleSoft posted an article where he argues that OSGi is too complex for end user developer. Although I can sympathize, I do not completely agree. Yes there are areas where OSGi is middleware centric. Yes there are always things that should be simplified. Yes there are pains moving to OSGi.

OSGi is a Dynamic Module System for Java. The key word is Module. Modularity is hard, not OSGi. Properly drawing boundaries between components is hard. Getting communication protocols and APIs right is hard. Unlearning habits of the past is hard.

Dynamic is not something that a regular developer ever learned to deal with properly. For years we have been in a servlet world, where one never really worried about resources/services disappearing or even cared about writing code to account for a multi-threading. I still see code that treats HttpSession as a private HashMap.

Think about all the iterations that enterprise Java went through and all of the technologies involved. CORBA, EJB1, EJB2, RMI, JINI, JNDI, JSP, JDBC, JMS, JCA, JPA, WS-(death)*, and on and on. How many books, articles, man-years of effort and learning went into getting developers to understand that set of technologies? All sorts of stacks and frameworks were built to hide the complexities of that set of technologies. Struts, WebWork, iBatis, Hibernate, Spring (later validated with EJB3/JEE5 and 6), Facelets, Seam, etc. That is a lot of effort from a lot of very smart people to get us to where we are now. It is very easy now to write an app in 3-4 weeks that is useful, pretty and functional. The same would be one to two years of manpower with EJB+JSP+"name the container you hate the most" just seven, six or even five years ago.

With OSGi the situation is very similar to the days of EJB1. Very little information was available in dead-tree format (until recently) and not too many people who you knew were using OSGi. Advice was hard to come by. Surrounding ecosystem was narrowly focused on middleware, embedded devices or Eclipse plugins. The situations is improving dramatically lately. Books are getting published (check out OSGi in Action and Spring DM in Action). OSGi Alliance has started a wiki to spread the jungle knowledge. Many OSS projects are picking up OSGi and provide feedback and information on project specific pages.

OSGi is a great technology, but it is fairly low level technology. It is like coding your whole application persistence logic with JDBC all over again. There are number of OSGi specs that address most of perceived complexities of OSGi: Declarative Services (DS) and Blueprint (Eclipse/SpringDM and Apache Aries) bring DI capabilities to OSGi. Building OSGi bundle metadata becomes simpler by the use of tooling support provided by bnd, bundlor and IDE tooling. Containers like Apache Karaf and Eclipse Virgo are simplifying the use of OSGi with each release.

Having said that, there is one issue with OSGi. Please bear with me while I address it in a roundabout way.

I think it was 2007 or 2008. I was at the SpringExperience/SpringOne conference. There was a lot of talk about data grids, super-duper distributed caching, mass scaling. All that sounded like candy to me. During one of the BOFs I asked Rob Harrop of SpringSource fame - "what is stopping adoption of this technology for use in an everyday project". His answer was very interesting and I wish I wrote it down, but it boiled down to (paraphrasing) :

Developers want to use APIs and tools that they already know. If there are serious limitations on usage of those tools and APIs, developers tend to scream bloody murder and bail.

OSGi is a different programming model from what we have learned to use so far. It has different quirks (TCCL handling is undefined in the spec for example) and not all libraries that we grew up with play nicely in that different programming model. Until all/most of the current cream of the crop libraries work seamlessly, or with very limited, configuration-only changes (no recompile/re-bundling required), there will be a push back on OSGi adoption.

I do not consider myself an OSGi evangelist or a zealot. I really do not think that OSGi is a golden hammer or a nail. OSGi and modularity forces architects and developers to think about overall architecture in much more detail. There are projects that just don't need it. But there are applications that will benefit greatly from OSGi support. Those applications will tend to have a longer lifespans without complete rewrites and will be less complex after 2 years in production than a usual package tangle that is found in other so called "enterprise" applications.

News flash from SpringOne2GX

2010-10-20T21:40:00.002-04:00

This is very interesting development. https://greenhouse.springsource.org/ (get source at http://git.springsource.org/greenhouse)

A way to use Spring when building social/mobile apps. Including OAuth, integration with Twitter/LinkedIn/etc.
There is SpringMobile and SpringSocial projects.
Very very interesting. Including Grails/Spring Data support for NoSql datastores - very inventing of them to
revitalize Spring Framework in post JEE world.

Compiling Hibernate 3.5.x

2010-03-02T09:13:00.004-05:00

Few days ago I wanted to build Hibernate new 3.5.x trunk to see the documentation and basically eyeball differences from prior versions. I found this page (http://www.hibernate.org/422.html) and followed the set-up steps. This is where the pain started.

First off, build failed with an maven enforcer plugin error. I am running on jdk 1.6, specifically "1.6.0_17". Enforcer has a configuration that stops build when building with 1.6 jdk i.e. [1.5,1.6) - require at least 1.5 exclusive of 1.6.
Ended up changing that to [1.5,1.7)

Secondly, I am working on a Mac and hibernate builds documentation with po2xml that is not available on mac out of the box. Need to use ports (fink, macports, etc). I had an Ubuntu VM - so instead of messing around with ports I just moved to vm.

Thirdly, build was doing some very strange things - i.e. jar artifacts were not getting published to local .m2/repository. For some reason they were renamed to $artifact.jdocbook-style. This was totally bewildering result. I spent a bit of time trying to look at the debug log from Maven - but that provided no immediate results. A hint came from :


<requireMavenVersion>
 <version>(2.0.7,)</version>
</requireMavenVersion>

I was using Maven 2.2.1. So I thought - would it help to downgrade to 2.0.11 and see if that helps? Well - yes it did help.
After repointing M2_HOME to location of 2.0.11 - build worked fine.

The moral of the story - to build hibernate you MUST use Maven 2.0.11 until something funky is fixed in maven jdocbook plugin.

Common local repository location for spring-build ivy artifacts

2010-02-06T04:04:00.007-05:00

SpringFramework in version 3 came out with a common ant + ivy build system across most of the projects.
One thing that was driving me insane is that this build would pull artifacts into a project specific repository directory during ivy resolution vs. a common directory (like maven). As I was playing with the different projects and different versions of those projects disk usage was going through the roof.

The only way that I found to have a common location is to provide a -D flag to ant:


export ANT_OPTS="-Divy.cache.dir=$HOME/.spring-build-ivy-cache"

Single location, minimize disk usage. But there is always a but in there somewhere. dm-server code base for one makes some assumptions about where that repository is located, i.e. "../ivy-cache/repository/[artifact]". I ended up creating a symbolik link for those situations. Not the best solutions but freed about 1G of space on my machine.

WebFlow on dmServer

2010-01-22T17:10:00.003-05:00

It should be easy to use webflow on dmServer right? Well, not if you depend on maven to copy dependencies.
Just ran into few issues and wanted to share:

1. Bundle-Import both org.springframework.webflow and org.springframework.binding (too many packages to import individually)
WebFlow xml config will try to add a ConversionService from binding to your app context and if you don't have binding packages imported - BOOM...
2. Don't forget el libraries
WebFlow libd (library) has an optional dependency on org.jboss.el:com.springsource.org.jboss.el:2.0.0.GA and does not even lists ognl. org.springframework.binding imports javax.el, org.jboss.el and ognl as optional so resolution does not fail until you try to create an app context and webflow can't find any el parser to use and throws up.

That is it for now.

dmServer plans and osgi services

2009-12-12T09:09:00.011-05:00

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?

2009-12-11T12:27:00.004-05:00

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...

2009-08-13T16:44:00.002-04:00

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

2009-08-10T17:01:00.003-04:00

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

2009-02-09T09:44:00.004-05:00

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

2009-01-28T09:52:00.002-05:00

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.

SpringOne Keynote

2008-12-02T08:48:00.001-05:00

I am at SpringOne in Florida. As always it is nice to be out of the cold and in a nice hotel. Food is good, content is great. Good times.

Now for some news. Rod Johnson did an opening night keynote. Very informative and nicely presented as always. Major take away: SpringSource stands for "Creative destruction of complexity" and Spring Framework provides "Weapons for the war on Java complexity". So now you are warned!

I will not try to reproduce it all. Here and here have a great write-up already.

Biggest announcement has to be a new tc Server. Basically Tomcat with integrated AMS and great management console. That should open up a number of doors for SpringSource. I have been in a number of engagement where BEA and IBM servers were used only because they provided a much better operational environment. Will be interesting to see what SpringSource guys will come up with next.

At Philadelphia Spring User Group we will be doing a SpringOne redux on December 10th. So if you in the area come check it out. We will cover all of the announcements and happenings. phillyspring.org for information.

Comparing MVC Frameworks?

2008-10-28T11:20:00.003-04:00

I saw a question on one of LinkedIn groups asking for a comparison of MVC frameworks. Obvious reaction is to point to Matt Raible's presentation from 2007 on this topic. Thinking further brings up an "It Depends" moment. Now days it is not enough to just use "best" MVC framework.

Is this a green field project, i.e. do you have any legacy code to integrate?
What type of application is this going to be?
Is there need for wizards with suspend/restart functionality?
What are you using for persistence?
Do you have need for DI container?
Is there a need for "flashy" desktop feel to the application?
What is experience level of developers who will develop this application?

Those and other questions must be considered before making a decision on presentation framework. UI is only one, albeit very important, part of the system architecture. Care must be taken to pick a UI technology that compliments and plays nice with other pieces of overall system.

Before jumping in bed with a framework make sure that development staff is comfortable and understands underlying technology, i.e. does not have to be retrained. Make sure that picked technology fits with a business direction/objectives/strategy few years in a future. Don't get caught up in a short term trends or you will suffer pains of complete rewrite when business focus changes.

SpringSource dm Server with Rob Harrop

2008-10-07T21:24:00.003-04:00

Just a quick announcement. Philadelphia Spring User Group will be hosting Rob Harrop of SpringSource fame. He will be presenting on recently blessed SpringSource dm Server. This is the one that is all OSGi inside and out. Very cool stuff.
Rob is one of the best technology speakers out there. If you are insterest in OSGi, SpringDM and SpringSource dm Server, this is the presentation for you.

Check out http://phillyspring.org for details.

Change of course at SpringSource

2008-10-07T21:01:00.003-04:00

Glad to see an announcement from Rod. Honestly, what took so long?

We are amending our maintenance policy in the light of community feedback. We will make regular binary releases from the Spring trunk available to the community, with no 3 month window. For each version of Spring, community releases will be available while it remains the trunk or until the next version is stable.
Once we have published a release candidate for a new version of a project, we will typically not release further tags or binary builds of earlier versions of the project to the open source community. Such releases will be available for three years to SpringSource Enterprise customers.

This is the type of a policy that I would be completely comfortable with. Initial version seemed a little out of character and rushed. Call me a "Spring Fan Boy" but I am mighty happy with the news today.

Cloud Computing Conference

2008-10-03T15:43:00.003-04:00

What is Cloud Computing? It depends on who you speak to. I don't have an answer. I like the idea and would like to learn more about it. If you are like me, my employer Chariot Solutions is sponsoring a conference on Cloud Computing on Friday, October 17th at the Penn State Great Valley campus.

We have some big names attending:

Jeff Barr of Amazon.com speaking about Amazon's EC2 and S3 Cloud Computing platform
Joe Gregorio and Johnathan Rochelle of Google, talking about Google App Engine and Google Spreadsheets
Justin McCarthy and Britt Crawford of Cafe Press, the developers of HiveDB, a cloud-capable database platform
Prasaad Chakka of Facebook, speaking about data warehousing in the cloud with Hive
Chris Richardson, author of "POJOs in Action" and developer of CloudTools, a mechanism for deploying Java and Groovy applications in the cloud
Ezra Zygmuntowicz of Engine Yard, a Rubyist, developer of MERB (a high performance alternative to Ruby on Rails) and author of Vertebra, a cloud computing platform

There are several more sessions, including an hour-long panel talk on using Amazon and other cloud platforms with local experts Toby DiPasquale, Chis Cera, and Andrew Kortina.

If you're interested, the web site is http://www.cloudconeast.com

Maybe I'll see you there.

SpringSource travesty!

2008-09-23T09:57:00.005-04:00

Or Not? It Depends! There was a lot of speculation and outcry at the initial announcement. Just read theserverside fireside chat. Both Rod Johnson and Mark Brewer from SpringSource dropped by to provide some explanation. I am still hungry for explicit details.

How IP of the enterprise supported changes be handled or if there will be a difference at all?
Will there be tags made as point releases are made to the paying customers? I would really, really, really hate to go off the trunk only.
How transparent will the changes made to support paying customer be? Will there be a jira link, release notes, some sort of description of the change? That would be crucial when building of the trunk. Personally I do not have bandwidth to monitor FishEye.

I do not think that this is a sell out by SpringSource but I am biased. I have spent the last 5 years using Spring Framework. Now I can hardly write an "enterprise" app of any size without it. I got lazy about looking for an alternative because Spring is so damn good.

I am yet to see a huge issue with announcement outside of inconvenience. Most of the customers that I work with pick a version and stick with it for a while. Lets say they have 2.5.2 and it will take an act of deity to move them to 2.5.5 unless it it the next major internal release.

So lets wait and see. If SpringSource does pull an Ext, there is a solid foundation that can still be forked and developed by the community. I really hope it will never come to that.

Further reading:

SpringSource manifesto
Rod on Open Source contibutors
Rod on Enterprise Open Source (Presentaton Slides from Emerging Technology for Enterprise Conference 2007)
Craig Walls thoughts

Quick thought on Google BigTable

2008-09-13T14:48:00.003-04:00

We just had one of the internal geek fests at my much heralded employer. Eric presented on Google App engine. Very interesting. One observation that I came away on BigTable and transactions through data store api. That is ALL of the entities that you want persisted in transaction in AppEngine must belong to the same Entity Group.
Translate that to Java and DDD -> Aggregate Roots. The root entity could be an aggregate root and should be persisted as a whole. Interesting way to partition data. Have to play with Python and AppEngine.

So why "It Depends™"?

2008-09-05T09:19:00.004-04:00

What's in the name? Let me start with a story.

I once worked for a client. You know the type. The one with huge "NIH" (not invented here) syndrome. The one where "open source" is a curse word. Thankfully there are a number of very bright and gifted people working there trying to bring about a change. But no matter how great those folks are, the story is not about them.

While there, we were looking into introducing Spring Framework as a back bone of future architecture. Every one who worked with Spring knows that there are number of ways of doing anything with it. Fried, broiled, baked, shaken, not stirred... After a while I had a standard response to each question that client asked: "It Depends...". My coworker, very funny guy by the way, soon added a "TM" to the phrase and mentioned that all usage of the phrase cost 10c payable immediately.

So that is the story. But that got me thinking. And the thought was: There isn't a golden hammer in software engineering. And this engineering thing is a big misnomer. Working with software is more like art vs. production line and model T. There are no preset measurements on parts. No stringent requirements. "This procedure must be completed in 101.23 lines of code". There is a final product that should do X. And how it does it - who cares!!! End user does not. As long as it does what the user wanted, performs well, delivered on time. It must be maintainable and bug free to be viable as a product going forward. That is where art comes in and "It Depends™" takes root.

How to solve a problem always depends on the context of a problem and surrounding problem domain. Who in the right mind would use a JSF + WebSphere Portal + DB to display a static html page? But some companies do that, because that is the stack they use for web based deployments. There are tons such examples out there. No need to look further than last project you or I worked on. Oh do I have some stories to tell about those :) Maybe next time.

Hello World!

2008-09-04T10:11:00.000-04:00

I guess I should start with an introduction and a reason for you, dear reader to stop by back here and read the musing of another deranged blogger with Pinky and Brain aspirations. So here we go.

Hello and Welcome!

My name is Dmitry Sklyut and I am a software developer/architect living a peaceful life in suburban Philadelphia. I work here (and just in case: "The opinions expressed on this blog represent my own and not those of my employer unless specifically stated in section 42 of ...” You get the picture...). I work mostly with Java since around 1999, but was paid to write PowerBuilder (Remember Data Window??? Sight...) and MUMPS (don't ask) among other more standard things.

I am very into Spring Framework for its simplicity and productivity gains. Been using it since version 1.1. I like and use a lot of other open source technologies from Hibernate to Tomcat. Lately I got very interested in OSGi. Mostly for its ability to build modular applications and secondly for the deployment aspects. On my plate is a shelf full of books to read, languages to learn and technologies to explore.

I did start writing a blog a while back but that went by the way of Dodo Bird. This is my second attempt of providing some consistency to the endeavor. This attempt has been triggered by my last project and I will blog about it later.

What type of content can you expect? Technical, computery, and programy type of a stuff. I will try to minimize the rambling. Politics will not be discussed here, except in context of where to put the brackets in the code :)

So welcome again and stay tuned.