I wrote only 2 posts on this wonderful blog, and I'm already upset by the dumb formating options.
I thought : and if I was able to copy/paste the nice formatted code of an eclipse editor directly in the blog post, without having any edition to do about format itself... ?

Yeah...

Just made it

Look at my beautiful previous posts with gorgeous syntax highlight ! What a dream !! Rendered with my own tool !
You want to do it all the same ?
Come on, just check this code in, and with slight adaptations to match your blog engine it could work nice...

Analysis.java (ahh, of course the code itself is a perfect piece of crap)

Small howto :

* be sure to use Java 6 !!!
* download & compile the code
* run it as a main class
* copy some code from an arbitrary eclipse editor (java, xml, whatever...)
* paste it in the big window
* click the export button
* copy all the ugly code produced
* paste it to your naughty blog

It takes in account bold, italic, and colors. So feel free to configure eclipse with funny styles to use it as well ! (I'm pretty proud about my pink strings, in fact...)

Enjoy

Do you like Spring and Hibernate ? Personally, I do... but today I faced a strange issue... I tried to make the two incriminated guys auto generate a diff script for my DB schema...

To make it short, I wrote this kind of code :

        ApplicationContext context = new ClassPathXmlApplicationContext("conf/data-repository-conf.xml");
        LocalSessionFactoryBean lsfb = (LocalSessionFactoryBean) context.getBean("&mySessionFactory");
        SchemaUpdate update = new SchemaUpdate(lsfb.getConfiguration());
        update.execute(true, false);

And the associated conf/data-repository-conf.xml :

  <bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"
  	p:validationQuery="SELECT COUNT(*) FROM DUAL"
    p:driverClassName="com.mysql.jdbc.Driver"
    p:url="jdbc:mysql://host/schema"
    p:username="***"
    p:password="***"/>

  <bean id="mySessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"
    p:dataSource-ref="myDataSource">
    <property name="mappingResources">
      <list>
        <value>mappings.hbm.xml</value>
      </list>
    </property>
    <property name="hibernateProperties">
      <value>
        hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect
      </value>
    </property>
  </bean>

Little explanation here :
* first it creates the AppContext
* then it lookup for the LocalSessionFactoryBean (not the resulting SessionFactory, but its creator, the original Spring FactoryBean) : for that I use the special char "&" at the beginning of the bean's name
* the LocalSessionFactoryBean is needed to retrieve the underlying Configuration for Hibernate, and it creates with it a SchemaUpdate object
* finally, it runs the update stuff..

This is yet at a nice level of pornography, because of course an equivalent of such a code could be integrated in the bean declaration.
But it doesn't deserve my purpose for some reason... whatever, let's go further !
Here is the result at runtime:

org.hibernate.HibernateException: No local DataSource found for configuration - 'dataSource' property must be set on LocalSessionFactoryBean
	at org.springframework.orm.hibernate3.LocalDataSourceConnectionProvider.configure(LocalDataSourceConnectionProvider.java:50)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:124)
	at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:56)
	at org.hibernate.tool.hbm2ddl.ManagedProviderConnectionHelper.prepare(ManagedProviderConnectionHelper.java:27)
	at org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:127)

Hmmm... I googled this insane stack and found this is an old Spring issue :
http://jira.springframework.org/browse/SPR-1547
I'm using Spring 2.5.1 so I shouldn't have the problem... ?? The fact is : I have the problem...

After a small investigation, I discovered that the datasource is passed to the Update stuff via a strange ThreadLocal trick, but this trick failed here for some unobvious reasons... To waste no time, and as long as this small program is a one-shot test stuff, I decided to solve the problem with the ugly code following.
First we have a look inside the problematic class code to see how to fix that :

public class LocalSessionFactoryBean extends AbstractSessionFactoryBean implements BeanClassLoaderAware {

	private static final ThreadLocal configTimeDataSourceHolder = new ThreadLocal();

And now the fixed code itself - enjoy it:

        ApplicationContext context = new ClassPathXmlApplicationContext("conf/data-repository-conf.xml");
        LocalSessionFactoryBean lsfb = (LocalSessionFactoryBean) context.getBean("&mySessionFactory");
        SchemaUpdate update = new SchemaUpdate(lsfb.getConfiguration());
        try {
            Field declaredField = LocalSessionFactoryBean.class.getDeclaredField("configTimeDataSourceHolder");
            declaredField.setAccessible(true);
            ThreadLocal<DataSource> tl = (ThreadLocal<DataSource>)(declaredField.get(null));
            tl.set((DataSource)context.getBean("myDataSource"));
        } catch (Throwable e) {
            e.printStackTrace();
        }
        update.execute(true, false);

Huh, believe me or not, it simply works now

Small explanation:
* get the declared (static) field of the ThreadLocal
* make it accessible
* get its content (null arg for static access)
* put the DataSource in it
* here we go !!!

The main purpose of the following code is to grab the directory of the package of a classpath resource and use it to create a new file. It is used in our unit tests where we assume that classpath resources are in real directories. It's of course pornographic...

File file = new File(new File(getClass().getResource("noel.jpg").getPath()).getParentFile(), info.getFileName());

file.createNewFile();

I didn't remember where I found this, but I'd like to thank a lot the person who had invented it...
I'd never had figured such a thing by myself, or maybe after long and desperate nights of headache, as a last chance...
But the fact is : it works ! And it works fine !

The idea is to insert new URLs in the system classloader, to allow some JARs to be part of it after startup... for me, it's was a manner to expose a kind of pluggable component feature : you just drop a JAR in a specific directory, and without modifying a single line of startup script or whatever, your jar comes to life automaticaly in the app.

And now the beast, using a bit of reflective API, reaaaaally messy :

    private static final Class[] parameters = new Class[]{URL.class};
    
    public static void addURL(URL u) throws IOException {
        URLClassLoader sysloader = (URLClassLoader)ClassLoader.getSystemClassLoader();
        Class sysclass = URLClassLoader.class;
     
        try {
            Method method = sysclass.getDeclaredMethod("addURL",parameters);
            method.setAccessible(true);
            method.invoke(sysloader,new Object[]{ u });
        } catch (Throwable t) {
            t.printStackTrace();
            throw new IOException("Error, could not add URL to system classloader");
        }
    }

Welcome to JavaPorn, a blog dedicated to horrible java code

Here is the first piece of code ; it is used in a project to circumvent a parsing issue that throws OutOfMemoryError. Yes OutOfMemoryError !! (see SANSELAN-3 on ASF Jira)

try {

    IImageMetadata metadata = Sanselan.getMetadata(new File(sourcePath));

    // process stuff here 

} catch (OutOfMemoryError oome) {

    // do nothing here. see https://issues.apache.org/jira/browse/SANSELAN-3 for an explanation

    log.warn("Please resolve cleanly ASF SANSELAN-3, catching an OOME is so crappy");

}