The method server has a unique class loader arrangement because it has it’s own load directory (java_methods) and also allows for methods to be written and deployed as BOF modules. The following diagram illustrates the method server class loader configuration.
Categories
-
Top Posts
Blogroll
DISCLAIMER
The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at my discretion.
Blog at WordPress.com. Theme: Cutline by Chris Pearson.
2 responses so far ↓
Rob // December 23, 2008 at 2:22 am
I have a problem with this classloader mechanism and BOF, maybe you can give me a suggestion. I would like to leverage the BOF in my servermethods. I use a ITestType interface (for the test_type object type) in my servermethod, and the implementation of that interface is done in BOF.
When executing a session.getObject and casting it to the interface, I get an error:
TestTypeImpl___PROXY incompatible with ITestType.
Any hints?
btw. I can pronounce Scheveningen perfectly
donr7n // January 30, 2009 at 3:53 pm
Rob, sorry for the delay. I missed your comment going through moderation and only just stumbled across it.
This is basically a design flaw. You’ve probably figured that out already from the class loader diagram, but I can confirm it. You can’t use an orthogonal (ie. non DFC) interface of a BOF module from a server method loaded from the java_methods directory unless you put the interface in the method server startup classloader (a bad idea – don’t do that).
The “solution” is to re-implement the consuming method as a BOF module as described in another blog post here.
btw. I can’t, try as I might