map((lambda idea:blog),me)

As from version 4.2.0, JBoss ships with Apache Tomcat 6, which is supposed to be Bug-43079-free. However, a fresh install & run of Jboss 4.2.3 (with a little tweak of log4j settings) still shows the bogus log :

After decompiling the SecurityCollection.class file within jbossweb.jar under $JBOSS_HOME\server\bpm\deploy\jboss-web.deployer, I noticed that the bug stil there

if(pattern.endsWith("*") && pattern.charAt(pattern.length() - 1) != '/' && log.isDebugEnabled())

Not having mauch time to fix, recompile and repackage, here ’s a little workaround using particular log4j setting to send this log to a “/dev/null”-like planet:

<appender name="NULL" class="org.apache.log4j.varia.NullAppender" />
<logger name="org.apache.catalina.deploy.SecurityCollection" additivity="false">
<appender-ref ref="NULL" />
</logger>

Of course, we loose no extra logs information from SecurityCollection class as it only has one (and undesired) logging statement.

Syntaxhighlighter is a powerful Wordpress plugin, based on the the google-hosted highlighter project, and it’s what I’ve chose for posted code snippets. However, there still an issue not yet solved: the generated markup is not XHTML valid. Surely, this could be insignificant for some users, but a plugin for a bloging system whose motto is “Code is Poetry”, shall, in my opinion, never break this rule. This issue seems not to be under consideration by the plugin developers, and that’s why I’ve quickly made this Hack on the plugin code to make it XHTML compliant. The W3C validator is complaining as follows: there is no attribute “name”. So one most possible solution is to used the (highly recommended) “id” attribute, and as the “id” attribute value shall be unique along the DOM, a special pattern of the value could be defined by the server-side, allowing the client side javascript code to find the target element to highlight. In a nutshell :

In syntaxhighlighter.php, change line 297 :

