Re: [argouml-dev] Problem with the persistence/load of diagrams.

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 <tfmorris@xxxxxxxxx> 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: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx