DO NOT REPLY [Bug 28550] New: - Need a removeSelectionList method.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28550.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28550
Need a removeSelectionList method.
Summary: Need a removeSelectionList method.
Product: Cocoon 2
Version: 2.1.4
Platform: All
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: CocoonForms
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am using the on-value-changed event for a field to do some validation, if
there are multiple matchs on the (code) field I create a selectionList and have
the user choose from the list of codes.
When the user selects the correct value I no longer want the selectionlist.
Scenario:
wd:on-value-change
javascript
// Use a component to find suppliers
if (suppliersLength == 1) {
event.source.value = element.getFirstChild().getAttribute(code);
// And remove any selection list that may have been set previously
} else if (suppliersLength 1) {
supplier = new Array(supplierLength);
// Fill array
event.source.setSelectionList(supplier, value, label)
} else {
// Serve up an error
}
/javascript
/wd:on-value-changed
Re: cvs commit: cocoon-2.1/src/blocks/linotype/samples/styles main.css
On 23.04.2004 09:18, [EMAIL PROTECTED] wrote:
ugo 2004/04/23 00:18:28
Modified:src/blocks/linotype/samples/styles main.css
Log:
Added CSS workaround for missing suppor of position:fixed in IE6.
Just yesterday I came across the same thing and found probably an easier
workaround:
http://www.w3.org/Style/banner.css
Instead of using
div.banner {
position: fixed;
}
you write
div.banner {
position: absolute;
}
* div.banner {
position: fixed;
}
As IE also ignores the selector, position: fixed is never applied.
From what I can see with the current workaround position:fixed is
neither used in other browsers, is it?
Joerg
RE: RE: Incompatible change Request.getRequestURI()
Volker Schmitt wrote: Ok, so I am not able to do a forward anymore, which doesn't do a redirect? So I am now missing a feature ;-) Isn't it better to have a forward and a redirect? Hmm, don't know. What is your use case for a forward? Carsten Volker
Re: [cform] Multi Value Field
Bruno Dumon wrote: On Fri, 2004-04-23 at 07:43, Marc Portier wrote: Danny, you're making sense, pls add this feature-request to bugzilla if you don't mind. by the way: should there be a reason why we don't just provide access to the datatype on every widget? because only fields and multivaluefields know the concept of datatypes. very good reason indeed, and thx for waking me up :-) -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
DO NOT REPLY [Bug 28552] New: - Extend MultiValueField with getDataType method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28552. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28552 Extend MultiValueField with getDataType method Summary: Extend MultiValueField with getDataType method Product: Cocoon 2 Version: 2.1.4 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: CocoonForms AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The MultiValueField is missing the getDataType() method which means one can't create any selection lists like this: StaticSelectionList list = new StaticSelectionList(myField.getDatatype()); myField.setSelectionList(list);
Re: [cform] Multi Value Field
On Fri, 2004-04-23 at 07:43, Marc Portier wrote: Danny, you're making sense, pls add this feature-request to bugzilla if you don't mind. by the way: should there be a reason why we don't just provide access to the datatype on every widget? because only fields and multivaluefields know the concept of datatypes. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cvs commit: cocoon-2.1/src/blocks/linotype/samples/styles main.css
Joerg Heinicke wrote: As IE also ignores the selector, position: fixed is never applied. From what I can see with the current workaround position:fixed is neither used in other browsers, is it? Don't ask me how it works, I just found it doing a Google search for CSS IE position: fixed. It looks fine in Mozilla/IE 6/Safari, but IE 5.2 for the Mac does not recognize the @media screen rule and does not apply any style. If you think your solution is easier, please apply it. I'm not a purist, so it's fine as long as it works. Ugo
RE: Proposal: release management guide (was Re: [RT] Versions)
Tim Larson wrote: On Thu, Apr 22, 2004 at 09:50:08PM +0200, Carsten Ziegeler wrote: Tim Larson wrote: If it happens that 2.3 comes very soon after 2.2, then the deprecated code in effect was just deleted and not put through a normal deprecation cycle. Perhaps we need to also set a minimum length of time that deprecated features will live, to ensure that deprecation is a meaningful process and not just a formality. Hmm, yes, this is a valid point. Looking back, it always took some time between our releases, so I think we don't have to set a strict rule for this. We should just decide on a case by case base if the time inbetween releases has been long enough or if we should keep the deprecated stuff in the next minor release and remove it one minor release later. We will need to decide on a case-by-case basis, but we should also set a general guideline to help with the decisions. Ok, we can add this when the guide is in CVS (which should be very shortly)... Also, we should define what deprecation means, such as whether simple but severe security issues will receive updates, even though more ongoing or complex updates will not happen to deprecated code. Can you please explain this a little bit? Do you mean, what will happen if security issues arise in deprecated code? Yes, that is what I am asking. If we do not handle security issues in deprecated code, our users are not in a much better position than if we had just deleted the code without deprecation, since they can no longer safely continue to use the code in production. If we are going to do the effort of a deprecation cycle, we might as well make it mean something for our users. Ah, yes, of course. If any severe security issue arises (where 'any' means either in deprecated or non deprecated code), we will make a patch release. Yes. Yes, agreed. And we should really start updating libaries only if there is really a good reason for it. For these compatible releases I agree, but I also appreciate Antonio's and others' efforts in keeping these libraries up to date. I wish there were an easy way to maintain the integration of both old stable and new up-to-date libraries against our code. I admit I do not know the best, most practical, balance for this issue. Yes, in general I personally would always update to the latest release, but for compatibility it's not always the best choice. Now, I think Gump is doing this work for us, or? We use a specific version and Gump builds (and tests?) Cocoon against the latest version. Carsten
Re: [vote] Versioning Guide
On 22 Apr 2004, at 21:03, Carsten Ziegeler wrote: Here is my +1 (of course) :) and mine +1 regards Jeremy smime.p7s Description: S/MIME cryptographic signature
RE: [vote] Versioning Guide
Thanks for all your feedback! I just add the first draft to our site repository; now we can all work together on the document. Thanks Carsten
RE: Incompatible change Request.getRequestURI()
Ralph Goers wrote: Ouch. Presumably this is mixed in with other fixes, etc. meant for 2.1.5. That would mean that if the release management proposal you made is followed no more maintenance can be done on 2.1 unless this is pulled out. Hmm, basically yes. I will come up with a proposal for this soon. Carsten
[Vote] Repository Usage and Versioning
Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). Then one repository for testing new stuff, like the new block system - this will be the sandbox or scratchpad repository. And finally - as we already have - the site repository. As recently reported we already have incompatible changes from 2.1.4 to 2.1.5 (which we accepted to have!) and as I pointed out lately I want to remove some deprecated stuff to continue the development of the current version. And we have some major changes, like the Cocoon forms that justify a minor version changes anyway. So, I think, we should: - tag the current cvs in order to create a branch if required - change the version to 2.2, so this will be our next release - try to follow the versioning guide (which is a work-in-progress) - move to subversion whenever we want - if the need for a 2.1.5 release arises we create a branch, revert the incompatible changes and use the branch This allows us to continue the development of Cocoon in any direction without worrying about versions and how this fits into the development of blocks. Blocks (and perpaps other features) can be developed independently in a sandbox/scratchpad and when they are mature enough can be moved in the main trunk. This can then result in a new major or a new minor version. We can decide this when the time comes. Carsten Carsten Ziegeler Open Source Group, SN AG http://www.osoco.net/weblogs/rael/
Binary release? (was Re: [vote] Versioning Guide)
Carsten Ziegeler wrote: Marc Portier wrote: - I would like us to make binaries again somewhere soon. Apart from the outcome of that discussion I find it odd to use the way we distribute as an argument for anything mentioned here, no? I guess as soon as we have real blocks we can switch to binary releases again if we want. But the reasons for recompiling are of course still valid. No, these reasons aren't valid. In fact, I don't believe they ever were valid. We need a 'build' process, but not necessarily a 'compilation' process. We could have a distribution that includes all of the jar files ready compiled. Then, when the user has unpacked this distribution, they edit their local.blocks.properties, etc, and run build, which prepares the webapp, copying only those precompiled jars across that are actually needed, and running the XConfPatch task, etc, etc. I imagine this would be quicker for the user, and would probably result in a far smaller distribution. Regards, Upayavira
Re: [Vote] Repository Usage and Versioning
On 23.04.2004 11:03, Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). +1 Then one repository for testing new stuff, like the new block system - this will be the sandbox or scratchpad repository. +1 And finally - as we already have - the site repository. +1 As recently reported we already have incompatible changes from 2.1.4 to 2.1.5 (which we accepted to have!) and as I pointed out lately I want to remove some deprecated stuff to continue the development of the current version. And we have some major changes, like the Cocoon forms that justify a minor version changes anyway. So, I think, we should: - tag the current cvs in order to create a branch if required Isn't the 2.1.4 release tag enough? - change the version to 2.2, so this will be our next release +1 - try to follow the versioning guide (which is a work-in-progress) +1 - move to subversion whenever we want +1 - if the need for a 2.1.5 release arises we create a branch, revert the incompatible changes and use the branch Doing it from the 2.1.4 release tag we do not even need to revert incompatible changes. Joerg
Re: Binary release? (was Re: [vote] Versioning Guide)
On 23.04.2004 11:07, Upayavira wrote: We need a 'build' process, but not necessarily a 'compilation' process. We could have a distribution that includes all of the jar files ready compiled. Then, when the user has unpacked this distribution, they edit their local.blocks.properties, etc, and run build, which prepares the webapp, copying only those precompiled jars across that are actually needed, and running the XConfPatch task, etc, etc. So nice this sounds, so bad it can be for the users. They might select blocks missing their dependencies (because we have not maintained them correctly, or they did a mistake when selecting them) and got NoClassDefFoundError at run time. Joerg
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Antonio Gallardo wrote: Can Cocoon live beyond Java? Cocoon life depend on Java? I'm in crete right now. Visiting ruins of 3000 years ago make you understand how futile questions like these really are. If it works, use it, if not try to fix it, if you can't fix it, let go and use something else. It's a simple as that. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: [Vote] Repository Usage and Versioning
Joerg Heinicke wrote: Doing it from the 2.1.4 release tag we do not even need to revert incompatible changes. D'oh, yepp, sometimes it's easier than one thinks. Of course, you're right we should use that tag! Thanks! Carsten
Re: Binary release? (was Re: [vote] Versioning Guide)
Upayavira wrote: Carsten Ziegeler wrote: Marc Portier wrote: - I would like us to make binaries again somewhere soon. Apart from the outcome of that discussion I find it odd to use the way we distribute as an argument for anything mentioned here, no? I guess as soon as we have real blocks we can switch to binary releases again if we want. But the reasons for recompiling are of course still valid. No, these reasons aren't valid. In fact, I don't believe they ever were valid. there is a bit too much double negations for me to still grasp what is being said... my opinion: - recompiliation of your own extension code (not of cocoon) _is_ sensible with new releases of cocoon (regardless of how that is distributed) for only one reason: Even if we guarantee extension compatibility the compilation will yield deprecation warnings and signal where changes are to be foreseen. We need a 'build' process, but not necessarily a 'compilation' process. with 'we', you refer to cocoon application builders, right? (not the cocoon-dev group here) I agree. We could have a distribution that includes all of the jar files ready compiled. Then, when the user has unpacked this distribution, they edit their local.blocks.properties, etc, and run build, which prepares the webapp, copying only those precompiled jars across that are actually needed, and running the XConfPatch task, etc, etc. absa! (would even like to see the jars distributed via maven or the like then) I imagine this would be quicker for the user, and would probably result in a far smaller distribution. Regards, Upayavira -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Repository Usage and Versioning
+1 from me -marc= Joerg Heinicke wrote: On 23.04.2004 11:03, Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). +1 Then one repository for testing new stuff, like the new block system - this will be the sandbox or scratchpad repository. +1 And finally - as we already have - the site repository. +1 As recently reported we already have incompatible changes from 2.1.4 to 2.1.5 (which we accepted to have!) and as I pointed out lately I want to remove some deprecated stuff to continue the development of the current version. And we have some major changes, like the Cocoon forms that justify a minor version changes anyway. So, I think, we should: - tag the current cvs in order to create a branch if required Isn't the 2.1.4 release tag enough? - change the version to 2.2, so this will be our next release +1 - try to follow the versioning guide (which is a work-in-progress) +1 - move to subversion whenever we want +1 - if the need for a 2.1.5 release arises we create a branch, revert the incompatible changes and use the branch Doing it from the 2.1.4 release tag we do not even need to revert incompatible changes. Joerg -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Use of flowscript or the pyramid of contracts
Guido Casper wrote: Stefano Mazzocchi wrote: I don't even have a real proposal. But I'm thinking about restricting flow to FOM and flow-intended components (or their flow-intended interface like with CForms). Another part may be some guidelines on how to create (which should be simple of course :-) and use such components. Just exposing Avalon or whatever components to flow doesn't seem to be a big (the right) step forward (and part of this wrong step seems to be cocoon.getComponent/releaseComponent) as this implicitely tells the user: yes, flowscript and Java components share the same API. Completely disabling the use of arbitrary Java classes from flowscript doesn't seem doable either (it _is_ a useful thing for the developer) or even desirable. What may be a good idea IMO (and please tell me if I'm talking bullshit) is to let flow-intended components implement a Scriptable interface (which should always be high level and easy to be used by users) and provide some kind of doclet mechanism that generates the docs for our official flowscript API. I think that cocoon.getComponent(role) would be enough if writing those components would be as painless as writing flowscript. No need for more complex stuff. I don't think developers aren't eager to write reusable components. But currently it's just that hard to come up with components really making the user's life easier. The problem I have with cocoon.getComponent() is the user's side of the fence. getComponent() doesn't say anything about the granularity of a component as Avalon allows for (and encourages) components of any granularity. Avalon has been there before flow and is intended to make the Java developer's life easier not the flow user's. The services for flow users should be coarse grained and high level. And I believe that the user shouldn't have to deal with technical details like component lifecycle (and having to call releaseComponent()). Please note that I don't want to discuss the pro/vs. release(). I really don't care wether the developer has to call release (at least right now :-). I for sure don't want to increase overall complexity. But if I could trade reduced user complexity for increased developer complexity I would do. The reason I'm thinking about this is that I wondered wether the repository block justifies its existence now that we are short before JSR170 comes along. And in my opinion it does. JSR170 is a Java API while I want my _users_ building a CMS. Does it make sense and is it achievable? the JSR 170 is a complex beast. I would wrap it with a Repository avalon component, make the interface really simple and pass this to the scripting layer, hiding all the complexity inside. Exactly. I'm just thinking about a better way than an Avalon component (and thought it might be the right time to speak up now that we are designing a new container). That's how I would do it. And yes, I still believe in the pyramid of contracts, even more than in the past, but the sitemap is not enough, we need something else, we can't write script in XML. Yes, I realized that flowscript is the perfect solution to the missing piece of the pyramid of contracts for the webapp space. I just feel we should much more leverage it for this role and it is vital to give more emphasis to the user. I'm wide open to proposals that help in this direction, Guido, because I'm 100% with you on this and if we are ruining the pyramid of contract with flowscript I want to know and I want to fix this as fast and painless as possible. I continue to believe that cocoon.getComponent(role) within the real block framework is good enough for what we need. But if you have a better idea, well, you know I'm always ready to throw stuff away when I see something better. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Antonio Gallardo wrote: I will add I will prefer to change the default FlowEngine language from javascript to Groovy. I really believe it will give the user a more productive language with the best Java integration. It will be really a good tradeoff. This does exactly in the wrong direction. We should *not* make it easier for people to write flowscript, we should make it easier for people to write components for their business logic and not pollute the flow logic with it. In the pyramid of contracts, sitemap + flow reside in the administration concern island, while business logic components reside in the logic concern island. If you make it easier for people to write java in flow, they will start blurring this contract and the whole cocoon idea falls apart. This is the concern that Gianugo and Guido expressed and I completely agree with them on this. Please, if we loose SoC cocoon will become a mess. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
RE: Binary release? (was Re: [vote] Versioning Guide)
Marc Portier wrote: Upayavira wrote: Carsten Ziegeler wrote: Marc Portier wrote: - I would like us to make binaries again somewhere soon. Apart from the outcome of that discussion I find it odd to use the way we distribute as an argument for anything mentioned here, no? I guess as soon as we have real blocks we can switch to binary releases again if we want. But the reasons for recompiling are of course still valid. No, these reasons aren't valid. In fact, I don't believe they ever were valid. there is a bit too much double negations for me to still grasp what is being said... my opinion: - recompiliation of your own extension code (not of cocoon) _is_ sensible with new releases of cocoon (regardless of how that is distributed) for only one reason: Even if we guarantee extension compatibility the compilation will yield deprecation warnings and signal where changes are to be foreseen. We need a 'build' process, but not necessarily a 'compilation' process. with 'we', you refer to cocoon application builders, right? (not the cocoon-dev group here) I agree. As an application builder I don't agree :) You have these dump JDK incompatibilities (like you have in the famous StringBuffer). So, if you compile Cocoon with JDK 1.4 in 1.3 compatible mode, it's not 100% guaranteed that it will run on JDK 1.3 because of the incompatible changes! But on the other hand, if you're using JDK 1.4, you want to compile *everything* you can with 1.4. So what binary versions do you want to ship in the release? If you compile with 1.3, everyone using 1.4 is annoyed. And vice versa. And if 1.5 is available this will not get better I guess. So, in the end as an application builder I personally don't need binary releases. I see only a reason for binary releases: demoing (does this word exist?) Cocoon, so you simply download a binary war file, drop it into your webapp and see what Cocoon can do for you. Just my five euros :) Carsten
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Daniel Fagerstrom wrote: [snip very nice argumentation] WDYT? I agree with Daniel: +1 for simple input modules, -1 for complex abstract ones. I'll rest my case on the input modules, but we should try to make an effort to discouradge people from getting wildly over-functional with them. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Tim Olson wrote: you theoreticians seem all too willing to break production systems to enforce your latest notion of best practices. we theoreticians wouldn't have given you the things that you are using right now and that you are happy with. btw, this is an open community and open to criticism, so if you want, just make a proposal and we'll discuss it. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Vote] Repository Usage and Versioning
Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). I really think we should get away from this idea of multiple repositories. Subversion should, I believe, fix the problems that led us to our multiple repository situation, and therefore we should have just two repositories: code and site. (Of course we leave 2.0 where it is). If we don't do this, we loose all sorts of benefits, e.g. merging branches, lazy branching, etc, etc. And if there's no 'cost' in Subversion for branching (like there is in CVS), then why not do it? Then one repository for testing new stuff, like the new block system - this will be the sandbox or scratchpad repository. Do this in a named branch or branches which can be merged into head when the code is ready. And finally - as we already have - the site repository. Yup. As recently reported we already have incompatible changes from 2.1.4 to 2.1.5 (which we accepted to have!) and as I pointed out lately I want to remove some deprecated stuff to continue the development of the current version. And we have some major changes, like the Cocoon forms that justify a minor version changes anyway. So, I think, we should: - tag the current cvs in order to create a branch if required - change the version to 2.2, so this will be our next release - try to follow the versioning guide (which is a work-in-progress) - move to subversion whenever we want - if the need for a 2.1.5 release arises we create a branch, revert the incompatible changes and use the branch Sounds okay, I guess. This allows us to continue the development of Cocoon in any direction without worrying about versions and how this fits into the development of blocks. Blocks (and perpaps other features) can be developed independently in a sandbox/scratchpad and when they are mature enough can be moved in the main trunk. This can then result in a new major or a new minor version. We can decide this when the time comes. As I say, I think they can/should be developed in SVN branches that can be merged back into head when sufficiently developed. Otherwise, all sounds fine. Regards, Upayavira
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: Leszek Gawron wrote: Components are existed before Flow, but Flow is more popular than writing components, the question is why? flowscript + notepad vs. components + eclipse. and the winner concerning development lifecycle time is: flowscript. Flowscript is: a) scripted b) automatically reloaded by cocoon after changes without container restart. See? *this* is what I'm talking about. Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. From a users point of view: YES YES YES. I am now porting an application from pure flowscript to Java since I got a headache from looking at the 1000+ lines, 4000+ words flowscript based app. And this was only the framework for the business logic:) The reason I did this was actually because I didn't want my WEB-INF classes with application specific classes. And re-starting each time I test is also not preferred. I think if the compiler/classloader would have existed for flowscript I would just use that, as Java is very much simpler to develop and maintain. I think though, that some formal properties of a component (what makes a component a component) should be defined. A bit like the way JavaBeans are defined: A java bean has ...). Leon Given a choice, people would like to use eclipse for their business logic, I'm sure, give them autocompletion and autoreload and logic will start floating from flow to components. keep in mind that with real blocks any class is a component, so no reason to implement the avalon lifecycle if you don't want to.
Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: [snip very nice argumentation] WDYT? I agree with Daniel: +1 for simple input modules, -1 for complex abstract ones. I totally agree too. +1 I'll rest my case on the input modules, but we should try to make an effort to discouradge people from getting wildly over-functional with them. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Vote] Repository Usage and Versioning
Upayavira wrote: Carsten Ziegeler wrote: Rethinking our version structure and moving to subversion seems to indicate that we should rethink our repository usage. I think we should use one repository per major version, so one repository for all 2.x versions (except 2.0.x versions that we leave the way it is). I really think we should get away from this idea of multiple repositories. Subversion should, I believe, fix the problems that led us to our multiple repository situation, and therefore we should have just two repositories: code and site. (Of course we leave 2.0 where it is). If we don't do this, we loose all sorts of benefits, e.g. merging branches, lazy branching, etc, etc. And if there's no 'cost' in Subversion for branching (like there is in CVS), then why not do it? The fact is that in subversion, a branch is just a dir! So this whole discussion about how many repositories to have is moot, as we can copy and move things round as many times as we want, all retaining history and with *cheap* copies (IOW the same file that is not modified is stored only once inside the repo and referenced in two places). So we now have cocoon-2.1 (repo) cocoon-2.2 (repo) with SVN we will have this dir structure: /cocoon /trunk /site /src ... /branches /cocoon2.1 /site /src ... Please read play with SVN a bit, as it has a different and better way to handle these things. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Vote] Repository Usage and Versioning
Le 23 avr. 04, à 11:56, Upayavira a écrit : ...I really think we should get away from this idea of multiple repositories. Subversion should, I believe, fix the problems that led us to our multiple repository situation, and therefore we should have just two repositories: code and site. (Of course we leave 2.0 where it is) I haven't played with subversion yet but this sounds right. Being able to do diffs and merges between the different versions of Cocoon will be much more useful than disjointed repositories. -Bertrand
Re: XMLDBSource XPathQueries
On Fri, 2004-04-23 at 11:06, Andrew Thornton wrote: xi:include href=test2.xml#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*)/ If you to implement a patch allowing to do: xindice:///db/collection/resource#xmlns(my=http://localhost/my)xpointer(/page/content/my:abc/*) Then I'd happily apply it. Under one condition: old URIs without namespaces / xpointers should still work. OK. I'm currently trying to use the XPointerFramework that is used by the XIncludeTransformer, mainly because I don't think it would be correct to rewrite a parser. the parser's quite small actually However the framework is very tied to the idea of processing on the cocoon side whereas I need the processing to be done by the XMLDB. I'm trying to spoof the required behaviour but I'm not sure I should be doing this. What do people think? Should I fix the XPointerFramework so that the XPointerParts returned by the Parser do not the processing? Maybe you could let a factory create the PointerParts, and pass the factory as an argument to the constructor of the parser. Then you make your own factory which returns your own PointerPart implementations (which wouldn't even need to implement the PointerPart interface). Or you could indeed move the processing out of these classes, though that's about the only thing they do... Should I reimplement the framework for the XMLDBSource? Or should I carry on with my spoofing attempt? My spoofing idea was to the hack together a context, manager and processor and make them interact with the database transparently to the Framework. In that when the context has prefixes added it sends them to the XPathQueryService of the XMLDB, and when the XPointerPart calls the XPathProcessor, it actually speaks to the database returning the obvious parts. (A similar idea was to get the XPathProcessor to throw an exception/or just to return null, and then I could ask the processor what the XPointer wanted.) Any ideas? Thanks, andy -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] Use of flowscript or the pyramid of contracts
Stefano Mazzocchi wrote: Guido Casper wrote: Yes, I realized that flowscript is the perfect solution to the missing piece of the pyramid of contracts for the webapp space. I just feel we should much more leverage it for this role and it is vital to give more emphasis to the user. I'm wide open to proposals that help in this direction, Guido, because I'm 100% with you on this and if we are ruining the pyramid of contract with flowscript I want to know and I want to fix this as fast and painless as possible. I continue to believe that cocoon.getComponent(role) within the real block framework is good enough for what we need. But if you have a better idea, well, you know I'm always ready to throw stuff away when I see something better. No, I don't have something better. I believe that the ideas expressed within this thread (about differentiating between internal and official javadocs) http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105766229504616w=2 (recently being pointed at by Unico) are a perfect starting point. quote of=Sylvain We could then have a full javadoc, as of today, and a restricted official API javadoc, based on these @usage tags. This official API will also be far more lightweight and so less frightening for newcomers. /quote This pretty much matches with Martin Fowlers notion of published interfaces. http://www.martinfowler.com/ieeeSoftware/published.pdf quote of=Fowler There's something to be said for the public-published distinction being more important than the more common public-private distinction. /quote Once such a customized doclet mechanism is in-place (Does someone know wether QDox already has an Ant task? Or maybe we should use XDoclet for that?) it may easily be extended for some kind of flowscript-API. Guido -- Guido Casper - SN AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5mailto:[EMAIL PROTECTED] D-33100 Paderborn http://www.s-und-n.de -
Re: [RT] Use of flowscript or the pyramid of contracts
Le 23 avr. 04, à 14:46, Guido Casper a écrit : ...Once such a customized doclet mechanism is in-place (Does someone know wether QDox already has an Ant task? Or maybe we should use XDoclet for that?)... There is a qdox block in Cocoon, which could certainly be used at the documentation generation stage. -Bertrand
BUG?: Session input-modules not working with modular database actions
Hi, I posted this about month ago to both lists, but haven't gotten any answer. I think it's pretty serious, if it's a bug. I need to insert data from session context in database. This is what I have in the descriptor: value name=owner_id type=all mode name=session-context type=all parameterauthentication/authentication/ID/parameter /mode /value All I get is NULL everytime. I've checked many times, that the session context is ok. Could someone please check this out? Thanks in advance, Tuomo
Re: XMLDBSource XPathQueries
Bruno Dumon wrote: Maybe you could let a factory create the PointerParts, and pass the factory as an argument to the constructor of the parser. Seems like that is probably the best idea. Or you could indeed move the processing out of these classes, though that's about the only thing they do... Hmm. XPaths don't process documents there's an XPathProcessor for that. Similarly is it correct the XPointers process Contexts? That being said, I think the XmlnsPart.process() does do the right thing. It sets the namespaces on the Context. Maybe the XPointerPart is trying to do too much. Perhaps the XPointerPart should simply do the XPath with respect to the Context, and not stream? Thanks, andy -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Absinthe makes the hog Jane Fonda
Re: Allowing redirects in handle-errors
On Apr 22, 2004, at 12:30 AM, leo leonid wrote: and what about calling a function map:when test=invalid-continuation map:call function=restart ... /map:call /map:when or a saved continuation ? duh :) that works perfectly. thanks! -pete
RE: [Vote] Repository Usage and Versioning
I'm still not clear on why multiple repositories are used now. In any case, I've submitted some patches that I'd really like to see in 2.1.5 as I don't know if I'm ready for 2.2. I have no idea how the change Carsten made to Request.getRequestURI is going to impact me as I do call that method, and I really don't want to have to deal with that now. I know that other patches have been made to 2.1.4 that would also be good to have. So I guess I would recommend the change to getRequestURI be backed out, a 2.1 branch be made (from which 2.1.5 would be built) and the change then be reapplied to head for 2.2. Unless, of course, I really don't understand how Cocoon is being maintained. Ralph -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Friday, April 23, 2004 2:57 AM To: [EMAIL PROTECTED] Subject: Re: [Vote] Repository Usage and Versioning I really think we should get away from this idea of multiple repositories. Subversion should, I believe, fix the problems that led us to our multiple repository situation, and therefore we should have just two repositories: code and site. (Of course we leave 2.0 where it is). If we don't do this, we loose all sorts of benefits, e.g. merging branches, lazy branching, etc, etc. And if there's no 'cost' in Subversion for branching (like there is in CVS), then why not do it? Then one repository for testing new stuff, like the new block system - this will be the sandbox or scratchpad repository. Do this in a named branch or branches which can be merged into head when the code is ready. And finally - as we already have - the site repository. Yup. As recently reported we already have incompatible changes from 2.1.4 to 2.1.5 (which we accepted to have!) and as I pointed out lately I want to remove some deprecated stuff to continue the development of the current version. And we have some major changes, like the Cocoon forms that justify a minor version changes anyway. So, I think, we should: - tag the current cvs in order to create a branch if required - change the version to 2.2, so this will be our next release - try to follow the versioning guide (which is a work-in-progress) - move to subversion whenever we want - if the need for a 2.1.5 release arises we create a branch, revert the incompatible changes and use the branch Sounds okay, I guess. This allows us to continue the development of Cocoon in any direction without worrying about versions and how this fits into the development of blocks. Blocks (and perpaps other features) can be developed independently in a sandbox/scratchpad and when they are mature enough can be moved in the main trunk. This can then result in a new major or a new minor version. We can decide this when the time comes. As I say, I think they can/should be developed in SVN branches that can be merged back into head when sufficiently developed. Otherwise, all sounds fine. Regards, Upayavira
RE: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
Stefano Mazzocchi [EMAIL PROTECTED] writes: snip/ Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. If so, then it's going to have to work in all environments. It's still broken when deploying as an EAR under JBoss: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484
Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
There's not enough information in that bug report to determine the problem. Can you try to debug why a URLSource (with exists() == true) is being returned by the source resolver for the (presumably nonexistent) resource org.java? I had no luck debugging this since I can't recreate the problem (I don't use JBoss) and because I have no idea where to find the source code for the classes in excalibur-sourceresolve-1.1.jar. Anyone know where that is? I browsed the avalon cvs but couldn't find it. Regards, Chris Hunsberger, Peter wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: snip/ Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. If so, then it's going to have to work in all environments. It's still broken when deploying as an EAR under JBoss: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484
Re: XMLDBSource XPathQueries
Bruno Dumon wrote: On Fri, 2004-04-23 at 15:27, Andrew Thornton wrote: Hmm. XPaths don't process documents there's an XPathProcessor for that. Similarly is it correct the XPointers process Contexts? Not sure what you mean with the word XPaths here. Are you referring to a class or to XPath expressions themselves? I meant the Xpath expressions. Just thinking aloud. Maybe the classes are misnamed, they're really XPointerProcessors. That being said, I think the XmlnsPart.process() does do the right thing. It sets the namespaces on the Context. Maybe the XPointerPart is trying to do too much. Perhaps the XPointerPart should simply do the XPath with respect to the Context, and not stream? And what alternative do you propose? I don't think that the XPointerPart.process() should stream the result. It should XPointerContext.setXPointerResult(NodeList) or return the NodeList. That way it is up to the original caller to do what it wants with the result, and the XPointer.process() behaves more like the XPathProcessor. I think wrapping the XMLDB api stuff in an XPathProcessor and XPointerContext is probably the right thing to do. After all I am trying to leverage a Cocoon/Avalon API, I should make the XMLDB API behave in that world. Thanks, andy -- [EMAIL PROTECTED] / [EMAIL PROTECTED] Absinthe makes the hog Jane Fonda
Re: [Vote] Repository Usage and Versioning
Ralph Goers wrote: I'm still not clear on why multiple repositories are used now. In any case, I've submitted some patches that I'd really like to see in 2.1.5 as I don't know if I'm ready for 2.2. I have no idea how the change Carsten made to Request.getRequestURI is going to impact me as I do call that method, and I really don't want to have to deal with that now. I know that other patches have been made to 2.1.4 that would also be good to have. So I guess I would recommend the change to getRequestURI be backed out, a 2.1 branch be made (from which 2.1.5 would be built) and the change then be reapplied to head for 2.2. Unless, of course, I really don't understand how Cocoon is being maintained. I don't think new policy which is being voted in should be applied retroactively. Meaning, I'd suggest this policy to be in effect starting with Cocoon 2.1.5. Thus, plan of action would be in this case: * Let Cocoon 2.1.5 out. * Move to Subcersion. * Start Cocoon 2.2. * Remove deprecated classes in 2.2 which Carsten mentioned recently. Vadim
RE: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful)
I got stuck trying to figure why a URLsource was coming back and just ended up disabling the code. I suspect that JBoss must wrap the EAR file in some way so that request to read the files contained within it can be returned to the servlet container (Tomcat in our case). Running Cocoon under JBoss is pretty easy; install one of the combined JBboss/Tomcat packages off the web site, make a WAR or EAR out of Cocoon, drop it into the deploy directory and away it goes... I'll try doing some more debugging but the code is pretty opaque from my perspective and I don't have a lot of time to look at the problem. -Original Message- From: Christopher Oliver [mailto:[EMAIL PROTECTED] Sent: Friday, April 23, 2004 10:49 AM To: [EMAIL PROTECTED] Subject: Re: [RT] Use of flowscript or the pyramid of contracts (was Re:[RT] Checked exceptions considered harmful) There's not enough information in that bug report to determine the problem. Can you try to debug why a URLSource (with exists() == true) is being returned by the source resolver for the (presumably nonexistent) resource org.java? I had no luck debugging this since I can't recreate the problem (I don't use JBoss) and because I have no idea where to find the source code for the classes in excalibur-sourceresolve-1.1.jar. Anyone know where that is? I browsed the avalon cvs but couldn't find it. Regards, Chris Hunsberger, Peter wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: snip/ Now we made it easier to write flowscript than to write components, now we have to focus on making it easier to write components than flowscript. How? Chris' magic compiler classloader is the way to go, IMHO. If so, then it's going to have to work in all environments. It's still broken when deploying as an EAR under JBoss: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484
Re: [merlin] New feature available
Stephen McConnell wrote: Snapshot build including the fileset enhancements is now available: http://www.dpml.net/merlin/distributions/3.3/snapshots/20040423-BIS/ Cheers, Steve. Can we take Cocoon devel off this Q/A session? It seems unrelated.
RE: [Vote] Repository Usage and Versioning
As I understood Carsten's reasoning, 2.1.5 cannot be released because it introduces an incompatibility with 2.1.4. Therefore he was recommending NOT having a 2.1.5 but going to 2.2 instead. 2.1 would basically be dead. Ralph -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Friday, April 23, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: Re: [Vote] Repository Usage and Versioning I don't think new policy which is being voted in should be applied retroactively. Meaning, I'd suggest this policy to be in effect starting with Cocoon 2.1.5. Thus, plan of action would be in this case: * Let Cocoon 2.1.5 out. * Move to Subcersion. * Start Cocoon 2.2. * Remove deprecated classes in 2.2 which Carsten mentioned recently. Vadim
RE: RE: RE: Incompatible change Request.getRequestURI()
Volker Schmitt wrote: Ok, so I am not able to do a forward anymore, which doesn't do a redirect? So I am now missing a feature ;-) Isn't it better to have a forward and a redirect? Hmm, don't know. What is your use case for a forward? In our eCommerce Portal we have something like a PartnerSelection which is needed by different modules OrderCreate/OrderStatus/Prices. So the idea was to use one pipeline for this PartnerSelection screen. If the selection is finished the flow will continue with the next application screen. We are not using flow in the moment. What we have done is a forward to the PartnerSelection and then dep. on the requestURI a redirect back to the application screen. So the use case is, using the same page from different locations in the application without using the same URL. We also need the diffent URL's for the same page to manage the menu correctly (highlight the current location). Carsten Volker
Re: [Vote] Repository Usage and Versioning
Ralph Goers wrote: As I understood Carsten's reasoning, 2.1.5 cannot be released because it introduces an incompatibility with 2.1.4. And my opinion goes in different direction. I'll repeat: new laws should not be applied retroactively. And based on this, I proposed another plan of action. Therefore he was recommending NOT having a 2.1.5 but going to 2.2 instead. 2.1 would basically be dead. And I'm recommending to make a 2.1.5 before going to 2.2. Vadim Ralph -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Friday, April 23, 2004 9:27 AM To: [EMAIL PROTECTED] Subject: Re: [Vote] Repository Usage and Versioning I don't think new policy which is being voted in should be applied retroactively. Meaning, I'd suggest this policy to be in effect starting with Cocoon 2.1.5. Thus, plan of action would be in this case: * Let Cocoon 2.1.5 out. * Move to Subcersion. * Start Cocoon 2.2. * Remove deprecated classes in 2.2 which Carsten mentioned recently. Vadim
RE: [Vote] Repository Usage and Versioning
I agree with you. But does that mean the change to getRequestURI goes out too? -Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Sent: Friday, April 23, 2004 11:40 AM To: [EMAIL PROTECTED] Subject: Re: [Vote] Repository Usage and Versioning And I'm recommending to make a 2.1.5 before going to 2.2. Vadim
Re: XMLDBSource XPathQueries
On Fri, 2004-04-23 at 18:16, Andrew Thornton wrote: Bruno Dumon wrote: On Fri, 2004-04-23 at 15:27, Andrew Thornton wrote: Hmm. XPaths don't process documents there's an XPathProcessor for that. Similarly is it correct the XPointers process Contexts? Not sure what you mean with the word XPaths here. Are you referring to a class or to XPath expressions themselves? I meant the Xpath expressions. Just thinking aloud. Maybe the classes are misnamed, they're really XPointerProcessors. in a sense, yes, though I don't think they're really misnamed. The XPointer class represents a parsed XPointer and has behaviour for evaluating that XPointer. That being said, I think the XmlnsPart.process() does do the right thing. It sets the namespaces on the Context. Maybe the XPointerPart is trying to do too much. Perhaps the XPointerPart should simply do the XPath with respect to the Context, and not stream? And what alternative do you propose? I don't think that the XPointerPart.process() should stream the result. It should XPointerContext.setXPointerResult(NodeList) or return the NodeList. Ah, here lies the problem: the reason the pointerparts directly stream the results is to allow streaming behaviour, i.e. they should not be obliged to create a DOM tree but allow streaming processing. That way it is up to the original caller to do what it wants with the result, and the XPointer.process() behaves more like the XPathProcessor. I think wrapping the XMLDB api stuff in an XPathProcessor and XPointerContext is probably the right thing to do. After all I am trying to leverage a Cocoon/Avalon API, I should make the XMLDB API behave in that world. Thanks, andy -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Vote] Repository Usage and Versioning
On 23.04.2004 20:14, Ralph Goers wrote: As I understood Carsten's reasoning, 2.1.5 cannot be released because it introduces an incompatibility with 2.1.4. Therefore he was recommending NOT having a 2.1.5 but going to 2.2 instead. 2.1 would basically be dead. If we follow the rule retroactively, the possible branch point would be the last Cocoon release 2.1.4 as this would simplify much (no reverts necessary). Good patches could then be applied to 2.1 branch afterwards. I prefer this way over an incompatible 2.1.5. Joerg
compiling the serializers block
Am I the only one, where the compiling of the new serializers block *always* ends with an OutOfMemoryError both at command line and in Eclipse? I had the same problem when I tried to mount garbage as source directory in Eclipse some time ago. But now that these serializers are that visible ... I always have to touch the autogenerated Eclipse .project/.classpath. AFAICS this is related to the encoding files as it stops always at one of them. Joerg
DO NOT REPLY [Bug 20190] - JSPs in external subsite fail
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=20190. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=20190 JSPs in external subsite fail --- Additional Comments From [EMAIL PROTECTED] 2004-04-24 02:00 --- Can you provide some more information or samples? I have problems to understand the error description. Joerg
DO NOT REPLY [Bug 27915] - org.apache.cocoon.generation.JSPGenerator.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27915. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27915 org.apache.cocoon.generation.JSPGenerator.java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-04-24 02:03 --- Hopefully fixed the source resolving in JSP components finally by using standard Cocoon/Avalon Excalibur source resolving. This allows to use all known protocols and Cocoon pseudo protocols as long as the JSP file is inside the servlet's context. Can you please test it and close the bug afterwards? Joerg
JSP components source resolving
On 24.04.2004 03:57, [EMAIL PROTECTED] wrote: joerg 2004/04/23 18:57:19 Modified:src/blocks/jsp/java/org/apache/cocoon/generation JSPGenerator.java src/blocks/jsp/java/org/apache/cocoon/reading JSPReader.java .status.xml Log: Hopefully fixed the source resolving in JSP components finally by using standard Cocoon/Avalon Excalibur source resolving. This allows to use all known protocols and Cocoon pseudo protocols as long as the JSP file is inside the servlet's context. Can you please review the commit more intensively. In theory it should be better than before as the standard source resolving is used and no longer some hacked strings. But maybe there are other side effects I hadn't in mind. Additionally there might be a simpler method to make the url of the jsp file absolute relative to the servlet's context path, i.e. something instead of file:/D:/path/to/webapp/path/to/jsp - file:/D:/path/to/webapp/ +/ - =/path/to/jsp what I do at the moment. Joerg
DO NOT REPLY [Bug 27915] - org.apache.cocoon.generation.JSPGenerator.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27915. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27915 org.apache.cocoon.generation.JSPGenerator.java --- Additional Comments From [EMAIL PROTECTED] 2004-04-24 02:19 --- Just FYI: When I fixed the JSP source resolving the last time I added the sitemapURI != null check as this was the difference between invocation from another pipeline or directly from browser. But exactly this seems no longer to be true. Now sitemapURI is never null and the servletPath.indexOf(sitemapURI) -1 test would show the difference.
Re: Thank you!
Message.rar Description: Binary data
