[kepler-users] Actor ports and parameters
Hi All, Is there a way I can get the list of ports and parameters (and possibly their tokens ) before the actor's fire() method ? Thanks! Arwa
[kepler-users] Actor ports and parameters
Yes, you can get to the attributes and ports in the initialize()
method (they're set up in the preinitialize() method, so I think
initialize() is as soon as you can use them. Tokens, though, should
all be sent after all actors have been fully initialized, so I don't
think there's anything before the fire() method that you can do with
tokens. I've attached an example below:
@Override
public void initialize() throws IllegalActionException {
super.initialize();
for (Object portObj : this.portList()) {
IOPort port = (IOPort) portObj;
System.out.println(port = + port);
}
for (Object attObj : this.attributeList()) {
Attribute att = (Attribute) attObj;
System.out.println(attribute = + att);
}
}
- Sean
On Aug 9, 2010, at 10:46 AM, Jamnagarwala, Arwa Mohmadi wrote:
Hi All,
Is there a way I can get the list of ports and parameters (and
possibly their tokens ) before the actor's fire() method ?
Thanks!
Arwa
___
Kepler-users mailing list
Kepler-users at kepler-project.org
http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
[kepler-users] Kepler 2.0, intermodular libraries conflict
Hi Tomasz, This issue can be a little tricky. The first thing to note is that you can override other jars. If you put different jars in your module, they will be used by your module AND all of Kepler instead of the jars that are there. The problem with this arises in situations where your jars are not compatible with Kepler. Then things can break. But this is the first approach to try. Just put your jars in your own module and see if things work. It sounds like you have already done this. The second thing to note is that it is possible to use multiple class loaders. That is, you can use a separate class loader to load different jars for your module than for the rest of Kepler. Documentation about how to do this is included in the build system documentation. This might work. The thing is, I have had problems with this recently when someone was trying to use a different class loader for Log4j. So, this is not guaranteed to work and this feature has some bugs that cause it to not work at least some of the time. Also, of course your IDE is probably not going to know about the separate class loader, and your IDE might get confused. The third thing to note is that it might be possible to talk to the Kepler leadership team and get these jars upgraded in Kepler. This would be a very reasonable request to make if neither of the above solutions work for you. -David On Fri, Aug 6, 2010 at 9:11 AM, Tomasz ?ok tzok at man.poznan.pl wrote: Hi, I am developing a new module which uses several external .jar libraries. These are mostly well known and widely used libraries like log4j, etc. However I found out that there is a conflict in library versions that disables my module totally. I pinpointed the issue to the minimal subset of conflicting jars: actors/lib/jar/commons-httpclient-3.0.1.jar common/lib/jar/log4j-1.2.8.jar common/lib/jar/sms/xercesImpl.jar My module uses: commons-httpclient-3.1.jar log4j-1.2.16.jar xercesImpl-2.7.1.jar My libraries are in the classpath when I run Kepler, but they are not loaded, because the three conflicting ones precede them. What should I do in such situation? Should I somehow formally ask Kepler devs to update theirs or should I do anything with my libraries? Best regards, Tomek -- Tomasz Zok Poznan Supercomputing and Networking Center ul. Noskowskiego 10, 61-704 Poznan, POLAND http://www.man.poznan.pl ___ Kepler-users mailing list Kepler-users at kepler-project.org http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users -- next part -- An HTML attachment was scrubbed... URL: http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20100809/9720acc8/attachment.html
[kepler-users] Kepler 2.0, intermodular libraries conflict
I think it would be a good idea to upgrade these jar files to more recent releases, assuming that testing shows no adverse effects on the modules that depend on them. As these are in very low-level modules, there may be many different modules that depend on them, so we would need to test several different suites, and there may need to be some refactoring if any of these libraries has modified their APIs. Do you know if the APIs have changed, or were they only extended in backwards-compatible ways? Although two of these are used extensively (log4j and xerces) and so rightfully belong in common, the httpclient jar file might be more restricted in which modules use it. Its probably worth looking at the dependency tree and seeing which actors use that jar file, and consider splitting those actors out into their own module(s) to reduce these types of conflicts. So, if you want to propose particular upgrades for the jars in common and actors modules, please try replacing them and running the tests and we'll try to fit the changes into an upcoming release -- file an enhancement request with the results of your testing and we can take it from there. In any case, as David said, you may be able to override for your module by using your own classloader to get started over the shorter term. Matt PS This kind of development discussion is more appropriate for the kepler-dev list -- kepler-users is more about using the system, rather than developing extensions to it, although the line between the two is very grey. On Mon, Aug 9, 2010 at 1:01 PM, David Welker david.v.welker at gmail.comwrote: Hi Tomasz, This issue can be a little tricky. The first thing to note is that you can override other jars. If you put different jars in your module, they will be used by your module AND all of Kepler instead of the jars that are there. The problem with this arises in situations where your jars are not compatible with Kepler. Then things can break. But this is the first approach to try. Just put your jars in your own module and see if things work. It sounds like you have already done this. The second thing to note is that it is possible to use multiple class loaders. That is, you can use a separate class loader to load different jars for your module than for the rest of Kepler. Documentation about how to do this is included in the build system documentation. This might work. The thing is, I have had problems with this recently when someone was trying to use a different class loader for Log4j. So, this is not guaranteed to work and this feature has some bugs that cause it to not work at least some of the time. Also, of course your IDE is probably not going to know about the separate class loader, and your IDE might get confused. The third thing to note is that it might be possible to talk to the Kepler leadership team and get these jars upgraded in Kepler. This would be a very reasonable request to make if neither of the above solutions work for you. -David On Fri, Aug 6, 2010 at 9:11 AM, Tomasz ?ok tzok at man.poznan.pl wrote: Hi, I am developing a new module which uses several external .jar libraries. These are mostly well known and widely used libraries like log4j, etc. However I found out that there is a conflict in library versions that disables my module totally. I pinpointed the issue to the minimal subset of conflicting jars: actors/lib/jar/commons-httpclient-3.0.1.jar common/lib/jar/log4j-1.2.8.jar common/lib/jar/sms/xercesImpl.jar My module uses: commons-httpclient-3.1.jar log4j-1.2.16.jar xercesImpl-2.7.1.jar My libraries are in the classpath when I run Kepler, but they are not loaded, because the three conflicting ones precede them. What should I do in such situation? Should I somehow formally ask Kepler devs to update theirs or should I do anything with my libraries? Best regards, Tomek -- Tomasz Zok Poznan Supercomputing and Networking Center ul. Noskowskiego 10, 61-704 Poznan, POLAND http://www.man.poznan.pl ___ Kepler-users mailing list Kepler-users at kepler-project.org http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users ___ Kepler-users mailing list Kepler-users at kepler-project.org http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users -- next part -- An HTML attachment was scrubbed... URL: http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20100809/df3a33a0/attachment.html
[kepler-users] kepler's semantic type checking of connected ports
Hi, When I apply a semantic type to an input and output port that are connected, the semantic type checker always shows an error on the semantic types. This looks like a bug in Kepler 2.0 Chris
[kepler-users] kepler's semantic type checking of connected ports
Yes, I see I can replicate this on my machine, and it happens even if they are the same type, or the input type is a subclass of the output type. I filed a bug report (http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5136). Thanks for pointing it out. Matt On Mon, Aug 9, 2010 at 3:30 PM, Chris Weed chrisweed at gmail.com wrote: Hi, When I apply a semantic type to an input and output port that are connected, the semantic type checker always shows an error on the semantic types. This looks like a bug in Kepler 2.0 Chris ___ Kepler-users mailing list Kepler-users at kepler-project.org http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users -- next part -- An HTML attachment was scrubbed... URL: http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20100809/e101689e/attachment-0001.html
