On Fri, Dec 12, 2008 at 9:58 AM, Howard Gilbert <[email protected]>wrote:
> <snip /> > > Obviously it would be possible to break CAS-Core into its component pieces > (presentation, ticket service, ticket cache, handlers) and package them as > separate bundles. Then one could upgrade one part of CAS, say the ticket > cache, without upgrading the other parts. That sounds, however, like > functionality that nobody is requesting to solve a problem nobody has. I > suspect that "OSGi" is just one of those technology trends that someone is > requesting without understanding. Before even thinking hard about it, the > person proposing it should provide some value proposition. What does it > bring to CAS? What problems does it solve? How is it to be used? > People are asking for this, which is why it was initially brought up. Minimizing server downtime, allowing real-time server reconfiguration, etc. are admirable goals. OSGi may or may not be the answer to this. I think the best option is for the people who are interested in OSGi to enumerate their use cases. Either way this most likely isn't going to make 4.0.0. ;-) But having discussions around highly available CAS instances, dynamic reconfiguration and updating with minimal downtime are useful as they are directions we may wish to look into. We've already added support for distributed CAS instances. Being able to dynamically reconfigure or update CAS is another step in the direction of increasing server uptime. The CAS project has a history of leveraging technology to improve the overall project and generally does not use technology for the sake of using technology. Previous examples of this include early adoptage of Spring, Spring Web Flow, and more recently adopting JPA, memcached, Terracotta, etc. > > > The OSGi Bundle is mostly a ClassLoader functionality that allows different > groups of classes/objects access to different versions of library services. > However, as soon as you have more than code version differences but also > have state differences (like a ticket cache) then OSGi doesn't help. Then > you need something like Spring Beans and dependency injection (local) or EJB > Session Beans (local/global), or an ESB and SOA services (global) to find > the right CAS ticket cache in the container on in the network. Since the CAS > server is mostly about maintaining that state, it has to be instantiated in > a container somewhere, and at that point it ceases to be anything OSGi is > architecturally good at handling. > Spring Dynamic Modules exists to allow Spring projects to leverage OSGi: http://www.springsource.org/osgi We would clearly need to look into it more before declaring it thing we would want to use. Again, you'll notice the original request was for people to enumerate how they think OSGi could/would/does best fit within CAS at all. It may end up not being a viable option at all. And since no one but you responded, it probably won't go anywhere any time soon :-) -Scott > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Scott Battaglia > *Sent:* Thursday, December 11, 2008 11:40 PM > *To:* CAS Developers Mailing List > *Subject:* [cas-dev] OSGi Support in CAS4 > > > > Folks, > > We've had some inquiries about OSGi in CAS4. If you're interested in OSGi > or an OSGi expert, and you'd like to write up some recommendations on best > practices, how you think it should look/work, etc. please let me know. > > This is one of those things that if we get support will probably make it > in, but might get pushed back if we don't get help. Rutgers has a longterm > interest in OSGi, but not a short-term. > > -Scott > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > _______________________________________________ > cas-dev mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas-dev > >
_______________________________________________ cas-dev mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas-dev
