Modify MomlParser to load actors via ActorProvider services

[GoogleCodeExporter]

MomlParser uses direct class loading and construction-through-reflection to 
instantiate an actor when parsing a moml file.

This must be adapted to use ActorProvider services, both for Java-based actors 
and moml-based actors.

The service must be aware of actor versions as well (cfr issue 28).

Different implementations must be possible in a dynamic way, exploiting OSGi's 
micro-services principles.

Original issue reported on code.google.com by erwin...@gmail.com on 8 Jun 2012 at 2:47

[GoogleCodeExporter]

Some more info, as described previously on Ptolemy's Triq mailing list :

> Dear triq members,
> 
> I would like to reopen the discussion on an evolution of Ptolemy's 
MomlParser, to enable an integration of Ptolemy in an OSGi-based solution,
> and gather feedback on the proposal below.
> 
> (For some previous discussions, pls check the Triq archives of March&April 
2010. The discussion at the time was about going for the eclipse-specific 
approach of their extension registry to declare and find actor classes in 
contributed OSGi bundles, or to choose another mechanism, e.g. based on plain 
OSGi services combined with e.g. an ActorProvider interface defined in Ptolemy.)
> 
> Within the Passerelle system (migrated in the meantime from CodeHaus to 
http://code.google.com/a/eclipselabs.org/p/passerelle/), we have built a first 
usable (very basic) version of an eclipse RCP-based design workbench for 
Passerelle/Ptolemy models.
> 
> To define the actor library that is shown in a "palette" for the model 
designer, we have defined some simple extension points for declaring actors, 
and their grouping. This is fine for an RCP, as it depends on eclipse concepts 
by nature.  But for a core engine component like the MomlParser, I would not 
want to build-in a strong dependency on the eclipse extension registry.
> Furthermore, the problem is not limited to declaring and loading Java-coded 
actor classes, that can be contributed by OSGI bundles that could use eclipse's 
extension-points mechanism.
> Also for loading "actor class" MOML files, a solution must be found within an 
OSGi context.
> Such "actor class" momls are created "ad hoc" by the users, so can not easily 
be handled directly as actor extensions as these must be defined upfront by 
bundle developers.
> 
> Within Passerelle, we need to support different runtime environments (desktop 
apps & web apps), most of them based on OSGi/Equinox, but some still on plain 
Java/Swing.
> Ideally, a common MomlParser implementation could be used in all of these 
settings, combined with custom actor class loading strategies.
> 
> To encapsulate the specific issues around actor class loading (or also for 
other Ptolemy entities and NamedObj things) within MomlParser, I would like to 
propose following approach :
> - isolate all class loading in a new method MomlParser.loadClass(String 
className)
> - replace all occurrences of Class.forName(...) by a call to the new method
> - introduce an interface ClassLoadingStrategy, with the same method 
loadClass(...)
> - A MomlParser must have a setter/getter for such a strategy
> - MomlParser.loadClass() delegates to the strategy instance; if no strategy 
is set, we do the default Class.forName(...) as now.
> 
> We can then implement the strategy in different ways and try them out freely.
> E.g. one that is based on the eclipse extension registry, one based on 
ActorProvider services etc.
> 
> Within an OSGi setting, the strategy can be easily configured with the 
"Dynamic Services" approach.
> Within non-OSGi settings, any kind of "dependency injection" can be used (cfr 
Spring framework etc).
> 
> What do you think, is this OK?
> If such an approach is acceptable, I would be happy to kickstart it.
> 
> Regards
> erwin

Original comment by erwin...@gmail.com on 8 Jun 2012 at 3:41

[GoogleCodeExporter]

kick-off : MomlParser delegates class loading to a strategy. Simple impl just 
uses the parser's class loader as before...

next step : define ActorProvider interface and some impls...

Original comment by erwin...@gmail.com on 8 Jun 2012 at 4:46

• Changed state: Started

[GoogleCodeExporter]

Version control, i.e. being able to specify a required version for an actor, 
which can be used to "filter" between several providers offering different 
versions of a same actor class, will be tricky.

Basic approach, using a VersionAttribute on the actor inside the model MOML, 
implies that the version is only known after the actor class has already been 
loaded. Property moml elements are handled in the MOML parser after their 
parent entity.

Two possible approaches to get this solved :
- allow multiple actor providers for (different versions of) a same actor class 
to provide their candidate class incl version info somehow (will be needed 
anyway), and modify the MomlParser to maintain a collection of candidate 
classes and instantiate the entity only when the version is known.
- modify the MOML DTD to add version as an attribute on the entity element. 
Then it can be read immediately upon parsing/handling the entity element and 
the best ActorProvider can be selected from the start.

I've asked for advise on the Ptolemy Triq mailing list. The version attribute 
on the entity element in the MOML is the preferred approach.

For now, I will just ignore the version-control aspect.

Original comment by erwin...@gmail.com on 27 Jul 2012 at 4:14

[GoogleCodeExporter]

Basic needs covered, i.e. supporting dynamic actor class/moml resolving based 
on registered service impls.

Version mgmt is for a next phase.

Original comment by erwin...@gmail.com on 27 Jul 2012 at 4:16

[GoogleCodeExporter]

Adapted the MOML DTD in Passerelle and forked src for Ptolemy MomlParser, to 
allow setting a version attribute on an actor entity in a MOML.

Add possibility to set default version spec for submodels (i.e. actor oriented 
classes). 
This is relevant in a context where groups of MOMLs (parent models and 
sub-models) are maintained in a versioning repository and can get tagged to 
indicate that their versions "belong together".
The tag could then be put as default version spec, i.e. could be specified 
outside of the parent models' MOMLs, which makes it much easier to work with 
versioned model assets.

This should mark the work as a first useable version...

Original comment by erwin...@gmail.com on 17 Sep 2012 at 12:46

• Changed state: Fixed