seroUtils.jar management

So, can I
[ ] get the needed sources
or
[ ] decompile the needed classes it for ScadaBR?

and

[ ] put them in a different packages?

OR have a double license GPL and closed source licenses for serotonin only? (this can include any code commited to the GPL version is also in the closed source as well)?

Arne

For seroUtils? No. The license would be one of usage with Mango.

So for ScadaBR I will have to throw out all references to seroUtil in order to get a full Open Source?

Im missing a way to JSON serialize an enum by annotation - can you provide the sources to implement this?
Or should I take the approach from my last mail?

This message was edited 1 time. Last update was at 24/09/2011 02:26:10

So for ScadaBR I will have to throw out all references to seroUtil in order to get a full Open Source?

They might do that i suppose, but rewriting all of that supporting code would be a large effort. The good news is that we just started the process of releasing seroUtils as open source. The first project is here: http://code.google.com/p/serotonin-json.

Please note that this is *not* the version of JSON that is used in Mango, but a more advanced and streamlined version. (The API is similar in many ways, but different enough in others.)

The release of other parts of seroUtils is forthcoming.

Regarding serializing enums, you don't annotate them. The id of the enum is serialized as a string.

I am delighted

Here a "bug" for you. Please have a look at pointListChangeLock in DataSourceRT and PollingDataSourceRT.

1. the lock filed is not final.
2. Its a commonly known static Object Boolean.TRUE
3. the same lock will be used for writing the "cache" and working with the list, which made the lock useless in the first place.
this is fixed in ScadaBR

Arne.

P.S. if you interested in further bugs, if I come along, please let me know.

Hi Arne,

Sorry, i'm not seeing what the bug is here. You point 2 is incorrect. The lock object is not Boolean.TRUE, it is a new Boolean object created for each data source instance. And contrary to point 3, the lock is only used to manage the point list, not writing to the cache (unless writing to the cache is part of a data sources usage of the point list).

Maybe if you posted the "fix", it would help me understand.

in DataSourceRT.addDataPoint(...)
pointListChangeLock is used to synchronize access to addedChangedPoints and removedPoints.

in PollingDataSource.scheduleTimeout you synchronize also with pointListChangeLock...

This makes the whole thing useless, you wont have separate access to add/Remove points.

@2 You right, I was puzzled by the usage of Boolean ;-)

Sorry, i still don't understand how this makes the whole thing pointless. You absolutely do have separate threads accessing scheduleTimeout and add/removeDataPoint. The former is a runtime function, the latter is a UI function. It still looks fine to me.

I thougth that the the whole thing is there, to add new DataPoints to RT if the RT is polling the dataPoints.
with the lock only one Thread can access the add/Remove or pointList.

I have a lock for the addList (the addList) one for remove and one for the pointList.
so adding will lock only the addList ...
If I copy over I must lock all.

src is here (modified)
https://scadabr.svn.sourceforge.net/svnroot/scadabr/trunk/scadabr/scadabr/src/main/java/com/serotonin/mango/rt/dataSource/DataSourceRT.java