[wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

[Rebecca Searls]

comment on the original post.

> 
>   I think such a tool is a good stop gap measure but in general I think our
>   perspective on this is all wrong.  We have a great modular framework and
>   isolated classloading.  Its a framework that can support applications
>   running
>   different lib versions on it.  Why not leverage that more?
> 
>   It's the changes to the server framework implementation that seems to
>   always
>   cause the most pain in moving an application from one server version to
>   another.
>   AS7 is a case in point.  Providing a new improved framework is a good thing
>   but why not provide an infra-structure (module) along with it to enable the
>   move
>   from the previous to the current seamless?  Why make the customer do so
>   much
>   hard work?
> 
>   We've all seen the forum discussion where a user is attempting to migrate
>   their
>   AS 4 app lock stock and barrel to AS 7 and ask how to resolve related
>   errors?
>   I too have scratched my head and asked, "why would he ever want to do
>   that".
>   Well, the user has put in a lot of man hours writing that app, fixing bugs,
>   and
>   making it stable.  He does not want to take the risk of introducing any new
>   bugs with changes.  He does want to write his new code to the current
>   standard
>   and run it in the current environment and he wants a single server
>   environment
>   to do it in.
>     
>   I've always envisioned JEE implementations to be an environment much like
>   an
>   OS.  When I update my OS I don't have to alter any of the apps I'm running.
>   I don't have to redeploy them or reconfigure them in any way.  It just
>   works.
>   I expect the same of my JEE implementations, and to date I've been
>   disappointed
>   by all the vendors.
> 
>  
>   I think the framework provided in AS 7 and WildFly empowers us to provide
>   an
>   JEE environment that supports that AS 4 app running unaltered in WildFly. I
>   think there a number of functions that can and should be *retrofited* to
>   WildFly.
>   The Hibernate 3 module is an example of this.  An AS4/AS5 server config
>   loader module is another.  Support for the predecessors of HornetQ and
>   Infinispan
>   are others.
> 
>   As we move forward with WildFly and future versions I would argue we need
>   to
>   design seamless support for prior versions of the components and provide
>   backward
>   compatibility not just at the JEE api level but the server framework
>   implementation
>   level. (Treat it like an OS)
>      
>      
>