>> we are using stax now under the covers as well.
>>
>> These are just different models of jaxp parsing: dom, sax, stax.
I wasn't aware of stax / jaxb interoperability so sorry for that noise ;)
> Right, and the benefit of JAXB is the typed API.
sounds good as long as the xml and model still
On Fri, 15 Apr 2011 18:06:47 +0200, Steve Ebersole
wrote:
> we are using stax now under the covers as well.
>
> These are just different models of jaxp parsing: dom, sax, stax.
Right, and the benefit of JAXB is the typed API.
It is very hard to find reliable sources for performance comparisons
we are using stax now under the covers as well.
These are just different models of jaxp parsing: dom, sax, stax.
On 04/15/2011 10:57 AM, Max Rydahl Andersen wrote:
>
> On Apr 15, 2011, at 17:49, Steve Ebersole wrote:
>
>> What causes the bad performance? You do realize there are 3 aspects to
>
On Apr 15, 2011, at 17:49, Steve Ebersole wrote:
> What causes the bad performance? You do realize there are 3 aspects to
> performing jaxb right? You have the actual jaxp parsing, the validation and
> then finally the binding.
>
> Conversely, with DOM you have jaxp parsing, validation and D
On Fri, 15 Apr 2011 17:45:23 +0200, Max Rydahl Andersen
wrote:
> im confused - are we seriously looking at using jaxb for parsing the xml
> configurations even though
> they are doing what they can to remove any jaxb stuff from AS7 codebase
> because of the bad performance
> and maintenance
What causes the bad performance? You do realize there are 3 aspects to
performing jaxb right? You have the actual jaxp parsing, the validation
and then finally the binding.
Conversely, with DOM you have jaxp parsing, validation and DOM model
binding.
So what is the big difference?
On 04/15/
im confused - are we seriously looking at using jaxb for parsing the xml
configurations even though
they are doing what they can to remove any jaxb stuff from AS7 codebase because
of the bad performance
and maintenance overhead (especially when its part of the server) ?
/max
On Apr 13, 2011, at
On Tue, 12 Apr 2011 21:26:01 +0200, Steve Ebersole
wrote:
> Do we want to make caching of files a flag for processing all of the xml
> files?
>
> Currently we have methods:
> addFile(String path)
> addFile(File file)
> addCacheableFile(String path)
> addCacheableFile(File file)
>
> Could we ins
On Wed, 13 Apr 2011 01:03:55 +0200, Steve Ebersole
wrote:
>> Note, if more than just xml based metadata could be cached that would
>> be awesome - but that might be
>> better solved via something like AS7 annotation index mechanism.
>
> funny you should say that... ;)
Right. With the current
2011/4/13 Hardy Ferentschik :
> On Wed, 13 Apr 2011 00:44:16 +0200, Steve Ebersole
> wrote:
>
>> Hm, if we move to jaxb are those generated binding classes serializable?
>
> The classes are not serializable out of the box.
> It can be done though using a custom base class for all binding classes
>
On Wed, 13 Apr 2011 00:44:16 +0200, Steve Ebersole
wrote:
> Hm, if we move to jaxb are those generated binding classes serializable?
The classes are not serializable out of the box.
It can be done though using a custom base class for all binding classes
and some
xjc (name of the plugin gener
On Apr 13, 2011, at 24:44, Steve Ebersole wrote:
> Hm, if we move to jaxb are those generated binding classes serializable?
jaxb? i thought we wanted this stuff to be faster, not slower ? (sorry,
couldn't resist ;)
/max
>
> On 04/12/2011 02:41 PM, Hardy Ferentschik wrote:
>>
>>
>>
>>
>>
Surely they are serializable in XML ;)
(Sorry, could not resist)
On 13 avr. 2011, at 00:44, Steve Ebersole wrote:
> Hm, if we move to jaxb are those generated binding classes serializable?
>
> On 04/12/2011 02:41 PM, Hardy Ferentschik wrote:
>>
>>
>>
>>
>> On Apr 12, 2011, at 21:26, Steve Eb
Sanne for 3.6 cool, but be aware that we are redoing all of this ATM in
master
On 04/12/2011 06:15 PM, Sanne Grinovero wrote:
> 2011/4/13 Steve Ebersole:
>> On 04/12/2011 06:01 PM, Max Rydahl Andersen wrote:
>>> This was my original implementation but it was changed to this explicit API
>>> with
2011/4/13 Steve Ebersole :
> On 04/12/2011 06:01 PM, Max Rydahl Andersen wrote:
>> This was my original implementation but it was changed to this explicit API
>> with the reasoning
>> that doing this caching should be an explicit act of intent and not just a
>> simple flag working globally.
>
> B
On 04/12/2011 06:01 PM, Max Rydahl Andersen wrote:
> This was my original implementation but it was changed to this explicit API
> with the reasoning
> that doing this caching should be an explicit act of intent and not just a
> simple flag working globally.
But isn't the user explicitly saying
> Do we want to make caching of files a flag for processing all of the xml
> files?
>
> Currently we have methods:
> addFile(String path)
> addFile(File file)
> addCacheableFile(String path)
> addCacheableFile(File file)
>
> Could we instead condense these and allow configuration of whether to
Hm, if we move to jaxb are those generated binding classes serializable?
On 04/12/2011 02:41 PM, Hardy Ferentschik wrote:
>
>
>
>
> On Apr 12, 2011, at 21:26, Steve Ebersole wrote:
>
>> Do we want to make caching of files a flag for processing all of the xml
>> files?
>>
>> Currently we have meth
Do we want to make caching of files a flag for processing all of the xml
files?
Currently we have methods:
addFile(String path)
addFile(File file)
addCacheableFile(String path)
addCacheableFile(File file)
Could we instead condense these and allow configuration of whether to
try and cache xml fi
19 matches
Mail list logo
