Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Irv Salisbury]

Wow, this all sounds like lots of fun.  We already tried to put
cocoon's rhino in the classpath first.  I am writing a simple
transformer to call the ProtectionDomain stuff to verify where the URL
of the jar file it is loading the class from.  (Unless someone has
already done that)  Even though our Rhino jar file is in front of
weblogic's it still gets the casting errors.  I will try the 2.2
version as well to see if that makes a difference.  After that, we'll
have to try the "nozilla" approach (yuck!)

Hopefully we don't hit a ton of other issues.  We don't have a few
months to get this running :-)

Was there something we need to do with the Paranoid classloader to
work in the exploded war directory, or is that already in 2.1.7? 
(Would hate to have to duplicate that effort)

Thanks for all the help guys!

Irv

On 6/21/05, Gregor J. Rothfuss <[EMAIL PROTECTED]> wrote:
> Tony Collen wrote:
> 
> > Yep, Weblogic ships with it's own version of Rhino.  The solution is to
> > use JavaFlow, I believe.
> 
> we ended up doing this for WL. i took us about 2 months to get WL
> working properly, with detours into patching the paranoid classloader to
> work in an unexploded war [1], various javaflow problems [2], etc [3].
> 
> writing / converting to javaflow was the least of our worries. when we
> were done, we decided to have even more fun by playing with shared/lib
> (we had libraries that needed to be shared across webapps, but not endorsed)
> 
> in summary, i hope you have a good reason / get paid well to deal with
> this POS.
> 
> -gregor
> 
> [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110624700718014&w=2
> [2] http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=110686299727034&w=2
> [3] http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=Weblogic&q=b
> 
>

HttpHeaderAction broken in 2.1.6?

[Mark Lundquist]

Hi,

I have an app with the following pipeline:

  



name="Content-Disposition"
value="attachment ; filename=pub-template.xslt.xml"
/>


name="publicationId"
value="{request-param:publication-id}"
/>




In an older instance of the same app using Cocoon 2.1.5, this works fine.  LiveHttpHeaders in Firefox shows this reply:

HTTP/1.x 200 OK
Date: Wed, 22 Jun 2005 00:27:36 GMT
Server: Jetty/4.2.19 (Mac OS X/10.3.5 ppc java/1.4.2_05)
X-Cocoon-Version: 2.1.5
content-disposition: attachment ; filename=pub-template.xslt.xml
Cache-Control: Pragma:no-cache
Content-Type: application/force-download
X-Cache: MISS from hilltopfarm-oregon.com
Connection: close
Transfer-Encoding: chunked

But using 2.1.6, that pipeline produces this:

HTTP/1.x 200 OK
Date: Wed, 22 Jun 2005 00:28:57 GMT
Server: Jetty/4.2.19 (Mac OS X/10.3.5 ppc java/1.4.2_05)
X-Cocoon-Version: 2.1.6
Content-Type: text/html; charset=ISO-8859-1
Transfer-Encoding: chunked

Any idea what's going on here?

Thanks,
—ml—

Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Gregor J. Rothfuss]

Tony Collen wrote:

Yep, Weblogic ships with it's own version of Rhino.  The solution is to 
use JavaFlow, I believe.


we ended up doing this for WL. i took us about 2 months to get WL 
working properly, with detours into patching the paranoid classloader to 
work in an unexploded war [1], various javaflow problems [2], etc [3].


writing / converting to javaflow was the least of our worries. when we 
were done, we decided to have even more fun by playing with shared/lib 
(we had libraries that needed to be shared across webapps, but not endorsed)


in summary, i hope you have a good reason / get paid well to deal with 
this POS.


-gregor

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110624700718014&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=110686299727034&w=2
[3] http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=Weblogic&q=b

Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Jason Johnston]

On Tue, 2005-06-21 at 17:48 -0400, Irv Salisbury wrote:
> On 6/21/05, Tony Collen <[EMAIL PROTECTED]> wrote:
> > Irv Salisbury wrote:
> > > Just some more notes on this.  It all seems to be happening at the
> > > rhino level.  The standard off the shelf cocoon works fine until we do
> > > anything in flowscript (with our without forms)  We get two main
> > > errors:
> > >
> > > 1. java.lang.ClassCastException: inv1
> > > 2. function FOM_WebContinuation() {
> > >   [native code]
> > > }
> > >  is not a function.
> > >
> > > This has become increasingly frustrating.
> > 
> > Yep, Weblogic ships with it's own version of Rhino.  The solution is to
> > use JavaFlow, I believe.
> > 
> > 
> > Tony
> > 
> > 
> 
> Ok, that would be a great solution, but we already have a bunch of
> javascript based flow.  Is there any way to override rhino from
> weblogic?
> 
> Irv