$content = str_replace( $match[0], '<pre name="code" class="'

to

$content = str_replace( $match[0], '<pre id="code__'.rand() . '" class="'

In shCore.js, add the following prototype at the beginning of the script:

String.prototype.startsWith = function(str)
{return (this.match("^"+str)==str)}

and change line 146

if(tags[i].getAttribute('name')==name)

to

if( ((x = tags[i].getAttribute('id'))!=null) && (x.startsWith(name + '__')))

Basically, instead of looking for elements with name = “code”, it will look for elements whith id attribute starting with “code__”. That’s it. It’s working and XHTML compliant above all!

PS : The probability that few consecutive calls to PHP rand() function give 2 equal values is really infinitesimal and this guarantee to never get two id with the same value.

I’ve finished writing my online cuuriculum vitae, and as I’ve used maven to build the site (building for instance is just parsing my plain APT text file), I didn’t find a suitable skin for it among those publicly available. So I made my own skin consisting of small tuning of the well known stylus maven skin. It can be downloaded from here, and one unzipped somewhere, it can be installed by issuing the command:

Once the skin installed, it can be used in a site  descriptor (site.xml) like this:

<skin>
<groupId>net.labidi</groupId>
<artifactId>net.labidi.skin</artifactId>
<version>1.0.0-SNAPSHOT</version>
</skin>

Update:

The archetype is updated and available from this dedicated site.

Working with Jboss JBPM in conjunction with maven could be made simpler and easier when using this little useful maven archetype to generate starting-block jbpm projects. I built this artifact on top of the skeleton project generate under Eclipse by the Jboss JBPM Eclipse plugin, but with much more enhancement.

Features

• Junit tests are upgraded to junit 4, and use the hamcrest assertions
• All required configuration files are included and default DataBase is MySQL 5
• There are 2 junit tests : one for testing the process from a local process definition XML, and one for making the same test but loading the process from a Database (this means the process should be deployed in prior)
• Maven dependencies are included, even a C3PO pool connection manager
• No more “default” package. The desired package name for java classes could be chosen when generating the project and the filtering mechanism will applied to java classes packages declarations as well as “class” attribute for Action elements in the process definition.
• It works smoothely with JBPM 3.2.3 (latest stable release) and integrates seamlessly with M2Eclipse maven plugin under Eclipse Ganymede.
• Generated projects are targeting jdk 1.5

prerequisites

• Maven 2.0.9
• Jboss JBPM 3.2.3 Eclipse plugin
• M2Eclipse maven plugin for Eclipse (Optional)

Download

The archetype can be downloaded from here.

Installation

The installation is a straight-forward one line maven command

Usage

The archetype can be used either naturally from the command line, and it goes like this:

or it can be used from M2Eclipse plugin, which is the way I prfer to use (How many people are out there coding JBPM process from outsides IDEs ?)

Creating from local archetype catalog with M2Eclipse

choosing project coordinates. Package name is auto-filled

Generated JBPM Maven project under eclipse

Maven Dependencies under M2Eclipse

Exept Junit, all other dependencies are provided-scoped. This because JBPM project are basically aimed to be deployed under an application server whose container provides almost of theses packages (except jbpm-jpdl, jbpm-identity and c3po, they need to be deloyed once for all into the aplication server)

Here is a simple practical solution for highlighting source code served from an Apache web server. The motivation behind this was when I wondered how to allow syntax highlight for my SVN hosted source code when viwed with a browser. I came across a very useful tool written in python, pygmentize. Once this python module downloaded and installed, the following settings should be put in Apache httpd.conf file:

Action highlight /cgi-bin/highlight.py
AddHandler highlight .java

the highlight.py is a python script using pygmentise, and here’s the simplicity :

#!/bin/python
import cgi
import cgitb; cgitb.enable()
import os
from pygments import highlight
from pygments.lexers import JavaLexer
from pygments.formatters import HtmlFormatter

def main():
   print "Content-type: text/html\n"
   print highlight(open(os.environ['PATH_TRANSLATED']).read(), JavaLexer(), HtmlFormatter(full=True))

main()

Obviously, this will hilight java or whatever source code, but will not touch files served via WebDAV/SVN (Hopefully!)

That’s the big issue I was facing this morning when starting the MySQL service version 5.0.67/Win32. The first step I took is to simply look for a google-looked-up page that deals with this issue, and it was the mysql forums. However, I found the diffrent exposed solutions a lot radical as almost of them tend to a backup-delete-reinstall strategy, and it does not really suit my needs. So the first thing I’ve done is to try starting the mysql service in the console  debug mode :

and the output was very explicit about the possible roots of the innoDB issue :

So basically, the MySQL service is complaining about a mismatch between the effective innoDB log file size on the disk (24MB), and the defined size (10MB) within the my.ini file. So changing the my.ini property would help solving the issue :

A little attenion should be paid to another property in my.ini file which is innodb_buffer_pool_size as its value is impacted by the innodb_log_file_size setting. After this simple setting, the service was correctly started. No data/log backup, deletion required, nor service reinstallation. Nevertheless, I still not understand the real issue behind this file size mismatch…

One of the greatest featurse with nowodays SVC systems, in particular Subversion, is its accessibility through a banch of network protocols, as HTTP, when SVN is coupled with Apache web server. When making my own install on my lapotop, and as I’m very sensitive to keep each peace of software in it’s own containing folder, I came to these points :

- It was impossible for me to avoid copying required SVN dlls to Apache bin folder. That’s the most annoying part of the installation especially when the 2 official tutorials are not really explicit. In fact, including the bin directory of SVN installation into the PATH system variable is not working. And copying only intl3_svn.dll and libdb44.dll is not working eather. I finally come across the solution consisting of copying intl3_svn.dll as well as all the lib*.dll to the Apache/bin folder, without overrwiting the existing ones. It’s about 12 dll files.
- The SVN official documentation states that the stylesheet files (necessary if we want to visualize a well-presented web page when accessing to the repository URL) shall be put in the DocumentRoot of the Apache server. That’s also an annoying point for me as I always want to avoid putting any extra document or file in the standard Apache installation. This time, I found a little hack to avoid this, without even playing with VirtualHosts configuration. The main part to add to httpd.conf is the following :

<Location /svn>
DAV svn
SVNListParentPath on
SVNParentPath D:\svnrepo
SVNIndexXSLT /svnindex.xsl
AuthType Basic
AuthName "Subversion repositories"
AuthUserFile "auth/__users.txt"
Require valid-user
</Location>

wich makes the SVN repository accessible at http://localhost/svn. Now we want the SVN stylesheets material to be placed outside the Apache DocumentRoot, for example in the folder D:/www/svn-web-content/, we have just to add the following configuration to httpd.conf :

Alias /svn-web "D:/www/svn-web-content/"
<Directory "D:/www/svn-web-content/">
AllowOverride None
Order Deny,Allow
Allow from all
</Directory>

And then change the directive SVNIndexXSLT to point at /svn-web/svnindex.xsl instead of /svnindex.xsl. Now if we open the page http://localhost/svn, we unfortunately see the same unformatted basic page. However, after looking to the Apache acess log file, we can understand the trick :

“GET /svn-web/svnindex.xsl HTTP/1.1″ 200 3558
“GET /svnindex.css HTTP/1.1″ 404 1950
“GET /menucheckout.ico HTTP/1.1″ 404 1950

So XSL file is correctly found and sent by the server, but not the CSS/ICO file. The solution is really simple by editing the XSL file and replacing each occurrence of href=”/svnindex.css with href=”/svn-web/svnindex.css, and the same for the file menucheckout.ico. It’s up and running.

After donwloading and installing wordpress version 2.6.1, and as soon as I went through its consol, it told me that version 2.6.2 is already available for upgrade. I didn’t wait to grab it and upgrade. However, I found it funny to see that the readme file in the 2.6.2 archive still mentionning version 2.6.1. Anyway, wordpress is a great peace of software, with a greate ease-of-use (surely, after one knows how to correctly set the “uploads” folder path and rights). And by the way, Hello Wolrd !