Berin Loritsch wrote, On 02/09/2003 19.11:
Geoff Howard wrote:
...
Could someone (Berin?) give an estimate of what the damage would be
even if we agree it's a good move?
Risk Assessment and Mitigation Strategy:
1) Legacy Components. All legacy components are handled as expected with
Marc Portier wrote:
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
mpo 2003/08/26 02:04:39
Added: src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Log:
Adding the new ContinuationsDisposer interface declaring the
callback for
[EMAIL PROTECTED] wrote:
Hi,
I'm playing with Woody and Flowscript and want to include some dynamic
javascript as Flowscript. The javascript would be generated by
transforming some XML markup into script. So I tried:
cocoon.load(cocoon:/getControllerLogic);
from somewhere in Woody's
Hi Michael,
If flowscripts are reloaded depends on two parameters: First on the
configuration of the interpreter if it allows reloads at all and how
often reloads are checked. And second on the script itself. Currently
we use the (deprecated) getLastModified methods to determin if a script
has
Sylvain Wallez wrote:
I've seen this behaviour with static files : FlowScript doesn't seem to
check changes on scripts loaded with cocoon.load().
This is a bug, and the current workaround is to touch the main script file.
I've been experiencing the same, even in the main script.
I have:
Hello Andreas,
This is very interesting!
But I'm not sure to understand:
Is your organization tree stored in a LDAP repository?
Your four groups of users are similar to roles?
You store the role information inside the InetOrgPerson class. Is it a persistence
class?
Where do you use Cocoon in
Nicola Ken Barozzi wrote:
Berin Loritsch wrote, On 02/09/2003 19.11:
Geoff Howard wrote:
...
Could someone (Berin?) give an estimate of what the damage would be
even if we agree it's a good move?
Risk Assessment and Mitigation Strategy:
1) Legacy Components. All legacy
On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
snip/
I think we should do this switch asap. *If* we can solve the commandmanager
issue discussed in the other thread, I will make a 2.1.1 release this week.
The issue can in fact be fixed immediately by changing the way we use
the
Bruno Dumon wrote:
On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
snip/
I think we should do this switch asap. *If* we can solve the
commandmanager
issue discussed in the other thread, I will make a 2.1.1
release this week.
The issue can in fact be fixed immediately by
On Wed, 2003-09-03 at 11:05, Carsten Ziegeler wrote:
Bruno Dumon wrote:
On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
snip/
I think we should do this switch asap. *If* we can solve the
commandmanager
issue discussed in the other thread, I will make a 2.1.1
release this
On Wed, 2003-09-03 at 11:05, Carsten Ziegeler wrote:
Bruno Dumon wrote:
On Wed, 2003-09-03 at 10:23, Carsten Ziegeler wrote:
snip/
I think we should do this switch asap. *If* we can solve the
commandmanager
issue discussed in the other thread, I will make a 2.1.1
release this
Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
mpo 2003/08/26 02:04:39
Added: src/java/org/apache/cocoon/components/flow
ContinuationsDisposer.java
Log:
Adding the new ContinuationsDisposer interface
Thanks to Bruno we have a solution (or workaround)
for the CommandManager problem. Great!
So afaik we don't have another blocker for the 2.1.1 release.
As I'm going on vacation starting saturday (yeah), I propose
to do the release this friday.
The alternatives are:
- someone else does the
Carsten Ziegeler wrote, On 03/09/2003 12.01:
...
As I'm going on vacation starting saturday (yeah), I propose
to do the release this friday.
+1
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
From: Carsten Ziegeler
Thanks to Bruno we have a solution (or workaround)
for the CommandManager problem. Great!
So afaik we don't have another blocker for the 2.1.1 release.
As I'm going on vacation starting saturday (yeah), I propose
to do the release this friday.
The
Reinhard Poetz wrote:
One question: Has the issue with proxies been solved?
Do you have a pointer?
Carsten
a comment by Vadim:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106096301526641w=2
the original bug report on the users list:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=106018487631767w=2
I'm not sure - I think Vadim and Jörg worked on this issue.
Reinhard
-Original
On Wed, 2003-09-03 at 12:01, Carsten Ziegeler wrote:
snip/
As I'm going on vacation starting saturday (yeah), I propose
to do the release this friday.
+1
Since we decided that we don't like creating new repositories nor CVS
branches, I assume this will be the last release in the 2.1.x series?
From: Bruno Dumon
On Wed, 2003-09-03 at 12:01, Carsten Ziegeler wrote:
snip/
As I'm going on vacation starting saturday (yeah), I
propose to do the
release this friday.
+1
Since we decided that we don't like creating new repositories
nor CVS branches, I assume this will be the
Reinhard Poetz wrote
a comment by Vadim:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106096301526641w=2
the original bug report on the users list:
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=106018487631767w=2
I'm not sure - I think Vadim and Jörg worked on this issue.
From: Reinhard Poetz
From: Bruno Dumon
On Wed, 2003-09-03 at 12:01, Carsten Ziegeler wrote:
snip/
As I'm going on vacation starting saturday (yeah), I
propose to do the
release this friday.
+1
Since we decided that we don't like creating new repositories
nor CVS
Carsten Ziegeler wrote:
Thanks to Bruno we have a solution (or workaround)
for the CommandManager problem. Great!
So afaik we don't have another blocker for the 2.1.1 release.
As I'm going on vacation starting saturday (yeah), I propose
to do the release this friday.
The alternatives are:
-
Reinhard Poetz wrote:
Since we decided that we don't like creating new repositories
nor CVS branches, I assume this will be the last release in
the 2.1.x series?
If this doesn't mean that we wait another 18 months or so
until releasing 2.2 ... ;)
more seriously: How do we deal
Reinhard Poetz wrote:
more seriously: How do we deal with bugfix releases in the future if we
don't have a branch or another repository?
Like we do with 2.0.x? It's just a matter of releasing, actually.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought -
Carsten Ziegeler wrote:
So, is this only a typo or really a bug?
typo.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at
From: Carsten Ziegeler
Im really tired of discussing this (it's not your fault, Reinhard).
I suggested again and again to start a new repository for 2.2
(which is equivalent to starting a 2.2 branch - or a 2.1.x
branch), but I always got the reply let's see if we really
need 2.2, let's
Reinhard Poetz wrote:
I understand your feelings ...
IMO we should be able to release 2.1.x version in the future. Mabe I'm a
bit afraid of the changes (blocks, fortress, virtual sitemap components)
and how long it takes us to release stable versions of Cocoon (not beta,
not milestone or
From: Steven Noels
Reinhard Poetz wrote:
I understand your feelings ...
IMO we should be able to release 2.1.x version in the
future. Mabe I'm
a bit afraid of the changes (blocks, fortress, virtual sitemap
components) and how long it takes us to release stable versions of
Reinhard Poetz wrote:
a comment by Vadim:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106096301526641w=2
My comment has nothing to do with proxies. As Joerg found out, this is
the problem with M$ html extensions and XPath:
From: Vadim Gritsenko
Reinhard Poetz wrote:
a comment by Vadim:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106096301526641w=2
My comment has nothing to do with proxies. As Joerg found
out, this is
the problem with M$ html extensions and XPath:
Nicola Ken Barozzi dijo:
Carsten Ziegeler wrote, On 03/09/2003 12.01:
...
As I'm going on vacation starting saturday (yeah), I propose
to do the release this friday.
+1
+1 ;) But please include:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13070
Best Regards,
Antonio Gallardo
--- Reinhard Poetz [EMAIL PROTECTED] wrote:
...
I think so many people (of course including me) were waiting for 2.1 and
I really want to use it for some time in production without doing
alpha/beta testing of 2.2 and I like to have support of bugfix
releases of 2.1 (see the security holes
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Since we decided that we don't like creating new repositories nor CVS branches, I assume this will be the last release in the 2.1.x series?
If this doesn't mean that we wait another 18 months or so until releasing 2.2 ... ;)
more
Timothy Larson dijo:
--- Reinhard Poetz [EMAIL PROTECTED] wrote:
...
I think so many people (of course including me) were waiting for 2.1
and I really want to use it for some time in production without doing
alpha/beta testing of 2.2 and I like to have support of bugfix
releases of 2.1 (see
I have been aware for some time that the HTMLGenerator doesn't work
within the CLI. Looking at the code, right at the beginning of the setup
method it says:
HttpServletRequest request = (HttpServletRequest)
objectModel.get(HttpEnvironment.HTTP_REQUEST_OBJECT);
Now a regular component
From: Antonio Gallardo
Timothy Larson dijo:
--- Reinhard Poetz [EMAIL PROTECTED] wrote:
...
I think so many people (of course including me) were
waiting for 2.1
and I really want to use it for some time in production
without doing
alpha/beta testing of 2.2 and I like to have
Reinhard Poetz wrote:
I haven't got it: How are we able to release e.g. 2.1.2 without a
branch/new repository without using e.g. Fortress as container (nothing
against Fortress, I'm no specialist in these container things and maybe
this is the reason for my concerns)? I would like to give us some
Steven Noels wrote:
I'm +1 on a 2.2 module, and +1 on 2.1.1 on Friday. Fortress might be
something for 2.2 rather than 2.1.1, but I'll leave that to the people
^
duh: 2.1.x, of course
/Steven
--
Steven Noels
Hi,
I reduced the dependency to the http environment now. It's only
required now if the html generator is used like the stream
generator. If you specify a src it should work in CLI again.
I don't know who put that it, but I could remove it :)
Carsten
-Original Message-
From:
Antonio Gallardo wrote:
+1 ;) But please include:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13070
I will apply the patch asap. Thanks Antonio!
Could you please provide some docs as well for using the
logicsheet in the correct xml format. Something like you
have in the readme
Carsten Ziegeler dijo:
Antonio Gallardo wrote:
+1 ;) But please include:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13070
I will apply the patch asap. Thanks Antonio!
Could you please provide some docs as well for using the
logicsheet in the correct xml format. Something like you
Carsten Ziegeler wrote:
m_threadPool.waitWhenBlocked();
to
m_threadPool.discardWhenBlocked();
functionally, this shouldn't change anything (I think), and it will
avoid the problem in PooledExecutor completely. If you have some time
available to try this out, that would be great.
Yes, I just
I'm using JXTemplateGenerator (very nice stuff BTW), and remarked that
if the result of an expression is a org.w3c.dom.Node, it will again be
executed, i.e. parsed as a JXTemplate and interpreted.
I'd like to be able to disable this behaviour, on the one hand because
the data might contain
Berin Loritsch wrote:
Carsten Ziegeler wrote:
m_threadPool.waitWhenBlocked();
to
m_threadPool.discardWhenBlocked();
functionally, this shouldn't change anything (I think), and it will
avoid the problem in PooledExecutor completely. If you have some time
available to try this
Carsten Ziegeler wrote:
I think we should do this switch asap. *If* we can solve the commandmanager
issue discussed in the other thread, I will make a 2.1.1 release this week.
Immediately after that work can start on the migration.
Berin, you mention above in 3) that the configuration format
Berin Loritsch wrote:
SNIP GOOD EXPLAINS/
Thanks Berin for the info, so with Fortress we can finally forget
the double lookups when selectors were used.
Carsten
On Wed, 3 Sep 2003, Steven Noels wrote:
IMHO, it's simply unworkable to have major stuff going on in one module,
over two branches, at the same time.
In CVS, I've always found branches == pain.
I appreciate a move to something like subversion is quite a revolution,
and I'd suggest it's
Carsten Ziegeler wrote:
As I'm going on vacation starting saturday (yeah), I propose
to do the release this friday.
+1 for Friday
Geoff
Reinhard Poetz wrote:
From: Carsten Ziegeler
Im really tired of discussing this (it's not your fault, Reinhard).
I suggested again and again to start a new repository for 2.2
(which is equivalent to starting a 2.2 branch - or a 2.1.x
branch), but I always got the reply let's see if we really
Berin Loritsch wrote:
Carsten Ziegeler wrote:
I think we should do this switch asap. *If* we can solve the
commandmanager
issue discussed in the other thread, I will make a 2.1.1 release this
week.
Immediately after that work can start on the migration.
Berin, you mention above in 3) that the
beware of snips/
Berin Loritsch wrote:
The above in Fortress would be redone as:
jdbc-datasource id=foo/
j2ee-datasource id=bar/
...
In Fortress, you can do things the old ECM way, or you can incorporate
the ID
to get whichever component you want and bypass the selector completely
like
this:
[Resending because it did not seem to reach the list]
The Cocoon flow debugger works well except it is not
showing any local variables in the Locals tab.
Does anybody else have this problem?
Using snapshot from 2003-09-02:
cocoon-2.1_20030902102048.tar.gz
--Tim Larson
On Wednesday, September 3, 2003, at 03:52 PM, Timothy Larson wrote:
The Cocoon flow debugger works well except it is not
showing any local variables in the Locals tab.
Does anybody else have this problem?
Yes.
Although I just thought I was using the debugger incorrectly :)
Platform: MacOSX
Berin Loritsch wrote:
Geoff Howard wrote:
Berin Loritsch wrote:
In Cocoon/ECM we have the following constructs:
regular-component
stuff/
/regular-component
database-selector
jdbc name=foo/
j2ee name=bar/
informix name=baz/
/database-selector
Without a .roles file would we even have
IMHO, it's simply unworkable to have major stuff going on in one module,
over two branches, at the same time.
In CVS, I've always found branches == pain.
I appreciate a move to something like subversion is quite a revolution,
and I'd suggest it's something best kept for the next
hi,
in the current version of the petstore sample the jxform part does not
work.
If you signed in ad want to change your account informations get errors.
This can easily be fixed by removing action=petstore attribute from
xf:form in the following files:
Yep, unfurtunatly I can confirm this.
Reinhard
-Original Message-
From: Timothy Larson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 4:53 PM
To: [EMAIL PROTECTED]
Subject: Flow debugger not showing local variables
The Cocoon flow debugger works well except it
Geoff Howard wrote:
Great - I think we're all looking forward to this. I'm trying to get a
handle on upgrade path for current users. Sounds like we could acheive
drop-in support for the old cocoon.xconf format complete with my.roles
etc. but could switch the default cocoon.xconf (or
Jeff Ramsdale wrote:
If all the cool features that users want to play with are in the HEAD via
Subversion, you might think about easing the path to entry for the new
user...
Ain't this (http://cvs.apache.org/snapshots/cocoon-2.1/) easy enough? :)
Vadim
Well, that is at least three of us with this problem.
For me the Locals tab is always empty, refering to
a local in the Watch tab gets 'localvar is not defined.',
and assigning a value to a local in the Evaluate tab
causes Cocoon to freeze.
This is with:
Win2KPro, Sun JSDK 1.4.1_03, Cocoon
when i lauch the XML sample woody, i have
this error..
Original Exception: java.lang.NoSuchMethodError:
org.apache.cocoon.woody.datatype.SelectionListBuilder.build(Lorg/w3c/dom/Element;Lorg/apache/cocoon/woody/datatype/Datatype;)Lorg/apache/cocoon/woody/datatype/SelectionList; at
Hi Sylvain!
[EMAIL PROTECTED] wrote:
Hello Andreas,
This is very interesting!
But I'm not sure to understand:
First, I have to explain something about our background to let you
better understand what we do and why. This way it might be easier for
you to decide, whether this applies to you
Hi Leo,
Please do.
Thanks,
Chris
-Original Message-
From: leo leonid [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2003 7:57 AM
To: [EMAIL PROTECTED]
Subject: fixing/completing petstore sample for 2.1.1
hi,
in the current version of the petstore sample the jxform part
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13070.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22916.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
If all the cool features that users want to play with are in the HEAD via
Subversion, you might think about easing the path to entry for the new
user...
Ain't this (http://cvs.apache.org/snapshots/cocoon-2.1/) easy enough? :)
Vadim
For a moment I was going to acquiesce, but then I
Jeff Ramsdale wrote:
I expect the average new Cocoon user is also a Windows user (though I could be wrong). So why are the snapshots not in .zip format?
FYI: WinZip supports tar.gz files just fine.
- Miles Elam
Hi Reinhard,
Reinhard Poetz [EMAIL PROTECTED]
wrote on 09/03/2003 01:01:07 AM:
If flowscripts are reloaded depends on two parameters:
First on the
configuration of the interpreter if it allows reloads at all and how
often reloads are checked.
I checked cocoon.xconf and reload-scripts is
Sylvain,
Thanks for the tip. It turns out
that I must touch *both* the script file containing the load(...) instruction
and the sitemap (!) before my .js file is properly updated. I did
not try touching the main script file; this would be woody.js,
which is in a jar.
It's a hack, but it works,
My original intention in evaluating the DOM object was to support the
macro factility in JXTemplate. But in its current state the macro
facility is pretty much useless. So I'm +1 on removing macro
completely and changing the code to simply stream DOM objects as SAX
events. Do you want to make
It's true that only the scripts specified in map:flow in your sitemap
are automatically reloaded when modified. But you shouldn't have to
touch the sitemap or woody.js.
BTW you could use cocoon.processPipelineTo() to create your script and
then use eval() to load it.
Regards,
Chris
[EMAIL
I've just checked in a fix for this.
Regards,
Chris
Timothy Larson wrote:
Well, that is at least three of us with this problem.
For me the Locals tab is always empty, refering to
a local in the Watch tab gets 'localvar is not defined.',
and assigning a value to a local in the Evaluate tab
72 matches
Mail list logo
