On Feb 22, 2012, at 3:08 PM, Mohammad Nour El-Din wrote: > On Wed, Feb 22, 2012 at 11:33 PM, David Blevins > <david.blev...@gmail.com>wrote: > >> From what I understand you're talking about a file that contains 100% of >> the metadata and eliminates the need for most or all of the actual >> deployment process. That's definitely a good idea. >> > > That is exactly what I am talking about but this meta-data file I was > talking to make it in *code* and compile as part of the deployment process > to make it fast and memory efficient. More specifically for running the > application(s) over and over again, unless there is a chance and hence the > process is repeated. > > The code can be generated in Groovy or any dynamic language that can make > it easy to deal with at run time. > > Using Groovy can have an advantage which that Groovy has facilities for > building DSL(s) which we can use to define a DSL for describing whatever > aspects we need while scanning or any other operation we want to do while > deploying which also can serve as a more readable, almost English language > rather than the tree like language based on XML.
Maybe check out this doc. Some of the things you mention might tie in here: http://openejb.apache.org/dev/configuration-and-assembly.html There are two layers you could deploy apps in code: 1. Build the EjbModule by hand and configure then assemble it. 2. Build the AppInfo by hand then assemble it. Working with the AppInfo tree is a bit like writing assembly code. Working with the EjbModule and EjbJar tree is a bit more like a DSL. There are nice and fancy methods in there and even some DSL syntax. In pure performance terms, considering no other requirements, cutting out the ConfigurationFactory by simply saving the resulting AppInfo object then reloading it on each deploy is going to be pretty fast. It would cut out 80% of the deploy code, including scanning. Not how this strictly relates to what you might be thinking, but that is at least some insight on the problem space. -David
