Hi... *cool* :D
I will look into that the coming few days and get back with questions/feedback On Thu, Feb 23, 2012 at 1:21 AM, David Blevins <david.blev...@gmail.com>wrote: > > 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 > > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