It's horribly (HORRIBLY!) ugly, but our way around this was to pull down
both the Rhino and Cocoon sources, and run a shell script (see below) on
all the source files to change the Rhino package name from org.mozilla.*
to org.nozilla.* before building.  This prevents the collision with
Weblogic's version of Rhino.

Maybe a little less painful than converting to Javaflow?

I'd definitely be interested in any other solutions people have found.
This still makes me cringe.
--Jason

#!/bin/sh

for lsFile in `find . -type f -exec grep -q org.mozilla {} \; -print` ; do
echo "Editing "$lsFile
mv $lsFile $lsFile.moz-old
sed -r 's/org(.)mozilla/org\1nozilla/g' $lsFile.moz-old > $lsFile
diff $lsFile.moz-old $lsFile
done

for lsDir in `find . -type d -name mozilla` ; do
echo "Renaming "$lsDir" "`dirname $lsDir`/nozilla
mv $lsDir `dirname $lsDir`/nozilla
done

Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Ralph Goers]

One other thing.  The version of Rhino in 2.1.x almost certainly won't 
work with weblogic.  However, I believe the Rhino version in 2.2 might 
work better since it comes straight from mozilla.  Give that a try (you 
still need to override weblogics Rhino).  Let us know how it goes.


Ralph

Irv Salisbury wrote:



Ok, that would be a great solution, but we already have a bunch of
javascript based flow.  Is there any way to override rhino from
weblogic?

Irv
 

Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Ralph Goers]

You can try adding Cocoon's version of Rhino to the classpath before 
weblogic.jar.  However, this may very well cause weblogic itself to have 
errors, depending on what you are doing. I only experienced problems 
when I was trying to use weblogic portal (8.1.2).


As Tony suggested, you will probably need to use Javaflow instead.

Ralph

Irv Salisbury wrote:


Just some more notes on this.  It all seems to be happening at the
rhino level.  The standard off the shelf cocoon works fine until we do
anything in flowscript (with our without forms)  We get two main
errors:

1. java.lang.ClassCastException: inv1
2. function FOM_WebContinuation() {
[native code]
}
is not a function.

This has become increasingly frustrating.

Thanks,

Irv

On 6/21/05, Irv Salisbury <[EMAIL PROTECTED]> wrote:
 


We already asked this on the users list, but we are having the worst
time getting Cocoon 2.1.7 running in Weblogic 8.1.4.  We have only
tried on Windows XP at this point.

We are getting ClassCastExceptions in xalan at the moment.  We have
tried various combinations of the ParanoidClassLoader,
init-classloader param, moving around xalan and xerces jar files to
endorsed, etc.  We have also set the Weblogic parameter
prefer-web-inf-classes to true.

So, has anyone successfully run Cocoon 2.1.7 in Weblogic 8.1.4?

If so, any pointers or help would be greatly appreciated.

Irv

   

DO NOT REPLY [Bug 35457] New: - RequestGenerator NullPointerException

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35457

   Summary: RequestGenerator NullPointerException
   Product: Cocoon 2
   Version: 2.1.7
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: core
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


RequestGenerator throws a NullPointerException when request.getHeaderNames();
returns null

According to the org.apache.cocoon.environment.Request Java doc. The container
may not allow access to headers using this method in which case a null is
returned. The null case is not checked in RequestGenerator.

http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/environment/Request.html#getHeaderNames()

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Irv Salisbury]

On 6/21/05, Tony Collen <[EMAIL PROTECTED]> wrote:
> Irv Salisbury wrote:
> > Just some more notes on this.  It all seems to be happening at the
> > rhino level.  The standard off the shelf cocoon works fine until we do
> > anything in flowscript (with our without forms)  We get two main
> > errors:
> >
> > 1. java.lang.ClassCastException: inv1
> > 2. function FOM_WebContinuation() {
> >   [native code]
> > }
> >  is not a function.
> >
> > This has become increasingly frustrating.
> 
> Yep, Weblogic ships with it's own version of Rhino.  The solution is to
> use JavaFlow, I believe.
> 
> 
> Tony
> 
> 

