Details
-
Improvement
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
1.0 Final
-
None
-
None
-
Operating System: All
Platform: All
-
8924
Description
The reason for this is to allow CompiledExpression objects to be created outside
the context of any bean.
Attached is a refresher conversation I had with Dmitri.
Greetings,
Ovidiu
The compilation process itself does not require a context at all. The
only reason the context is involved is that JXPathContext is an
abstract class that allows multiple implementations of JXPath. The
actual implementation, along with the compiler is found dynamically.
I ran into this issue myself when I was writing a Jex-JXPath adapter
(see http://www.plotnix.com/jex/index.html). There I simply created a
static context with null for a context node and was using it for all
compilations.
I'll add a newContext method without parameters. For that matter I
don't see what would be wrong with an explicit setRootObject(...)
method. I'll add that too.
Could you submit this to Bugzilla so we could track it?
Thanks,
- Dmitri
— Ovidiu Predescu <ovidiu@cup.hp.com> wrote:
>
> Hi Dmitri,
>
> I've finally managed to update my code to use your latest 1.0b1
> release of JXPath: really good stuff, and the documentation is very
> nice! Thanks a lot for the hard work you put in this, it's really
> great!
>
> I encountered one small problem with the API. In order to obtain
> CompiledExpression, I need to create a JXPathContext. I want to
> compile the XPath expressions and assign them to some instance
> variables of a class, before I actually use them in my methods. There
> doesn't seem to be a way however to obtain the compiled
> representation
> without providing a bean when creating the context. So the current
> code I have reads like this:
>
> JXPathContext jxpathContext = JXPathContext.newContext(new
> Object());
> CompiledExpression jxpath_a = jxpathContext.compile("a");
>
> jxpath_a.getValue(someJXPathContext);
>
> Would it be possible to eliminate the need to pass a bean context in
> newContext()? I think the API for compiled expressions would be a bit
> cleaner. I can live with it as it is, no problem, it's just that
> would
> be cleaner this way.