| Library Plugins and Classloaders [message #274566] |
Mon, 25 October 2004 12:36 |
 Marcus Olk
Messages: 130
Registered: July 2009 |
Senior Member |
|
|
Hi folks.
While I was implementing a type safe NLS solution I encountered
the following problem:
I compiled a tools library containing some simple NLS framework
classes to be extended by concrete NLS classes providing the
key/value mappings. The goal: minimum effort to define a resource
bundle class by extending an abstract resource bundle class that
does the standard bundle lookup etc.
So I found out that I do run into a problem like this
plugin 1 (the 'tools plugin'):
class abstract MyAbstractClass
{
MyAbstractClass loadMe(String className)
{
// uses Reflection to load the class 'className'
// => in the concrete case: delegation to
// ResourceBundle.getBundle() which internally
// uses its classloader(s) to find the bundle for
// the default locale....
...
}
}
plugin 2 ('tools using plugin'):
class MyClass extends MyAbstractClass
{
public static MyClass doLoad()
{
return (MyClass) loadMe("MyClass");
}
}
Due to the fact that each plugin has its own classloader,
MyAbstractClass#loadMe is not able to load MyClass, right?
So: what's the solution to this common problem:
How can I write a common library plugin that offers extendable
base classes to be extended by a class defined a different plugin?
I hope that I don't have to use the extension point machanism with
its overhead which killed my idea of a type safe resource bundle:
I'd have to define my extension point describing how to extend my
'resource bundle extension point'. That should by fairly simple.
But: I'd have to define every single extension of this 'NLS extension point'
in each plugin.xml that provides translated text! That's way to
complicated and no one will use this NLS framework.
Any ideas?
Thanks,
Marcus
|
|
|
Powered by
FUDForum. Page generated in 0.02715 seconds
] 
Search
Help
Register
Login
Home