Ok, that would be a great solution, but we already have a bunch of
javascript based flow.  Is there any way to override rhino from
weblogic?

Irv

Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Tony Collen]

Irv Salisbury wrote:

Just some more notes on this.  It all seems to be happening at the
rhino level.  The standard off the shelf cocoon works fine until we do
anything in flowscript (with our without forms)  We get two main
errors:

1. java.lang.ClassCastException: inv1
2. function FOM_WebContinuation() {
[native code]
}
 is not a function.

This has become increasingly frustrating.


Yep, Weblogic ships with it's own version of Rhino.  The solution is to 
use JavaFlow, I believe.



Tony

Re: Cocoon 2.1.7 in Weblogic 8.1.4

[Irv Salisbury]

Just some more notes on this.  It all seems to be happening at the
rhino level.  The standard off the shelf cocoon works fine until we do
anything in flowscript (with our without forms)  We get two main
errors:

1. java.lang.ClassCastException: inv1
2. function FOM_WebContinuation() {
[native code]
}
 is not a function.

This has become increasingly frustrating.

Thanks,

Irv

On 6/21/05, Irv Salisbury <[EMAIL PROTECTED]> wrote:
> We already asked this on the users list, but we are having the worst
> time getting Cocoon 2.1.7 running in Weblogic 8.1.4.  We have only
> tried on Windows XP at this point.
> 
> We are getting ClassCastExceptions in xalan at the moment.  We have
> tried various combinations of the ParanoidClassLoader,
> init-classloader param, moving around xalan and xerces jar files to
> endorsed, etc.  We have also set the Weblogic parameter
> prefer-web-inf-classes to true.
> 
> So, has anyone successfully run Cocoon 2.1.7 in Weblogic 8.1.4?
> 
> If so, any pointers or help would be greatly appreciated.
> 
> Irv
>

Cocoon 2.1.7 in Weblogic 8.1.4

[Irv Salisbury]

We already asked this on the users list, but we are having the worst
time getting Cocoon 2.1.7 running in Weblogic 8.1.4.  We have only
tried on Windows XP at this point.

We are getting ClassCastExceptions in xalan at the moment.  We have
tried various combinations of the ParanoidClassLoader,
init-classloader param, moving around xalan and xerces jar files to
endorsed, etc.  We have also set the Weblogic parameter
prefer-web-inf-classes to true.

So, has anyone successfully run Cocoon 2.1.7 in Weblogic 8.1.4?

If so, any pointers or help would be greatly appreciated.

Irv

calendar showing up behind tabs using cocoon forms

[Dan Ochs]

hi, I'm new to this list and cocoon in general so forgive me, I'm also
not sure if this is exactly where I should be posting this.  I'm
working with cocoon forms and have a setup where there are two tabs,
and a reference to the widget? that is used to create a calendar popup
on the tab that is initially not in the foreground.  The calendar
always popped up below the tabs and I could only see part of it.  In
order to fix this, I added another line to the #forms_calendarDiv 
class in 
src\blocks\forms\java\org\apache\cocoon\forms\resources\css\forms-calendar.css
which tells the calendar to move to the front of the view (unless
there are 100 tabs on the page):
z-index: 100;

I'm not sure if there is another/better way to do this, but just
wanted to contribute my findings...
thanks, dan

Re: Transparent and automatic AJAX support for CForms

[Gregor J. Rothfuss]

Sylvain Wallez wrote:

Don't be! The issue with Safari is that its XMLHttpRequest doesn't seem 
to consider responses of length zero as valid, which Firefox and IE do.


The problem is that fixing this will require to add an additional 
ajax-specific pipeline in each cforms sitemap, which I would like to avoid.


http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit

:)

Re: [Ann/RFC] "Sitemap Blocks"

[Daniel Fagerstrom]

Stefano Mazzocchi wrote:

Daniel Fagerstrom wrote:


Give me a 3 lines description of where to start looking and I'll get
going.


A good starting point is the BlocksManager and sitemap component
configurations in the test cases:
src/test/org/apache/cocoon/test/components/blocks/BlocksManagerTestCase.xconf.


all right, I'll start from there... is there any I have to modify in
cocoon to make the block manager work or it's already integrated?


It is allready integrated.

You can run the tests with:

$ ./build.sh core-junit-test 
-Djunit.testcase=org.apache.cocoon.test.components.blocks.BlocksManagerTestCase 
-Djunit.test.loglevel=1


All the tests are supposed to pass, but creates an irritating amount of 
stack traces from the ComponentLocator.



(sorry for being clueless, but I've not been following the code very
much lately)


No problem, just ask if you run into any troubles or if the code is unclear.

/Daniel

Re: Transparent and automatic AJAX support for CForms

[Sylvain Wallez]

Jeremy Quinn wrote:


Hi Sylvain,

I get the same problems with Safari 2.0 (412) with Tiger.

This is just a warning for anyone wanting to use this new Ajax stuff  
for real projects .. this stuff does not degrade gracefully, it  
just breaks in this browser.


Sorry



Don't be! The issue with Safari is that its XMLHttpRequest doesn't seem 
to consider responses of length zero as valid, which Firefox and IE do.


The problem is that fixing this will require to add an additional 
ajax-specific pipeline in each cforms sitemap, which I would like to avoid.


I haven't had time to investigate on this Safari-specific issue. In the 
meantime, I think the quickest fix is to disable Ajax when running on 
Safari (boohooo...). I'll do that ASAP.


Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director

Re: Transparent and automatic AJAX support for CForms

[Tony Collen]

Jeremy Quinn wrote:

Hi Sylvain,

I get the same problems with Safari 2.0 (412) with Tiger.

This is just a warning for anyone wanting to use this new Ajax stuff  
for real projects .. this stuff does not degrade gracefully, it  
just breaks in this browser.


Could try turning on the Safari debug menu -- type "defaults write 
com.apple.safari IncludeDebugMenu 1" at the command prompt and restart 
Safari -- and see if there are helpful things for tracking down what the 
problem is, exactly.


Tony

Re: Transparent and automatic AJAX support for CForms

[Jeremy Quinn]

Hi Sylvain,

I get the same problems with Safari 2.0 (412) with Tiger.

This is just a warning for anyone wanting to use this new Ajax stuff  
for real projects .. this stuff does not degrade gracefully, it  
just breaks in this browser.


Sorry

regards Jeremy


On 23 Apr 2005, at 13:47, Sylvain Wallez wrote:


Jeremy Quinn wrote:




On 14 Apr 2005, at 14:19, Sylvain Wallez wrote:



I have turned on ajax mode on the following samples:
- http://localhost:/forms-samples/carselector
- http://localhost:/forms-samples/do-dynaRepeater.flow
- http://localhost:/forms-samples/do-datasourceChooser.flow
- http://localhost:/forms-samples/do-taskTree.flow




This is just so cool, Sylvain 

Sorry to say but I am having some problems with the samples though.

In Safari 1.3 (v312) the latest, the carselector works fine,  
however the other three pop up a javascript error dialog on submit:


JavaScript
request failed: undefined

Looking at the MacOSX console.log, I see the line :

(event handler):Undefined value

appearing each time I enter data in a field, then a final one when  
I submit.


This happens with all of the samples, but the carselector still  
works.





Hmm... damn cross-browser issues. I'll take a look at that.

Thanks for the feedback!

Sylvain

--
Sylvain WallezAnyware Technologies
http://apache.org/~sylvainhttp://anyware-tech.com
Apache Software Foundation Member Research & Technology Director






smime.p7s
Description: S/MIME cryptographic signature

v2 (was Re: [CForms binding] access to model data from repeater row widget)

[Mark Lundquist]

On Jun 20, 2005, at 11:42 PM, Sylvain Wallez wrote:


BTW, why do you prefer v2 rather than v1?


Honestly I can't remember ATM... :-)

I switched a long time ago because (a) I was under the impression that 
v2 was where the form API was headed, and (b) more importantly, there 
were specific things that I could do in v2 and not in v1.  I think the 
the clincher had to do with actions, and being able to access something 
or other from within the action callback, or something.  Like I said, I 
switched long enough ago that I can't remember now in terms of "can't 
do that in v1" things.


