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. > > Some work has been done in that regard, though it's not yet functional. > It's a much harder problem than optimizing component scanning. > Can you give me hints where I can find that, I want to have a look at it and continue that if possible ? At last I could have a successful OpenEJB build on my machine since years now :D. > > Note also that there are two types of scanning. There is: > > A. scanning jars for classes that use a specific annotation > B. scanning a class for annotations > > Due to memory and speed limitations you can't do B on every class in all > jars, so limiting that scope is important. This is where A comes in. > > The scan.xml proposal effectively only tackles issue A. > We can have options to control on which level we want to apply this. Or even this can be provided a tool for developers to run over their code before deploying it generating the meta-date *code* which can be detected while deployment loaded and take actions based on what we find there. I know this might sound like complicated, but it is not it is just different in my ex-company we used Python all the time even when describing services and object model(s) (a.k.a DSL) which is more readable and more efficient than reading XML or YAML. Thoughts ? > > > -David > > On Feb 22, 2012, at 2:07 PM, Mohammad Nour El-Din wrote: > > > Never it seems not to be a good idea :) > > > > On Wed, Feb 22, 2012 at 9:11 PM, Romain Manni-Bucau > > <rmannibu...@gmail.com>wrote: > > > >> Hmm, not sure i follow too, > >> > >> We just spoke about generating xml then reading it to avoid scanning. > >> > >> Le 22 févr. 2012 21:06, "Alan D. Cabrera" <l...@toolazydogs.com> a > écrit : > >> > >>> > >>> On Feb 22, 2012, at 11:49 AM, Mohammad Nour El-Din wrote: > >>> > >>>> Hi Romain and Alan :) > >>>> > >>>> I didn't say ever to not use XML or a simple file, which what I meant > >>> by > >>>> the declarative side, what I mean is additionally to that, at the time > >> of > >>>> deploy that out of that file Java code is generated which provides the > >>>> information we need while scanning and thats what I meant by the > >>>> execution/runtime perspective. > >>> > >>> I think I'm a bit lost. Why would Java code be generated when simply > >>> reading the file will do? :) > >>> > >>> Can you provide a more detailed and concrete example that explains your > >>> idea? > >>> > >>> > >>> Regards, > >>> Alan > >>> > >>> > >> > > > > > > > > -- > > Thanks > > - Mohammad Nour > > ---- > > "Life is like riding a bicycle. To keep your balance you must keep > moving" > > - Albert Einstein > > -- Thanks - Mohammad Nour ---- "Life is like riding a bicycle. To keep your balance you must keep moving" - Albert Einstein
