I'm no expert on class loaders so I'm not be able to offer any advice there.
However this is obviously a problem for you so I could look at a
workaround for this.
It seems that you can call the constructors of your own Figs but
creating by reflection has problems.
So what I can do is provide an API in GEF where an application can
register a factory object to create diagrams. If this factory fails to
create a diagram then GEF will revert to its current method of
creating by reflection. So standard ArgoUML will not be effected by
this change, it is only your module that would create this factory and
register it.
Your factory would be something like -
public class MACMASDiagramFactory extends DiagramFactory {
public Diagram createDiagram(HashMap properties) {
if
("org.argouml.uml.diagram.traceability.ui.MACMASTraceabilityDiagram".equals(
properties.get("type")) {
return new MACMASTraceabilityDiagram();
} else {
return null; // If null is returned to GEF it will use
reflection to create the diagram
}
}
}
I'll create some API in GEF where you can add such a factory instance
into a list of factories for GEF to try before attempting reflection.
I assume there'll be a similar problem with Figs and can do the same for that.
How does this sound? Anyone got any better suggestions?
Bob.
On 13/11/06, Tom Morris <[EMAIL PROTECTED]> wrote:
> That class is part of our module, and obviously it exists.
> How can I solve that problem?
Well, just as obviously, it's not accessible to the classloader that's
trying to load it.
The failing line of code is
Class cls = Class.forName(clsName);
which is equivalent to
Class cls = Class.forName(clsName, true, this.getClass().getClassLoader())
so your class needs to be accessible to the classloader that loaded
GEF/PGML. The answer will probably also depend on your execution
environment (Eclipse vs Ant vs Java Web Start) and the packaging of your
plugin module.
Since plugin modules are loaded explicitly by the plugin module loaders
(either the old-style loader or the new-style loader), they potentially
could be visible to the module loader, but not to a classloader. If this is
the problem, one possible workaround would be to explicitly load your Fig
class at module initialization time.
You'll probably want to read a little bit about classloaders to understand
better how they work and what the potential problem areas are in your
application. They're complex enough that just hacking at things blindly is
likely to be a long and frustrating process.
Tom
p.s. It looks like your manifest was copied from someplace else without
updating it for your application. You might want to update
Implementation-Title, Implementation-Version, and Implementation-Vendor
which clearly refer to a different plugin.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
