RE: Selecting XML Parsers

[Jim Fuller]

> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: 30 December 2003 13:25
> To: [EMAIL PROTECTED]
> Subject: Selecting XML Parsers
> 
> 
> I am having a very hard time porting my build to 1.6.0.
> I would like to get some input on how I should address my problem,
> not sure if it is my problem or ANTs.
> 
> I need to use Saxon for some of my XSLT transformations, since I am
> using
> specific features of it. However, Saxon comes with Aelfred XML parser
> which
> is non-validating. Which means that  and  for
> example
> cannot use them.
> 
> In 1.5.x I solved this situation by having Saxon.jar outside of
ant/lib
> and passing it to  in the classpath. That does not seem to
work
> in 1.6.0 since  only uses the classpath to find the the Liason
> but the TRAX liason does not uses it to find the factories.
> 
> If I put Saxon.jar in ant/lib. All tasks will start using Aelfred
parser
> and will break. Even tasks that specify a classpath, they do not use
it
> to find the parsers.
> 
> The main issue here seem to be that non of our tasks set the
> ContextClassLoader
> before calling the methods on the xml-apis. If the context classloader
> where set, one could control on a task by task basis what parsers,
> transformers,
> etc, to use. I think the basic problem is in JAXPUtils where non of
the
> methods
> allow passing a classloader. Had the methods allow a classloader, then
> they could
> have set the contextclassloader appropriatelly, before calling the
> XMLAPI library.
[Jim Fuller] 

Since v7.1 Saxon is not bound to Aelfred xml parser, and doesn't ship
with it, Saxon will use by default JVM parser if Aelfred is not on the
classpath...I am running v7.8 saxon with v1.6.0 Ant with no probs, so
not so sure that ContextClassLoader is the issue.

M. Kay most recent code is usually very stable, at least near production
quality and I have been using 7.1 and up with no probs with respect to
XSLT...though there are issues with XSLT 2.0 and the nascent XQUERY
implementation. 

What version of Saxon are you using ?

Cheers, Jim Fuller


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25394] - OutofMemory when running lots of

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25394

OutofMemory when running lots of 

RE: XML Namespace avoids collision between xml vocabularies was RE: a comment about xml namespace

[didge]

> -Original Message-
> From: Steve Loughran [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 30, 2003 3:48 PM
> To: Ant Developers List
> Subject: Re: XML Namespace avoids collision between xml vocabularies was
> RE: a comment about xml namespace
>
>
> Jim Fuller wrote:
> >>From: Steve Loughran [mailto:[EMAIL PROTECTED]
> >>Sent: 29 December 2003 17:59
> >>Subject: Re: XML Namespace avoids collision between xml vocabularies
> >
> > was
> >
> >>RE: a comment about xml namespace
> >>If you are interested in this kind of thing, point your browser at
> >>http://1060.org and d/l a build of NetKernel -preferably 2.1 when it
> >>ships shortly. This is definitely a generic XML processor engine which
> >>does plenty much magic, like (in v2.1) autobinding a database select
> >
> > to
> >
> >>an XML document for later xformation.
> >
> >
> > [Jim Fuller] interesting, will have a look...
> >
>
> yes, worth a play.
>
> On an ant topic, they have an alternate dependency model, one not that
> suited to a generic build process, but ideal for an XML engine.
>
> Here is where we are today:
>
> Ant: leave everything to the tasks
> Make: declare everything
> msbuild: declare everything (I think)
>
> NetKernel code consists of a set of instructions, all with a standard
> syntax for operands and results, with different XML in the operand
> field. The engine takes the operands and concatenates that with the
> operator and constructs a URI that describes the operation.
>
> e.g. here is me applying xtidy to some generated code:
>  
>  XHTMLTidy
>  this:response
>  
>  /results/row/details
>  
>  var:tidied_details
>  
>
> The cool thing is that the contents of every operation are cached;
> stored in the cache relative to the URI in. Which means that next time
> the command is executed, if the inputs havent changed, the cached result
> is returned instead.
>
> So the SQL query used to generate the XML to tidy up is just stuck in in
> front, with the runtime handling all the details of pooling, database to
> xml binding and choosing when to run stuff:
>  
>  stm
>  
>  
>  http://1060.org/stm";>
>  
>  SELECT *
>  from col
>  where col.colID= xpath="substring-after(/uri , ':')"/>
>  ;
>  
>  
>  
>  var:col
>  var:sql
>  
>  
> Col
>   var:sql
>   
>  sqlQuery
>  
>   this:response
>  
>
> Of course, there is a problem: what if another operation has side
> effects, like a SQL update. That is where you need to create pseudo
> dependencies that sequences say they depend on; other things can touch
> these to mark them out of date.
>
> The nice thing about this model is that there is a single engine
> managing caching across all the threads working away, and it caches the
> intermediate stuff, with various controls to choose when stuff expires
> (different stuff can be marked as more important, so a big db query is
> cached above some little xslt operation).
>
> Like I said, I dont see it applying to Ant, but it shows an alternate
> world view in the XML-workflow-language space, at least for a workflow
> focused on a server handling requests, doing things and sending the
> results back.
>
>
> >
> > [Jim Fuller] uhhh, I just want an xml document to be used by multiple
> > processors, not have Ant *be* the generic processor. I always assume
> > that data lives longer then the applications that generate or manipulate
> > themoh well as I said, I will leave this thread asis, for the time
> > being. I need to spend a few days looking at Ant internals, before I
> > comment any further.
>
> Ok, that is all right then.
>
> Maybe we should have
>
> 1. an  type; takes generic XML.
>
> 2. an  type, that takes generic XML with an ID that you can
> refer to later. So any task that wants to use XML inline, can share the
> data.
>
> Thoughts? And yes, I know (1) and (2) are nearly identical. But (1)
> could discard all internal sax events.
>
> -steve
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25832] - [PATCH] Do not define twice

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25832

[PATCH] Do not define  twice





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 11:23 ---
Task names are case sensitive so one cannot
remove one of these.
There is actually one other that is defined
twice - style and xslt.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ScriptDef revisited

[Peter Reilly]

You could try playing with beanshelldef
http://marc.theaimsgroup.com/?l=ant-dev&m=106577547220771&w=2
Peter
Jose Alberto Fernandez wrote:
Hi,
my current struggle with  and beanshell, made me notice how
inefficient
or script task is (i.e., on every execution the script is recompiled,
and executed).
Although there is no other way for  it would be nice is

could do something more efficient. Currently  will recompile
the
src on every invocation of the defined script.
It would be nice if we could somehow cache the already parsed source,
and
being able to reexecute it multiple times with different element and
attribute
instances on each execution. So, to treat it a little more like compiled
code.
The way I see it, such a script definition would specify an expression
entrypoint
that can be called over and over. Something like:

  
  void executeScript() {
print (attributes.get("att1"));
  }

The execute attribute indicates the expression to be evaluated
on each  instance, and it also indicates that it is safe
to keep the compiled source (i.e., bsf engine object around).
Notice that it may not be thread-safe to do this since the engine
is statefull. hu
So, what do people think?
Jose Alberto


 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25826] - ejbjar NullPointer Exception

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25826

