tag:blogger.com,1999:blog-78765060898210140472024-02-08T14:12:57.488+01:00Shards of DevelopmentA blog about Java, Eclipse, OSGiGiammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-7876506089821014047.post-34899319655369219242022-01-06T15:01:00.001+01:002022-01-06T15:01:24.956+01:00SITE MOVED - you will be redirected in 5 seconds<p> SITE MOVED - you will be redirected in 5 seconds</p>Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-37889786678900691102017-05-31T20:19:00.001+02:002017-05-31T20:19:39.592+02:00Java 9 delayed... again <p dir="ltr">As expected, after the down vote of the expert group, jigsaw and Java 9 are delayed once more. This time it's a 8 week delay <br>
http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-May/005864.html</p>
<p dir="ltr">Will the expert group reach an agreement? I am not very optimistic, but would be happy to be proven wrong. <br>
</p>
Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-4614245878123498672017-04-17T11:58:00.001+02:002017-04-17T12:20:27.820+02:00Java 9 Jigsaw and OSGiOn Google+ <a href="https://plus.google.com/+MarkDerricutt/posts/JCBVnePiAJj" target="_blank">Mark Derricut</a> wrote about a <a href="https://developer.jboss.org/blogs/scott.stark/2017/04/14/critical-deficiencies-in-jigsawjsr-376-java-platform-module-system-ec-member-concerns" target="_blank">post</a> by RedHat's Scott Stark about Jigsaw, the Java 9 module system, as well as a <a href="https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f" target="_blank">follow up</a> by <a class="link link link--darken link--darker u-baseColor--link" data-action-source="post_header_lockup" data-action-type="hover" data-action-value="3748c5d6e52c" data-action="show-user-card" data-collection-slug="mike-hearn" data-user-id="3748c5d6e52c" dir="auto" href="https://blog.plan99.net/@octskyward?source=post_header_lockup">Mike Hearn</a>.<br />
<br />
I have been following Jigsaw for some years, and I found both posts very interesting. Scott's post highlights some worrying problems in the current Jigsaw implementation. I was already aware of some of them as I read some earlier posts by <a href="http://njbartlett.name/index.html" target="_blank">Neil Bartlett</a>, saw his <a href="https://www.eclipsecon.org/europe2016/taxonomy/term/1031/all" target="_blank">presentation</a> at EclipseCon Europe 2016, and I have been following <a href="https://wiki.eclipse.org/Thomas_Watson" target="_blank">Thomas Watson</a> OSGi-Jigsaw interoperability <a href="https://www.eclipseconverge.org/na2017/session/osgi-java-modules-jpms-all-way-down" target="_blank">experiments.</a><br />
<br />
In his follow-up post Mike says to lean more toward Jigsaw because OSGi is complicated, poorly documented, uses a crazy versioning approach, and is not that well known. He also said that he'd rather prefer the module declaration to be a source file compiled to byte-code rather than a XML or textual file, and highlights <b>jlink</b> (which allows you to create a <i>statically linked</i> distribution of your application that includes the JRE) as an example of good tools that the JDK will provide on top of Jigsaw. Mike says the RedHat post is not fair, that the authors think <i>“we were here first, so what we did is best practice and you should do it too”</i>, and that Oracle dropped many aspects of other module systems such as OSGi or JBoss Modules to avoid their complexity and reduce the risk.<br />
<br />
I personally believe that RedHat builds amongst the most sophisticated products on the market. We must recognize that their people are knowledgeable, their software is robust and runs thousands of applications in production. Writing modular software is certainly more complex than writing monolithic applications. By making Application servers and middleware solutions, companies like RedHat and IBM have to deal with this problem more than any one else. They also have a very large client base, therefore they should be aware of the Java enterprise landscape more than anyone else. Hence, it's my opinion that when RedHat engineers express concerns about the ability of Jigsaw to fulfill today requirements for modularity we should listen to them very carefully. Besides, RedHat JBoss does not officially support OSGi, so they are not really trying to advocate for it; I believe they are simply trying to highlight the issues in Jigsaw. Scott's post includes contributions by Maven committers, and I trust their opinion as Maven is not tied to OGSi or JBoss Modules. Like it or not, Maven is the standard for building Java, therefore I am very worried by the long list of issues between Jigsaw and Maven and if I was Oracle I would have paid more attention to Jigsaw-Maven compatibility.<br />
<br />
I also believe that it should be clear to everyone that in recent years Oracle has been working a lot on JavaSE without caring that much about JavaEE, still stuck at version 7. I am afraid we will need to wait ages for JavaEE 9 or that it may happen that JavaEE 9 will be skipped and we will have JavaEE 10 when Jigsaw will have matured in JavaSE 10. <br />
Long story short: future does not look bright for JavaEE developers, who historically always had to use older versions of Java for several years and now it may be even worse.<br />
<br />
Is modularity only important for vendors like RedHat or IBM? Of course not. Enterprise applications become more and more complex year after year. For example, it's now very common to have to support native mobile applications as clients, to have to provide API for third parties, to have to provide features such as social integration (Facebook, Twitter, LinkedIn) and collaboration (e.g. chat and video conference capabilities), and many more.<br />
If you are a vendor with a large functional offering there are many chances that not all your clients will want to buy everything, hence you need to modularize your offering to be able to license to your clients and deploy nothing more than what they want and need.<br />
<br />
I am not affiliated with RedHat, OSGi but I would like to comment to some of Mike statements.<br />
<br />
First few words about myself. I have been coding in Java since 1999, professionally since 2001. I spent the first few years of my career on Java Enterprise, then moved to Eclipse plug-in development for 7 years or so, then back to Java enterprise. In 2001 I was deploying Java Enterprise applications on IBM WebSphere 3, by copying all Jars to some folder on the server file system and by specifying the application class-path in a 20 column (yet scrollable!) text field of the Swing Gui used for administering WebSphere (EAR files were not supported at that time).<br />
<br />
<b>Mike' statement #1: OSGi is complicated</b><br />
When working with large JavaEE applications, the so-called Java "<a href="https://dzone.com/articles/what-is-jar-hell" target="_blank">Jar hell</a>" has always been a major issue to me. It's when I started coding for Eclipse 3 that I met OSGi for the first time, and I can tell you that I can not imagine a platform like Eclipse to succeed without a strong modular system. Eclipse plug-ins are "simplified" OSGi bundles: most of them don't use<br />
the OSGi registry (or at least do not require downstream plug-ins to use it), they express dependencies in term of plug-in names rather than packages, and the Equinox OSGi container runs in a more "relaxed" way than strict OSGi. Programming for the Eclipse platform told me that OSGi is not that complex, you can code your first Eclipse plug-in in minutes, and modularity really helps in large applications. <br />
<br />
When I moved back to JavaEE I tried to run OSGi on the server. The specification addresses some complex concerns such as dynamicity and the possibility that bundles are installed/uninstalled<br />
on a live application. This requirement is covered by API such as BundleListener and ServiceTracker which certainly add complexity. However most applications will not need that dynamism. Eclipse for example does not allow users to replace individual bundles and always requires a restart after installing/updating some plug-ins. IBM WebSphere Liberty, a JavaEE and OSGi Application Server, does not allow you to hot-swap individual bundles of your OSGi application, which can only be started/stopped as a whole.<br />
Hot-swap makes a lot of sense for IoT or embedded systems, but is not strictly necessary for Enterprise Applications. So if you don't need that level of dynamism most of the perceived OSGi complexity disappears and OSGi becomes just a module system, offering API on top of Java that you may want to use or not. For example, if you like Spring you can get <a href="https://www.eclipse.org/virgo/" target="_blank">Eclipse Virgo for Tomcat Server </a>and develop your truly modular, Spring based, application with very limited knowledge of OSGi itself (disclaimer: I am a Virgo committer). But you will still get an OSGi environment that enforces true modularity (and can support the most complex scenarios in case you need them).<br />
<br />
If you compare it with JavaEE, the OSGi spec is smaller and in my opinion better written. If you started with JavaEE several years ago and saw it growing then you learned JAXB, JAX-RS, JPA gradually. But if you start today as a new developer, JavaEE has a learning curve which is as complex as OSGi. That's why frameworks like Spring are so popular.<br />
<br />
<b>Mike's statement #2: OSGi is poorly documented</b><br />
This may be the case. For plain Java you go to the Oracle website and start from there. For OSGi, information is scattered over the web and it's difficult to pick the right one for starting. The OSGi Alliance web site is not that good, although they are trying to fix that with project <a href="http://enroute.osgi.org/" target="_blank">enRoute</a>.<br />
<br />
<b>Mike's statement #3: OSGi is not that successful</b><br />
A lot of products out there are built on OSGi. Let me give some examples:<br />
<br />
<ul>
<li>Pretty much all IBM Java products (Eclipse, IBM Notes, WebSphere, the Rational suite). I read somewhere that IBM has 100+ products implemented in OSGi. Again, my opinion is that if IBM selected it there must be some good value in OSGi.</li>
<li>If I am not mistaken, Sonatype Nexus, the Maven repository, is an OSGi application.</li>
<li>Liferay is an OSGi application. </li>
<li>At least some WSO2 products are OSGi based (Carbon)</li>
<li>Glassfish/Payara is OSGi based</li>
<li>If I remember correcty, Oracle WebLogic is built on OSGi</li>
<li>Most of the popular Java libraries are also OSGi bundles, for example: Google Guava, Google Guice, Google Gson, most of the Apache libraries, Jackson, Slf4j, EclipseLink and Jersey by Oracle and many many more. I doubt all these projects had OSGi metadata out of the box if no one was asking for them.</li>
</ul>
<br />
<br />
<b>Mike's statement #4: OSGi’s approach to versioning is really crazy</b><br />
Mike complains that OSGi requires you to give a version not only to the module itself but also to the exported Java packages. Having worked on Eclipse plug-ins first and later on pure OSGi I think the OSGi approach makes a lot of sense. Eclipse plug-ins depend on module names. This is problematic when the code base is refactored and a large plug-in is split in two: your dependency is impacted and you need to change the name of the plug-in you depend upon or add another one. That's why Eclipse contains "compatibility" bundles that re-aggregate and re-export as a whole modules that have been split. Depending on packages makes much more sense, your dependency declaration is not affected even if the maintaners split or rename their bundles. Would you depend on javax.xml.parsers or would you depend on Apache Xerces? Would you depend on the Servlet spec or would you want your code to depend on Tomcat implementation? <b> </b><br />
<br />
<b>Mike's statement #5: module declaration should be a source file</b><br />
I agree with Mike that the module declaration should be natively supported by the compiler. I believe this is also what the OSGi Alliance would have wanted if they had the ability to change the compiler. Module declarations as source files will allow the compiler to check for errors at compile-time. At the same time I also agree with Scott that the module declaration should be readable to diagnose problem at run-time. Therefore I agree it should not be compiled to byte-code, but rather kept "as is" to be readable, or maybe compiled at run-time, or maybe compiled in a readable format, such as a MANIFEST.MF file or a XML file.<br />
<br />
<b>Mike's statement #6: Oracle will build better tools on top of Jigsaw</b><br />
It's true that today to code for OSGi or JBoss Modules you have to rely on IDEs and third party tools as those module systems are not supported natively by the JDK. So it's clear that the situation will improve when the the Java language will provide modularity out of the box. However this point is a bit stretched in my opinion, because this could have been the case also if Oracle decided to build a different Jigsaw, or to adopt OSGi or JBoss Modules. Plus, I would not bring jlink as an example of a great improvement because that tool will most likely be of little interest to Java enterprise developers, and in my opinion it's in Java Enterprise where modularity is most important. The Eclipse platform of course is not JavaEE but despite being a desktop application, it's nature makes it more similar to a container than a JavaSE application.<br />
<br />
<b>Conclusions</b><br />
To conclude, in my opinion modularity in software is inherently complex. Module systems need to support that complexity and therefore will be complex as well. OSGi not only addresses modularity but also dynamism which adds additional levels of complexity. You can however decide to ignore the dynamic part of OSGi, like the Eclipse platform does, and simply take advantage of it's support for modularity. Jigsaw could do the same, be a subset of OSGi and provide support for modularity. I understand that Oracle is having troubles making the JDK modular, and that Jigsaw is conservative to reduce risks. However it's probably a bit too limited as a modular system. Let's hope this is the first iteration, let's hope it will be adopted by developers, and Oracle will quickly release a 2.0 version that will be feature-wise closer to OSGi or JBoss Modules. Meanwhile, Maven will probably play a big role in making Jigsaw successful or not.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-71897608102604025692017-03-10T19:48:00.004+01:002017-03-10T19:49:55.528+01:00Virgo 3.7.0 Released Today Florian <a href="https://www.eclipse.org/forums/index.php/t/1084915/" target="_blank">announced</a> the availability of Virgo 3.7.0. <br />
<br />
Virgo 3.7.0 brings several <a href="https://www.eclipse.org/virgo/download/release-notes/3.7.0.RELEASE.php" target="_blank">improvements</a> (most notably Tomcat 8.5 and Spring Framework 4.2) and is paired by release 1.5.0 of the Virgo Tools, the Eclipse IDE integration.<br />
<br />
This is the first official Virgo release since I joined the project as a committer, and it's also my first open source release in general. I am very happy and very proud of what we achieved.<br />
<br />
<a href="https://www.eclipse.org/virgo/download/" target="_blank">Download</a> Virgo and get Virgo Tools from the update <a href="http://download.eclipse.org/virgo/release/tooling/" target="_blank">site</a>!Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-88355360497144209902017-02-02T17:24:00.001+01:002017-02-02T17:24:01.227+01:00Virgo 3.7.0.M4 releasedVirgo 3.7.0 M4 has been <a href="https://www.eclipse.org/forums/index.php/t/1083995/" target="_blank">released.</a><br />
<br />
The final 3.7.0 release is planned for end of Feb. Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-45419158305473179412017-01-05T21:43:00.001+01:002017-01-05T21:44:59.411+01:00Virgo Tools 1.5Since September 2015 I am a committer of the open source <a href="http://www.eclipse.org/virgo" target="_blank">Eclipse Virgo</a> project.<br />
<br />
I have written several posts in the past about the Eclipse Virgo OSGi application server, and after having helped the project team with patches and bug fixes I have been invited by <a href="http://eclipsesource.com/blogs/author/fwaibel/" target="_blank">Florian</a>, the project lead, to join the team as a committer.<br />
<br />
I am an individual committer, contributing to the project in my spare time. I spent almost all of my effort on the Virgo Tools, the Eclipse plug-ins that integrate Virgo as a test environment in Eclipse. The most notable improvements of the upcoming version 1.5 of the Virgo tools will be:<br />
<ol>
<li><b>Support for PDE Plug-in projects</b>. This is the possibility to develop for the Virgo runtime using the Eclipse PDE Tools, Plug-in Development Environment. This was one of the most requested and long standing missing features. See <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198" target="_blank">here</a> and <a href="http://www.eclipse.org/virgo/documentation/virgo-documentation-3.7.0.M01/docs/virgo-tooling-guide/html/ch07.html" target="_blank">here</a>.</li>
<li><b>Improved support for plan projects. </b>Virgo supports deployment of a number of artifacts, including Plans. Plans are XML files listing Bundles and other Plans to be activated. The Virgo Tools now provide fair <a href="http://www.eclipse.org/virgo/documentation/virgo-documentation-3.7.0.M01/docs/virgo-tooling-guide/html/ch08.html" target="_blank">support</a> for having Plan files in Eclipse and deploying them to the test environment.</li>
<li><b>Bug fixes and documentation</b></li>
<li><b>Compatibility fixes for Eclipse Neon</b></li>
</ol>
We are currently planning to release the Virgo Tools 1.5 in January 2017 to be shortly followed by Eclipse Virgo 3.7.<br />
<br />
Stay tuned!<br />
<br />
<br />Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-13425549864204003562014-10-22T13:20:00.002+02:002014-10-22T13:20:46.875+02:00Profiling Virgo with JProfilerThe information below has been tested with JProfile 5 on Linux 64bit, and assumes that the JProfiler Agent is installed in folder <code>/opt/jprofiler5.</code><br />
<code><span style="font-size: small;"><span style="font-family: inherit;"></span></span> </code>While this post refers to a rather old JProfiler version, I am sure the principles apply also to more recent JProfiler version.<code> </code><br />
<code> </code><br />
The following environment variables must be set <strong>before starting Virgo</strong>: <br />
<blockquote class="tr_bq">
<pre>export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/jprofiler5/bin/linux-x64
export JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/a:/opt/jprofiler5/bin/agent.jar -agentpath:/opt/jprofiler5/bin/linux-x64/libjprofilerti.so=port=8849"
</pre>
</blockquote>
If your JProfiler installation is not located in <code>/opt/jprofiler5</code> change the above paths accordingly.<br />
<br />
<div class="wiking flash tip">
A convenient method for setting the
environment variables consists in creating a <b>setenv.sh</b> file in the Virgo
bin folder. If such file exists, it will be invoked by the <b>startup.sh</b>
script.</div>
<div class="wiking flash tip">
</div>
Additionally, it is necessary to modify the <code>java6-server.profile</code> file contained in the <code><VIRGO_HOME>/configuration</code> folder to ensure that the property <code>org.osgi.framework.bootdelegation</code> contains the <code>com.jprofiler</code> package, as in the example below.<br />
Note: <u>do not replace the file content, just add the <code>com.jprofile.*,\</code> line</u>.<br />
<blockquote class="tr_bq">
<pre><code class="a syntaxhl"><span class="CodeRay">org.osgi.framework.bootdelegation = \
org.eclipse.virgo.osgi.extensions.*,\
org.eclipse.virgo.osgi.launcher.*,\
org.eclipse.virgo.kernel.authentication,\
com.sun.*,\
com.jprofiler.*,\
javax.xml.*,\
org.apache.xerces.jaxp.*,\
org.w3c.*,\
org.xml.*,\
sun.*</span></code></pre>
</blockquote>
After applying the above changes, start Virgo and connect using the JProfiler GUI.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-4219117906695751392014-08-30T11:08:00.001+02:002014-08-30T11:08:40.834+02:00How to use Hyperic to monitor Eclipse Virgo 3.6Few days ago I started looking for a monitoring tool to track the health status of our <b>Virgo Server for Apache Tomcat</b> instances.<br />
<br />
As I could not find anything Virgo specific, I looked for an open source tool that supported Apache Tomcat 7.0.<br />
<br />
First try was <a href="http://www.moskito.org/" target="_blank">Moskito</a>, but it does not seem to support the OSGi-aware Tomcat that is embedded in Virgo. In any case I did not like the deployment approach, which requires to add Mosquito to every monitored Web App.<br />
<br />
So I searched for monitoring tools that used Tomcat JMX support, as I believed such tools should be unaffected by the OSGi runtime, and I found <a href="http://www.hyperic.com/" target="_blank">Hyperic</a>. <br />
<br />
<h3>
Hyperic 5.8 </h3>
<h3>
</h3>
Hyperic is developed by SpringSource and there exists both an enterprise distribution (vCenter Hyperic) and a <a href="http://sourceforge.net/projects/hyperic-hq/" target="_blank">free-to-use</a> distribution.<br />
<br />
Hyperic consists of the Hyperic Server and the Hyperic Agent.<br />
<br />
The server is a Tomcat6-based Web application that uses PostgreSQL for storing historical data and which provides the monitoring console.<br />
<br />
The agent is a stand-alone Java application that integrates with the O.S. via the well known <a href="http://www.hyperic.com/products/sigar" target="_blank">Sigar</a> native library (used by <a href="http://jmeter.apache.org/" target="_blank">JMeter</a>, <a href="http://www.elasticsearch.org/" target="_blank">Elasticsearch</a> etc), and which features a number of plug-ins for different servers and database systems (WebSphere, WebLogic, JBoss, Tomcat, Apache, Oracle, DB/2, PostgreSQL, MySQL and many <a href="https://github.com/hyperic/hq/tree/master/hq-plugin" target="_blank">more</a>).<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://a.fsdn.com/con/app/proj/hyperic-hq/screenshots/196982.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://a.fsdn.com/con/app/proj/hyperic-hq/screenshots/196982.jpg" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">A screenshot taken from the SourceForge download page</td></tr>
</tbody></table>
<h4>
Installation and usage</h4>
You must first install the Hyperic Server, typically on a dedicated machine that you will be using for monitoring. Then you must install the Hyperic Agent on every server machine that you want to monitor.<br />
<br />
The Hyperic Agent will automatically discover running database systems and application servers on the machine where it is installed, and it will offer them as observable resources to the Hyperic Server.<br />
<br />
From the Hyperic Server console the administrator can select what to monitor (e.g. Apache Tomcat, MySQL, but also operating system CPU, SWAP, file system, I/O, network etc)<br />
<br />
The agent will then start sampling the requested items and will push the information to the console. which will be able to display historical data, paint graphs, and which can be configured to raise alerts when certain conditions are met (e.g. low disk space, high CPU usage, Tomcat process crashed etc etc).<br />
<br />
<h3>
Tweaking the Virgo installation to pretend it's Tomcat 7</h3>
Even if Virgo was created by SpringSource, Hyperic does not seem to support Virgo OOTB, or at least the open source edition does not seem to support Virgo. <br />
<br />
It however supports Tomcat 7.0 via an agent plug-in called <a href="http://tomcat-plugin.jar/">tomcat-plugin.jar</a>. <br />
A quick look at the plug-in <a href="https://github.com/hyperic/hq/blob/master/hq-plugin/tomcat-plugin" target="_blank">sources</a> reveals the Tomcat 7.0 discovery process:<br />
<ol>
<li>The plug-in uses a Sigar <a href="https://github.com/hyperic/hq/blob/master/hq-plugin/tomcat-plugin/src/main/resources/etc/hq-plugin.xml#L230" target="_blank">query</a> to identify running processes that are potential Tomcat servers. The query just looks for running Java processes that include parameter <span style="font-family: "Courier New",Courier,monospace;">-Dcataliba.base=<some_path></span> in the command line. </li>
<li>The version of Tomcat is determined by checking the existence of some files that are specific to each Tomcat version. For Tomcat 7, the file is <span style="font-family: "Courier New",Courier,monospace;"><catalina.base>/lib/tomcat-api.jar <span style="font-family: Arial,Helvetica,sans-serif;">(see <a href="https://github.com/hyperic/hq/blob/master/hq-plugin/tomcat-plugin/src/main/resources/etc/hq-plugin.xml#L616" target="_blank">here</a>)<span style="font-family: "Courier New",Courier,monospace;">.</span></span></span></li>
<li>Once Tomcat is identified, the agent will connect to the process to collect samples, provided that JMX support is enabled. Luckily enough JMX is enabled per default in Virgo.</li>
</ol>
To have Virgo recognized as Tomcat 7.0:<br />
<ol>
<li>Set JAVA_OPTS to -Dcatalina.base=<VIRGO_INSTALLATION_FOLDER> before starting Virgo: <br /><blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">export JAVA_OPTS=-Dcatalina.base=/home/giamma/virgo</span><span style="font-family: "Courier New",Courier,monospace;"></span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">./startup.sh</span></blockquote>
</li>
<li> Create an empty file named tomcat-api.jar in the Virgo lib folder:<br /><blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">cd /home/giamma/virgo </span></blockquote>
<blockquote class="tr_bq">
<span style="font-family: "Courier New",Courier,monospace;">touch lib/tomcat-plugin.jar</span></blockquote>
</li>
</ol>
Now start Virgo and after few seconds it will show up as a Tomcat 7 server in the Hyperic console.<br />
Note that the Hyperic template for Tomcat 7 will use wrong defaults for log files etc, but you can change them after enrolling the Virgo server in the Hyperic console.<br />
<br />
In case you wonder, the<span style="font-family: "Courier New",Courier,monospace;"> catalina.base</span> system property has no side effect on Virgo, see <a href="https://www.eclipse.org/forums/index.php/mv/msg/796484/1404664/#msg_1404664" target="_blank">here</a>.<br />
<br />
<h3>
Patching the Agent to monitor global data sources</h3>
The current Hyperic Agent plugin for Tomcat is capable of monitoring only data sources that are defined at the Web App level.<br />
<br />
If you are using Tomcat global data sources as we are doing (see <a href="http://devshards.blogspot.com/2012/10/global-jndi-support-in-virgo-server-35.html" target="_blank">here</a> for details), they will not be monitored by Hyperic.<br />
<br />
However, you can easily patch the tomcat-plugin.jar as explained <a href="https://communities.vmware.com/message/1935596#1935596" target="_blank">here</a>. Just remember that after patching the plug-in you must replace it both in the Hyperic Agent and in the Hyperic Server.<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;">./agent-5.8.2/bundles/agent-5.8.2/pdk/plugins/tomcat-plugin.jar</span><br />
<span style="font-family: "Courier New",Courier,monospace;"><br />./server-5.8.2/hq-engine/hq-server/webapps/ROOT/WEB-INF/hq-plugins/tomcat-plugin.jar</span>Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-83168193648424080472013-11-23T15:01:00.002+01:002013-11-23T15:01:47.591+01:00Dependency Injection and Sisu<a href="http://en.wikipedia.org/wiki/Dependency_injection">Dependency injection</a> is certainly one of the most effective design patterns for writing clean, maintainable and testable code.<br />
<br />
For these reasons it's been very popular over the past few years and a number of libraries/frameworks have been created to provide support for dependency injection.
The most well known implementations are probably <a href="http://code.google.com/p/google-guice/" target="_blank">Google Guice</a>, the <a href="http://projects.spring.io/spring-framework/" target="_blank">Spring Framework</a> and the <a href="http://en.wikipedia.org/wiki/OSGi" target="_blank">OSGi</a> <b>Service Registry</b> while <a href="http://square.github.io/dagger/" target="_blank">Dagger</a> is possibly the most
recent yet significant addition to this group.<br />
<br />
A standardization effort in dependency injection began in 2006 which resulted in <a href="http://jcp.org/en/jsr/detail?id=299" target="_blank">JSR 299</a> first and then in <a href="http://jcp.org/en/jsr/detail?id=330" target="_blank">JSR 330</a>, now supported by
Guice and Spring which changed their API to comply with the proposed specification.<br />
<br />
So what is the best choice today for those who want to use dependency injection in their code?
Well, in my humble opinion the answer is.... <a href="http://www.eclipse.org/sisu" target="_blank">Eclipse Sisu</a>!. The <b>Sisu</b> home page describes <b>Sisu</b> as<br />
<blockquote class="tr_bq">
"a modular JSR330-based container that supports classpath scanning, auto-binding, and dynamic auto-wiring.
Sisu uses Google-Guice to perform dependency injection and provide the core JSR330 support, but removes the need to write explicit bindings in Guice modules." </blockquote>
The project is still in incubation phase, and the documentation is not yet complete, but after playing with <b>Sisu</b> for some time, I can state that it is an excellent product,
one of those rare Java libraries that focus on doing just one thing but do that thing exceptionally well.
The code itself is very well written and an interesting reading for every Java developer (apart from the unusual C-like formatting :-)).<br />
<br />
<b>Sisu</b> is the type of middleware component you would normally expect to find at Apache.org, and the fact that its actually hosted at Eclipse foundation
may be yet another indication that <a href="http://www.infoworld.com/d/open-source-software/has-apache-lost-its-way-225267" target="_blank">Apache is no more as succesful as it used to be.</a><br />
<br />
Here are some great features of <b>Sisu</b>:<br />
<ul>
<li><b>Sisu</b> can be used in both a <b>Java SE</b> environment and in an <b>OSGi</b> environment, and dependency injection becomes as simple as annotating relevant classes
and letting <b>Sisu</b> magically discover them via class file scanning, or providing an index file.</li>
<li>No knowledge of Google Guice is required, but
usage of the Google Guice API is supported.</li>
<li>Not only OSGi support is first class, but the author has also set the goal of integrating <b>Sisu</b> with the <b>Equinox Registry</b> and the <b>OSGi Service Registry</b>. Once accomplished this will bring a single, unified programming
model helping portability between JavaSE and OSGi. </li>
</ul>
Download <b>Sisu</b> now and start experimenting with it, chances are you'll be really amazed!
Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-60524497460062792852013-05-30T10:12:00.001+02:002013-05-30T10:12:29.183+02:00Tinybundles, a little gem for OSGi testingIn my OSGi applications I often make use of the <a href="http://blog.osgi.org/2007/02/osgi-extender-model.html" target="_blank">OSGi extender pattern</a>. An excellent example is available on <a href="http://www.toedter.com/blog/?p=236" target="_blank">Kai's Toedter blog</a>.<br />
<br />
As Peter Kriens explained:<br />
<blockquote class="tr_bq">
In the Synchronous Bundle Listener event call back, the subsystem can
look at the resources of the bundle and check if there is anything of
its liking. If it is, it can use this resource to perform the necessary
initialization for the new bundles. <br />
</blockquote>
<br />
Writing unit tests for a <a href="http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/SynchronousBundleListener.html" target="_blank">Synchronous Bundle Listener</a> is often a tricky task. To test the behaviour of your extender you need to install and start (and later stop and uninstall) bundles via the OSGi API.<br />
<br />
The API allows you to install a bundle by passing in an InputStream opened from a bundle file. So, the simplest solution usually consists in packaging a small test bundle as a binary resource in the test case package, and to use the OSGi API from the test case class to install the bundle in the OSGi framework. This approach certainly works but is quite annoying because you need to repackage the test bundle every time you have to make a change.<br />
<br />
Some time ago I found a better solution: the <b>Tinybundles</b> library. The project documentation is <a href="https://ops4j1.jira.com/wiki/display/ops4j/Tinybundles" target="_blank">here</a>, while sources for the library are available on <a href="https://github.com/ops4j/org.ops4j.pax.tinybundles" target="_blank">github</a>.<br />
<br />
Tinybundles provides a convenient API to create an OSGi bundle from resources and classes available in your test case classpath:<br />
<br />
<pre class="brush: java;">
TinyBundle bundle = TinyBundles.bundle()
.add( TestActivator.class )
.add( HelloWorld.class )
.set( Constants.BUNDLE_SYMBOLICNAME, "test.bundle" )
.set( Constants.EXPORT_PACKAGE,
HelloWorld.class.getPackage().getName() )
.set( Constants.IMPORT_PACKAGE,
"org.apache.commons.collections" )
.set( Constants.BUNDLE_ACTIVATOR,
TestActivator.class.getName() );
InputStream is = bundle.build(TinyBundles.withBnd());
Bundle installed = getBundleContext().installBundle("dummyLocation", is);
installed.start();
</pre>
<br />
In this way you can generate bundles on-the-fly within your test case for the purpose of testing your bundle listeners. <br />
<br />
Simple, isn't it?Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-66372473379303236202013-04-27T12:31:00.001+02:002013-04-27T12:33:25.594+02:00Edit keyboard shortcuts in Nautilus 3.6After upgrading to Ubuntu 13.04, I was a bit annoyed by a short-cut change: I have always used a lot <b>BackSpace</b> in Nautilus to go up one folder. Now, in Nautilus 3.6 this has been changed to <b>ALT-UP</b>.<br />
<br />
Luckily enough, even if there is no GUI for this, you can change Nautilus key bindings pretty easily.
To change "go up one folder" from ALT-UP to BackSpace, just edit<br />
<br />
<span style="font-size: large;"><span style="font-family: "Courier New",Courier,monospace;">~/.config/nautilus/accels </span></span><br />
<br />
with your favorite editor (mine is <a href="http://www.geany.org/" target="_blank"><b>geany</b></a>) and add this line at the end:<br />
<br />
<br />
<span style="font-family: "Courier New",Courier,monospace;"><span style="font-size: large;">(gtk_accel_path "<actions>/ShellActions/Up" "BackSpace") </actions></span></span><br />
<span style="font-size: large;"><actions><br /></actions></span>
<actions>Source: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1108637</actions>Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-50662499559855920722012-10-31T09:04:00.000+01:002012-10-31T13:39:18.913+01:00Global JNDI support in Virgo Server 3.5 for Tomcat<div>
<br />
This rather long post analyses four solutions to the problem of using data sources,
and more in general JNDI in Virgo, the 4th being the one I recommend
and decided to use, which consists in leveraging Tomcat's built-in JNDI provider in Eclipse Virgo Server for Apache Tomcat.<br />
<br />
If you are not interested in the reasons why I
dropped the first three, jump directly to the fourth.<br />
<br />
Even if the post is mostly focused on JDBC data sources, once Tomcat JNDI provider is exposed to the application it can be used for any type of resource, not only data sources. <br />
<br />
Most of the credits for this solution go to my colleague Stefano Malimpensa.<br />
<br />
<h2>
<b>1. JDBC </b><b>data sources in OSGi</b> </h2>
The most correct approach to obtain a JDBC data source in a pure OSGi enterprise application consists in using the OSGi JDBC Service (see the official OSGi <a href="http://www.osgi.org/Download/File?url=/download/r4v42/r4.enterprise.pdf" target="_blank">JDBC specification</a>). In Virgo, that means using <a href="http://www.eclipse.org/gemini/dbaccess/" target="_blank">Gemini DBAccess</a>.<br />
<br />
However, in my humble opinion Gemini DBAccess is not an optimal solution for a number of reasons:<br />
<br />
<ol type="1">
</ol>
<ul>
<li> Gemini DBAccess is currently available
only for Derby, and to use a different database you need to write your own implementation. Not a big issue but some extra effort anyway.<br />
</li>
<li> To integrate DBAccess with EclipseLink you should probably use <a href="http://www.eclipse.org/gemini/jpa/" target="_blank">Gemini JPA</a>, which is affected by a bug that prevents connection pooling
from working and is therefore not usable in production <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397">https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397</a><br />
</li>
<li> When using DBAccess with Gemini JPA you need configure
connection parameters in each bundle's persistence.xml. I find this inconvenient because it is necessary to repackage the bundles every time the
connection parameters change, and due to the modular nature of OSGi one complex application may include several bundles with persistence units.<br />
</li>
<li>If DBAccess is used without GeminiJPA, DBAccess will
provide only a data source factory, and it will be the responsibility of your code to
instantiate and configure the data source (e.g. pass in user name, password etc). In such case you would need to support a
configuration file to let system administrators easily change
connnection parameters, which is again extra effort.</li>
<li>DBAccess requires the
OSGi registry, which means it would not work with legacy code or third
party libraries written for J2EE. </li>
</ul>
<ol type="1">
</ol>
As the name implies, Gemini DBAccess is tailored to data base
resources. If you want a single, unified approach for looking up any type
of resource, then it's not a good fit for you.<br />
<br />
<h2>
<b>2. Full JNDI in OSGi</b> </h2>
At this point you may want to try <a href="http://www.eclipse.org/gemini/naming/" target="_blank">Gemini Naming</a>, which implements the OSGi<a href="http://www.osgi.org/Download/File?url=/download/r4v42/r4.enterprise.pdf" target="_blank"> JNDI service specification</a>. Even Gemini Naming is in my humble opinion not an optimal solution:<br />
<ol>
</ol>
<ul>
<li>There is no configuration console, nor a configuration file: the only way you can bind resources in the JNDI namespace is programmatically. This implies a lot of boring initialisation code, and you probably need to support a
configuration file to let system administrators easily change configuration parameters, which is again extra effort. </li>
<li>Gemini Naming requires the
OSGi registry, which means it would not work with legacy code or third
party libraries written for J2EE. </li>
</ul>
<ol>
</ol>
<br />
<h2>
<b>3. Local JNDI declared inside a Web App</b></h2>
<br />
Virgo supports JNDI lookups for data sources inside a Web App. To achieve this you have to:<br />
<ol>
</ol>
<ul>
<li>Include in the Web application the JDBC driver(s) and the pool implementation (e.g. Apache DBCP or Tomcat JDBC) as jars in your WEB-INF/lib folder</li>
<li>Configure web.xml to list the usual JNDI resource-refs</li>
<li>Include a Tomcat context.xml file in the Web App and configure it as explained <a href="http://www.eclipse.org/virgo/documentation/virgo-documentation-3.5.0.RELEASE/docs/virgo-user-guide/htmlsingle/virgo-user-guide.html#configuring-tomcat" target="_blank">here</a> and <a href="http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Resource_Definitions" target="_blank">here </a></li>
</ul>
<ol>
</ol>
The above will work for JDBC data sources but has the following draw backs:<br />
<ul>
<li>You must include the JDBC driver and pool in every Web App of yours. This means that each Web App will have its own pool, even if they connect to the same database, and that you must repackage the WAR if you need to update the JDBC driver</li>
<li>JNDI lookup will work only in a thread originated by a HTTP request. This means that application bundles that are not WARs will not be able to obtain the data source via a JNDI lookup, unless their code is executed by a thread started by the Web container. In fact, the JNDI lookup will fail from threads created by Equinox: this is for example the case of code that observes OSGi framework lifecycle events (BundleListener) and need access the database when a bundle is installed or uninstalled.</li>
</ul>
In my case the main show stopper to this solution is the thread issue described above, because my application must access the database (and therefore the data source) from threads that are not always started by the Web container. If you are interested in the historical roots of this apparently strange limitation, I recommend reading <a href="http://njbartlett.name/2012/10/23/dreaded-thread-context-classloader.html" target="_blank">this post</a> by Neil Bartlett.<br />
<br />
<h2>
<b>4. Tomcat global JNDI registry</b></h2>
<br />
Another option is available, which is not affected by any of the above issues and limitations and it consists in using Tomcat's global JNDI
support. You gain a general purpose well tested and well documented JNDI
registry capable of deploying any type of resource, not only
data-sources (can even be extended to support custom resource types <a href="http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#Adding_Custom_Resource_Factories">http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html#Adding_Custom_Resource_Factories</a>).<br />
<br />
Please note that this solution will make the global JNDI namespace available, disabling the Web App <b>java:comp/env</b> context. In order words, you cannot use the java:comp/env prefix in your JNDI lookups. This should be an acceptable limitation, given that the java:comp/env prefix in any case would work only within a Web App and not from a plain OSGi bundle.<br />
<br />
In order to use the Tomcat JNDI registry for data sources in Virgo the following mandatory steps are required:<br />
<br />
<ol>
<li>Create a bundle fragment for Catalina to extend Virgo's Tomcat with connection pooling support. The Virgo distribution contains in fact a stripped down version of Tomcat that removes the libraries required for JDBC pooling. Luckily enough, you can create a fragment to contribute the libraries back to Catalina. You just need to make sure that your fragments are placed in the bundle repository folder, not in pickup. </li>
<li>Create a bundle fragment for Catalina to make the required JDBC driver(s) available to the server and the application</li>
<li>Create a fragment that gets the JNDI context from Tomcat and that registers in the JVM a global <a href="http://docs.oracle.com/javase/1.4.2/docs/api/javax/naming/spi/InitialContextFactoryBuilder.html" target="_blank">InitialContextFactoryBuilder</a> </li>
<li>Edit tomcat-server.xml and define your global resources</li>
</ol>
<h4>
<span style="font-weight: normal;">All the above fragments are a convenient method for extending Tomcat/Catalina to use third party libraries whose Java packages were not originally imported by the Virgo bundles. For further details refer to <a href="http://underlap.blogspot.it/2011/03/importing-packages-into-3rd-party.html" target="_blank">this post</a> by Glyn Normington, the project lead of Virgo. If you are working with Virgo his personal blog is a must read!</span></h4>
<br/>
<br/>
<h4>
1. The pool bundle fragment</h4>
Here is a sample for Apache DBCP. The MANIFEST.MF below is added to the DBCP JAR, that's why there is no Bundle-Classpath.
Mind the fragment host header.<br />
<br />
<pre class="brush: bash;">Manifest-Version: 1.0
Fragment-Host: com.springsource.org.apache.catalina
Bundle-ManifestVersion: 2
Bundle-Name: Tomcat DBCP
Bundle-SymbolicName: org.apache.tomcat.dbcp
Bundle-Version: 7.0.27
Bundle-Vendor: apache
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: javax.management,
javax.management.openmbean,
javax.naming,
javax.sql,
org.apache.juli.logging
</pre>
<br />
<br/>
<h4>
2. The JDBC driver bundle fragment</h4>
Here is a sample for PostgreSQL. The MANIFEST.MF below is added to the PostgreSQL driver JAR, that's why there is no Bundle-Classpath.
Mind the fragment host header.<br />
<br />
<pre class="brush: bash;">Manifest-Version: 1.0
Fragment-Host: com.springsource.org.apache.catalina
Bundle-ManifestVersion: 2
Bundle-Name: PostgreSQL JDBC Driver
Bundle-SymbolicName: org.postgresql.jdbc.catalina
Bundle-Version: 9.2.1000
Bundle-Vendor: postgresql
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
</pre>
<br />
<br/>
<h4>
3. JNDI bridge fragment</h4>
Create a fragment with the following MANIFEST.MF that includes the two classes below and place it in the repository folder.<br />
<br />
<pre class="brush: bash;">Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: JNDITomcatBridge
Bundle-SymbolicName: jndi.tomcat.bridge
Bundle-Version: 1.0.0.qualifier
Bundle-Vendor: org.example
Fragment-Host: com.springsource.org.apache.catalina;bundle-version="7.0.26"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Import-Package: org.apache.catalina.mbeans;version="7.0.26"
</pre>
<br />
The code below consists of two classes.<br />
<br />
The first, GlobalJNDILifecycleListener, is a GlobalResourcesLifecycleListener subclass that downcasts the server instance to get the global JNDI context and that registers in the JVM NamingManager a custom InitialContextFactoryBuilder which wraps the JNDI context obtained from Tomcat.<br />
<br />
Other options are of course possible, including doing everything in the custom implementation of InitialContextFactoryBuilder without subclassing the listener, but whatever approach you adopt, it is important to make sure that the invocation to NamingManager.setInitialContextFactoryBuilder occurs only once in the life of a Virgo server instance, because the method will fail and raise a runtime exception if it is called more than once. <br />
<br />
<br />
<pre class="brush: java;">import javax.naming.Binding;
import javax.naming.Context;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
import javax.naming.spi.NamingManager;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.Server;
import org.apache.catalina.mbeans.GlobalResourcesLifecycleListener;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
public class GlobalJNDILifecycleListener extends GlobalResourcesLifecycleListener {
private static final Log log = LogFactory.getLog(GlobalJNDILifecycleListener.class);
@Override
public void lifecycleEvent(LifecycleEvent event) {
super.lifecycleEvent(event);
if (Lifecycle.START_EVENT.equals(event.getType())) {
Server server = (Server) event.getLifecycle();
Context ctx = server.getGlobalNamingContext();
ContextFactory factory = new ContextFactory(ctx);
try {
NamingManager.setInitialContextFactoryBuilder(factory);
log.info("Published Global Naming as default InitialContext");
logJNDIEntries(ctx, null);
} catch (NamingException e) {
log.error("Naming Exception:", e);
}
}
}
private void logJNDIEntries(Context context, String prefix) throws NamingException {
NamingEnumeration<Binding> namingEnumeration = context.listBindings("");
while (namingEnumeration.hasMoreElements()) {
Binding binding = namingEnumeration.next();
String nameEntry = binding.getName();
String fullName = (prefix == null || prefix.equals("") ? nameEntry : prefix + "/" + nameEntry);
String entryClassName = binding.getClassName();
if (Context.class.getName().equals(entryClassName)) {
Context ctx = (Context) binding.getObject();
logJNDIEntries(ctx, fullName);
} else {
log.info("Found: " + fullName);
}
}
}
}</pre>
<pre class="brush: java;">import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.naming.spi.InitialContextFactory;
import javax.naming.spi.InitialContextFactoryBuilder;
/**
* Simple implementation of {@link InitialContextFactory} that returns the global {@link InitialContext}
* obtained from Tomcat
*
* @author giamma, stefano
*
*/
public class ContextFactory implements InitialContextFactoryBuilder, InitialContextFactory {
private Context context;
public ContextFactory(Context context) {
this.context = context;
}
@Override
public InitialContextFactory createInitialContextFactory(Hashtable environment) throws NamingException {
return this;
}
@Override
public Context getInitialContext(Hashtable environment) throws NamingException {
return context;
}
}
</pre>
<br/>
<h4>
4. tomcat-server.xml</h4>
<h4>
</h4>
Replace the listener with yours and declare your JNDI resources:
<br />
<pre class="brush: xml;">
<-- Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> -->
<Listener className="com.example.catalina.mbeans.GlobalJNDILifecycleListener"/>
</pre>
<pre class="brush: xml;">
<GlobalNamingResources>
<Resource name="jdbc/db"
type="javax.sql.DataSource" username="user"
password="password"
factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"
driverClassName="org.postgresql.Driver"
url="jdbc:postgresql://127.0.0.1/db"
maxActive="20" maxIdle="10"/>
</GlobalNamingResources>
</pre>
<br />
You can now happily perform plain old new InitialContext().lookup() from every method of every class of your OSGi application deployed in Virgo, regardless of the origin of the thread.
</div>
Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com2tag:blogger.com,1999:blog-7876506089821014047.post-81334703159956735072012-10-02T10:01:00.000+02:002012-10-02T10:09:25.949+02:00Developing for Virgo server with Eclipse PDELast week I pushed to github an Eclipse plug-in released under the <a href="http://www.eclipse.org/legal/epl-v10.html" target="_blank">EPL</a> license that allows using <a href="http://www.eclipse.org/pde/" target="_blank">PDE</a> plug-in projects with <a href="http://wiki.eclipse.org/Virgo/Tooling" target="_blank">Virgo Tools</a>. Source code, binaries and documentation are available here: <a href="http://github.com/giamma/pde2virgo">http://github.com/giamma/pde2virgo</a><br /> <br />The plug-in is pretty simple: it contributes a new builder to a PDE plug-in project and the builder takes care of copying the content of the <b>META-INF</b> folder, as well as any <b>library</b> referred by the <b>Bundle-ClassPath</b> header, to the project binary folder, where Virgo Tools expect those resources to be located. <br /> <br />To develop for Virgo using PDE you also have to properly configure the PDE <b>target</b> <b>platform</b> so that your plug-ins compile against the Virgo bundle repository. Plus, you must add the <b>OSGi Bundle Nature</b> to your PDE Plug-in projects, otherwise Virgo Tools won't let you deploy them to the server instance. More details are available in the github project wiki <a href="https://github.com/giamma/pde2virgo/wiki">https://github.com/giamma/pde2virgo/wiki</a><br /> <br />I originally developed the plug-in in my spare time when looking for a solution that would allow me to develop OSGi bundles for Virgo Server using PDE plug-in projects rather than Virgo Tools' OSGi bundle projects. The plug-in is still affected by a couple of minor issues, but it works well and has been used by about ten colleagues of mine in the last three months. I decided to release it to the public because of this discussion <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198">https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198</a> and because Eclipse gave me a lot in the last 8 years, so it was my turn to give back a little.<br />
<br />
After some months developing with Eclipse Virgo Server for Apache Tomcat I can state that I am really glad I chose it as the target application server: it is a high-quality, lightweight OSGi enterprise app server capable of blending traditional Web Applications with OSGi applications, that provides great diagnostic features, meaningful error messages and that can significantly reduce your development time thanks to a fast start-up time and the ability to hot-swap OSGi bundles. Its Eclipse integration, Virgo Tools, still needs some work, though. <br /> <br />Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-8564117387055115872012-10-01T23:03:00.001+02:002012-10-01T23:03:48.692+02:00EclipseLink and extensible entitites[Originally shared on G+ the 14th of August 2012] <br />
<br />
If you are interested in EclipseLink support for extensible entities,
besides the official documentation you may want to have a look at this
forum thread:<br />
<a class="ot-anchor" href="http://www.eclipse.org/forums/index.php/mv/msg/357791/880331/#msg_880331">http://www.eclipse.org/forums/index.php/mv/msg/357791/880331/#msg_880331</a><br />
<br />
The last post is under my name but credits go to <span class="proflinkWrapper"><span class="proflinkPrefix">my colleague </span><a class="proflink" href="https://plus.google.com/112748004657308528194">Paolo Di Patria</a></span> for writing a working test case.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-12049466216265757092012-10-01T23:01:00.004+02:002012-10-01T23:01:50.306+02:00Eclipse and the Ubuntu global menu[Originally shared on G+ the 7th of August 2012] <br />
<br />
For those working with Eclipse on Ubuntu, if you don't like the fact
that the Eclipse menu does not blend into Unity's global menubar, you
may want to try this hack <a class="ot-anchor" href="https://bugs.launchpad.net/eclipse/+bug/618587/comments/46">https://bugs.launchpad.net/eclipse/+bug/618587/comments/46</a><br /><br />You
may experience some refresh glitches from time to time, but I
personally prefer the menu to be integrated in Unity, especially because
I use shortcuts way more than the menu.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-79563908618411644872012-10-01T22:56:00.003+02:002012-10-01T23:00:19.089+02:00First contact with Virgo Server, Virgo Tools, Eclipse Link[Updated version of a post originally shared on G+ on the 22nd of June 2012]<br />
<br />
My team and I have been working on an OSGi
enterprise prototype since April 2012. We decided to use Eclipse Virgo Tomcat Server as
our application server. Here is the experience collected so far, using
Virgo 3.5M4 and version 1.0.0.201205110321-MILESTONE of the Virgo tools,
both pre-release versions.<br />
<h3>
<b>Documentation and other sources of information</b></h3>
Virgo
comes with a lot of official documentation, and the documentation
quality is generally high. On the other hand, if you look over the Web
for articles, blog posts, forum posts etc you won't find that much
besides the official documentation and the Eclipse community forums.<br />
And
while the quality of Virgo is generally very high, keep in mind that if
you experience an uncommon issue, chances are that you will have to
solve it on your own.<br />
A good knowledge of the OSGi specification is
really required to work with Virgo. Even long time Eclipse plug-in
developers may have troubles developing proper OSGi bundles, because
Eclipse plug-in developers are typically used to requiring bundles
rather than importing packages, and because of the different boot
delegation of Equinox when used in Eclipse, see <a class="ot-anchor" href="http://blog.springsource.org/2009/01/19/exposing-the-boot-classpath-in-osgi/">http://blog.springsource.org/2009/01/19/exposing-the-boot-classpath-in-osgi/</a><br />
<h3>
<b>Error reporting</b></h3>
Virgo
is very good in giving you precise error and diagnostic information if
your OSGi bundles fail to be resolved. The Virgo error messages are much
much better than Equinox's and this is very very valuable.<br />
<h3>
<b>Attention points</b></h3>
Even if Virgo is an OSGi
application server, and even if it is based on Equinox, Virgo does not
support split packages and does not favor required bundles.<br />
I totally
agree that split packages are evil, a very dangerous pitfall of the
OSGi specification. So I was originally pretty happy with this decision,
till I wanted to use the Equinox Registry in my application. In fact, I
found out that the org.eclipse.core.runtime package is split across
multiple bundles, and could not find a way to have the Equinox Registry
bundles work "as is" in Virgo. A user in the Virgo Eclipse forums
advised me to create a Plan (a virgo deployment artefact) that would
include the bundles with the split package, but that did not solve my
issue. I eventually worked around the problem by repackaging the Equinox
registry bundles in a single bundle. Maybe other solutions are
possible, but this was
the fastest solution. The second important attention point is that Virgo
authors dislike the use of <b>Require-Bundle</b> manifest header. I again understand the decision and I agree that one should prefer <b>Import-Package</b>, but what I dislike is that Virgo offers an alternative header attribute <b>Import-Bundle</b>
that is Virgo specific, and does not belong to the OSGi specification.
It is a sort of macro which will make Virgo enhance your bundle headers
at deploy time to make them import all packages of the imported bundle.
While this may appear as a convenient macro, it is Virgo specific and it
will prevent your application from running in other OSGi containers or
OSGi application servers (unless of course you modify the MANIFEST). So I have decided not to use it.<br />
<h3>
<b>IDE Tools</b></h3>
If
you are a long time Eclipse plug-in developer like me you are probably
used to the PDE and love it, and you may expect to be able to develop
bundles for Virgo using PDE.<br />
Unluckily this is not possible, and you
have to use the Virgo Tools, a totally different toolset. You could
develop bundles with PDE, export them as binaries and deploy to Virgo,
and it will of course work, but if you want to be able to build and run
from the workspace your projects cannot be PDE plug-in projects but must
be Virgo Tools' OSGi Bundle projects. The bad thing here is that
developing with Virgo Tools is not as smooth as developing with PDE
tools.<br />
Here are a few examples:<br />
<ol>
<li>Much like PDE, Virgo Tools add a
container to your project build path. The container should automatically
populate the classpath according to bundle dependencies. In practice,
the container is often out of sync resulting in spurious build errors,
and you have to open the MANIFEST, add a blank, save and build to fix
them. Plus, if you don't use autobuild, you'll need to build twice: once
for the container to be updated after you change the MANIFEST and a
second time for the code to be compiled after the container has updated. </li>
<li>If you want to import a package from another bundle in the workspace,
you must enlist the other bundle in your <i>Project References</i>
property page for the container to see it, but the MANIFEST editor will
not help you, you'll need to switch to the source view and manually add
the imported package. </li>
<li>If one of your workspace bundles exports packages
that are included in some embedded JARs and you need another bundle to
use classes from those packages, you'll have again to manually import
the package, but you'll also need to add those JARs to your Java Project
Buildpath, otherwise the dependant bundle will not compile, because the
container will never see the JARs. </li>
</ol>
There are a number of other smaller
issues but the above are the most annoying.<br />
<h3>
<b>Runtime Bugs</b></h3>
We spotted 3 defects, two related to the
EclipseLink - Gemini JPA integration:<br />
<a class="ot-anchor" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=381369">https://bugs.eclipse.org/bugs/show_bug.cgi?id=381369</a><br />
<a class="ot-anchor" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397">https://bugs.eclipse.org/bugs/show_bug.cgi?id=379397</a><br />
<br />
And one in the EcilpseGemini Web component, part of Virgo Server:<br />
<a class="ot-anchor" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=380362">https://bugs.eclipse.org/bugs/show_bug.cgi?id=380362</a><br />
<br />
As usual the Eclipse community has been great in providing support and advice to workaround the issues.<br />
<br />
<h3>
<b>Great Virgo features</b></h3>
<ol>
<li><i>Very good diagnostic tools</i>.
Logs, dumps, detailed wiring information, all those features simplify
problem determination of malfunctioning OSGi applications.<i> </i></li>
<li><i>User regions</i>.
You can deploy bundles in isolated user regions (exported packages and
offered OSGi services will be visible and usable only by bundles in the
same region). You can have the same bundles deployed more than once in
different user regions, because virgo will qualify the bundle symbolic
name with the region name.<i> </i></li>
<li><i>Deployment artifacts galore</i>. You
can deploy to Virgo Tomcat Server bundles, plain WAR files, Plans, PARs,
Web Application Bundles (WAB) and all that flexibility allows you to
deploy OSGi enterprise applications and plain old Web Applications
within the same Virgo instance. Plain WARs can even load classes from
the deployed OSGi bundles.<i> </i></li>
<li><i>Hot swapping</i>. You can easily
remove/add a deployment artefact (e.g. a bundle) from/to the server,
without stopping the server and the application. Of course you need to
make proper use of OSGi ServiceTrackers, the OSGi Extender pattern and
write your application code to deal with such use cases.<i> </i></li>
<li><i>No more issues with 3rd party libraries</i>
When working with traditional J2EE application servers a frequent issue
consists in classloading problems that may originate when your
application and the app server use different versions of the same third
party library. In such cases, depending on the app server of use, you
have different ways of bypassing the problem, but none of them is really
perfect, and in general, I wish I'd never have to deal with such
issues. I am glad OSGi and Virgo free me from those problems.</li>
</ol>
<br />
<h3>
<b>Conclusion</b></h3>
All
in all Eclipse Virgo is an exciting piece of technology. It's a full
featured OSGi and Web container packaged with lots of useful diagnostic
features that enables blending traditional Web Applications with OSGi
(enterprise) applications. True modularity is visible in Virgo itself,
which comes in 3 different flavors (Nano, Kernel, Tomcat Server). I
believe it's a solid product and probably the best option for OSGi
enterprise applications.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-8023018293913169402012-10-01T22:43:00.001+02:002012-10-01T22:43:35.808+02:00How to fix unreadable Eclipse tooltips in Ubuntu 12.04[Originally posted on G+ on May 7th 2012] <br />
<br />
Similarly
to what happened in earlier versions of Ubuntu, the default tooltip
colors of the Ambiance theme (Ubuntu default) results in unreadable
Eclipse tooltips (black foreground text on black background).<br /><br />In
earlier versions of Ubuntu you could edit the Ambiance theme via Gnome
control panel and change the tooltip colors. Unluckily, the new
"Appearance" settings dialog of Ubuntu 12.04 allows you to select the
theme but you cannot tweak its colors anymore. <br /><br />So here is how you can fix the problem.<br />Install gnome-color-chooser:<br />
<blockquote class="tr_bq">
<b>sudo apt-get install gnome-color-chooser</b> </blockquote>
run the tool and switch to the <b>Specific</b> tab. Activate the <b>Tooltip</b>
group and set your tooltip colors (I use black foreground on white
background). Then, at the bottom of the dialog select the value <b>Theme Default</b> for the profile combo and press apply. The next time you start Eclipse it will honour your tooltip colors.<br /><br />For those who may be interested, gnome-color-chooser will change your <b>~/.gtkrc-2.0</b> file.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com5tag:blogger.com,1999:blog-7876506089821014047.post-63505262569874320402012-10-01T22:40:00.001+02:002012-10-01T22:41:07.907+02:00Jericho HTML Parser[Originally posted on G+ on February 6th 2012]<br />
<br />
Yesterday evening I was looking for a HTML parser that would be tolerant
wrt malformed documents. I first looked at Jericho HTML <a class="ot-anchor" href="http://jericho.htmlparser.net/">http://jericho.htmlparser.net</a> (I read about it a while back), and when looking for a comparison between Jericho and CyberNeko HTML Parser <a class="ot-anchor" href="http://sourceforge.net/projects/nekohtml/">http://sourceforge.net/projects/nekohtml/</a> (which is mentioned in the Jericho home page), I stumbled upon JSoup <a class="ot-anchor" href="http://jsoup.org/">http://jsoup.org/</a><br />
<br />
I immediately fell in love with JSoup because:<br />
<br />
<ol>
<li>it's open source under the MIT license</li>
<li>it's DOM oriented and declares to support HTML 5.0</li>
<li>it's a very small library with no dependencies (CyberNeko to the contrary depends on Apache Xerces)</li>
<li>it declares Android compatibility</li>
<li>it offers a decent API for performing HTTP requests (design looks similar to Apache HTTP Client)</li>
<li>it is fully documented and comes with several code examples</li>
</ol>
<br />
I
made a quick test fetching and parsing a couple of HTML documents
resulting from the flow of a dynamic website and everything worked fine.
<br />
<br />
Don't know how it behaves on more complex pages, but the
positive comments I read in Stack Overflow and other sites give me good
hope.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0tag:blogger.com,1999:blog-7876506089821014047.post-78394534272364651252012-10-01T22:31:00.002+02:002012-10-12T23:52:32.756+02:00Sonar and PDE Build[Originally posted on G+ on the 17th of January 2012] <br />
<br />
I finally completed the integration of #Sonar (<a class="ot-anchor" href="http://www.sonarsource.org/">http://www.sonarsource.org</a>) in our PDEBuild (<a class="ot-anchor" href="http://eclipse.org/pde/pde-build/">http://eclipse.org/pde/pde-build/</a>) based build system.<br />
<h4>
<b>Requirements</b></h4>
I was looking for an integration approach that would allow us to run the analysis on our OSGi bundles and to globally define default values for as many configuration parameters as possible (to avoid copy/pasting the same Sonar configuration values in every project build script), but I also wanted to provide project owners with convenient means of tweaking the configuration parameters of their projects and overriding default values when appropriate.<br />
<h4>
<b>PDEBuild customBuildCallbacks.xml</b></h4>
After playing a bit with the many customisation hooks that #PDEBuild offers (see <a class="ot-anchor" href="http://help.eclipse.org/galileo/topic/org.eclipse.pde.doc.user/tasks/pde_customization.htm">http://help.eclipse.org/galileo/topic/org.eclipse.pde.doc.user/tasks/pde_customization.htm</a>) I believe that the best option is to use per project custom build call backs<br />
(<a class="ot-anchor" href="http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_custom_callbacks.htm">http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_custom_callbacks.htm</a>).<br />
These callbacks consist in a Ant script containing a number of predefined targets (a template is included in the #PDEBuild bundle) that, if declared in the project's <i>build.properties</i> file, will be invoked by #PDEBuild during many steps of each bundle's build process.<br />
<h4>
<b>Some implementation details</b></h4>
I want Sonar analysis to take place if and only if the source code compiles successfully, therefore I believe the most appropriate callback is the <i>post.name</i> target (which becomes <i>post.@dot</i> for those bundles that are deployed as JARs and <i>post.<jarname.jar></i> for those bundles that are deployed as folders (in Eclipse the latter usually feature the <i>BundleShape: dir</i> header attribute in their <i>MANIFEST.MF</i> file).<br />
<br />
Being PDEBuild an Ant based build process, my first try consisted in using the Sonar Ant task (<a class="ot-anchor" href="http://docs.codehaus.org/display/SONAR/Analyse+with+Ant+Task">http://docs.codehaus.org/display/SONAR/Analyse+with+Ant+Task</a>) but that failed because such Ant task plays some tricks with the classloader to run Sonar that are not OSGi friendly and does not work within the Eclipse Ant Runner (and therefore within PDEBuild ), even if you package the Sonar Ant task as a bundle that contributes to the Eclipse Ant runner.<br />
<br />
Luckily enough, Sonar provides also a standalone Java application for performing the analysis called SonarRunner (<a class="ot-anchor" href="http://docs.codehaus.org/display/SONAR/Analyse+with+a+simple+Java+Runner">http://docs.codehaus.org/display/SONAR/Analyse+with+a+simple+Java+Runner</a>), which can be successfully executed by PDEBuild . It's basically a shell script that starts a JVM to run the Sonar analyser. SonarRunner requires a global configuration file ($SONAR_RUNNER_HOME/conf/sonar-runner.properties) where you can set database connection parameters, server URL as well as the default source and binary folder (project relative path).<br />
<br />
Given that by convention most of our bundles have a single source folder named <i>src/</i> and that the vast majority of our bundles are deployed as JARs (in which case PDEBuild automatically names the binary folder <i>@dot</i> during compilation), the global file was a very good location for defining good defaults for most projects.<br />
<br />
The remaining mandatory configuration parameters will be set on a per-project basis in the PDE custom build callback, by creating a dedicated properties file in the project root folder for SonarRunner just before executing it, as documented in the SonarRunner page.<br />
<br />
Eventually, my SonarRunner global configuration looked like this:<br />
<br />
<pre class="brush: bash;">
#----- Default Sonar server
sonar.host.url=http://localhost:9000
#----- MySQL
sonar.jdbc.url=jdbc:mysql://localhost:3306/sonar?useUnicode=true&characterEncoding=utf8
sonar.jdbc.driver=com.mysql.jdbc.Driver
#----- Global database settings
sonar.jdbc.username=<user>
sonar.jdbc.password=<password>
#----- Default directory layout
sources=src/
tests=test/
binaries=@dot/
sonar.sourceEncoding=UTF-8
</pre>
<br />
and a project specific callback to perform the analysis looked like this:<br />
<br />
<br />
<pre class="brush: xml;">
<target name="post.@dot">
<antcall target="sonar"/>
</target>
<target name="sonar" if="run.sonar">
<propertyfile file="${plugin.destination}/sonar-project.properties">
<!-- ==== Common properties, should not be changed ====-->
<entry key="sonar.projectKey" value="studio:${bundleId}"/>
<entry key="sonar.projectName" value="${bundleId}"/>
<entry key="sonar.projectVersion"
value="${sonar.projectVersion}"/>
<!-- ==== Project specific properties -->
<!-- <entry key="sources" value="${plugin.destination}/src"/> -->
<!-- <entry key="binaries" value="${plugin.destination}/@dot"/>-->
<!-- == Additional Sonar properties. Add project specific properties here == -->
<!-- <entry key="sonar.exclusions" value="com/mycompany/*/.java,**/*Dummy.java"/> -->
<!-- <entry key="sonar.profile" value="MyProfile"/> -->
</propertyfile>
<exec spawn="false" command="${sonar.runner}" failonerror="true" />
</target>
</pre>
where the property <i>run.sonar</i> is set globally somewhere earlier in the main build script, to make sure that the analysis (which can be very time consuming if you enable a lot of rules) is perfomed only if the build flavour is <i>nightly</i> or when explicitly requested by the build master.<br />
<br />
<b>Final comments</b><br />
Congrats to the Sonar team for writing such a great piece of software! I am really looking forward for the next release which, according to the roadmap <a class="ot-anchor" href="http://www.sonarsource.org/roadmap/">http://www.sonarsource.org/roadmap/</a>, should be out in January 2012 and may provide the ability to use #Sonar as a generic code review tool, as opposed to current version 2.12 which supports code review limited only to the violations reported by Sonar.Giammahttp://www.blogger.com/profile/04703973847802955656noreply@blogger.com0