You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@juntadeandalucia.es> on 2008/09/05 14:59:51 UTC
Dispatcher 1.0 - towards a stable version
Hi all,
I will have some time in the next week to enhance the performance of the
dispatcher. The performance always have been the Achilles’ heel of the
dispatcher.
Another week point was/is the readability of the code. The StAX
experiment I conducted a while ago is far easier to read. The missing
part is the integration with cocoon. This however can be done easily
with a transformerWrapper class that will call the StAX implementation
and execute the work with the StAX components.
Another thing that I always wanted to integrate are java based
contracts. I want to allow within the next version of the dispatcher
that one can use a class instead of a xsl.
Since future version of cocoon are based on Spring and I am really
appreciate Spring as an excellent IoC container the dispatcher will be
as well based it.
My plan is that this work will be compatible with the current version of
the dispatcher. It will provide simple shell scripts to update the
current version of structurer/contracts to the new form. I do not like
the specific extension we have for structurer (.fv)/contracts (.ft)
anymore since they are historic and do not reflect anymore the reality.
To remember ft stands for forrestTemplate and fv for forrestView which
is the first names of contracts and structurer.
Instead I suggest *.contracts.xml and *.structurer.xml.
My initial plan is to reuse the code from whiteboard/dispatcher, conduct
the needed changes to work with java contracts and add spring support.
Any thoughts.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Dispatcher 1.0 - towards a stable version
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Thorsten Scherler wrote:
>> My initial plan is to reuse the code from whiteboard/dispatcher, conduct
>> the needed changes to work with java contracts and add spring support.
>>
>> Any thoughts.
>
> When we all talk about "Dispatcher" i thought that we were
> talking about the whiteboard/plugins/o.a.f.plugin.internal.dispatcher
> That is what i use and what the zone demos use.
I missed that nuance. Thanks for picking it up David.
All my comments were targtetted at getting the dispatch plugins into core.
In particular, my one about "lets finish one feature before starting the
next".
Ross
Re: Dispatcher 1.0 - towards a stable version
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Mon, 2008-09-08 at 08:59 +0200, Thorsten Scherler wrote:
> On Sat, 2008-09-06 at 11:14 +1000, David Crossley wrote:
> > ...
> > I have never understood what the whiteboard/dispatcher code
> > is for.
>
> It is the same idea and principals behind it but differently implemented
> - more efficient. My idea is to create a clean java implementation that
> can be used standalone and with a wrapper classes in cocoon.
A reminder to myself and other that may want to help. The wrapper is
basically a cocoon transformer that stores the sax events and on the end
invokes the StAX component with it.
Apache Tuscany has some adapters but non that dos sax2stax.
https://svn.apache.org/repos/asf/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tuscany/sca/databinding/xml/
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Dispatcher 1.0 - towards a stable version
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
> David Crossley wrote:
> >
> > There is a big concern that i should have raised before.
> > You have made the STAX jar a dependency, and your
> > whiteboard/dispatcher/README.txt mentions license issues.
>
> Only to include it directly (as add a copy to the lib dir). It is
> included in the 6.0 jdk but in 1.5 not.
>
> I thought about to add ivy support and let ivy resolve it the first
> time.
We are not to work around ASF license concerns,
but rather work within them. Using Maven or Ivy
does not absolve us.
See http://www.apache.org/legal/resolved.html
and the legal-discuss archives.
-David
> > Please see the legal-discuss mailing list over the last
> > couple of years. This has come up a few times, but sorry
> > i cannot recall the outcome.
> >
> > Also see the recent Board report from Apache XML Commons
> > and their recent mailing lists.
> > http://wiki.apache.org/xerces/August2008
> > They discussed that same problem and added an API
> > to xml-commons-external.
>
> I will have a look at this API rewrite and will preferable use that.
>
> Thanks for pointing out.
>
> salu2
> --
> Thorsten Scherler thorsten.at.apache.org
> Open Source Java consulting, training and solutions
>
Re: Dispatcher 1.0 - towards a stable version
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Sat, 2008-09-06 at 11:14 +1000, David Crossley wrote:
> Thorsten Scherler wrote:
> >
> > My initial plan is to reuse the code from whiteboard/dispatcher, conduct
> > the needed changes to work with java contracts and add spring support.
> >
> > Any thoughts.
>
> When we all talk about "Dispatcher" i thought that we were
> talking about the whiteboard/plugins/o.a.f.plugin.internal.dispatcher
> That is what i use and what the zone demos use.
>
> I have never understood what the whiteboard/dispatcher code
> is for.
It is the same idea and principals behind it but differently implemented
- more efficient. My idea is to create a clean java implementation that
can be used standalone and with a wrapper classes in cocoon.
>
> There is a big concern that i should have raised before.
> You have made the STAX jar a dependency, and your
> whiteboard/dispatcher/README.txt mentions license issues.
Only to include it directly (as add a copy to the lib dir). It is
included in the 6.0 jdk but in 1.5 not.
I thought about to add ivy support and let ivy resolve it the first
time.
> Please see the legal-discuss mailing list over the last
> couple of years. This has come up a few times, but sorry
> i cannot recall the outcome.
>
> Also see the recent Board report from Apache XML Commons
> and their recent mailing lists.
> http://wiki.apache.org/xerces/August2008
> They discussed that same problem and added an API
> to xml-commons-external.
I will have a look at this API rewrite and will preferable use that.
Thanks for pointing out.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Dispatcher 1.0 - towards a stable version
Posted by David Crossley <cr...@apache.org>.
Thorsten Scherler wrote:
>
> My initial plan is to reuse the code from whiteboard/dispatcher, conduct
> the needed changes to work with java contracts and add spring support.
>
> Any thoughts.
When we all talk about "Dispatcher" i thought that we were
talking about the whiteboard/plugins/o.a.f.plugin.internal.dispatcher
That is what i use and what the zone demos use.
I have never understood what the whiteboard/dispatcher code
is for.
There is a big concern that i should have raised before.
You have made the STAX jar a dependency, and your
whiteboard/dispatcher/README.txt mentions license issues.
Please see the legal-discuss mailing list over the last
couple of years. This has come up a few times, but sorry
i cannot recall the outcome.
Also see the recent Board report from Apache XML Commons
and their recent mailing lists.
http://wiki.apache.org/xerces/August2008
They discussed that same problem and added an API
to xml-commons-external.
-David
Re: xpath injection in contracts (was Re: Dispatcher 1.0 - towards
a stable version)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Fri, 2008-09-19 at 13:41 +0200, Thorsten Scherler wrote:
> On Fri, 2008-09-19 at 12:29 +0200, Thorsten Scherler wrote:
> > On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
> > > Hi all,
> > >
> > > I will have some time in the next week to enhance the performance of the
> > > dispatcher. The performance always have been the Achilles’ heel of the
> > > dispatcher.
> >
> > Regarding the implementation of the hook processing.
> >
> > There is a small downsides in the current implementation: the xpath
> > injection are NOT working well when the injection point is within the
> > main stream of the events.
>
> Some interesting links around the topic:
> http://www.idealliance.org/proceedings/xml04/papers/226/BuildingXPathFramework.html
> http://www.theserverside.com/discussions/thread.tss?thread_id=47577
> http://acs.lbl.gov/nux/
http://ws.apache.org/commons/axiom/OMTutorial.html
looks VERY promising to solve the problem.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: xpath injection in contracts (was Re: Dispatcher 1.0 - towards
a stable version)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Fri, 2008-09-19 at 12:29 +0200, Thorsten Scherler wrote:
> On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
> > Hi all,
> >
> > I will have some time in the next week to enhance the performance of the
> > dispatcher. The performance always have been the Achilles’ heel of the
> > dispatcher.
>
> Regarding the implementation of the hook processing.
>
> There is a small downsides in the current implementation: the xpath
> injection are NOT working well when the injection point is within the
> main stream of the events.
Some interesting links around the topic:
http://www.idealliance.org/proceedings/xml04/papers/226/BuildingXPathFramework.html
http://www.theserverside.com/discussions/thread.tss?thread_id=47577
http://acs.lbl.gov/nux/
salu2
>
> It is possible to inject e.g. to /html/head but injecting
> to /html/body/... will not inject the new events in the principal stream
> to the location that one w
> ould await. The main reason is that the generation of the result
> document is now as well based on StAX and not any more in DOM.
>
> However to have the same behavior as we have currently in the
> DispatcherTransformer I do not see any other possibility then using DOM
> again.
>
> Like with the xml properties I will make the usage configurable since I
> reckon in 90% of all cases the StAX based calculation is used. For the
> rest I am stil
> l investigating but it seems that DOM is the only possibility because
> every other possibility that me occur is imitating DOM.
>
> For the
> dispatcher/testing/org/apache/forrest/dispatcher/master.structurer.xml
> that I am using for testing I get:
> <?xml version='1.0' encoding='UTF-8'?>
> <html>
> <body>
>
> <!-- the normal stream of contract no xpath used in contract
> Using the xpath from structurer-->
>
> <hook id="example">
> Content going to the location defined by the structurer.
> $test-inline: position:hook/contract $test-inline-xml: No xml
> parameter has been passed
> <hook id="level2"> Content going to the location defined by the
> structurer. $test-inline: position:hook/hook/contract
> $test-inline-xml: No xml parameter has been passed</hook>
> </hook>
> Another test! $test-inline: xxx $test-inline-xml: No xml parameter
> has been passed
> </body>
>
> <!-- xpath injection but to a path not in structurer default path -->
>
> <head>
> <meta name="Description"
> content=" Content going to a fixed location defined by the
> contract (here: /html/head)." />
> <meta name="Description"
> content=" Content going to a fixed location defined by the
> contract (here: /html/head)." />
> <meta name="Description" content="m2 - another test" />
> </head>
>
> <!-- Injections from the contract to a specific xpath -->
> <body>
> <hook>
> <hook>
> <p>master-xxx</p>
> <p>master-xxx</p>
> </hook>
> </hook>
> </body>
> </html>
>
> Like you can see the 3 part is not in the desired nodes.
>
> To solve this, one need to localize the stream event that comes the
> closest to the xpath expression and then inject new events there.
>
> Somebody has an idea?
>
> Meanwhile I will add the DOM result creation as alternative.
>
> salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
xpath injection in contracts (was Re: Dispatcher 1.0 - towards a
stable version)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
> Hi all,
>
> I will have some time in the next week to enhance the performance of the
> dispatcher. The performance always have been the Achilles’ heel of the
> dispatcher.
Regarding the implementation of the hook processing.
There is a small downsides in the current implementation: the xpath
injection are NOT working well when the injection point is within the
main stream of the events.
It is possible to inject e.g. to /html/head but injecting
to /html/body/... will not inject the new events in the principal stream
to the location that one w
ould await. The main reason is that the generation of the result
document is now as well based on StAX and not any more in DOM.
However to have the same behavior as we have currently in the
DispatcherTransformer I do not see any other possibility then using DOM
again.
Like with the xml properties I will make the usage configurable since I
reckon in 90% of all cases the StAX based calculation is used. For the
rest I am stil
l investigating but it seems that DOM is the only possibility because
every other possibility that me occur is imitating DOM.
For the
dispatcher/testing/org/apache/forrest/dispatcher/master.structurer.xml
that I am using for testing I get:
<?xml version='1.0' encoding='UTF-8'?>
<html>
<body>
<!-- the normal stream of contract no xpath used in contract
Using the xpath from structurer-->
<hook id="example">
Content going to the location defined by the structurer.
$test-inline: position:hook/contract $test-inline-xml: No xml
parameter has been passed
<hook id="level2"> Content going to the location defined by the
structurer. $test-inline: position:hook/hook/contract
$test-inline-xml: No xml parameter has been passed</hook>
</hook>
Another test! $test-inline: xxx $test-inline-xml: No xml parameter
has been passed
</body>
<!-- xpath injection but to a path not in structurer default path -->
<head>
<meta name="Description"
content=" Content going to a fixed location defined by the
contract (here: /html/head)." />
<meta name="Description"
content=" Content going to a fixed location defined by the
contract (here: /html/head)." />
<meta name="Description" content="m2 - another test" />
</head>
<!-- Injections from the contract to a specific xpath -->
<body>
<hook>
<hook>
<p>master-xxx</p>
<p>master-xxx</p>
</hook>
</hook>
</body>
</html>
Like you can see the 3 part is not in the desired nodes.
To solve this, one need to localize the stream event that comes the
closest to the xpath expression and then inject new events there.
Somebody has an idea?
Meanwhile I will add the DOM result creation as alternative.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Dispatcher 1.0 - towards a stable version
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Fri, 2008-09-05 at 20:14 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Fri, 2008-09-05 at 14:51 +0100, Ross Gardler wrote:
> >> Thorsten Scherler wrote:
> >>> Hi all,
> >>>
> >>> I will have some time in the next week to enhance the performance of the
> >>> dispatcher. The performance always have been the Achilles’ heel of the
> >>> dispatcher.
> >> Actually, the achilles' heel is the lack of clarity in the documentation.
> >>
> >> This mail is an amazing coincidence. One of our team hear asked me this
> >> morning how to do something with the dispatcher. I've done it before and
> >> have sites running dispatcher, but I can't remember how I did it and I
> >> can't point to any documentation about it.
> >
> > How about
> > http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/
> >
> > I agree that documentation always can be enhanced but we have some.
>
> I didn't say there was no documentation I said there was a documentation
> problem.
Just wanted to link to the existing docu for the archive.
>
> Pointing to a resource that is unintelligible does not help.
>
> I've read those docs, even written some of them, but they make little
> sense to me and I have the background of Forrest. The individual I'm
> talking about has also read them and failed to achieve what he needs.
We need more examples and the corresponding how to's. We started but
sadly is has not been pursued.
> ...
> > Yes, I agree. I found a nice tool to create uml diagrams in javadocs:
> > UmlGraph. Have a look at the droids javadoc to see it in action.
>
> What about the horrible mess of redirection (indirection) between
> sitemap and locationmap. I've found it near to impossible to figure out
> what is coming from where in the dipatcher.
>
> I'm sure it doesn't need to be as complex as it is, but I can't figure
> out how to simplify it.
I started to drop some locationmaps a while ago but I reckon they can be
dropped some more. The matches in the sitemap should nearly go away
entirely after the rewrite.
> Perhaps an effort to document the flow will help make it understandable
> or illustrate where we can simplify.
The small part that should stay I will document. Actually a colleague of
mine needs to write a comprehensive documentation of the dispatcher - in
Spanish but maybe I can get him to translate it and submit it as patch.
> Again, I doubt I'm going to be able to do this myself, I'm just flagging
> areas for improvement - sine you ask ;-)
jeje, that is perfect. Thanks.
...
> It's still in whiteboard , therefore it is unfinished.
>
> I'm just saying we should get a usable version out there that people can
> use (normal people, not just those with years of Forrest history) and
> then start adding new features.
Agreed.
>
> > Cheers Ross for your feedback.
>
> You're welcome. I know your big enough to pick and choose the most
> important bits, rather than think I'm demanding the world (although if
> you want to deliver the world...)
lol
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Dispatcher 1.0 - towards a stable version
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2008-09-05 at 14:51 +0100, Ross Gardler wrote:
>> Thorsten Scherler wrote:
>>> Hi all,
>>>
>>> I will have some time in the next week to enhance the performance of the
>>> dispatcher. The performance always have been the Achilles’ heel of the
>>> dispatcher.
>> Actually, the achilles' heel is the lack of clarity in the documentation.
>>
>> This mail is an amazing coincidence. One of our team hear asked me this
>> morning how to do something with the dispatcher. I've done it before and
>> have sites running dispatcher, but I can't remember how I did it and I
>> can't point to any documentation about it.
>
> How about
> http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/
>
> I agree that documentation always can be enhanced but we have some.
I didn't say there was no documentation I said there was a documentation
problem.
Pointing to a resource that is unintelligible does not help.
I've read those docs, even written some of them, but they make little
sense to me and I have the background of Forrest. The individual I'm
talking about has also read them and failed to achieve what he needs.
(and yes I have directed him to the lists - he'll turn up soon I'm sure
- but this is a low priority project for us so time is not on our side)
...
> I totally agree that the next version should be documented in more
> detail. I promise I will write as much javadocs as possible and we
> should review above linked documentation and see how we can be more
> clear about it.
Excellent - thank you.
Of course, I should help myself, but I don't have the time. I only
mention it because you asked for opinion.
>>> Another week point was/is the readability of the code.
>> Indeed, this is part of the documentation.
>
> Yes, I agree. I found a nice tool to create uml diagrams in javadocs:
> UmlGraph. Have a look at the droids javadoc to see it in action.
What about the horrible mess of redirection (indirection) between
sitemap and locationmap. I've found it near to impossible to figure out
what is coming from where in the dipatcher.
I'm sure it doesn't need to be as complex as it is, but I can't figure
out how to simplify it.
Perhaps an effort to document the flow will help make it understandable
or illustrate where we can simplify.
Again, I doubt I'm going to be able to do this myself, I'm just flagging
areas for improvement - sine you ask ;-)
>
> e.g.
> http://people.apache.org/~thorsten/droids/api/org/apache/droids/api/Droid.html
I'll have to take a look at UMLGraph - thanks.
>>> Another thing that I always wanted to integrate are java based
>>> contracts. I want to allow within the next version of the dispatcher
>>> that one can use a class instead of a xsl.
>> How about we finish one feature before adding another?
>
> Which feature is unfinished? I have more or less a week for the rewrite
> and yes I will first concentrate on implementing everything we have till
> now in a clean efficient way and then if time allows at the java
> contract support.
Dispathcer.
It's still in whiteboard , therefore it is unfinished.
I'm just saying we should get a usable version out there that people can
use (normal people, not just those with years of Forrest history) and
then start adding new features.
> Cheers Ross for your feedback.
You're welcome. I know your big enough to pick and choose the most
important bits, rather than think I'm demanding the world (although if
you want to deliver the world...)
Ross
Re: Dispatcher 1.0 - towards a stable version
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2008-09-05 at 14:51 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > Hi all,
> >
> > I will have some time in the next week to enhance the performance of the
> > dispatcher. The performance always have been the Achilles’ heel of the
> > dispatcher.
>
> Actually, the achilles' heel is the lack of clarity in the documentation.
>
> This mail is an amazing coincidence. One of our team hear asked me this
> morning how to do something with the dispatcher. I've done it before and
> have sites running dispatcher, but I can't remember how I did it and I
> can't point to any documentation about it.
How about
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/
I agree that documentation always can be enhanced but we have some.
>
> In many cases this will mean that the dispatcher is not used and a
> potential contributor is lost.
>
> Performance is irrelevant if there are no users.
Agree but actually there are a couple of user, here on the list and
people that are not actively participating on this list. Feedback from
those that uses the dispatcher is that performance have to be enhanced.
I totally agree that the next version should be documented in more
detail. I promise I will write as much javadocs as possible and we
should review above linked documentation and see how we can be more
clear about it.
>
> > Another week point was/is the readability of the code.
>
> Indeed, this is part of the documentation.
Yes, I agree. I found a nice tool to create uml diagrams in javadocs:
UmlGraph. Have a look at the droids javadoc to see it in action.
e.g.
http://people.apache.org/~thorsten/droids/api/org/apache/droids/api/Droid.html
>
> > Another thing that I always wanted to integrate are java based
> > contracts. I want to allow within the next version of the dispatcher
> > that one can use a class instead of a xsl.
>
> How about we finish one feature before adding another?
Which feature is unfinished? I have more or less a week for the rewrite
and yes I will first concentrate on implementing everything we have till
now in a clean efficient way and then if time allows at the java
contract support.
...
>
> > My initial plan is to reuse the code from whiteboard/dispatcher, conduct
> > the needed changes to work with java contracts and add spring support.
> >
> > Any thoughts.
>
> Documentation. Documentation and, er, documentation.
>
> Other than that go for it!
>
> Ross
Cheers Ross for your feedback.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Dispatcher 1.0 - towards a stable version
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> Hi all,
>
> I will have some time in the next week to enhance the performance of the
> dispatcher. The performance always have been the Achilles’ heel of the
> dispatcher.
Actually, the achilles' heel is the lack of clarity in the documentation.
This mail is an amazing coincidence. One of our team hear asked me this
morning how to do something with the dispatcher. I've done it before and
have sites running dispatcher, but I can't remember how I did it and I
can't point to any documentation about it.
In many cases this will mean that the dispatcher is not used and a
potential contributor is lost.
Performance is irrelevant if there are no users.
> Another week point was/is the readability of the code.
Indeed, this is part of the documentation.
> Another thing that I always wanted to integrate are java based
> contracts. I want to allow within the next version of the dispatcher
> that one can use a class instead of a xsl.
How about we finish one feature before adding another?
> Since future version of cocoon are based on Spring and I am really
> appreciate Spring as an excellent IoC container the dispatcher will be
> as well based it.
+1
> My plan is that this work will be compatible with the current version of
> the dispatcher. It will provide simple shell scripts to update the
> current version of structurer/contracts to the new form. I do not like
> the specific extension we have for structurer (.fv)/contracts (.ft)
> anymore since they are historic and do not reflect anymore the reality.
> To remember ft stands for forrestTemplate and fv for forrestView which
> is the first names of contracts and structurer.
>
> Instead I suggest *.contracts.xml and *.structurer.xml.
Fine.
> My initial plan is to reuse the code from whiteboard/dispatcher, conduct
> the needed changes to work with java contracts and add spring support.
>
> Any thoughts.
Documentation. Documentation and, er, documentation.
Other than that go for it!
Ross
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a stable
version)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2008-09-10 at 10:10 +0100, Ross Gardler wrote:
>> Thorsten Scherler wrote:
>>> On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
>> ...
>>
>>> The first solution is fast to implement and seems quite clean. The
>>> downside is that we cannot use xml anymore. Which actually IMO is not
>>> that bad since maybe we start to use the actual forrest.properties.xml
>>> to configure contracts.
>>>
>>> The second solution is more complicated to implement since the
>>> aggregation has to be done in the DispatcherTransformer which does not
>>> feel right but we could use xml in the properties.
>>>
>>> Personally the cleaner solution is 1 but that would break downward
>>> compatible by a couple of contracts.
>>>
>>> WDYT?
>> I haven't thought long and hard about this. I'm going on your assessment
>> and my gut reaction.
>>
>> I'd say go for option 1 because:
>>
>> a) I like that it brings more configuration into the new properties system
>>
>> b) you said it is easier to implement
>>
>> c) we currently have no use case for using XML in the properties
>>
>> d) if we find a use case for XML we can deal with it at that point (and
>> maybe implement the second solution by adapting the properties system to
>> allow XML)
>>
>
> To not break downward compatibility I will implement the option 1 but
> with a flag "allowXmlProperties". I added the javadoc that setting this
> properties to true will be paid by performance but this let our current
> dispatcher user decide when to update their contracts and structurer.
>
Perfect.
Ross
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a
stable version)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Wed, 2008-09-10 at 10:10 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
>
> ...
>
> > The first solution is fast to implement and seems quite clean. The
> > downside is that we cannot use xml anymore. Which actually IMO is not
> > that bad since maybe we start to use the actual forrest.properties.xml
> > to configure contracts.
> >
> > The second solution is more complicated to implement since the
> > aggregation has to be done in the DispatcherTransformer which does not
> > feel right but we could use xml in the properties.
> >
> > Personally the cleaner solution is 1 but that would break downward
> > compatible by a couple of contracts.
> >
> > WDYT?
>
> I haven't thought long and hard about this. I'm going on your assessment
> and my gut reaction.
>
> I'd say go for option 1 because:
>
> a) I like that it brings more configuration into the new properties system
>
> b) you said it is easier to implement
>
> c) we currently have no use case for using XML in the properties
>
> d) if we find a use case for XML we can deal with it at that point (and
> maybe implement the second solution by adapting the properties system to
> allow XML)
>
To not break downward compatibility I will implement the option 1 but
with a flag "allowXmlProperties". I added the javadoc that setting this
properties to true will be paid by performance but this let our current
dispatcher user decide when to update their contracts and structurer.
Thanks for your feedback, Ross.
salu2
> Ross
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Properties for contract (was Re: Dispatcher 1.0 - towards a stable
version)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
...
> The first solution is fast to implement and seems quite clean. The
> downside is that we cannot use xml anymore. Which actually IMO is not
> that bad since maybe we start to use the actual forrest.properties.xml
> to configure contracts.
>
> The second solution is more complicated to implement since the
> aggregation has to be done in the DispatcherTransformer which does not
> feel right but we could use xml in the properties.
>
> Personally the cleaner solution is 1 but that would break downward
> compatible by a couple of contracts.
>
> WDYT?
I haven't thought long and hard about this. I'm going on your assessment
and my gut reaction.
I'd say go for option 1 because:
a) I like that it brings more configuration into the new properties system
b) you said it is easier to implement
c) we currently have no use case for using XML in the properties
d) if we find a use case for XML we can deal with it at that point (and
maybe implement the second solution by adapting the properties system to
allow XML)
Ross
Properties for contract (was Re: Dispatcher 1.0 - towards a stable
version)
Posted by Thorsten Scherler <th...@juntadeandalucia.es>.
On Fri, 2008-09-05 at 14:59 +0200, Thorsten Scherler wrote:
> Hi all,
>
> I will have some time in the next week to enhance the performance of the
> dispatcher. The performance always have been the Achilles’ heel of the
> dispatcher.
One thing that I identify as performance killer is described in [1].
The properties that we pass to the contract are passed as parameter. It
seems this is only possible as org.w3c.dom.Document which is a big
downer.
I sees various workaround to the problem:
1) Not allow custom xml for the contract properties in the structurer
but only Strings (much we have in forrest.properties.xml). Then passing
the string to the xsl.
Same is valid for the whole forrest.properties.xml that we as well pass
to every contract as param. Instead passing the whole file it makes
sense to just pass the key and the value to the xsl transformation.
2) Aggregate the properties to the dataUri outcome and not pass
parameter at all to the transformation. The result would look something
like:
<content>
<dataUri>
<!-- result of the dataUri -->
</dataUri>
<structurerProperties>
<!-- properties defined in the strucutrer for this contract -->
</structurerProperties>
<properties>
<!-- forrest.properties.xml -->
</properties>
</content>
The first solution is fast to implement and seems quite clean. The
downside is that we cannot use xml anymore. Which actually IMO is not
that bad since maybe we start to use the actual forrest.properties.xml
to configure contracts.
The second solution is more complicated to implement since the
aggregation has to be done in the DispatcherTransformer which does not
feel right but we could use xml in the properties.
Personally the cleaner solution is 1 but that would break downward
compatible by a couple of contracts.
WDYT?
salu2
[1] http://marc.info/?l=xalan-j-users&m=122095755104055&w=2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions