[kepler-dev] [Bug 1851] New: - Problem with composite actor classes in the new actor library system

[bugzilla-daemon@ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1851

           Summary: Problem with composite actor classes in the new actor
                    library system
           Product: Kepler
           Version: 1.0.0alpha3
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: interface
        AssignedTo: berkley at nceas.ucsb.edu
        ReportedBy: wibke at oci.unizh.ch
         QAContact: kepler-dev at ecoinformatics.org


Cutted and pasted from email conversation:

On 03.01.2005 18:34, "Chad Berkley" <berkley at nceas.ucsb.edu> wrote:

> Hi Shawn, Ilkay and Wibke,
> 
> This is probably our problem.  There are several problems like this that 
> i've been finding as i've been working with our newly re-worked actor 
> library system.  The best thing to do at this point is to enter a bug 
> and we can prioritize it and hopefully work on it at the kepler meeting 
> at the end of the month.  I think there are several other bugs like this 
> so maybe we can fix them all at the same time.
> 
> chad
> 
> Shawn Bowers wrote:
>> 
>> I'm not really sure what is causing your problem, but the actor library 
>> uses the file basicKeplerActorLibrary.xml and not basicKeplerLibrary.xml.
>> 
>> This file is basically just wrapped by a <group> without any additional 
>> "wrapper" (i.e., the UserLibrary stuff).
>> 
>> 
>> Shawn
>> 
>> 
>> 
>> Ilkay Altintas wrote:
>> 
>>> Hi Chad and Shawn,
>>> 
>>> Wibke had some problems with the cloning of the composite actors to 
>>> the actor library.
>>> All the details are given below. I thought you guys would help her 
>>> better than me.
>>> 
>>> I tried the same thing that she is trying to do under the regular PTII 
>>> and it seems to work.
>>> Please let me or her (cce'd) know if it is something we are missing or 
>>> unaware.
>>> 
>>> Wibke: The explanation below is great. Thanks so much for sending it.
>>> 
>>> Thanks everybody,
>>> -ilkay
>>> 
>>> 
>>> Begin forwarded message:
>>> 
>>>     *From: *Wibke Sudholt <Wibke.Sudholt at web.de>
>>>     *Date: *December 20, 2004 12:41:30 AM PST
>>>     *To: *Ilkay Altintas <altintas at sdsc.edu>
>>>     *Subject: Reuse of composite actors again
>>>     *
>>>     Hi Ilkay,
>>> 
>>>     I think the problem with the reuse of composite actors is a problem
>>>     of the
>>>     new actor tree/ontology layout in Kepler.
>>> 
>>>     According to the Ptolemy II documentation
>>>     
>>> (http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII4.0.1/doc/design/ 
>>> 
>>> 
>>>     usingVergil/index.htm), things should basically work as described 
>>> in my
>>>     previous email. For example, the user library may look like this
>>>     (see also
>>>     http://ptolemy.eecs.berkeley.edu/~cxh/ptpub/addinganactor.htm):
>>> 
>>>     <entity name="UserLibrary" class="ptolemy.moml.EntityLibrary">
>>>     <configure>
>>>     <group>
>>>     <entity name="CompositeActor" class="myActors.CompositeActor"/>
>>>     </group>
>>>     </configure>
>>>     </entity>
>>> 
>>>     So, the library is processed by ptolemy.moml.EntityLibrary via a
>>>     configure
>>>     group. This according to the documentation suppresses evaluation of
>>>     the MoML
>>>     commands as far as I understand. Thus when using
>>>     myActors.CompositeActor by
>>>     dragging & dropping onto the workspace, the MoML content under
>>>     entity is
>>>     used in the workflow exactly as it is put in the library.
>>> 
>>>     In contrast, in Kepler the library basicKeplerLibrary.xml in the 
>>> Kepler
>>>     configs dir basically looks like this:
>>> 
>>>     <entity name="actor library" class="ptolemy.kernel.CompositeEntity">
>>>     <group>
>>>     ...
>>>     </group>
>>>     </entity>
>>> 
>>>     In the middle (...) entities are imported via external files.
>>>     Differences
>>>     are that Kepler (1) uses the master class
>>>     ptolemy.kernel.CompositeEntity and
>>>     (2) directly implements the MoML entities, not via configure. As far
>>>     as I
>>>     understand, this does not suppress the evaluation of the MoML while
>>>     dragging
>>>     & dropping onto the workspace. In my case (see below) this leads 
>>> to the
>>>     source link being resolved and consequently the sub-entities of the
>>>     composite actor appearing two times in the workflow (one time via
>>>     the source
>>>     link copied and one time directly after resolving the link). This 
>>> might
>>>     perhaps explain the problems I observe when trying to include 
>>> composite
>>>     actor classes into the Kepler actor tree as described in my previous
>>>     email.
>>> 
>>>     This is as far as I could find out up to now. I am of course not
>>>     really sure
>>>     if this is the reason for the problems or if I misunderstand
>>>     something here.
>>>     But I would be very happy if you could clarify this for me, since
>>>     you are
>>>     the much better Kepler expert than I am :-) and I am really stuck 
>>> here
>>>     currently ...
>>> 
>>>     Thanks a lot,
>>> 
>>>     Wibke
>>> 
>>> 
>>>     ----------
>>> 
>>>     Hi Ilkay,
>>> 
>>>     I think I finally found a possibility to reuse/link composite actors.
>>> 
>>>     One has to include something like the following into the xml file 
>>> which
>>>     describes the library for the actor tree:
>>> 
>>>     <entity class="resurgence.ClassTest" name="Class Test"
>>>     source="ptolemy/configs/kepler/resurgence/ClassTest.xml">
>>>     <property class="org.ecoinformatics.seek.util.NamedObjId"
>>>     name="entityId" value="urn:lsid:ecoinformatics.org:kepler.1302.1"/>
>>>     </entity>
>>> 
>>>     The "source" attribute makes that the class MoML file (here
>>>     "ptolemy/configs/kepler/resurgence/ClassTest.xml") is reloaded each
>>>     time I
>>>     use a workflow which uses the entity.
>>> 
>>>     To make changes in the classes work, one has to recompile
>>>     kepler-configs.jar, however.
>>> 
>>>     Unfortunately, there are still problems with this setup. First of 
>>> all,
>>>     somehow a workflow generated on the workspace does not only get the
>>>     "entity"
>>>     entry from above, but also the contents of the ClassTest.xml file
>>>     included
>>>     (although it is still linked to this file, too, and the link works 
>>> e.g.
>>>     after changes and when looking inside a composite actor). Second,
>>>     whenever I
>>>     use ports and links etc. inside the class and not only just 
>>> entities, I
>>>     cannot dragg&dropp the actor to the workspace anymore and the
>>>     program hangs.
>>>     To me this actually looks like this might even be a bug in Ptolemy
>>>     or Kepler
>>>     ...
>>> 
>>>     Do you perhaps know how to solve this or could you forward this to a
>>>     person
>>>     who might know?
>>> 
>>>     Thanks a lot,
>>> 
>>>     Wibke
>>>