Blogger vs Everyone Else

So I'm too busy to care anymore about other blogging platforms. I looked at them, they all have some cool features. Given the preponderance of great Essbase and technical blogs on Blogger I was actually inclined to go somewhere else, it's probably my counterproductive instinct to be different. But I like Google, I like their vision, and their relentless investment in science and technology, often just for the sake of science and technology. That's as good a reason as any for me to pick a platform as opposed to "feature x" that can easily be implemented by someone else if they think it important.

And of course the point of a blog is the content, not that mine has anything meaningful to say, but worrying about a particular editing feature is truly the height of technical preoccupation.

JBoss 7 AS and Essbase APS Embedded mode

Wow,

Well 1 year later (or so), here is the solution. Kudos to Iris for finding this out and to Oracle for actually fixing something I cared about. As you might notice from previous notes, upgrading to any JBoss application server after 4 (5-7.2) broke our products ability to to connect to Essbase using an APS server in embedded mode. That's an incredibly esoteric expectation, so if you're here I expect you know what I mean, if you don't, move along it doesn't matter.

The solution ultimately was to use the ojdl.jar library from the Essbase 11.1.2.2 release. No previous release works (AFAIK) but the way the logging library cast failed no longer occurs.

So that's it...get your latest ojdl.jar and you're back in business. We continue to find embedded mode the way to go for intense Essbase communication problems. Having said that, a 64bit instance of APS as available in 11.1.2.0+ should have the same capability as embedded mode when deployed in a modern (6/7) 64bit JDK.

JBoss 7 and Oracle Logging Update

So we finally got our application upgraded to JBoss 7. After beating my head against this OJDL in JBoss 6 error for a while I just put it away hoping that JBoss 7 would fix it. I must say that I really like JBoss 7, almost as much as I hated JBoss 6. It just seems like everything works better and is better documented to boot.

Unfortunately while all the CXF/Spring stuff is working great, and I was even able to use log4j in a custom fashion, I still get this error when attempting to use embedded mode connecting Essbase:

java.lang.ClassCastException: org.jboss.logmanager.Logger cannot be cast to oracle.core.ojdl.logging.ODLLogger

at oracle.core.ojdl.logging.ODLLogger.getODLLogger(ODLLogger.java:102)

at com.hyperion.dsf.server.framework.BaseLogger.(Unknown Source)

...

This guy had a decent writeup on oclj (about the only thing I could fine) but I still have to read it more closely.

And I can't help but think if I understood sflj better it might help as well. I've included it in my war to help clear up some errors but honestly I need few less frameworks trying to help me...

JBoss 6 Classloading and the JAPI

Well I'm about stuck, so I'll write this post to clarify my thoughts and see if anyone stumbles upon this with a good idea.

I have long used Oracle Essbase's JAPI (HAS/EDS/APS) to query and push data and metadata to Essbase. All our code typically runs in JBoss 4.x (other app servers tested as well) however I recently decided to upgrade to JBoss 6. I have finally solved almost everything with a couple of exceptions. I had all the typical spring/hibernate/cxf issues. I felt these links helped the most with those issues.

CXF/Spring/Hibernate in JBoss 6
JAXB Issue

But my last issue is quite obscure because you have to use special jars from Oracle to connect to Essbase. As of Essbase @11.1.x.x their came some new required jars to connect to Essbase when using embedded mode (ojdl.jar and theoretically cpld.jar). Up until the 11.1.2 release we had to use external APS mode due to some bugs in the implementation of saves when run in embedded mode. They were fixed as of 11.1.2 however so we switched to embedded mode for a variety of reasons. It worked in a fairly straight forward way by adding the relevant jars, until I upgraded to JBoss 6.

In JBoss 6 their seems to be a new logging framework being used that extends or wraps log4j. I get an error along the lines of ...

java.lang.ClassCastException: org.jboss.logmanager.Logger cannot be cast to oracle.core.ojdl.logging.ODLLogger

@

at oracle.core.ojdl.logging.ODLLogger.getODLLogger(ODLLogger.java:102)

at com.hyperion.dsf.server.framework.BaseLogger.(Unknown Source)

at com.hyperion.dsf.server.framework.DsfLoggingService.sm_initialize(Unknown Source)

at com.essbase.server.framework.EssOrbPluginDirect.setupLoggingService(Unknown Source)

at com.essbase.server.framework.EssServerFramework.(Unknown Source)

Why this happens in embedded mode and not external mode is a mystery to me.

To see it in JBoss 6 and not 4 says classloading, but any attempts at isolating the app via jboss-classloading.xml only produces a different exception in the same spot.

java.lang.NullPointerException

@

at com.essbase.api.session.EssbaseProperties.(Unknown Source)

at com.essbase.api.session.EssbaseProperties.getInstance(Unknown Source)

at com.essbase.api.session.Essbase.(Unknown Source)

at com.essbase.api.session.IEssbase$Home.create(Unknown Source)

I've stuck the Essbase jars in every directory you can imagine (/lib /lib/endorsed, /common/lib/endorsed, /profile/lib / profile/lib/endorsed)

I think it might come down to an essbase.properties file, a logging.xml file or the existence of a /data/domain.db file, all of wich are available in external mode on the APS server but not in embedded mode, but again why was none of that required in JBoss 4 vs 6

So that's where I'm at, I'm publishing this in the interest of hearing any ideas. I will solve it at which point I'll edit this post to reflect the right answer.

Well it's worth mentioning that the Pace Planning product was purchased by Alvarez & Marsal to extend their expertise and leadership in the retail space.
All Pace customers should be extremely excited given the depth of talent and credibility of A&M, and personally I'm looking forward to a period of significant enhancement of the current product suite.