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=10203.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
- Original Message -
From: Vadim Gritsenko [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 2:48 PM
Subject: RE: Servlet initializing twice
From: Jeroen ter Voorde [mailto:[EMAIL PROTECTED]]
Hi,
I read this problem was fixed in the latest tomcat versions.
From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
Let's vote for making XSLTC the default XSLT parser in Cocoon 2.1-dev
alpha.
+1
I think the stylesheets which depend on Xalan
extensions should
specificly name the transformer. All the rest should be fine
with XSLTC,
or if they're not,
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Hi team,
The extended sitemap variable substitution syntax based on
InputModules
is available in HEAD.
Sitemap variables can now be prefixed by the name of an InputModule.
This means for example that {request:foo} will evaluate to
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=10117.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
sylvain 2002/06/25 00:55:13
Modified:src/java/org/apache/cocoon/components/treeprocessor
AbstractProcessingNodeBuilder.java
src/java/org/apache/cocoon/components/treeprocessor/sitemap
MatchNodeBuilder.java
On Tuesday 25 June 2002 09:40, Piroumian Konstantin wrote:
Hi team,
The extended sitemap variable substitution syntax based on
InputModules
is available in HEAD.
excellent!
Sitemap variables can now be prefixed by the name of an InputModule.
This means for example that
On 25.Jun.2002 -- 11:40 AM, Piroumian Konstantin wrote:
Sitemap variables can now be prefixed by the name of an InputModule.
This means for example that {request:foo} will evaluate to
the value
of the foo request parameter or that {session:myAttr}
will evaluate
to the value of
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
Piroumian Konstantin wrote:
Writing JavaScript even for client-side can be very tricky
sometimes, but
when you'll start to perform component lookups, EJB calls,
etc. in JS then
you'll have much fun trying to understand why your
On 25.Jun.2002 -- 10:13 AM, Torsten Curdt wrote:
hm... if we'd go that far request:getParameter(bla) would probably the most
straight forward syntax for those users. But sooner or later there will be
requests asking for default values (if a parameter is not set) and we end up
with a
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
Christian Haul wrote:
there's a -target release switch to javac.
Yes, and this is set to 1.2 (I hope) and afaiu it affects
only the byte-code but not the libraries/packages used for
compilation.
In Ant, there is a
cziegeler2002/06/25 01:52:58
Modified:src/documentation/xdocs/developing/webapps
authentication.xml
src/java/org/apache/cocoon/webapps/authentication/acting
LoginAction.java
src/webapp/samples/portal
cziegeler2002/06/25 02:32:48
Modified:src/webapp/samples/mod-db sitemap.xmap
src/webapp/samples/protected sitemap.xmap
Log:
Avoid usage of context: . Now these samples are relocatible
Revision ChangesPath
1.2 +3 -3
Get yourself default values (from current cocoon.xconf):
component-instance
class=org.apache.cocoon.components.modules.input.DefaultsMetaModule
name=defaults
input-module name=request/
values
skindefaultSkin/skin
base-urlhttp://localhost:8080/cocoon/base-url
/values
haul2002/06/25 02:37:05
Modified:src/documentation/xdocs/userdocs/concepts modules.xml
Log:
Add new sitemap syntax, thanks to Sylvain.
Revision ChangesPath
1.2 +51 -12
xml-cocoon2/src/documentation/xdocs/userdocs/concepts/modules.xml
Index:
On 25.Jun.2002 -- 11:32 AM, Frank Taffelt wrote:
Get yourself default values (from current cocoon.xconf):
component-instance
class=org.apache.cocoon.components.modules.input.DefaultsMetaModule
name=defaults
input-module name=request/
values
skindefaultSkin/skin
Christian Haul wrote:
AFAIK it is possible to declare components in a sitemap using
map:components. Thus
map:components
input-modules logger=core.modules.input
component-instance
class=org.apache.cocoon.components.modules.input.DefaultsMetaModu
le name=my-defaults
- Original Message -
From: Vadim Gritsenko [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 2:48 PM
Subject: RE: Servlet initializing twice
From: Jeroen ter Voorde [mailto:[EMAIL PROTECTED]]
Hi,
I read this problem was fixed in the latest tomcat
On 25.Jun.2002 -- 11:50 AM, Carsten Ziegeler wrote:
AFAIK, the discussion was a little bit different. Some of us wanted
to remove *all* component definitions from the sitemap, so completly
removing the map:components section.
But I can't recall a discussion about adding own component
On Tuesday 25 June 2002 10:39, Christian Haul wrote:
On 25.Jun.2002 -- 10:13 AM, Torsten Curdt wrote:
hm... if we'd go that far request:getParameter(bla) would probably the
most straight forward syntax for those users. But sooner or later there
will be requests asking for default values
From: Piroumian Konstantin [EMAIL PROTECTED]
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
Piroumian Konstantin wrote:
For completeness of the example I have to say, that
business logic is
implemented partially in EJBs (in pure Java) and partially
comes from
external
Does anyone remember the good old SAXConnector?
It was originally designed for transparently handling
xinclude/cinclude statements. But it wasn't used for this
because of the problems it caused for the caching.
Then SAXConnectors were used for profiling and debugging.
The profiling code was
On 25.Jun.2002 -- 12:07 PM, Torsten Curdt wrote:
On Tuesday 25 June 2002 10:39, Christian Haul wrote:
On 25.Jun.2002 -- 10:13 AM, Torsten Curdt wrote:
Well, but I bet people want default values per use... (this is not a proposal
just an example ;) something like:
Well, from a
From: Christian Haul [mailto:[EMAIL PROTECTED]]
...
OTOH I believe that the current implementation is a big step forward
and while there is plenty of room to extend this concept, we should
gather hands-on experience first before attaching too many knobs to
it.
+1
Vadim
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Does anyone remember the good old SAXConnector?
It was originally designed for transparently handling
xinclude/cinclude statements. But it wasn't used for this
because of the problems it caused for the caching.
Then SAXConnectors were
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=10208.
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=10208.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi!
I am remembering that I removed (or wished to) all the JSP* stuff from the
root sitemap after the JSP sample refactoring, but they are still there. Is
it intended so or I simply forgot to do it?
Konstantin
_
Konstantin Piroumian
Lead Developer
Vadim Gritsenko wrote:
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Does anyone remember the good old SAXConnector?
It was originally designed for transparently handling
xinclude/cinclude statements. But it wasn't used for this
because of the problems it caused for the
bloritsch2002/06/25 06:35:08
Modified:src/java/org/apache/cocoon/components/language/generator
GeneratorSelector.java
src/java/org/apache/cocoon/components/validation/schematron
SchematronFactory.java
On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote:
snip /
So what use cases do we have?
* It should definitely be easy to write wizards in a flow description
language.
I believe this is the case for flowscripts (see
Please keep in mind that in JDK 1.4 the word 'assert' is a keyword. To
avoid broken compiles, please refrain from using that word.
I used 'assertion' as it means the same thing, but won't cause compile
errors if someone wanted to compile Cocoon with assertion support.
They that give up
cziegeler2002/06/25 07:04:58
Modified:src/documentation/xdocs/installing updating.xml
src/java/org/apache/cocoon cocoon.roles
Log:
Updated updating docs a little bit
Revision ChangesPath
1.6 +18 -1
Hi,
At the moment I think about a source resolver which handles a pool
of sources. At the moment, for every retrieving a source you must
create a new object.
I would propose to store the Source components into a store(perhaps the
transient store). This will speed up some things.
I also noticed
Piroumian Konstantin wrote:
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
Piroumian Konstantin wrote:
Writing JavaScript even for client-side can be very tricky
sometimes, but
when you'll start to perform component lookups, EJB calls,
etc. in JS then
you'll have much fun
Diana Shannon wrote:
On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote:
snip /
So what use cases do we have?
* It should definitely be easy to write wizards in a flow description
language.
I believe this is the case for flowscripts (see
Hi All,
I downloaded the latest version of cocoon2.1-dev and I get the following
error while trying to run the
examples of SourceWriterTransformer (tomcat 404b2+jdk1.4+winnt4.0):
java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:79)
at java.util.Stack.pop(Stack.java:61)
at
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Vadim Gritsenko wrote:
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Does anyone remember the good old SAXConnector?
It was originally designed for transparently handling
xinclude/cinclude statements. But it wasn't
Is it possible to make the InputModule feature available to 2.0.3 as well as
2.1?
Per
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Stefano Mazzocchi wrote:
Sure. I tried and I *HATED* the fact that in order to do something as
simple as
if (request.blah 0)
call(error.html, request.blah);
else
call(result.html, request.blah);
I have to write a 'ComparingSelector' and then use it like this
map:act
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
Christian Haul wrote:
there's a -target release switch to javac.
Yes, and this is set to 1.2 (I hope) and afaiu it affects
only the byte-code but not the libraries/packages used for
On 25.Jun.2002 -- 11:57 AM, Per Kreipke wrote:
Is it possible to make the InputModule feature available to 2.0.3 as well as
2.1?
InputModules are in 2.0.x scratchpad, a bit out of sync though.
As for the sitemap integration - 2.0.3 is a bug fix release and no new
features should be
Diana,
On 6/25/02 6:52 AM, Diana Shannon [EMAIL PROTECTED] wrote:
On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote:
snip /
So what use cases do we have?
* It should definitely be easy to write wizards in a flow description
language.
I believe this is the case for
Per Kreipke wrote:
Is it possible to make the InputModule feature available to 2.0.3 as well as
2.1?
Seems you like this feature, eh ?
Well, there are several problems for this to be available in 2.0.3 :
- InputModules are in scratchpad and TreeProcessor in the main trunk and
now has a
Christian, Sylvain,
Thanks for your responses. Unfortunately, living on the bleeding edge isn't
possible for a (soon to be) production system :-o.
Also, it seems like 'waiting for 2.1' could turn into a play of a similar
name ;-) [tongue in cheek, no criticism intended!] It sounds like there
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Does anyone remember the good old SAXConnector?
It was originally designed for transparently handling
xinclude/cinclude statements. But it wasn't used for this
because of the problems it caused
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=10228.
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=10228.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Carsten Ziegeler wrote:
...
AFAIK, the discussion was a little bit different. Some of us wanted
to remove *all* component definitions from the sitemap, so completly
removing the map:components section.
But I can't recall a discussion about
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Per Kreipke wrote:
Is it possible to make the InputModule feature available to 2.0.3 as
well as
2.1?
Seems you like this feature, eh ?
Well, there are several problems for this to be available in 2.0.3 :
- InputModules are in
From: Piroumian Konstantin [mailto:[EMAIL PROTECTED]]
Hi!
I am remembering that I removed (or wished to) all the JSP* stuff from
the
root sitemap after the JSP sample refactoring, but they are still
there. Is
it intended so or I simply forgot to do it?
Go ahead.
Vadim
Konstantin
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
Christian Haul wrote:
there's a -target release switch to javac.
Yes, and this is set to 1.2 (I hope) and afaiu it affects
only the byte-code but not the
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
Does anyone remember the good old SAXConnector?
It was originally designed for transparently handling
xinclude/cinclude statements. But
Ugo Cei wrote:
warningshameless plug ahead/warning
Stefano Mazzocchi wrote:
I'm not skeptical about visual tools that exist (gosh, I love GUIs!).
I'm skeptical about 'visual tools' that are possible but don't exist,
nor are freely available for us to play with, enhance and control.
54 matches
Mail list logo
