RE: Is there a way to revert to the old store?

[Carsten Ziegeler]

 
Pier Fumagalli wrote:
> 
> Howto? :-P I had to backport the DefaultPersistentStore and 
> hack all the way through...
> 
> It was definitely not nice not to have the 
> DefaultPersistentStore java source in the 2.1.5 source 
> tarball, :-( :-(
> 
> In the future, can people be slightly more careful in 
> removing stuff? I don't care if you switch configurations 
> from 2.1.4 to 2.1.5, but at least leave the files in there, 
> given that we are still including JISP as a JAR...
> 
The source is still there; it has just been moved into the deprecated
directory.

Carsten

RE: [RT] Migrating to Fortress

[Carsten Ziegeler]

 
Sylvain Wallez wrote:

> > <>I forgot that if we move to Fortress, we don't need 
> selectors anymore.
> 
> 
> Argh. I just hope that although we no more _need_ them, 
> there's a compatibility layer for all the code out there that 
> uses selectors.
> 
Sure! I said "we don't need selectors anymore" not "selectors
are not supported anymore" :) You can use selectors the way
you used them, but you don't have to anymore.
So, again, a smooth migration path.

Carsten

RE: advice

[Carsten Ziegeler]

When does the migration to SVN happen? I thought I read somewhere that
it would be this week.

Carsten 

> -Original Message-
> From: Ralph Goers [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 07, 2004 10:00 PM
> To: [EMAIL PROTECTED]
> Subject: RE: advice
> 
> I agree with Peter. Create the branch for 2.1.5, check in the 
> two missing files and then re-release 2.1.5 as 
> 2.1.5.something.  I don't think it is a great idea to just 
> remove 2.1.5.
> 
> Ralph
> 
> 
> Hunsberger, Peter said:
> > Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
> >
> > Maybe release a 2.1.5b with a readme explaining what happened, (and 
> > remove the current 2.1.5 from the archives)?  Otherwise, I 
> don't see 
> > much of a big deal if 2.1.5 is missing from the archives, in 
> > particular, if you add a note to the downloads page.
> >
> >
> 
> 

Re: CIncludeTransformer issues

[Leszek Gawron]

Torsten Curdt wrote:
Having a strip-root parameter on the
CInclude transformer makes sense IMO.

I have a patch. It works only with cinclude:include tag. 
caching-include and includexml is way to much complicated for me to 
change it.

Could you please add it to bugzilla?
cheers
--
Torsten
Could you please apply the patch ?
--
Leszek Gawron  [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67  http://www.mobilebox.pl
mobile: +48 (501) 720 812   fax: +48 (61) 853 29 65

Re: [RT] Migrating to Fortress

[Antonio Gallardo]

Carsten Ziegeler dijo:
> I think its time to think again about migrating to Fortress for 2.2.

+1

Best Regards,

Antonio Gallardo

Re: Is there a way to revert to the old "store"?

[bernhard huber]

> >> Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen on 
> >> 2.1.5-dev.
> >> I am guessing that something is wrong with the new JCS-based store...
> >> Is there a way to revert back without re-implementing the whole thing?
> >

running some tests i had following experiences

A   B
100 71ms
200670ms
500   4917ms
1000 28221ms

A .. number of string entries to be cached
B .. measured time in ms

Seems that caching time rises not linear using JCS.


-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info

Re: ClassCastException in binding framework.

[Joerg Heinicke]

On 07.07.2004 18:01, Vilya Harvey wrote:
With the Cocoon 2.1.5 release, the binding framework throws a 
ClassCastException if you use anything other than an  in the 
 part of a repeater binding. Is this intentional behaviour, 
or a bug?
It's a known feature ;-)
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107906438632484&w=4
The first line inside the for statement, which retrieves a field ID, is 
where the exception occurs. If you're using an  binding 
to generate IDs dynamically, for example, the value in the childBindings 
array will be an instance of JavaScriptJXPathBinding - which cannot be 
cast to ValueJXPathBinding.

I'm guessing that the correct thing to do would be to use only methods 
from the JXPathBindingBase class to retrieve the identity values, but I 
can't see how. I'm probably overlooking something, as I'm not very 
familiar with the internals of the binding framework (yet!).

Can anyone shed any more light on this?
Getting the value is exactly the problem. As you can read in the 
mail/thread mentioned above I added the getFieldId() method only to the 
ValueJXPathBinding to get it working at all, but it is a bad dependency, 
so this dependency was not introduced to the interface or base class.

It might work for you the same way as I did it here:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/samples/forms/form2_bind_xml.xml?annotate=1.4#71.
Joerg

Re: inserver unit testing

[Sylvain Wallez]

Claas Thiele wrote:
Hi,
I've written a JUnit adapter making JUnit tests inside a Cocoon 
servlet possible.

advantages are;
- no mock objects for context creation needed
- testing of special servlet environments (i.e. weblogic) possible
- standard junit reporting (ant, maven) can be used
There is a CocoonTestCase extending TestCase having the objectmodel 
and servicemanager as member variables. This is the base class for 
testcases running on serverside. And there is a TestCaseReader to be 
included in the sitemap. Its for activating the testcases and sending 
back the results.

Looks like a great job!
Maybe, it can make testing Cocoon easier.

It certainly can help... if we can get our hands on the code ;-)
If you consider contributing this code, please add it to bugzilla.
Thanks,
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

inserver unit testing

[Claas Thiele]

Hi,
I've written a JUnit adapter making JUnit tests inside a Cocoon servlet 
possible.

advantages are;
- no mock objects for context creation needed
- testing of special servlet environments (i.e. weblogic) possible
- standard junit reporting (ant, maven) can be used
There is a CocoonTestCase extending TestCase having the objectmodel and 
servicemanager as member variables. This is the base class for testcases 
running on serverside. And there is a TestCaseReader to be included in 
the sitemap. Its for activating the testcases and sending back the results.

Maybe, it can make testing Cocoon easier.
Claas

RE: advice

[Ralph Goers]

I agree with Peter. Create the branch for 2.1.5, check in the two missing
files and then re-release 2.1.5 as 2.1.5.something.  I don't think it is a
great idea to just remove 2.1.5.

Ralph


Hunsberger, Peter said:
> Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
>
> Maybe release a 2.1.5b with a readme explaining what happened, (and
> remove the current 2.1.5 from the archives)?  Otherwise, I don't see
> much of a big deal if 2.1.5 is missing from the archives, in particular,
> if you add a note to the downloads page.
>
>

Re: Native JVM Continuations

[Jorg Heymans]

Java 1.6... that will be in 2007 :-(
surely you meant Java 6.1 here ;)
Jorg

Re: advice

[Dirk-Willem van Gulik]

On Wed, 7 Jul 2004, Stefano Mazzocchi wrote:

> Pier just found out that due to a build script problem, Cocoon 2.1.5 was
> released without the LICENSE.txt and NOTICE.txt files.

Mistakes are made; not a problem. No reason for panic.

At this stage I suggest you pull 2.1.5, skip it and release a new 2.1.6.
Perhaps replace 2.1.5 by a notice pointing to 2.1.6 with some explanation;
as this will also purge the mirrors.

Though it is scary that we got +1's for something that much awry :-) Folks
- do check the tarballs, not just cvs/tag, before giving it a +1 :-).

Dw

Re: Is there a way to revert to the old "store"?

[Pier Fumagalli]

On 7 Jul 2004, at 18:46, Torsten Curdt wrote:
Pier Fumagalli wrote:
Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen on 
2.1.5-dev.
I am guessing that something is wrong with the new JCS-based store...
Is there a way to revert back without re-implementing the whole thing?
We also had problems
Can you describe yours? I noticed weird lock-ups, like the machine was 
not loaded, but at the same time it was processing requests _seriously_ 
slowly...

...switching to EHCache solved them.
Did you try that one?
Howto? :-P I had to backport the DefaultPersistentStore and hack all 
the way through...

It was definitely not nice not to have the DefaultPersistentStore java 
source in the 2.1.5 source tarball, :-( :-(

In the future, can people be slightly more careful in removing stuff? I 
don't care if you switch configurations from 2.1.4 to 2.1.5, but at 
least leave the files in there, given that we are still including JISP 
as a JAR...

(took me a day to get 2.1.5 working with the old cache)
	Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: advice

[Joerg Heinicke]

On 07.07.2004 19:51, Pier Fumagalli wrote:
I agree with Jim... Although rolling 2.1.6 might be non trivial given 
that noone created a new branch/repo for 2.2 and _a_lot_ of changes (in 
libraries and related) have been committed since.
We decided to do "lazy branching". Where is the problem using 2.1.5 tag 
as branch point?

Joerg

Re: advice

[Pier Fumagalli]

I agree with Jim... Although rolling 2.1.6 might be non trivial given 
that noone created a new branch/repo for 2.2 and _a_lot_ of changes (in 
libraries and related) have been committed since.

Pier
On 7 Jul 2004, at 18:24, Jim Jagielski wrote:
My recommendation would be to release 2.1.6 and remove 2.1.5,
with a reason on the website and within the release itself.
On Jul 7, 2004, at 12:42 PM, Stefano Mazzocchi wrote:
Pier just found out that due to a build script problem, Cocoon 2.1.5 
was released without the LICENSE.txt and NOTICE.txt files.

This has now been fixed (thanks to Carsten) so next release will 
contain those files.

Now, should we do anything?
Replacing that release with a fresh one with those files included 
would be bad because it would modify the hashcodes.

Should we release 2.1.6 and remove 2.1.5 from the archives. (at that 
point, tons of people will wonder why a number was skipped, or what 
happend to that version they depend on!).

I personally don't know what to suggest, what do you people think?
--
Stefano.




smime.p7s
Description: S/MIME cryptographic signature

Re: Is there a way to revert to the old "store"?

[Torsten Curdt]

Pier Fumagalli wrote:
Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen on 
2.1.5-dev.
I am guessing that something is wrong with the new JCS-based store...

Is there a way to revert back without re-implementing the whole thing?
We also had problems ...switching to EHCache solved them
Did you try that one?
cheers
--
Torsten

Re: advice

[Jim Jagielski]

My recommendation would be to release 2.1.6 and remove 2.1.5,
with a reason on the website and within the release itself.
On Jul 7, 2004, at 12:42 PM, Stefano Mazzocchi wrote:
Pier just found out that due to a build script problem, Cocoon 2.1.5 
was released without the LICENSE.txt and NOTICE.txt files.

This has now been fixed (thanks to Carsten) so next release will 
contain those files.

Now, should we do anything?
Replacing that release with a fresh one with those files included 
would be bad because it would modify the hashcodes.

Should we release 2.1.6 and remove 2.1.5 from the archives. (at that 
point, tons of people will wonder why a number was skipped, or what 
happend to that version they depend on!).

I personally don't know what to suggest, what do you people think?
--
Stefano.

DO NOT REPLY [Bug 29945] - [PATCH] BetwixtTransformer: removed deprecation warning with latest betwixt

[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=29945

[PATCH] BetwixtTransformer: removed deprecation warning with latest betwixt





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 17:36 ---
Betwixt 0.5 is only 4 days old:
http://jakarta.apache.org/site/news/news-2004-2ndHalf.html#20040703.1

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 17:27 ---
Hi, Morten

Sorry for missing your attached java class. I did a quick test with your 
commandline program DocumentTest, however, I got the same result. 
C:\>java DocumentTest 20381.xsl 20381.xml
BrogansBrogans<
bar>Hogans

By the way, I am using JDK 1.4.2 with Xalan2.6.0 release. What do you use? 
Thanks,

RE: advice

[Hunsberger, Peter]

Stefano Mazzocchi <[EMAIL PROTECTED]> writes:
 
> Pier just found out that due to a build script problem, 
> Cocoon 2.1.5 was 
> released without the LICENSE.txt and NOTICE.txt files.
> 
> This has now been fixed (thanks to Carsten) so next release 
> will contain 
> those files.
> 
> Now, should we do anything?
> 
> Replacing that release with a fresh one with those files 
> included would 
> be bad because it would modify the hashcodes.
> 
> Should we release 2.1.6 and remove 2.1.5 from the archives. (at that 
> point, tons of people will wonder why a number was skipped, or what 
> happend to that version they depend on!).
> 
> I personally don't know what to suggest, what do you people think?

Maybe release a 2.1.5b with a readme explaining what happened, (and
remove the current 2.1.5 from the archives)?  Otherwise, I don't see
much of a big deal if 2.1.5 is missing from the archives, in particular,
if you add a note to the downloads page.

Re: Native JVM Continuations

[Stefano Mazzocchi]

Tony Collen wrote:
James Strachan writes [1]:
"Spent a great afternoon & evening with John Rose from Sun (compiler & 
VM team), who's on the Groovy JSR - we've managed to figure out many of 
the gremlins in the language. Plus I learnt quite a bit about the JVM. 
e.g. it might not be that hard to implement continuations at the JVM 
level! Apparently the JVM already does a kind of continuation internally 
for optimising bytecode - so if you want native continuations, hassle 
the good folks at Sun & raise some bug reports, maybe we can persuade 
them to sneak it into 1.6 :). Native Java continuations would totally 
rock - and avoid all that inefficient bytecode swizzling we'd have to do 
to implement continuations on top of the JVM."
Nice!
Well, I wonder what it will happen to java (or to me!) in the 7 years 
that will take java 1.6 to be widespread enough for us to switch to it.

:-/
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: NekoHTMLGenerator and Gump

[Stefano Mazzocchi]

Upayavira wrote:
I have written a simple NekoHTMLGenerator, much like the existing one, 
but based around NekoHTML. This does much less clever stuff compared to 
JTidy, and parses to SAX events instead of via a DOM object, which 
should be much more efficient. I have also been told by one happy user 
of my generator that it fixed a problem where JTidy didn't preseve CDATA 
sections in scripts, or some such.

The NekoHTML jar adds 46k to the distribution, and its licence is ASL1.1 
based.

I'd like to commit it to the HTML block.
+1
I have one question though, which relates to gump.xml. If I am adding a 
new jar, presumably I need to reference NekoHTML as a project. In which 
case, presumably the NekoHTML needs to be defined somewhere else?

Or should I just not mention NekoHTML in gump.xml?
no, you have to mention the dependency, but you can add the dependency 
as a library (not as a running gump project). see the bottom of gump.xml 
for examples of that (we do that for a number of libraries already).

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

advice

[Stefano Mazzocchi]

Pier just found out that due to a build script problem, Cocoon 2.1.5 was 
released without the LICENSE.txt and NOTICE.txt files.

This has now been fixed (thanks to Carsten) so next release will contain 
those files.

Now, should we do anything?
Replacing that release with a fresh one with those files included would 
be bad because it would modify the hashcodes.

Should we release 2.1.6 and remove 2.1.5 from the archives. (at that 
point, tons of people will wonder why a number was skipped, or what 
happend to that version they depend on!).

I personally don't know what to suggest, what do you people think?
--
Stefano.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Migrating to Fortress

[Sylvain Wallez]

Carsten Ziegeler wrote:
I think its time to think again about migrating to Fortress for 2.2.
By migrating to Fortress I just mean using Fortress as an ECM replacement.
So without using meta-data etc. Fortress is able to use the ECM configuration, so from the user pov there shouldn't be a difference.
 

That's good, as transparent migration is a key point.
There shouldn't be any compatibility problems. The only thing I'm not so sure about is XSP where ComponentHandlers are used. But I'm sure we will find a solution for that as well.
 

ComponentHandler is called in JavaProgram to create a pool for instances 
of the XSP's Class. If Fortress allows to create a similar abstraction 
from a Class object, migration shouldn't be a problem.

I'll also update the TreeProcessor to remove the need for Recomposable 
which was actually a misuse of the underlying concept.

<>I forgot that if we move to Fortress, we don't need selectors anymore.

Argh. I just hope that although we no more _need_ them, there's a 
compatibility layer for all the code out there that uses selectors.

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Is there a way to revert to the old "store"?

[Pier Fumagalli]

Guys, I'm seeing some problems on 2.1.5 and 2.2 which don't happen on 
2.1.5-dev.
I am guessing that something is wrong with the new JCS-based store...

Is there a way to revert back without re-implementing the whole thing?
	Pier


smime.p7s
Description: S/MIME cryptographic signature

Re: Native JVM Continuations

[Sylvain Wallez]

Tony Collen wrote:
James Strachan writes [1]:
"Spent a great afternoon & evening with John Rose from Sun (compiler & 
VM team), who's on the Groovy JSR - we've managed to figure out many 
of the gremlins in the language. Plus I learnt quite a bit about the 
JVM. e.g. it might not be that hard to implement continuations at the 
JVM level! Apparently the JVM already does a kind of continuation 
internally for optimising bytecode - so if you want native 
continuations, hassle the good folks at Sun & raise some bug reports, 
maybe we can persuade them to sneak it into 1.6 :). Native Java 
continuations would totally rock - and avoid all that inefficient 
bytecode swizzling we'd have to do to implement continuations on top 
of the JVM."

[1] http://radio.weblogs.com/0112098/2004/07/07.html#a490

Java 1.6... that will be in 2007 :-(
We'd better work with James on that "inefficient bytecode swizzling" and 
submit a JSR to standardize our API in 1.6...

Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Nasty flowscript issue - nailed

[Gianugo Rabellino]

On Jul 7, 2004, at 8:03 AM, Sylvain Wallez wrote:

Giaunugo, I committed the unique ID fix (using an instance counter). 
Can you please crosscheck?

Thanks so much Sylvain! I'm out of the office for the next two days, 
but I'll get back to you ASAP if Andrew/Jerm don't beat me at it...

Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com

NekoHTMLGenerator and Gump

[Upayavira]

I have written a simple NekoHTMLGenerator, much like the existing one, 
but based around NekoHTML. This does much less clever stuff compared to 
JTidy, and parses to SAX events instead of via a DOM object, which 
should be much more efficient. I have also been told by one happy user 
of my generator that it fixed a problem where JTidy didn't preseve CDATA 
sections in scripts, or some such.

The NekoHTML jar adds 46k to the distribution, and its licence is ASL1.1 
based.

I'd like to commit it to the HTML block.
I have one question though, which relates to gump.xml. If I am adding a 
new jar, presumably I need to reference NekoHTML as a project. In which 
case, presumably the NekoHTML needs to be defined somewhere else?

Or should I just not mention NekoHTML in gump.xml?
Regards, Upayavira

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 09:45 ---
Created an attachment (id=12048)
Stylesheet that reproduces the bug

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 09:44 ---
Created an attachment (id=12046)
Main transformation document

DO NOT REPLY [Bug 29945] - [PATCH] BetwixtTransformer: removed deprecation warning with latest betwixt

[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=29945

[PATCH] BetwixtTransformer: removed deprecation warning with latest betwixt





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 09:53 ---
Created an attachment (id=12049)
patch BetwixtTransformer to remove deprecated method call

DO NOT REPLY [Bug 29945] New: - [PATCH] BetwixtTransformer: removed deprecation warning with latest betwixt

[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=29945

[PATCH] BetwixtTransformer: removed deprecation warning with latest betwixt

   Summary: [PATCH] BetwixtTransformer: removed deprecation warning
with latest betwixt
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Betwixt is close to release. So here is a patch for the Cocoon
BetwixtTransformer that removes the deprecation warning when compiling cocoon. 
I haven't checked if it works for the betwixt 0.5 version that is currently
distributed together with cocoon. But it would be nice if somebody replaces it
with betwixt 1.0 beta. If needed, I can upload the betwixt.jar here.

for the patch see the uploaded file.

ClassCastException in binding framework.

[Vilya Harvey]

Hi,
With the Cocoon 2.1.5 release, the binding framework throws a 
ClassCastException if you use anything other than an  in the 
 part of a repeater binding. Is this intentional behaviour, or 
a bug?

The offending code comes from RepeaterJXPathBinding.java:
--
/**
 * Get the identity of the given row. That's infact a list of all the
 * values of the fields in the form model that constitute the identity.
 * @param thisRow
 * @return List the identity of the row
 */
private List getIdentity(Repeater.RepeaterRow row) {
  List identity = new ArrayList();
  JXPathBindingBase[] childBindings =
  this.identityBinding.getChildBindings();
  if (childBindings != null) {
int size = childBindings.length;
for (int i = 0; i < size; i++) {
  String fieldId =
  ((ValueJXPathBinding)childBindings[i]).getFieldId();
  Widget widget = row.getChild(fieldId);
  Object value = widget.getValue();
  identity.add(value);
}
  }
  return identity;
}
--
The first line inside the for statement, which retrieves a field ID, is 
where the exception occurs. If you're using an  binding to 
generate IDs dynamically, for example, the value in the childBindings array 
will be an instance of JavaScriptJXPathBinding - which cannot be cast to 
ValueJXPathBinding.

I'm guessing that the correct thing to do would be to use only methods from 
the JXPathBindingBase class to retrieve the identity values, but I can't see 
how. I'm probably overlooking something, as I'm not very familiar with the 
internals of the binding framework (yet!).

Can anyone shed any more light on this?
Cheers,
Vil.
--
__
   o|   _. /  \|o._  _  _ ._  _  ._  _ _|_
\/ ||\/(_|| (|/||| |(/_(_)| |(/_o| |(/_ |_
 / \__
http://website.lineone.net/~vilya

Native JVM Continuations

[Tony Collen]

James Strachan writes [1]:
"Spent a great afternoon & evening with John Rose from Sun (compiler & 
VM team), who's on the Groovy JSR - we've managed to figure out many 
of the gremlins in the language. Plus I learnt quite a bit about the 
JVM. e.g. it might not be that hard to implement continuations at the 
JVM level! Apparently the JVM already does a kind of continuation 
internally for optimising bytecode - so if you want native 
continuations, hassle the good folks at Sun & raise some bug reports, 
maybe we can persuade them to sneak it into 1.6 :). Native Java 
continuations would totally rock - and avoid all that inefficient 
bytecode swizzling we'd have to do to implement continuations on top 
of the JVM."

[1] http://radio.weblogs.com/0112098/2004/07/07.html#a490
Regards,
Tony

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 15:25 ---
Hi, Morten

Thanks for your test case. I don't know what you mean by "terminal", I am using 
org.apache.xalan.xslt.Process commandline program with -XSLTC setting, it works 
as expected. I got:

BrogansBrogans<
bar>Hogans

How did you reproduce the bug? inside cocoon? Thanks,

RE: JDK 1.3.1 compatibility for cvs-head

[Hunsberger, Peter]

Pier Fumagalli <[EMAIL PROTECTED]> asks:

2.2 discussion

> BTW, anyone knows of any good tool who can generate SHITLOADS of 
> requests simulating "real" traffic (maybe from a log file or 
> something 
> like it).
> 

Can't vouch for it personally, but one of our guys uses

http://downloads.pushtotest.com/TestMaker409.zip

I suspect it's not quite what you want, from what I know he records a
script of a bunch of actions over the site and this thing plays them
back. It allows staggering the start of some number of identical
scripts, but I don't think you can play back multiple random scripts
which is what I'd want if I was trying to simulate real traffic.  OTOH,
perhaps you can run it from multiple machines each with a different
script (each generating a couple 1000 users or whatever) and get
something at least partially realistic.

Re: [RT] Migrating to Fortress

[Vadim Gritsenko]

Carsten Ziegeler wrote:
I think its time to think again about migrating to Fortress for 2.2.
By migrating to Fortress I just mean using Fortress as an ECM replacement.
 

I've got no objections to this; hopefully excalibur community takes off 
and will support fortress for the time frame we need it.

Vadim

DO NOT REPLY [Bug 29951] - [portal] CopletTransformer does not handle forms with method="get"

[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=29951

[portal] CopletTransformer does not handle forms with method="get"





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 14:17 ---
Created an attachment (id=12055)
FIX for bug

DO NOT REPLY [Bug 29951] New: - [portal] CopletTransformer does not handle forms with method="get"

[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=29951

[portal] CopletTransformer does not handle forms with method="get"

   Summary: [portal] CopletTransformer does not handle forms with
method="get"
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: blocks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The CopletTransformer cannot submit forms which require the method
get and don't have the enctype attribute set.

cronjob and cocoonpipelinecronjob

[arnaud DANEELS]

Hi,

 

    I need some help with
cocoon-2.2.0-dev with cronjob and CocoonPipelineCronJob
functionnality 

 

    Samples of cron (testcronjob) don’t
work in this version of cocoon. (he did in the 2.1.5): 

 

INFO    (2004-07-07) 15:55.06:024  
[cron] Unknown-thread/QuartzJobExecutor: Scheduling cron job named 'test'

INFO    (2004-07-07) 15:55.06:039  
[cron.test] Unknown-thread/TestCronJob: CronJob test launched at Wed Jul 07 15:55:06
CEST 2004 with message 'I'm here' and sleep timeout of 23000ms

ERROR   (2004-07-07) 15:55.06:039  
[cron] Unknown-thread/QuartzJobExecutor: Cron job name 'test died.

org.apache.avalon.framework.CascadingRuntimeException:
CronJob test raised an exception

    at
org.apache.cocoon.components.cron.TestCronJob.execute(TestCronJob.java:100)

    at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

    at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

    at
java.lang.reflect.Method.invoke(Method.java:324)

    at
org.apache.avalon.excalibur.component.ComponentProxyGenerator$ComponentInvocationHandler.invoke(ComponentProxyGenerator.java:143)

    at
$Proxy14.execute(Unknown Source)

    at
org.apache.cocoon.components.cron.QuartzJobExecutor.execute(QuartzJobExecutor.java:109)

    at
org.quartz.core.JobRunShell.run(JobRunShell.java:188)

    at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)

    at
java.lang.Thread.run(Thread.java:534)

Caused by: java.lang.UnsupportedOperationException

    at
org.apache.cocoon.environment.background.BackgroundEnvironment$NullProcessor.getContext(BackgroundEnvironment.java:164)

    at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:55)

    at
org.apache.cocoon.components.source.CocoonSourceResolver.resolveURI(CocoonSourceResolver.java:70)

    at
org.apache.cocoon.components.cron.TestCronJob.execute(TestCronJob.java:83)

    ...
10 more

 

    In the 2.2.0 dev, libraries are
updated to 1.4 for quartz.jar and 1.3.4 for util-current and
cocoonpipelinecronjob is 

    added to cron block.

 

 

    Have you any idea about this
problem  and test this functionnality

 

Thank you for your help.

 

Arnaud

RE: [RT] Migrating to Fortress

[Carsten Ziegeler]

I forgot that if we move to Fortress, we don't need selectors anymore.

Carsten 

> -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, July 07, 2004 9:16 AM
> To: Cocoon-Dev
> Subject: [RT] Migrating to Fortress
> 
> I think its time to think again about migrating to Fortress for 2.2.
> 
> By migrating to Fortress I just mean using Fortress as an ECM 
> replacement.
> So without using meta-data etc. Fortress is able to use the 
> ECM configuration, so from the user pov there shouldn't be a 
> difference.
> 
> So, why migrating at all? Fortress has some benefits over 
> ECM. I think Berin mentioned an improved pooling code etc. We 
> could use setter and constructor injection if we want etc.
> In addition, the development of Fortress will continue over 
> at Excalibur, so if something interesting will happen there 
> we can benefit from it.
> 
> But my main point currently is the use of own lifecycle 
> interfaces. It seems that perhaps we will someday move away 
> from the Avalon based world (let's not discuss this here if 
> we will or wont, please!). Even if that will not happen, we 
> will need additional core functionality that is not available 
> in Avalon (a different lookup etc.).
> With Fortress we can add our own marker interface into the 
> component lifecycle and for example introduce a (very silly 
> example!) CocoonLogEnabled interface. If a component 
> implements this, it gets the Cocoon logger (this is just an example!)
> 
> If we need this functionality for blocks in Cocoon 2.3 (or 
> whatever version), we could start adding the interfaces (when 
> they are solid) to Cocoon 2.2.x and people can start 
> migrating their components slowly. So, when the real blocks 
> are out, its much easier to migrate the code (if required) as 
> this has already happened (for parts).
> 
> There shouldn't be any compatibility problems. The only thing 
> I'm not so sure about is XSP where ComponentHandlers are 
> used. But I'm sure we will find a solution for that as well.
> 
> Carsten 
> 
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://www.osoco.net/weblogs/rael/
> 
> 

Re: Cocoon JSR 168 Portlet in Cocoon Portal

[Vadim Gritsenko]

Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
 

There is a very simple demo of the Cocoon JSR-168 portlet 
included, just go to the "JSR168" tab in the portal block 
demo. The only thing you need to do before running demo is to 
comment out implementation of the
checkEnvironment() method in the EnvironmentHelper:
   

...
Carsten, can you shed more light as to what will be the best 
course for this?

   

Argh, ok, perhaps we can finally find the bug with this!
The checkEnvironment is an integrated "test" to see if something went
wrong with the internal environment handling. So if this method
logs the exception, something went wrong :)
We have an internal stack, bound as a thread local variable, that keeps
track of the current environment and sitemap. So, if you enter
a sitemap, the current environment and sitemap processor are pushed
onto the stack and when the sitemap is left, the values are taken
from the stack.
The checkEnvironment() method checks at the end of the processing if the
stack is empty. If not, something has not been taken from stack.
Now, this gets more complicated, when internal pipeline calls are used.
As these run in the same thread, the environment of the internal pipeline
and of the external call are both on the same stack. An index for
each pipeline keeps track of which environment belongs to which pipeline.
It seems that the problem arises when this index somehow gets confused
or, when something is not taken from the stack. 

I checked the code several times, but push and pop always come in a pair,
so I'm a little bit clueless :)
Is the message reproducable with every coplet? What do I have to do,
to reproduce it?
 

It's actually very easy to reproduce:
1. cvs up
2. build clean; build
3. cocoon servlet
4. http://localhost:/samples/blocks/portal/portal
5. login
6. JSR-168 tab
Exception is printed neatly within "JSR-168 Cocoon Portlet" content pane.
Please bear in mind, call stack here is the following:
 CocoonServlet
  Cocoon (1)
   Treeprocessor, ...
CopletSource
 ManagedCocoonPortlet
  Cocoon (2)
   EnvironmentHelper
Where, (1) and (2) are the same instance of the Cocoon class, on the 
same thread. I think that's why it is confused. Here is head of trace:

org.apache.cocoon.ProcessingException: Environment stack has not been cleaned up 
properly. Please report this (if possible together with a test case) to the Cocoon 
developers.
at 
org.apache.cocoon.environment.internal.EnvironmentHelper.checkEnvironment(EnvironmentHelper.java:294)
at org.apache.cocoon.Cocoon.process(Cocoon.java:692)
at 
org.apache.cocoon.portlet.ManagedCocoonPortlet.render(ManagedCocoonPortlet.java:557)
at 
org.apache.cocoon.portal.pluto.factory.LocalPortletInvokerImpl.render(LocalPortletInvokerImpl.java:140)
at 
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103)
at 
org.apache.cocoon.portal.coplet.adapter.impl.PortletAdapter.streamContent(PortletAdapter.java:168)
at 
org.apache.cocoon.portal.coplet.adapter.impl.AbstractCopletAdapter.toSAX(AbstractCopletAdapter.java:128)
at org.apache.cocoon.portal.source.CopletSource.toSAX(CopletSource.java:168)
at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:134)
at org.apache.cocoon.components.source.SourceUtil.toSAX(SourceUtil.java:114)
at 
org.apache.cocoon.transformation.CIncludeTransformer.processCIncludeElement(CIncludeTransformer.java:545)

Vadim

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 09:46 ---
I have attached a test program (that can be run from a terminal). This shows how
the value of variable 'one' changes its value after the document() function has
been called.

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 09:44 ---
Created an attachment (id=12047)
Document imported using document() function

DO NOT REPLY [Bug 20381] - XSLTC: top-level xsl:variable with document() breaks

[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=20381

XSLTC: top-level xsl:variable with document() breaks





--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 09:44 ---
Created an attachment (id=12045)
This test app reproduces the bug

Re: JDK 1.3.1 compatibility for cvs-head

[bernhard huber]

> BTW, anyone knows of any good tool who can generate SHITLOADS of 
> requests simulating "real" traffic (maybe from a log file or something 
> like it).

i tried once grinder from sourceforge,
it is able to record your clicking, and replay.

You can control the number of processes, and number of thread,
generating real lots of load easily

regards bernhard


-- 
+++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl

DO NOT REPLY [Bug 29381] - JXTemplate - Can't process DOM document passed from flowscript

[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=29381

JXTemplate - Can't process DOM document passed from flowscript

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED]   |[EMAIL PROTECTED]
 Status|REOPENED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2004-07-07 07:17 ---
Sure. The above stacktrace should not occur in the above scenario. To accomplish
this JXTemplateGenerator should simply ignore startDocument and endDocument when
streaming nodes.

[RT] Migrating to Fortress

[Carsten Ziegeler]

I think its time to think again about migrating to Fortress for 2.2.

By migrating to Fortress I just mean using Fortress as an ECM replacement.
So without using meta-data etc. Fortress is able to use the ECM
configuration,
so from the user pov there shouldn't be a difference.

So, why migrating at all? Fortress has some benefits over ECM. I think
Berin mentioned an improved pooling code etc. We could use setter and
constructor injection if we want etc.
In addition, the development of Fortress will continue over at Excalibur,
so if something interesting will happen there we can benefit from it.

But my main point currently is the use of own lifecycle interfaces. It 
seems that perhaps we will someday move away from the Avalon based world
(let's not discuss this here if we will or wont, please!). Even if that
will not happen, we will need additional core functionality that is
not available in Avalon (a different lookup etc.).
With Fortress we can add our own marker interface into the component
lifecycle and for example introduce a (very silly example!)
CocoonLogEnabled interface. If a component implements this, it
gets the Cocoon logger (this is just an example!)

If we need this functionality for blocks in Cocoon 2.3 (or whatever
version), we could start adding the interfaces (when they are solid)
to Cocoon 2.2.x and people can start migrating their components
slowly. So, when the real blocks are out, its much easier to
migrate the code (if required) as this has already happened (for parts).

There shouldn't be any compatibility problems. The only thing I'm not
so sure about is XSP where ComponentHandlers are used. But I'm sure
we will find a solution for that as well.

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/