why not to production compile xml

[xVik]

Im just curious about:
why not to compile xml configuration for the production
..
as i can see from my work xml its pretty good format for describing configuration..
its very human-friendly (readable)
for me, xml have only one disadvataje - it takes a long time for parse

im also like annotations, but in case of schemas, for example, its more pleasure to configure it
in xml

and small tool that will compile xml to bytecode will be the silver bullet in case of develoment pleasure

what you think?

[Knut Wannheden]

xVik,

We did experiment with serializing the parsed XML module definitions
as POJOs (i.e. standard Java object serialization). It turned out that
reading that back in was really just marginally faster than parsing
the equivalent XML.

If I understand you correctly you propose compiling the module
definitions to Java code (e.g. a class implementing
ModuleDescriptorProvider) and in turn save that as a Java bytecode
file. To do that one could use Javassist, CGLIB, etc.

I have indeed thought about this idea. But I never got around
implementing it. I agree with you that the XML is quite nice for
defining configuration contributions for a given schema, so even with
the advent of Java annotation based definitions it may be worthwhile.

Let us know if you have any more concrete thoughts / ideas about this.

Regards,

--knut

On 2/2/07, xVik <2rvv@...> wrote:

>
> Im just curious about:
> why not to compile xml configuration for the production
> ..
> as i can see from my work xml its pretty good format for describing
> configuration..
> its very human-friendly (readable)
> for me, xml have only one disadvataje - it takes a long time for parse
>
> im also like annotations, but in case of schemas, for example, its more
> pleasure to configure it
> in xml
>
> and small tool that will compile xml to bytecode will be the silver bullet
> in case of develoment pleasure
>
> what you think?
> --
> View this message in context: http://www.nabble.com/why-not-to-production-compile-xml-tf3159231.html#a8762179
> Sent from the Hivemind - User mailing list archive at Nabble.com.
>
>

[xVik]

I see this concept in thunkmap (thinkmap.com)
there is beautiful xml configuration (it's real pleasure to work with)

and special packager to compile xml into bytecode for production.

but, the bad news is its not open or free

for now, i dont have enough knowledge and time to implement something like
but it is still possible :)

Knut Wannheden wrote:

xVik,

We did experiment with serializing the parsed XML module definitions
as POJOs (i.e. standard Java object serialization). It turned out that
reading that back in was really just marginally faster than parsing
the equivalent XML.

If I understand you correctly you propose compiling the module
definitions to Java code (e.g. a class implementing
ModuleDescriptorProvider) and in turn save that as a Java bytecode
file. To do that one could use Javassist, CGLIB, etc.

I have indeed thought about this idea. But I never got around
implementing it. I agree with you that the XML is quite nice for
defining configuration contributions for a given schema, so even with
the advent of Java annotation based definitions it may be worthwhile.

Let us know if you have any more concrete thoughts / ideas about this.

Regards,

--knut

On 2/2/07, xVik <[e-mail]> wrote:
>
> Im just curious about:
> why not to compile xml configuration for the production
> ..
> as i can see from my work xml its pretty good format for describing
> configuration..
> its very human-friendly (readable)
> for me, xml have only one disadvataje - it takes a long time for parse
>
> im also like annotations, but in case of schemas, for example, its more
> pleasure to configure it
> in xml
>
> and small tool that will compile xml to bytecode will be the silver bullet
> in case of develoment pleasure
>
> what you think?
> --
> View this message in context: http://www.nabble.com/why-not-to-production-compile-xml-tf3159231.html#a8762179
> Sent from the Hivemind - User mailing list archive at Nabble.com.
>
>

[alebu]

So such compiled descriptors will be stored in classpath as some
classes? Am I understanding idea correctly?
How Hivemind will discover such descriptors? Can anyone explain more
detailed how it possibly can be implemented ( main concepts )?
How people will use it, and as on... Because IMO Hivemind apps startup
time is probably the only one negative thing about it.
xVik wrote:

> I see this concept in thunkmap (thinkmap.com)
> there is beautiful xml configuration (it's real pleasure to work with)
>
> and special packager to compile xml into bytecode for production.
>
> but, the bad news is its not open or free
>
> for now, i dont have enough knowledge and time to implement something like
> but it is still possible :)
>
>
> Knut Wannheden wrote:
>  
>> xVik,
>>
>> We did experiment with serializing the parsed XML module definitions
>> as POJOs (i.e. standard Java object serialization). It turned out that
>> reading that back in was really just marginally faster than parsing
>> the equivalent XML.
>>
>> If I understand you correctly you propose compiling the module
>> definitions to Java code (e.g. a class implementing
>> ModuleDescriptorProvider) and in turn save that as a Java bytecode
>> file. To do that one could use Javassist, CGLIB, etc.
>>
>> I have indeed thought about this idea. But I never got around
>> implementing it. I agree with you that the XML is quite nice for
>> defining configuration contributions for a given schema, so even with
>> the advent of Java annotation based definitions it may be worthwhile.
>>
>> Let us know if you have any more concrete thoughts / ideas about this.
>>
>> Regards,
>>
>> --knut
>>
>> On 2/2/07, xVik <2rvv@...> wrote:
>>    
>>> Im just curious about:
>>> why not to compile xml configuration for the production
>>> ..
>>> as i can see from my work xml its pretty good format for describing
>>> configuration..
>>> its very human-friendly (readable)
>>> for me, xml have only one disadvataje - it takes a long time for parse
>>>
>>> im also like annotations, but in case of schemas, for example, its more
>>> pleasure to configure it
>>> in xml
>>>
>>> and small tool that will compile xml to bytecode will be the silver
>>> bullet
>>> in case of develoment pleasure
>>>
>>> what you think?
>>> --
>>> View this message in context:
>>> http://www.nabble.com/why-not-to-production-compile-xml-tf3159231.html#a8762179
>>> Sent from the Hivemind - User mailing list archive at Nabble.com.
>>>
>>>
>>>      
>>    
>
>  

[xVik]

its simple.. you working with xml descriptors during development
when you ready for production you compiles your code with special packager
(it may be an ant task for example)
packager will make class files from xml and place it in jar..
so you again have single jar with your plugin, but whithout xml configuration
(its "hardcoded")
it will require extended mechanizm for module detection but i don't think it would be difficult task

alebu wrote:

So such compiled descriptors will be stored in classpath as some
classes? Am I understanding idea correctly?
How Hivemind will discover such descriptors? Can anyone explain more
detailed how it possibly can be implemented ( main concepts )?
How people will use it, and as on... Because IMO Hivemind apps startup
time is probably the only one negative thing about it.
xVik wrote: