• New Feature
  • Status: Resolved
  • 3 Minor
  • Resolution: Won't Fix
  • teck
  • Reporter: teck
  • May 27, 2009
  • 0
  • Watchers: 1
  • September 06, 2013
  • September 06, 2013

Description

We have two classes that are part of the core TC code to support TIMs. In both cases we added specialized state objects in the L2. This means that the TIMs are dependent on the core code in unexpected and unmanaged ways.

The solutions to this issue are really open ended. We could load TIMs in the server (heck, we could wholesale host the TIM jars in the L2). Another idea would be ship code/classes from the L1 to the L2 to cover stuff like this.

[added later] in retrospect I’ve been thinking that instead of going wild here I think it might be possible to cover the needs of these specialized state classes generically. Looking at the special behavior of these state classes (above the standard physical state object) I think it could be possible to describe this in the DNA. You’ll still need a way for the TIM to setup this up on the class spec, but from then one I’d think the L1/L2 code could handle it generically (ie. no special knowledge of the the TIM type names)

Comments

Alex Miller 2009-05-27

Seems like the last idea is actually kind of similar to what we are now doing to ship classes from tims in L1 to the console for hibernate-cache.

Chris Dennis 2009-05-27

Personally, I like the idea of hosting the tims on the L2, and then serving the code to the L1s. It seems nice to be able to collect all the tims in one place, instead of copying them to every L1.

Geert Bevin 2009-05-28

One problem with hosting the TIM jars in the server with it being a central repo is that this should be possible without a server restart. I don’t think it’s acceptable to have to bring down a server because a client uses a new TIM. Also, this has to be coordinated between active, passive and several actives, if the server becomes the final authority for the TIMs.

Alex, one main difference I see in the current console stuff is that for this functionality it’s the other way ‘round. A TIM should register those classes at startup at bundle registration and before any functionality happens. The current console stuff is done on the fly, when needed.

We should especially be careful with this feature to not crash the server or create classloading problems. This is obvious, but I thought I’d point it out because we’re moving into shaky ground here if we’re probably introducing new classloaders to dynamically add server extensions from L1s.

Fiona OShea 2009-05-29

seems like we need to do something thinking around this…

Alex Miller 2009-11-16

Punt and think about for Taraval