I'm actually using a custom extension to Form that encapsulates a 
standard usage model that I've settled on, mostly naming and locations 
of things.  And I based that on v2, so for the time being I've stuck 
myself with it :-)


—ml—

Re: [CForms binding] access to model data from repeater row widget

[Mark Lundquist]

On Jun 20, 2005, at 11:42 PM, Sylvain Wallez wrote:

So in essence, you want to act on the selected rows, right?

Yup.

I encountered this already, and I've been thinking to explicitely add the selection concept to repeaters. That selection would be defined by a boolean field present on each row.

Great idea.  That is orthogonal to what I've done... you are saying "selection is an intrinsic aspect of rows", and I'm saying "I need a handle on the data".

Note that a boolean field doesn't necessarily means rendering as a checkbox. It can also be some highlighting of selected rows.

Yup.

That would lead to







Repeater actions such as "delete-rows" would then no more have a need to be given the select widget's name as of today.
+1

And even more, repeater actions could have constraints on the selection size, such as single-selection, multiple-selection, leading these actions to be disabled if their associated constraint isn't met.
...or a validation error.  Like the classic "you must choose at least one" constraint.

And finally, we may be able to specify on repeater bindings if they have to act on the whole repeater on just on the selection.
Not sure what you mean, can you give an example?

However...

I realized that I have a nomenclature clash with my choice of the name "model". I've been using the v2 API for a long time, so I forgot in v1, there is a Form.model property that denotes the widget value tree.


The "model" property is only available on the toplevel form JS object, so there may not be a clash.

It's not a hard "name clash", but it is a nomenclature clash in that it's a different sense of the term "model".  My new row "model" property is truly the "model", as in "MVC" or as in "loadFormFromModel()".  The v1 "model" is "model" in terms of "formmodel", I guess.  I just think it's too confusing to have both senses.  I actually sort of wish the v1 "model" were called something else, because it isn't the model a la MVC.

BTW, why do you prefer v2 rather than v1?

So I don't want to cause confusion with another sense of "model"... it should be called something else. "rowData"? "rowObject"? WDYT?

It doesn't seem good to me to provide at the API level a way to link the form to the data model,

No, no, it is good... :-)

as this is something that isn't suitable for all situations (think transactional systems, heavyweight objects, etc).

OK, for what percentage of real-life applications would you say it is unsuitable?  If it's 10-20%, then do we want to penalize the other 80-90%?  I don't deny those situations exist, but I think they are less common, and in those cases my instinct would be to use a DTO at some level instead of binding directly to the model object.  My instinct would not be to say, "ah, now here is why we don't provide a handle from repeater rows to their bound data!" :-)  One thing I've found to work really well is to build an ad hoc DTO right in the flowscript as a javascript object, which looks to the binding framework just like a Java bean.

Another way to say it: adding this repeater row decoration doesn't break any isolation between layers of the application.  It breaks an undesirable isolation within a single layer (the form definition, binding and flowscript all live in the UI layer).  The degree of isolation between the UI layer and the model, in turn, depends on what is given to the UI layer.  If that is a live model object, then the isolation is already broken, and that may or may not be a bad thing, but that concern doesn't belong to the internal architecture of CForms (IMHO... just trying to state a case here :-).

This is making me think of a discussion in "Hibernate in Action"... In the chapter "Writing Layered Applications", there's a section entitled "Rethinking DTOs".  The authors make the case that the dogma "you should never have live model objects in the view layer" is extreme (maybe it is "quaint and outmoded", like someone in the butthead government of my country has said about the Geneva convention :-/).  Anyway... it's not quite what we're talking about here, but it's related.

And one of the big strengths of CForms is its strong isolation with the data model while the user is messing around with input values.

Hmm, well you can't modify the data from JXTemplate, or at least the mechanisms are not well-known ;-/ (and maybe JXT is too strong :-)... in any case, I think most people really are interested in using JXT as just a template engine, not in programming in JXT :-).  That leaves the flowscript, and you can already have your way with the model data from flowscript if the live data is what the services layer provides...

However, there are some uses cases where this makes sense. You can then use widget attributes (see get/setAttribute) to attach some application data of your liking to any widget, including repeater rows.

