You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Dmitri Plotnikov <dm...@plotnix.com> on 2002/04/28 06:46:53 UTC
Re: [jxpath] CompiledExpression [was: New features, bug fixes and documentation]
Ovidiu,
I have added to JXPath the explicit caching you proposed in your earlier
submission:
[... snip...]
> > >
> > > > I've got a small suggestion for an optimization, if
> > > > you don't mind. In
> > > > the implementation I have, 0.1-dev from Jakarta's
> > > > CVS, I noticed
> > > > there's no way to compile an XPath, before using it.
> > > > Having a way to
> > > > compile the XPaths to be used later, would
> > > > considerably improve the
> > > > performance in repeated operations.
> > > >
> > > > E.g. right now you have something like this:
> > > >
> > > > Object bean = ...;
> > > > JPathContext context =
> > > > JPathContext.newContext(bean);
> > > > context.getValue("some XPath");
> > > >
> > > > I'd like to also have the ability to do:
> > > >
> > > > Object bean = ...;
> > > > JPathContext context =
> > > > JPathContext.newContext(bean);
> > > > XPathObject xpath = new XPathObject("some XPath");
> > > > context.getValue(xpath);
> > > >
> > > > With this approach, I can setup a dictionary of
> > > > already compiled XPath
> > > > expressions, and use compiled XPaths, instead of
> > > > having Xalan
> > > > interpret the XPath all the time.
> > > >
> > > > Last time I checked, Xalan did have the ability to
> > > > precompile XPaths
> > > > in its internal format, so maybe this is easy to
> > > > achieve.
> > > Actually JXPath is already doing something like that
> > > transparently to you. It maintains a static soft cache
> > > of parse trees (which are that internal representation
> > > you are talking about). The reason I am using soft
> > > cache as opposed to a regular map is that some
> > > applications will generate XPaths dynamically, in
> > > which case the size of the cache has a chance of going
> > > through the roof. The soft cache is cleared by
> > > garbage collector, which removes the possibility of
> > > running out of memory.
> > >
> > > I have been thinking about improving that mechanism a
> > > little bit. I now want to have a regular map of a
> > > limited size in addition to the soft cache.
> > > Everything that spills over the hard cache will still
> > > be stored in the soft cache. I think that will cover
> > > the 90% case.
I now see the need for caching external to JXPath: you may want to
precompile some expression at application start time, you may want to check
syntax before you use an expression etc.
I called "XPathObject" "CompiledExpression". You make an explicit call:
context.compile(xpath) to get a CompiledExpression. That method will in
fact check the internal cache before it proceeds with the compilation.
Thanks again for the suggestion,
Regards,
- Dmitri
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Avalon SourceRevolting ;-P
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi,
I think I found the bug for the NPE - it should be fixed now, the poi
examples work for me now.
Sorry for this, but remember that we are currently "entering alpha
phase" for the development of version 2.1 - this will propably mean
that we will have phases like this where some things aren't working
for days. This is unavoidable.
But I will try to keep these periods of time as small as possible,
so sorry for this dumb mistake.
Carsten
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Sunday, April 28, 2002 10:09 AM
> To: cocoon-dev@xml.apache.org
> Subject: Avalon SourceRevolting ;-P
>
>
> The POI samples page gives a *NullPointerException* coming somewhere from
> the Avalon source resolving.
> Since it's such a big change, I would have expected that who did
> the change
> would have tried the examples...
>
> Anyway, could someone please take a look at this?
>
> I've got a *big* itch to scratch now that it's weeks that the
> refactoring of
> the samples still lies there, and it's getting ever more frustrating ;-)
>
> Thank you.
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Avalon SourceRevolting ;-P
Posted by Nicola Ken Barozzi <ni...@apache.org>.
The POI samples page gives a *NullPointerException* coming somewhere from
the Avalon source resolving.
Since it's such a big change, I would have expected that who did the change
would have tried the examples...
Anyway, could someone please take a look at this?
I've got a *big* itch to scratch now that it's weeks that the refactoring of
the samples still lies there, and it's getting ever more frustrating ;-)
Thank you.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [jxpath] CompiledExpression [was: New features, bug fixes and documentation]
Posted by Ivelin Ivanov <iv...@apache.org>.
Thanks Dmitri. I think understand the difference now.
----- Original Message -----
From: "Dmitri Plotnikov" <dm...@plotnix.com>
To: "Ivelin Ivanov" <iv...@apache.org>; "Ovidiu Predescu"
<ov...@apache.org>
Cc: <co...@xml.apache.org>
Sent: Sunday, April 28, 2002 8:42 AM
Subject: Re: [jxpath] CompiledExpression [was: New features, bug fixes and
documentation]
> Ivelin,
>
> > So how does the CompiledExpression differ from a JXPointer?
> >
> > When I needed to cache a dictionary of paths I dused a Map.Entry where
the
> > key is the path string (JXPointer.asPath() )and
> > the value is a JXPointer (which has the getValue() setValue() methods).
>
> CompiledExpression is the result of the _compilation_ of an XPath, while
> Pointer is the result of an _evaluation_ of an XPath, augmented with
> information about where that value was found.
>
> For example, let's say your xpath looks like this: "//person[@name =
'John
> Doe']/phone". The corresponding Pointer.toString() may yield something
like
> "/addressBook/people/person[13]/phone".
>
> When you call Pointer.getValue(), it does not reevaluate the path - just
> gives you the result. Also you can say Pointer.setValue("5551234") and
does
> not reevaluate the path - just changes the corresponding value.
>
> Regards,
>
> - Dmitri
>
>
> > ----- Original Message -----
> > From: "Dmitri Plotnikov" <dm...@plotnix.com>
> > To: "Ovidiu Predescu" <ov...@apache.org>; "Ivelin Ivanov"
> > <iv...@apache.org>
> > Cc: <co...@xml.apache.org>
> > Sent: Saturday, April 27, 2002 11:46 PM
> > Subject: Re: [jxpath] CompiledExpression [was: New features, bug fixes
and
> > documentation]
> >
> >
> > > Ovidiu,
> > >
> > > I have added to JXPath the explicit caching you proposed in your
earlier
> > > submission:
> > >
> > > [... snip...]
> > >
> > > > > >
> > > > > > > I've got a small suggestion for an optimization, if
> > > > > > > you don't mind. In
> > > > > > > the implementation I have, 0.1-dev from Jakarta's
> > > > > > > CVS, I noticed
> > > > > > > there's no way to compile an XPath, before using it.
> > > > > > > Having a way to
> > > > > > > compile the XPaths to be used later, would
> > > > > > > considerably improve the
> > > > > > > performance in repeated operations.
> > > > > > >
> > > > > > > E.g. right now you have something like this:
> > > > > > >
> > > > > > > Object bean = ...;
> > > > > > > JPathContext context =
> > > > > > > JPathContext.newContext(bean);
> > > > > > > context.getValue("some XPath");
> > > > > > >
> > > > > > > I'd like to also have the ability to do:
> > > > > > >
> > > > > > > Object bean = ...;
> > > > > > > JPathContext context =
> > > > > > > JPathContext.newContext(bean);
> > > > > > > XPathObject xpath = new XPathObject("some XPath");
> > > > > > > context.getValue(xpath);
> > > > > > >
> > > > > > > With this approach, I can setup a dictionary of
> > > > > > > already compiled XPath
> > > > > > > expressions, and use compiled XPaths, instead of
> > > > > > > having Xalan
> > > > > > > interpret the XPath all the time.
> > > > > > >
> > > > > > > Last time I checked, Xalan did have the ability to
> > > > > > > precompile XPaths
> > > > > > > in its internal format, so maybe this is easy to
> > > > > > > achieve.
> > > > > > Actually JXPath is already doing something like that
> > > > > > transparently to you. It maintains a static soft cache
> > > > > > of parse trees (which are that internal representation
> > > > > > you are talking about). The reason I am using soft
> > > > > > cache as opposed to a regular map is that some
> > > > > > applications will generate XPaths dynamically, in
> > > > > > which case the size of the cache has a chance of going
> > > > > > through the roof. The soft cache is cleared by
> > > > > > garbage collector, which removes the possibility of
> > > > > > running out of memory.
> > > > > >
> > > > > > I have been thinking about improving that mechanism a
> > > > > > little bit. I now want to have a regular map of a
> > > > > > limited size in addition to the soft cache.
> > > > > > Everything that spills over the hard cache will still
> > > > > > be stored in the soft cache. I think that will cover
> > > > > > the 90% case.
> > >
> > > I now see the need for caching external to JXPath: you may want to
> > > precompile some expression at application start time, you may want to
> > check
> > > syntax before you use an expression etc.
> > >
> > > I called "XPathObject" "CompiledExpression". You make an explicit
call:
> > > context.compile(xpath) to get a CompiledExpression. That method will
in
> > > fact check the internal cache before it proceeds with the compilation.
> > >
> > > Thanks again for the suggestion,
> > >
> > > Regards,
> > > - Dmitri
> > >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [jxpath] CompiledExpression [was: New features, bug fixes and documentation]
Posted by Dmitri Plotnikov <dm...@plotnix.com>.
Ivelin,
> So how does the CompiledExpression differ from a JXPointer?
>
> When I needed to cache a dictionary of paths I dused a Map.Entry where the
> key is the path string (JXPointer.asPath() )and
> the value is a JXPointer (which has the getValue() setValue() methods).
CompiledExpression is the result of the _compilation_ of an XPath, while
Pointer is the result of an _evaluation_ of an XPath, augmented with
information about where that value was found.
For example, let's say your xpath looks like this: "//person[@name = 'John
Doe']/phone". The corresponding Pointer.toString() may yield something like
"/addressBook/people/person[13]/phone".
When you call Pointer.getValue(), it does not reevaluate the path - just
gives you the result. Also you can say Pointer.setValue("5551234") and does
not reevaluate the path - just changes the corresponding value.
Regards,
- Dmitri
> ----- Original Message -----
> From: "Dmitri Plotnikov" <dm...@plotnix.com>
> To: "Ovidiu Predescu" <ov...@apache.org>; "Ivelin Ivanov"
> <iv...@apache.org>
> Cc: <co...@xml.apache.org>
> Sent: Saturday, April 27, 2002 11:46 PM
> Subject: Re: [jxpath] CompiledExpression [was: New features, bug fixes and
> documentation]
>
>
> > Ovidiu,
> >
> > I have added to JXPath the explicit caching you proposed in your earlier
> > submission:
> >
> > [... snip...]
> >
> > > > >
> > > > > > I've got a small suggestion for an optimization, if
> > > > > > you don't mind. In
> > > > > > the implementation I have, 0.1-dev from Jakarta's
> > > > > > CVS, I noticed
> > > > > > there's no way to compile an XPath, before using it.
> > > > > > Having a way to
> > > > > > compile the XPaths to be used later, would
> > > > > > considerably improve the
> > > > > > performance in repeated operations.
> > > > > >
> > > > > > E.g. right now you have something like this:
> > > > > >
> > > > > > Object bean = ...;
> > > > > > JPathContext context =
> > > > > > JPathContext.newContext(bean);
> > > > > > context.getValue("some XPath");
> > > > > >
> > > > > > I'd like to also have the ability to do:
> > > > > >
> > > > > > Object bean = ...;
> > > > > > JPathContext context =
> > > > > > JPathContext.newContext(bean);
> > > > > > XPathObject xpath = new XPathObject("some XPath");
> > > > > > context.getValue(xpath);
> > > > > >
> > > > > > With this approach, I can setup a dictionary of
> > > > > > already compiled XPath
> > > > > > expressions, and use compiled XPaths, instead of
> > > > > > having Xalan
> > > > > > interpret the XPath all the time.
> > > > > >
> > > > > > Last time I checked, Xalan did have the ability to
> > > > > > precompile XPaths
> > > > > > in its internal format, so maybe this is easy to
> > > > > > achieve.
> > > > > Actually JXPath is already doing something like that
> > > > > transparently to you. It maintains a static soft cache
> > > > > of parse trees (which are that internal representation
> > > > > you are talking about). The reason I am using soft
> > > > > cache as opposed to a regular map is that some
> > > > > applications will generate XPaths dynamically, in
> > > > > which case the size of the cache has a chance of going
> > > > > through the roof. The soft cache is cleared by
> > > > > garbage collector, which removes the possibility of
> > > > > running out of memory.
> > > > >
> > > > > I have been thinking about improving that mechanism a
> > > > > little bit. I now want to have a regular map of a
> > > > > limited size in addition to the soft cache.
> > > > > Everything that spills over the hard cache will still
> > > > > be stored in the soft cache. I think that will cover
> > > > > the 90% case.
> >
> > I now see the need for caching external to JXPath: you may want to
> > precompile some expression at application start time, you may want to
> check
> > syntax before you use an expression etc.
> >
> > I called "XPathObject" "CompiledExpression". You make an explicit call:
> > context.compile(xpath) to get a CompiledExpression. That method will in
> > fact check the internal cache before it proceeds with the compilation.
> >
> > Thanks again for the suggestion,
> >
> > Regards,
> > - Dmitri
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [jxpath] CompiledExpression [was: New features, bug fixes and documentation]
Posted by Ivelin Ivanov <iv...@apache.org>.
So how does the CompiledExpression differ from a JXPointer?
When I needed to cache a dictionary of paths I dused a Map.Entry where the
key is the path string (JXPointer.asPath() )and
the value is a JXPointer (which has the getValue() setValue() methods).
----- Original Message -----
From: "Dmitri Plotnikov" <dm...@plotnix.com>
To: "Ovidiu Predescu" <ov...@apache.org>; "Ivelin Ivanov"
<iv...@apache.org>
Cc: <co...@xml.apache.org>
Sent: Saturday, April 27, 2002 11:46 PM
Subject: Re: [jxpath] CompiledExpression [was: New features, bug fixes and
documentation]
> Ovidiu,
>
> I have added to JXPath the explicit caching you proposed in your earlier
> submission:
>
> [... snip...]
>
> > > >
> > > > > I've got a small suggestion for an optimization, if
> > > > > you don't mind. In
> > > > > the implementation I have, 0.1-dev from Jakarta's
> > > > > CVS, I noticed
> > > > > there's no way to compile an XPath, before using it.
> > > > > Having a way to
> > > > > compile the XPaths to be used later, would
> > > > > considerably improve the
> > > > > performance in repeated operations.
> > > > >
> > > > > E.g. right now you have something like this:
> > > > >
> > > > > Object bean = ...;
> > > > > JPathContext context =
> > > > > JPathContext.newContext(bean);
> > > > > context.getValue("some XPath");
> > > > >
> > > > > I'd like to also have the ability to do:
> > > > >
> > > > > Object bean = ...;
> > > > > JPathContext context =
> > > > > JPathContext.newContext(bean);
> > > > > XPathObject xpath = new XPathObject("some XPath");
> > > > > context.getValue(xpath);
> > > > >
> > > > > With this approach, I can setup a dictionary of
> > > > > already compiled XPath
> > > > > expressions, and use compiled XPaths, instead of
> > > > > having Xalan
> > > > > interpret the XPath all the time.
> > > > >
> > > > > Last time I checked, Xalan did have the ability to
> > > > > precompile XPaths
> > > > > in its internal format, so maybe this is easy to
> > > > > achieve.
> > > > Actually JXPath is already doing something like that
> > > > transparently to you. It maintains a static soft cache
> > > > of parse trees (which are that internal representation
> > > > you are talking about). The reason I am using soft
> > > > cache as opposed to a regular map is that some
> > > > applications will generate XPaths dynamically, in
> > > > which case the size of the cache has a chance of going
> > > > through the roof. The soft cache is cleared by
> > > > garbage collector, which removes the possibility of
> > > > running out of memory.
> > > >
> > > > I have been thinking about improving that mechanism a
> > > > little bit. I now want to have a regular map of a
> > > > limited size in addition to the soft cache.
> > > > Everything that spills over the hard cache will still
> > > > be stored in the soft cache. I think that will cover
> > > > the 90% case.
>
> I now see the need for caching external to JXPath: you may want to
> precompile some expression at application start time, you may want to
check
> syntax before you use an expression etc.
>
> I called "XPathObject" "CompiledExpression". You make an explicit call:
> context.compile(xpath) to get a CompiledExpression. That method will in
> fact check the internal cache before it proceeds with the compilation.
>
> Thanks again for the suggestion,
>
> Regards,
> - Dmitri
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org