Re: Marking cforms stable in 2.1.8
On Mar, 7 de Junio de 2005, 0:33, Reinhard Poetz dijo: Ralph Goers wrote: We have a project that needs to use a forms framework that is more advanced than what SimpleForms provides. However, it is difficult on selling cforms simply because they are marked unstable. What is it going to take to mark it stable in 2.1.8? Can we simply identify the known bugs in bugzilla and mark it stable? Frankly, given the number of folks who appear to be using cforms already, and since this list has been recommending it for the last year, we should probably be treating it as stable now. If I wrote block.xml for cFroms I would fill in the state section as follows: state community=stable interfaces=unstable implementation=stable/ We have to finish the Flowscript API, review the repeater binding and flatten the forms.xconf entries to get the interfaces stable too. (http://wiki.apache.org/cocoon/22StabilizeCocoonForms) I will add: Improve selection-list inside repeaters. Best Regards, Antonio Gallardo
Re: Marking cforms stable in 2.1.8
Le 6 juin 05, à 20:44, Ralph Goers a écrit : ...Frankly, given the number of folks who appear to be using cforms already, and since this list has been recommending it for the last year, we should probably be treating it as stable now... It is certainly stable as in working reliably. What's still moving are some APIs, as Reinhard indicates. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: JDTCore.jar used for XSP only?
I have the source distribution of Cocoon 2.1.6 and have only switched on the blocks 'batik', 'fop' and 'paranoid', but I _am_ getting jdtcore.jar? Can anyone tell whether it is really necessary? I have to run Cocoon with the Paranoid class loader to prevent Cocoon from using the Oracle XML Parser provided by the Oracle Application Server and I'd like to keep the Web-inf/lib/ as tiny as possible. Any suggestions? Thanks, Geert Reinhard Poetz wrote: Geert Josten wrote: Hi, Is jdtcore.jar only used for compiling Java for XSP pages? I'm not using XSP currently, so I am wondering if I can just eliminate that jar file. It doesn't seem to affect Cocoon. Can anyone confirm? In trunk jdtcore.jar is only added if you enable the XSP block. Don't know what BRANCH_2_1_X does. -- = NB: het Daidalos kantoor is sinds 22 april jl. gevestigd op een nieuw adres: Daidalos BV Hoekeindsehof 1 - 4 2665 JZ Bleiswijk tel: +31 (0)10 850 12 00 fax: +31 (0)10 850 11 99 Bovenstaand adres is tevens het postadres. == [EMAIL PROTECTED] IT-consultant at Daidalos BV http://www.daidalos.nl/ GPG: 1024D/12DEBB50
Re: Marking cforms stable in 2.1.8
On Jun 6, 2005, at 11:44 AM, Ralph Goers wrote: We have a project that needs to use a forms framework that is more advanced than what SimpleForms provides. However, it is difficult on selling cforms simply because they are marked unstable. What is it going to take to mark it stable in 2.1.8? Can we simply identify the known bugs in bugzilla and mark it stable? I don't know what's going on with your group, but the problem may be that we define unstable = API subject to change, but the word unstable has other connotations, e.g. broken, alpha, not ready for prime-time (also prone to undergo a spontaneous nuclear decay reaction :-). Why don't we just 1) take everything currently marked stable, and re-badge those as frozen; 2) take forms, and anything else like it, and mark it as stable! I.e., redefine stable to mean what average people think it means. (half-joking,) ml :-)
Session replication
We have a customer who wants to use Cocoon for a high-profile project. However this customer has the requirement that the user-session must be replicated (using Tomcat etc.) so that the end-user can continue without problems in the event of a failover. Obviously Cocoon doesn't yet support this - through the problems in Flow etc. (and maybe others). So my question is basically: How are others handling this sort of requirement? Doesn't anyone else need this - or are there other ways of solving the problem? Any pointers/examples welcome! Thanks Matthew Langham
Re: Session replication
Le 7 juin 05, à 10:16, Matthew Langham a écrit : ...Obviously Cocoon doesn't yet support this - through the problems in Flow etc. (and maybe others)... FYI, in case you hadn't seen it, there's http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript- serialization Of course this doesn't solve the problem *today* ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Marking cforms stable in 2.1.8
Mark Lundquist wrote:
On Jun 6, 2005, at 11:44 AM, Ralph Goers wrote:
We have a project that needs to use a forms framework that is more
advanced than what SimpleForms provides. However, it is difficult on
selling cforms simply because they are marked unstable. What is it
going to take to mark it stable in 2.1.8? Can we simply identify the
known bugs in bugzilla and mark it stable?
I don't know what's going on with your group, but the problem may be
that we define unstable = API subject to change, but the word
unstable has other connotations, e.g. broken, alpha, not ready
for prime-time (also prone to undergo a spontaneous nuclear decay
reaction :-).
Why don't we just
1) take everything currently marked stable, and re-badge those as
frozen;
2) take forms, and anything else like it, and mark it as stable!
I.e., redefine stable to mean what average people think it means.
(half-joking,)
ml
:-)
The current situation is that the implementation (runs in many projects) and the
community (large developer and user community) are stable, but the interfaces
are *not*. I tried to express this with the hypothetical block descriptor fragment:
state
community=stable
interfaces=unstable
implementation=stable/
I don't want to mark Cocoon Forms as stable if we *know now* that the interfaces
will change. Marking Cocoon Forms as stable would require us to support them and
we would create a lot of confusion in the future (e.g. the different Form APIs
which are confusing enough now).
In other words, my +1 depends on a rewritten Flowscript API and repeater
binding. As long as nobody does the actual work we will have to live with an
unstable Cocoon Forms block. (though, if the majority of the Cocoon committers
wants to mark it as stable *now* I won't/can't stop it but expect my -1 to
express my concerns and a lot of I've told you so in the future ;-) )
--
Reinhard Ptz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
RE: Session replication
...Obviously Cocoon doesn't yet support this - through the problems in Flow etc. (and maybe others)... FYI, in case you hadn't seen it, there's http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript- serialization Of course this doesn't solve the problem *today* ;-) No, unfortunately not. The customer considers this requirement to be a make-or-break for using Cocoon :(. Matthew
Re: [Vote] Reduce dependencies to LogKit
So far we have many +1s and no -1, so I will reduce the dependencies in the next days. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[RT] Cache Cforms selection-list created at runtime using Javascript
Hi: We use javascript for creating a SelectionList (SL) at runtime. We do this mainly because we want dynamically change the @src of the SL. If the @src is change because an user input, then we can use the on-value-changed event to do this. Example: ... fd:on-value-changed fd:javascript var value= myWidget.setSelectionList(cocoon:/mySelectionList?id= + value); . /fd:javascript /fd:on-value-changed ... In samples without a repeater as the car selector, there is no need for caching the item list values. The SL is used in only 1 widget and it is not repeated again. The situation change if the same field is inside a repeater. And here we can again improve the SL performance, by caching the item list. Of course, this functionality should be optional, so we need another javascript function to create a cached SL. Maybe something like this: myWidget.setSelectionList(src, cache); where cache = [request|none]; Note: static has no sense here. As before, the solution can be implementing by obtaining the context. Then we should be able to reuse the current caching code. WDYT? Best Regards, Antonio Gallardo.
Re: Session replication
Matthew Langham wrote:
We have a customer who wants to use Cocoon for a high-profile project.
However this customer has the requirement that the user-session must be
replicated (using Tomcat etc.) so that the end-user can continue without
problems in the event of a failover.
Obviously Cocoon doesn't yet support this - through the problems in Flow
etc. (and maybe others). So my question is basically: How are others
handling this sort of requirement? Doesn't anyone else need this - or are
there other ways of solving the problem?
Any pointers/examples welcome!
AFAIU there is no workaround. I've already done some research work to make
Flowscript replication happend and I contacted a (Hungarian) developer who
solved the problem of Rhino scope and coninuation serialization in a different
context. Unfortunatly he and I are both swamped ATM but I think he is willing to
guide us with his experiences and also some demo code.
Also see http://issues.apache.org/bugzilla/show_bug.cgi?id=33324
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Session replication
On 6/7/05, Matthew Langham [EMAIL PROTECTED] wrote: ...Obviously Cocoon doesn't yet support this - through the problems in Flow etc. (and maybe others)... FYI, in case you hadn't seen it, there's http://wiki.apache.org/general/SummerOfCode2005#cocoon-flowscript- serialization Of course this doesn't solve the problem *today* ;-) No, unfortunately not. The customer considers this requirement to be a make-or-break for using Cocoon :(. Doesn't Javaflow support serialization? In any case, when I stumble across such kind of issues, my answer tends to be twofold: first of all I question the real need for unconditional failover, since this is an issue that tends to become gold plating in no time flat. I still have to see a single application that fails over nicely, given that devs tends to put in session objects any kind of stuff (most notably database connections). Remember that a single non-serializable object in your session will make failover support useless. Technically wise it's much better to plan for failures (don't use sessions unless you really have to) instead than leaving it to the underlying framework: high availability is much better achieved by redundancy than clustering (I saw just too many clusters failing). Having said that, it's definitely true that flowscript by itself isn't serializable (yet). However, in a business continuity scenario, what you should do is keep your sendPageAndWait() to a bare minimum: ideally a continuation shouldn't spawn more than two or three screens, whereas the business model should be kept elsewhere. Consider CForms, as an example: most of the time, the continuation is used for two or three screens: fill, [confirm], commit. The real use of continuations, here, is when form validation fails: this is where you might have a continuation lasting for a dangerous number of screens and, if a failure occurs, you might be stuck. However, it shouldn't be much of an hassle to perform (partial) bindings upon every submit on a clusterizable object, so that if something fails you can start a (new) form on the fallback server, losing as little work as possible. Bottom line: I consider this more as an uneducated CIO issue rather than a real technical blocker. But you will always find clueless people. :) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Cocoon zone redirect problems (was: Cocoon zone update)
Le 4 juin 05, à 17:54, Bertrand Delacretaz a écrit : ...Also, it seems like redirects do not work as expected. For example (starting with the new links at http://cocoon.zones.apache.org/), clicking the supersonic tour link at http://cocoon.zones.apache.org/demos/release/samples/blocks/ sends a redirect to http://cocoon.zones.apache.org/samples/blocks/tour/intro/docs/ index.html.. With ProxyPreserveHost Off instead of On in the httpd.conf, redirects seem to work correctly. Daisy doesn't seem to require this setting, so we'll leave it Off for now. CSS and others links are still broken on the samples, to fix this we'll need either a bunch of ugly mod_rewrite statements, or (much better) fix them in the samples to use relative links. -Bertrand smime.p7s Description: S/MIME cryptographic signature
RE: Session replication
Bottom line: I consider this more as an uneducated CIO issue rather than a real technical blocker. But you will always find clueless people. :) Thanks for all the comments Gianugo, I will try and use my convincing powers to clue the people up :-). Not sure if it will work in this case though. Matthew
CForms Binding: Update flag on change of form or repeater row
Hi ! Are there plans to include something like an on-update-flag into CForms / Binding? I can flag inserted and deleted repeaters, but there is no chance to mark a record as modified. This could be of importance (at least for me J ) when dealing with databases that store historic data. In case of handling a tree form update submit with some repeater-widgets you can not figure out which records have been modified. I had a look at the binding sources, and I found that there is a check old vs. new value, and a debug message, if those are not equal. Are there plans for including some flagging there ? Id maybe try my luck on implementing a patch, but as I am quite new to java and even newer to cocoon, Id welcome any hints J ! Best regards, Thomas Lutz
Summer of Code: cocoon-refdoc spec
I have written a first spec for this project, see http://wiki.apache.org/cocoon/CocoonRefDocProject Comments are welcome of course. -Bertrand, who'd love to be a student ;-) smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Per sitemap classloading and ClassLoaderFactory
Ok, as it seems that noone has a better idea I will make the role used to get the class loader factory configurable. Carsten Carsten Ziegeler wrote: Sylvain Wallez wrote: Can you elaborate on your use case? I can try :) I don't have a clear concept right now. All I want to do is to scan the classpath defined for the sitemap for some specific classes (or perhaps resources - don't know yet). If these classes implement a specific interface an instance of this class is created and registered. Something along these lines. Hmm... since this class has to be defined by a higher-level classloader, what about allowing different implementations for the ClassLoaderFactory, i.e. using a role rather than a class name? Ah, ok, I see, we have a chicken/egg problem here. Now, my idea was that the classloader resides in the classpath defined for the sitemap which wouldn't work. Hmpf. Ok, a role would work as well. Hmm, I'm not happy with that solution. My idea was that this mechanism is independent and the sitemap directory contains everything required to handle this, including the own classloader class. Do you see any possible solution for this? Also, it seems to me this property belongs more to map:classpath rather than map:components. Oh, you're right. Sure! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Why does XSPMarkupLanguage wrap text in xsp:text?
Vadim Gritsenko [EMAIL PROTECTED] wrote on 06.06.2005 16:19:44: Jochen Kuhnle wrote: I noticed that XSPMarkupLanguage.characters wraps text in xsp:text elements. Is there a reason for this? At least my XSPs work without this... This logic has been there since beginnings of Cocoon2 XSP implementation [1] (line 134), and I'd suggest leaving it there as logicsheets might bedependent on this. I just found one other thing: I'm implementing the cache control logic sheets for XSPs [1], and there, the xsp:text wrapping actually makes things more complicated. What we wanted was something like this: key:key xsp-request:get-parameter name=key/ /key:key where the key template would append all child elements to the cache key. A simple xsl:for-each select=*/ in the logic sheer would suffice. If not for the xsp:text wrapping... Because this actually wraps the white space between key:key and xsp-request:get-parameter in xsp:text, making things in the logic sheet more complicated. Not very straight forward: xsl:for-each select=*[namespace-uri() != 'http://apache.org/xsp' or local-name() != 'text' I guess original idea was that text() nodes can be safely ignored, while xsp:text nodes are meaningful. It might be still true, haven't digged deeper... Vadim [1] http://cvs.apache.org/viewcvs. cgi/cocoon-1/src/org/apache/cocoon/components/language/markup/xsp/XSPMarkupLanguage. java?rev=1.1.2.1only_with_tag=xml-cocoon2view=markup Regards, Jochen [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111693513631888w=2
Re: Why does XSPMarkupLanguage wrap text in xsp:text?
Jochen Kuhnle wrote: Vadim Gritsenko [EMAIL PROTECTED] wrote on 06.06.2005 16:19:44: Jochen Kuhnle wrote: I noticed that XSPMarkupLanguage.characters wraps text in xsp:text elements. Is there a reason for this? At least my XSPs work without this... This logic has been there since beginnings of Cocoon2 XSP implementation [1] (line 134), and I'd suggest leaving it there as logicsheets might be dependent on this. I guess original idea was that text() nodes can be safely ignored, while xsp:text nodes are meaningful. It might be still true, haven't digged deeper... Hmm, I don't think this behaviour is very intuitive, especially if compared to XSLT's handling of xsl:text. Maybe we could make it configurable and deprecate it? Especially if doing so does not break anything? I don't think that it is something which should be configurable: it should be either left in (and clarified where necessary) or removed. Without review, I can't +1 removal - first need to check that all corner cases are still processed properly without xsp:text/. Vadim
Re: Cocoon zone redirect problems
Bertrand Delacretaz wrote: CSS and others links are still broken on the samples, to fix this we'll need either a bunch of ugly mod_rewrite statements, It will be easier to deploy cocoon under same context path, won't it? Just need to edit tools/jetty/conf/main.xml so that instead of '/' you can pass some system property. Vadim
Re: Why does XSPMarkupLanguage wrap text in xsp:text?
Jochen Kuhnle wrote: Vadim Gritsenko [EMAIL PROTECTED] wrote on 06.06.2005 16:19:44: Jochen Kuhnle wrote: I noticed that XSPMarkupLanguage.characters wraps text in xsp:text elements. Is there a reason for this? At least my XSPs work without this... This logic has been there since beginnings of Cocoon2 XSP implementation [1] (line 134), and I'd suggest leaving it there as logicsheets might be dependent on this. I just found one other thing: I'm implementing the cache control logic sheets for XSPs [1], and there, the xsp:text wrapping actually makes things more complicated. What we wanted was something like this: key:key xsp-request:get-parameter name=key/ /key:key XML above - it is XML. It has two character events. XSP MUST process these character events, and it MUST NOT ignore those character events, as XSP is operating on the XML and character events are part of XML. It means, generally speaking, that the caching key above MUST be set to the value: \n + request.getParameter(key) + \n. Anything else is invalid behaviour which MUST be fixed. where the key template would append all child elements to the cache key. A simple xsl:for-each select=*/ in the logic sheer would suffice. If not for the xsp:text wrapping... Because this actually wraps the white space between key:key and xsp-request:get-parameter in xsp:text, making things in the logic sheet more complicated. Not very straight forward: See above - for correct behavior you must add xsp:text elements to the caching key. It is identical to: key:keyaaaxsp-request:get-parameter name=key/bbb/key:key And I guess you won't dispute the fact that 'aaa' and 'bbb' must be part of the key. Now, for efficiency reasons, one might argue that leading and trailing whitespaces should be trimmed, so that if clueless user uses the logicsheet he doesn't end up with large mostly whitespace keys. Here, I might agree with it, so one can trim the key, and key as generated from the snippet right above becomes: String.valueOf(aaa + request.getParameter(key) + bbb).trim() as long as it is crystal clear from logicsheet documentation that this particular logicsheet DOES NOT respect whitespaces. Notice: it still processes all xsp:text elements, and we trim afterwards. PS Definition of 'MUST' above is same as in RFCs. Vadim xsl:for-each select=*[namespace-uri() != 'http://apache.org/xsp' or local-name() != 'text' I guess original idea was that text() nodes can be safely ignored, while xsp:text nodes are meaningful. It might be still true, haven't digged deeper... Vadim [1] http://cvs.apache.org/viewcvs. cgi/cocoon-1/src/org/apache/cocoon/components/language/markup/xsp/XSPMarkupLanguage. java?rev=1.1.2.1only_with_tag=xml-cocoon2view=markup Regards, Jochen [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111693513631888w=2
Re: Cocoon zone redirect problems
Le 7 juin 05, à 14:49, Vadim Gritsenko a écrit : Bertrand Delacretaz wrote: CSS and others links are still broken on the samples, to fix this we'll need either a bunch of ugly mod_rewrite statements, It will be easier to deploy cocoon under same context path, won't it? Just need to edit tools/jetty/conf/main.xml so that instead of '/' you can pass some system property. Right - I'll see how I can do it while keeping the possiblity of just dumping a new release in place and restarting. A sed script to do this setup in main.xml should do. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Marking cforms stable in 2.1.8
Reinhard Poetz wrote: The current situation is that the implementation (runs in many projects) and the community (large developer and user community) are stable, but the interfaces are *not*. I tried to express this with the hypothetical block descriptor fragment: state community=stable interfaces=unstable implementation=stable/ I don't want to mark Cocoon Forms as stable if we *know now* that the interfaces will change. Marking Cocoon Forms as stable would require us to support them and we would create a lot of confusion in the future (e.g. the different Form APIs which are confusing enough now). The problem is that we are recommending (and have been recommending) CForms as our forms framework for a long time. Even if you haven't marked it stable, it already should be, based upon those recommendations. In other words, my +1 depends on a rewritten Flowscript API and repeater binding. As long as nobody does the actual work we will have to live with an unstable Cocoon Forms block. (though, if the majority of the Cocoon committers wants to mark it as stable *now* I won't/can't stop it but expect my -1 to express my concerns and a lot of I've told you so in the future ;-) ) I would prefer that CForms be marked stable unless the necessary work can be done in the next 6 weeks. Just so you know, I will be requiring a stable CForms on the next Cocoon release or I will vote -1. Ralph
Re: Cocoon zone redirect problems
Bertrand Delacretaz wrote: Le 7 juin 05, à 14:49, Vadim Gritsenko a écrit : Bertrand Delacretaz wrote: CSS and others links are still broken on the samples, to fix this we'll need either a bunch of ugly mod_rewrite statements, It will be easier to deploy cocoon under same context path, won't it? Just need to edit tools/jetty/conf/main.xml so that instead of '/' you can pass some system property. Right - I'll see how I can do it while keeping the possiblity of just dumping a new release in place and restarting. A sed script to do this setup in main.xml should do. Just edit the damn file in SVN! :-) -Arg//Arg +ArgSystemProperty name=context default=///Arg Vadim
Re: Why does XSPMarkupLanguage wrap text in xsp:text?
Vadim Gritsenko [EMAIL PROTECTED] wrote on 07.06.2005 14:34:36:
Jochen Kuhnle wrote:
Vadim Gritsenko [EMAIL PROTECTED] wrote on 06.06.2005 16:19:44:
Jochen Kuhnle wrote:
...
key:key
xsp-request:get-parameter name=key/
/key:key
XML above - it is XML. It has two character events. XSP MUST process
these
character events, and it MUST NOT ignore those character events, as XSP
is
operating on the XML and character events are part of XML.
It means, generally speaking, that the caching key above MUST be set
to the value:
\n + request.getParameter(key) + \n.
Anything else is invalid behaviour which MUST be fixed.
XSLT whitespace stripping removes whitespace only text() nodes in
templates, except if configured otherwise [1].
where the key template would append all child elements to the cache
key. A
simple xsl:for-each select=*/ in the logic sheer would suffice. If
not
for the xsp:text wrapping... Because this actually wraps the white
space
between key:key and xsp-request:get-parameter in xsp:text,
making
things in the logic sheet more complicated. Not very straight forward:
See above - for correct behavior you must add xsp:text elements to
the caching
key. It is identical to:
key:keyaaaxsp-request:get-parameter name=key/bbb/key:key
And I guess you won't dispute the fact that 'aaa' and 'bbb' must be
part of the key.
Now, for efficiency reasons, one might argue that leading and trailing
whitespaces should be trimmed, so that if clueless user uses the
logicsheet he
doesn't end up with large mostly whitespace keys. Here, I might
agree with it,
so one can trim the key, and key as generated from the snippet right
above becomes:
String.valueOf(aaa + request.getParameter(key) + bbb).trim()
as long as it is crystal clear from logicsheet documentation that this
particular logicsheet DOES NOT respect whitespaces. Notice: it
stillprocesses
all xsp:text elements, and we trim afterwards.
What I would prefer would be a whitespace handling similar to XSLT's:
key:key
aaa
xsp-request:get-parameter name=key/
bbb
/key:key
leads to (\naaa\n + request.getParameter(key) + \nbbb)
key:key
xsp:textaaa/xsp:text
xsp-request:get-parameter name=key/
xsp:textbbb/xsp:text
/key:key
leads to (aaa + request.getParameter() + bbb)
key:key
xsp-request:get-parameter name=key/
/key:key
leads to (request.getParameter())
If we don't do automagic wrapping by PreProcessFilter, the XSP author can
decide. It would also have another advantage: PreProcessFilter wraps
everything, including whitespace only text() nodes. This leads to loads of
unnecessary this.characters(\n); ('_' = space) in the XSPs. I
guess that most whitespaces between elements are in there for code
formatting purposes, and people don't need all of them ending up in the
internet. Might be nice to count needlessly sent whitespace bytes sometime
:)
In the distribution xsp:text mostly occurs in utility templates
(get-nested-content) that unwrap the automagically wrapped text. The
only occurence that I've found that does something different is in xsp.xsl
itself. The only occurence to quote text is in ViewOrder.xsp. Therefor I
don't think this change would have any impact on existing XSPs. But it
would make the code simpler and text handling more standard like.
Regards,
Jochen
[1] http://www.w3.org/TR/xslt#strip
Weird multithreading bug in Cron block
Hi all, I'm currently working on a publication application with complex database queries where we want to prefetch some of the pages linked to by the page currently being produced, in order to speed up response time on pages that are likely to be asked for by users. To achieve this, we have a PrefetchTransformer that grabs elements having a prefetch=true attribute and starts a background job to load the corresponding src or href URL using a cocoon:. At first I used JobScheduler.fireJob() to schedule for immediate execution, but went into *weird* bugs with strange NPEs all around in pipeline components. After analysis, it appeared that while the scheduler thread was processing the pipeline, the http thread was recycling the *background environment*, thus nulling the object model and other class attributes used by pipeline components. I spent the *whole day* trying to find the cause for this, without success (how frustrating). Then I decided to try another approach and use JobScheduler.fireJobAt(new Date()), meaning schedule the job for later execution... now!. And it worked! Weird, weird, weird! Anybody having a hint about why fireJob() is doing this environment mixture? Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Adding serializer info to SitemapSource
Hi all,
As mentioned in my previous post, I'm using background cocoon: URLs to
feed the cache with costly pages to speedup response time when a user
asks for that same URL.
The problem with this approach is that when processing internal
requests, the associated cache key strips out the serializer part. The
bad result of this is that a single URL leads to two different cache
entries if called externally (http:) or internally (cocoon:), this
defeating the prefetch strategy.
To circumvent the problem, I just had to create a subclass of
CachingProcessingPipeline with a single method:
public void prepareInternal(Environment environment) throws
ProcessingException {
preparePipeline(environment);
}
And it worked like a charm!
So the question is why do we remove the serializer information from the
key and validity for an internal request? Furthermore considering that
calling getInputStream() on a cocoon: source *does* use the Serializer.
I'd like to remove this distinction and have the full pipeline key be
used il all cases.
Thoughts, objections?
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111816379808621w=2
--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research Technology Director
[osgi] Package structure
I have started to experiment with OSGi, and this far it seem rather promising. I hope to be able to check in something in whiteboard rather soon. --- o0o --- A problem however is that our organization (or rather lack of organization) of packages in blocks, in some cases doesnt fit very well with how OSGi works. Each OSGi bundle declare what packages it exports and imports. Then if several bundles exports the same package, the framework will choose the package from one of the bundles and feed it to all bundles that imports the package. Read the spec for geting the details http://www.osgi.org/osgi_technology/download_specs.asp?section=2. There are, AFAIU, rather convincing reasons for solving it that way. Everything is handled at package level rather than at individual class level. This means that if: Cocoon Bundle - Export-Package: org.apache.cocoon.generation,org.apache.cocoon.transformation,... Batik Bundle Export-Package: org.apache.cocoon.generation,org.apache.cocoon.transformation,... and the Cocoon bundle is loaded first, org.apache.cocoon.generation.FragmentExtractorGenerator and org.apache.cocoon.transformation.FragmentExtractorTransformer will be available in any classloader in the system. Bundle internal classes that not are exported can have the same name in several bundles, but exported ones must be unique. --- o0o --- I don't think this is special for OSGi, I would assume that any reasonable framework with classloader isolation, (if there happen to be any alternatives), has to do something like this. Many blocks uses unique packagenames but not all. So IMO we need a policy for package naming. Is there any style guide for package names for Eclipse plugins that we can adapt? Otherwise using something like: org.apache.cocoon.blockname.** seem rather reasonable. Alsp using impl as suffix on non exported packages seem like a good idea. There is of course no need to change blocks that allready uses unique package names even if they don't happen to follow the yet to be decided style guide. A depredation strategy would be to move the classes to their new packages and then let the original classes be marked as deprecated and just extend the moved one. As Leszek did for org.apache.cocoon.generation.JXTemplateGenerator. Then it will work as before during the deprecation period and at the same time it can be used with the new package in a micro kernel environment. --- o0o --- I am completely aware about that this is rather inconvenient. But sooner or later I think we will have to create better order in our package naming anyway. WDYT? /Daniel
Re: [osgi] Package structure
Daniel Fagerstrom wrote: I have started to experiment with OSGi, and this far it seem rather promising. I hope to be able to check in something in whiteboard rather soon. Great! --- o0o --- A problem however is that our organization (or rather lack of organization) of packages in blocks, in some cases doesnt fit very well with how OSGi works. Each OSGi bundle declare what packages it exports and imports. Then if several bundles exports the same package, the framework will choose the package from one of the bundles and feed it to all bundles that imports the package. Read the spec for geting the details http://www.osgi.org/osgi_technology/download_specs.asp?section=2. There are, AFAIU, rather convincing reasons for solving it that way. Everything is handled at package level rather than at individual class level. This means that if: Cocoon Bundle - Export-Package: org.apache.cocoon.generation,org.apache.cocoon.transformation,... Batik Bundle Export-Package: org.apache.cocoon.generation,org.apache.cocoon.transformation,... and the Cocoon bundle is loaded first, org.apache.cocoon.generation.FragmentExtractorGenerator and org.apache.cocoon.transformation.FragmentExtractorTransformer will be available in any classloader in the system. Bundle internal classes that not are exported can have the same name in several bundles, but exported ones must be unique. --- o0o --- I don't think this is special for OSGi, I would assume that any reasonable framework with classloader isolation, (if there happen to be any alternatives), has to do something like this. Many blocks uses unique packagenames but not all. So IMO we need a policy for package naming. Is there any style guide for package names for Eclipse plugins that we can adapt? Otherwise using something like: org.apache.cocoon.blockname.** Yep. That's how it's done for Eclipse plugin. Each plugin has a name which is unique among all plugin and which is the root package for classes contained in the plugin. seem rather reasonable. Alsp using impl as suffix on non exported packages seem like a good idea. There is of course no need to change blocks that allready uses unique package names even if they don't happen to follow the yet to be decided style guide. A depredation strategy would be to move the classes to their new packages and then let the original classes be marked as deprecated and just extend the moved one. As Leszek did for org.apache.cocoon.generation.JXTemplateGenerator. Then it will work as before during the deprecation period and at the same time it can be used with the new package in a micro kernel environment. --- o0o --- I am completely aware about that this is rather inconvenient. But sooner or later I think we will have to create better order in our package naming anyway. WDYT? Sounds good. A number of blocks already take this approach. Those that don't are AFAICS mostly the ones that existed before being moved to blocks (e.g. SVG). Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