See, that's the problem, this is what I have to deal with currently :-)...  I have two parallel structures: a Collection, and a Repeate

Re: [Ann/RFC] "Sitemap Blocks"

[Stefano Mazzocchi]

Daniel Fagerstrom wrote:

>> Give me a 3 lines description of where to start looking and I'll get
>> going.
> 
> A good starting point is the BlocksManager and sitemap component
> configurations in the test cases:
> src/test/org/apache/cocoon/test/components/blocks/BlocksManagerTestCase.xconf.

all right, I'll start from there... is there any I have to modify in
cocoon to make the block manager work or it's already integrated?

(sorry for being clueless, but I've not been following the code very
much lately)

-- 
Stefano.

DO NOT REPLY [Bug 35444] - STX concurrency problem

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35444





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 15:38 ---
OK.

BTW, here is my request (dec-2004):

http://sourceforge.net/tracker/index.php?func=detail&aid=1093267&group_id=55258&atid=476374

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: [GT2005] News, vote and more news

[Steven Noels]

On 17 Jun 2005, at 16:41, Steven Noels wrote:


  [X]  5/6/7 October (Wed->Fri)



--
Steven Noelshttp://outerthought.org/
Outerthought  Open Source Java & XML
stevenn at outerthought.orgstevenn at apache.org

DO NOT REPLY [Bug 35444] - STX concurrency problem

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35444





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 15:28 ---
only upgrade in trunk and add a warning in 2.1 pointing to this Bugzilla issue?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35444] - STX concurrency problem

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35444





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 15:23 ---
The problem is that newer joost version requieres minimum java 1.4 and cocoon
2.1.x should run with 1.3. This is why I stopped to upgrade this jar. I also
requested on the joost mail list for java 1.3 compatibility. They rejected my
proposal. What we can do?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35444] New: - STX concurrency problem

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35444

   Summary: STX concurrency problem
   Product: Cocoon 2
   Version: Current SVN 2.1
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: blocks
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]


Cocoon ships with an old version of Joost (20040330), and this seems to have a 
concurrency problem. After upgrading Joost to 20050521, the problem 
disappeared.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 13:27 ---
I agree with Sylvain (of course) and therefore I have made a different
implementation. As Sylvain suggested, the URIPrefix can be obtained through the
request input module. This involves a change in the Request interface, so all
its implementing classes must be changed as well.

The rationale for this proposed change is as follows:
The Request (and hence the RequestModule) supports getSitemapURI which gives you
the part of the URI that is seen by the sitemap. Thus, if the sitemap is mounted
at /a/b, and the requested URI is /a/b/c/d, the sitemapURI is c/d. The URIPrefix
complements this, and would be a/b/. It is useful to have the URIPrefix to make
absolute links in a HTML document to other pipelines in the same sitemap. This
is often difficult when the ** pattern is used in a match, because simple
relative links will not work.

By using the URIPrefix, one can make sitemaps completely relocatable, i.e., they
still work when you change the mount point, if you make relative links absolute
by prefixing the URIPrefix. See also the third point in
http://www.rabellino.it/blog/index.php?title=things_to_remember_for_the_next_cocoon_p&more=1&c=1&tb=1&pb=1

The getURIPrefix code follows the getSitemapURI code very closely, so I expect
that it does not use any APIs which are going to be deprecated soon.

The necessary patches have been attached.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #15491|Patch   |Patch for CommandLineRequest
description||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 13:13 ---
Created an attachment (id=15496)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15496&action=view)
Patch for RequestWrapper


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 13:13 ---
Created an attachment (id=15495)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15495&action=view)
Patch for Request

This is the interface that all the other patched classes implement. This patch
modifies the interface, so the implementing classes must all be patched.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 13:12 ---
Created an attachment (id=15494)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15494&action=view)
Patch for PortletRequest


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 13:11 ---
Created an attachment (id=15493)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15493&action=view)
Patch for JXPathCocoonContexts


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435





--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 13:11 ---
Created an attachment (id=15492)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15492&action=view)
Patch for HttpRequest


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 35435] - [PATCH] New EnvironmentInputModule

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=35435


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #15479|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2005-06-21 13:10 ---
Created an attachment (id=15491)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15491&action=view)
Patch

This is the first of a series of attachments which extend the request input
module with a URIPrefix attribute.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.