Stephen Nimmo

28Aug/080

Hibernate Classpath and Weblogic

Wasted 8 hours on this...

WARNING: Note that "classpath*:" will only work reliably with at least one root directory before the pattern starts, unless the actual target files reside in the file system. This means that a pattern like "classpath*:*.xml" will not retrieve files from the root of jar files but rather only from the root of expanded directories. This originates from a limitation in the JDK's ClassLoader.getResources method which only returns file system locations for a passed-in empty String (indicating potential roots to search).

http://www.jdocs.com/spring/2.0.RC1/org/springframework/core/io/support/PathMatchingResourcePatternResolver.html

So if you have mapping files in the root of a project, the classloader will not find them using the classpath*:*.hbm.xml

You need to put them in a folder then set the mappingLocations of your LocalSessionFactoryBean to:

classpath*:/hibernate/*.hbm.xml

Filed under: Code No Comments
21Aug/080

JAMon and Spring

So it took me a little while but I finally figured out...Seems like JAMon tends to be designed for web applications with little documentation on how to use it on standalone applications, especially ones that run asynchronously based on external events.

So let's talk about how to get a pretty HTML report for a standalone java app. Here's the Unit Test.

ApplicationContext applicationContext = new ClassPathXmlApplicationContext("classpath:testApplicationContext.xml");
FixOrderRoutingGateway service = (FixOrderRoutingGateway) applicationContext.getBean("iceFixOrderRoutingGateway");
service.synchronizeMarkets();
String test = MonitorFactory.getReport();
FileWriter fileWriter = new FileWriter("C:/jamon.html");
BufferedWriter buffWriter = new BufferedWriter(fileWriter);
buffWriter.write(test);
buffWriter.flush();
buffWriter.close();

Setting a breakpoint on the....

String test = MonitorFactory.getReport();

allows the service to start up and begin digesting events. Because it's run in the same JVM, the monitor factory will "magically handle" the monitoring as long as you have the monitor pointed to the right places. So now let's talk about how to monitor your interfaces. Simple AOP. Now let's look how I attached it to the unit test without being intrusive to my existing codebase (this is also a way to monitor in production when code changes are a big no-no.

<import resource="classpath:applicationContext.xml"/>

<bean id="jamonPerformanceMonitorInterceptor" class="org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor" >
	<property name="trackAllInvocations" value="true"></property>
</bean>

<bean id="autoProxyCreator" class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
	<property name="interceptorNames">
		<list>
			<idref bean="jamonPerformanceMonitorInterceptor"/>
		</list>
	</property>
	<property name="beanNames">
		<list>
			<value>iceFixOrderRoutingMessageConsumer</value>
			<value>marketManager</value>
			<value>marketDAO</value>
		</list>
	</property>
</bean>

As you can see, I first import my existing applicationContext, rather than updating it to include this stuff. This allows me to run tests and change the targets without messing with the actual runtime code.  I then create the JamonPerformanceMonitorInterceptor from the Spring package and attach it to my interfaces using the ever versitile BeanNameAutoProxyCreator.

Once the service has been running for as long as you want and you feel you have enough reps for a good sample size (remember your unit test is suspended on the breakpoint),  simply release the breakpoint and go look at your pretty html report.

18Aug/080

Weblogic 9.2 and Eclipse Ganymede

Finally found the solution.

http://www.oracle.com/technology/software/products/oepe/index.html