ejbjar NullPointer Exception





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 12:32 ---
This is stange, you do not seem to be setting the
destdir attribute on the  task.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory utilization on ANT 1.6.0

[Peter Reilly]

The reason the refernces to created tasks is an accidental consequence
of the implementation of UnknownElement and RuntimeConfigurable.
It is difficult to remove the reference without telling UnknownElement
in Target#execute and Seqential#execute that the reference can be
removed.
Peter
Jose Alberto Fernandez wrote:
I think the two ways of reusing tasks that you point below
are fair usage, however that do not answer my question about
.
For the issue of reusability itself, let me point how I think it
should work on the cases you mentioned:
(1) If one IDs a task, we are really setting the ID on the 
UnknownObject(?) since we cannot resolve it at parsing time.
So when a script accesses the reference the resolution process
will create the actual task instance. As long as the script keeps
the actual task, well it will not be reclaimed. But if the 
reference is acessed on the project instance again, then you should get
a new task (i.e., UnknownObject should not keep internal references, 
it should be stateless).

(2) If your java task creates another task directly and uses it,
well it is upto you to make sure you dispose of it when you are
finish with it (i.e., do not keep it in some static table forever),
whether a task is design to be executed multiple times or not
is part of the task behaviour and is a separate issue.
My point is that ANT itself should not be keeping around
objects that it will not access again. I guess I am suggesting
to stop having resolved tasks and unresolve UnknownObjects as part
of the project tree, and instead have UnknownObjects all across.
It is really our DOM tree after all. 

 

From: Dominique Devienne [mailto:[EMAIL PROTECTED] 

I can see two ways for a task to be reused:
1) thru the controversial use of IDs on tasks,
  which can then be executed by 

DO NOT REPLY [Bug 25826] - ejbjar NullPointer Exception

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25826

ejbjar NullPointer Exception





--- Additional Comments From [EMAIL PROTECTED]  2003-12-31 20:46 ---
Yeah, and I managed to get it working if I add the destdir.  However, the docs 
state that it isn't 
necessary if you use at  element which contains the destdir.   I guess 
it is required in both 
places now.

Here's what the docs say regarding destdir in the ejbjar element:  

Note that this attribute is only used if the task is generating generic jars 
(i.e. no vendor-specific 
deployment elements have been specified).

See:  http://ant.apache.org/manual/OptionalTasks/ejb.html#ejbjar

Either way, a NullPointerException should not occur, but rather an error 
message explaining what's 
missing.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]