Upayavira wrote:
Seeing as we're all in RT mode at the moment...
So, I remember someone (Carsten?) saying that the only blocks that need
to modify something 'core' were those that needed to modify web.xml,
perhaps because they needed to provide their own servlet.
Yepp, this is a complete
Jorg Heymans wrote:
Daniel Fagerstrom wrote:
...
I'm not certain about exactly what distinction you refer to above.
Blocks (bundles) will be able to expose: classes, resources, components
and sitemap functionality. For some blocks it will make sense to expose
most or all of these
Sorry for replying so late but I had have some trouble
Am Freitag, 23. September 2005 22:52 schrieb Mark Lundquist:
Is that what you mean? Cocoon configuration is of course at
runtime, but the feature I want would allow for setting up the
transformer in a way that is more dynamic:
Daniel Fagerstrom wrote:
The distinction I was referring to boils down to using separate my.block
and my.block.samples directories. You separated it for core, so I was
wondering if we should do this for all Blocks.
Yes we decided, IIRC, to do that a while ago. Now we just wait for
Niclas Hedhman wrote:
On Sunday 25 September 2005 21:39, Daniel Fagerstrom wrote:
I think we should move the content of trunk/src/ to trunk/, and
start considering them as separate projects (blocks).
I would be really happy if a top-level build script (maven, ant, bash, perl,
whatever) is
Niclas Hedhman wrote:
On Monday 26 September 2005 04:20, Upayavira wrote:
Surely, if, in an OSGi scenario, if a block needs a servlet, it should
register it directly with the OSGi servlet container service, rather
than messing with Cocoon's web.xml?
Has it been sorted out how OSGi platform
Done.
If some people using the portal could test this would be great.
Carsten
Carsten Ziegeler wrote:
I'll commit an improved version today that will only use absolute urls
if the protocol is switched. If the protocol stays the same, the url
will be relative - as in 2.1.7.
Carsten
Carsten Ziegeler wrote:
I'll commit an improved version today that will only use absolute urls
if the protocol is switched. If the protocol stays the same, the url
will be relative - as in 2.1.7.
Many thanks Carsten!
Sylvain
--
Sylvain WallezAnyware Technologies
Niclas Hedhman wrote:
On Sunday 25 September 2005 21:39, Daniel Fagerstrom wrote:
I think we should move the content of trunk/src/ to trunk/, and
start considering them as separate projects (blocks).
I would be really happy if a top-level build script (maven, ant, bash, perl,
Registration ends on September 28th, so be quick!
We already have 70 attendees (from 11 countries), and the counter is still
rising..
If you're unable to register for any reason, but still want to come, please
drop me an email.
Cocoon GetTogether
Seriously ...noone?
cheers
--
Torsten
On 23.09.2005, at 10:56, Torsten Curdt wrote:
No this not another one of those let's switch the
logging system threads ;)
...instead I would like to get the components using
commons logging to log through logkit. I *know*
this was working at some stage.
* Mark Lundquist:
The I18nTransformer is giving me fits. When I change the
contents of a message catalogue, the changes don't take affect
unless I restart Cocoon.
It is already fixed, see
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=11155919291w=4
--
Jean-Baptiste Quenot
Joerg Heinicke wrote:
On 24.09.2005 13:17, Daniel Fagerstrom wrote:
WDYT?
What's the actual problem you want to solve?
There are a lot of large and small items to do to get working real
blocks. I think it would be more practical to gather these in Bugzilla
as soon as I find time to do
Hi Sylvain and Jason
Yes, many thanks to both of you !!
This patch fixes the issue I had whereby a submit originating from a
second widget, cause exceptions in the repeater.
The other issue was fixed by making sure TBU sent the continuation-id
if one existed.
So both issues are solved,
I've just done SVN up, done m2 -Dmaven.test.skip=true install
Then, I patched cocoon.sh:
Index: cocoon.sh
===
--- cocoon.sh (revision 291611)
+++ cocoon.sh (working copy)
@@ -93,7 +93,7 @@
Did you make a m2 clean:clean before?
I guess you have two versions of commons-jci in your WEB-INF/lib dir?
HTH
Carsten
Upayavira wrote:
I've just done SVN up, done m2 -Dmaven.test.skip=true install
Then, I patched cocoon.sh:
Index: cocoon.sh
Jeremy Quinn wrote:
Hi Sylvain and Jason
Yes, many thanks to both of you !!
This patch fixes the issue I had whereby a submit originating from a
second widget, cause exceptions in the repeater.
The other issue was fixed by making sure TBU sent the continuation-id
if one existed.
So
On 26 Sep 2005, at 14:00, Jason Johnston wrote:
Jeremy Quinn wrote:
Hi Sylvain and Jason
Yes, many thanks to both of you !!
This patch fixes the issue I had whereby a submit originating from
a second widget, cause exceptions in the repeater.
The other issue was fixed by making sure TBU
Carsten Ziegeler wrote:
Did you make a m2 clean:clean before?
I guess you have two versions of commons-jci in your WEB-INF/lib dir?
Thanks for your prompt reply. That sorted it. Maybe at some point I'll
actually understand all this Maven stuff :-)
Regards, Upayavira
Upayavira wrote:
Carsten Ziegeler wrote:
Did you make a m2 clean:clean before?
Boy, clean:clean is s /neat/ ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
I would suggest looking into the approach I am taking. We store a lot
of configuration information in a repository that sort of resembles JDK
1.4 preferences. To integrate this with Cocoon I wrote my own source
resolver. So I can put prefs://somestring as the location. The source
resolver
Carsten Ziegeler wrote:
Upayavira wrote:
Seeing as we're all in RT mode at the moment...
So, I remember someone (Carsten?) saying that the only blocks that need
to modify something 'core' were those that needed to modify web.xml,
perhaps because they needed to provide their own servlet.
Upayavira wrote:
Niclas Hedhman wrote:
On Monday 26 September 2005 04:20, Upayavira wrote:
Surely, if, in an OSGi scenario, if a block needs a servlet, it should
register it directly with the OSGi servlet container service, rather
than messing with Cocoon's web.xml?
Has it been sorted
Hi,
On 23 Sep 2005, at 10:48, Carsten Ziegeler wrote:
I'm just wondering if svn externals are a good idea wrt to versioning.
One unfortunate side-effect of using svn externals is it's tricky to
track down via viewcvs - eg http://svn.apache.org/viewcvs.cgi/cocoon/
On 26 Sep 2005, at 14:09, Jeremy Quinn wrote:
On 26 Sep 2005, at 14:00, Jason Johnston wrote:
Jeremy Quinn wrote:
Hi Sylvain and Jason
Yes, many thanks to both of you !!
This patch fixes the issue I had whereby a submit originating
from a second widget, cause exceptions in the
Hi all,
We started to use the new widget libraries today, and encountered a
number of semantic issues, mainly related to difficulties to clearly map
names to concepts.
To use libraries, we currently have at hand:
- fd:import to make a library available for reuse in the current form
(or
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
e) XSP and all blocks adding logicsheets
The configuration for XSP is still in the main cocoon.xconf, so this one
has to be patched for XSP and logicsheets.
Do they have to be there, or is it just that no one have changed them
to the new
Torsten Curdt wrote:
Seriously ...noone?
I've not looked into this yet but I think both commons-logging and log4j should
be integrated into the Cocoon's configured logger, so that output from all 3rd
party libraries can be sent to Cocoon's logger.
Vadim
Torsten
On 23.09.2005, at 10:56,
Il giorno 26/set/05, alle 17:23, Sylvain Wallez ha scritto:
- rename fd:class to fd:macro (this is the wording used on the
wiki [1][2])
- rename fd:new to fd:expand: expanding is the word used
traditionally to denote insertion of the macro contents at the current
location.
I'd rather use
I haven't looked at the new and improved CForms yet, but I'm all for
clarification.
Sylvain Wallez wrote:
These names make it very difficult to understand what does what. I'd
like therefore to propose a renaming:
- rename fd:class to fd:macro (this is the wording used on the wiki
[1][2])
Hi all,
While working on some new CForms stuff (Ajax suggest lists and
fi:styling as attributes), I felt more and more limited by the reduced
enviromnent that JXTG offers to macros.
Put it clearly, here's what I need to be accessible in macros:
- the service manager: I need to get a
Ugo Cei wrote:
Il giorno 26/set/05, alle 17:23, Sylvain Wallez ha scritto:
- rename fd:class to fd:macro (this is the wording used on the
wiki [1][2])
- rename fd:new to fd:expand: expanding is the word used
traditionally to denote insertion of the macro contents at the
current location.
Sylvain Wallez wrote:
Hi all,
We started to use the new widget libraries today, and encountered a
number of semantic issues, mainly related to difficulties to clearly map
names to concepts.
To use libraries, we currently have at hand:
- fd:import to make a library available for reuse in the
hepabolu wrote:
I haven't looked at the new and improved CForms yet, but I'm all for
clarification.
Sylvain Wallez wrote:
These names make it very difficult to understand what does what. I'd
like therefore to propose a renaming:
- rename fd:class to fd:macro (this is the wording used on the
Reinhard Poetz wrote:
Sylvain Wallez wrote:
Hi all,
We started to use the new widget libraries today, and encountered a
number of semantic issues, mainly related to difficulties to clearly
map names to concepts.
To use libraries, we currently have at hand:
- fd:import to make a library
On 26.09.2005 13:15, Jean-Baptiste Quenot wrote:
* Mark Lundquist:
The I18nTransformer is giving me fits. When I change the
contents of a message catalogue, the changes don't take affect
unless I restart Cocoon.
It is already fixed, see
Sylvain Wallez wrote:
Hi all,
While working on some new CForms stuff (Ajax suggest lists and
fi:styling as attributes), I felt more and more limited by the reduced
enviromnent that JXTG offers to macros.
Put it clearly, here's what I need to be accessible in macros:
- the service manager:
Hi everyone!
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Monday, September 26, 2005 17:24
To: dev@cocoon.apache.org
Subject: [cforms] rethinking library naming
Hi all,
We started to use the new widget libraries today,
Nice to see it's used! :D
Thorsten Scherler wrote:
Hi all,
in forrest we run lately into problems with the linkrewriter and jxpath.
I am trying to debug that but I had some problems.
The problem I had in debugging the
org.apache.cocoon.transformation.LinkRewriterTransformer class in
eclipse (3.1) for forrest is that I
On 26.09.2005 18:31, Sylvain Wallez wrote:
I think it's time to make the template block available in 2.1 as well.
We may want to keep the old generator in
o.a.c.generation.JXTemplateGenerator and use the new version only
through o.a.c.template.JXTemplateGenerator.
+1
Jörg
Upayavira wrote:
Niclas Hedhman wrote:
On Monday 26 September 2005 04:20, Upayavira wrote:
Surely, if, in an OSGi scenario, if a block needs a servlet, it should
register it directly with the OSGi servlet container service, rather
than messing with Cocoon's web.xml?
Has it been sorted out
On 26.09.2005 13:45, Daniel Fagerstrom wrote:
For the real blocks I would like to get more people involved. The main
hinderance for people to work on it is probably lack of time and/or
interest. But for some people the problem might be that it seem rather
complicated and that it is not that
Sylvain Wallez wrote:
Finally, I'm a bit fed up with maintaining the historical JXTG in the
2.1 branch. I think it's time to make the template block available in
2.1 as well. We may want to keep the old generator in
o.a.c.generation.JXTemplateGenerator and use the new version only
through
Vadim Gritsenko wrote:
Upayavira wrote:
Niclas Hedhman wrote:
On Monday 26 September 2005 04:20, Upayavira wrote:
Surely, if, in an OSGi scenario, if a block needs a servlet, it should
register it directly with the OSGi servlet container service, rather
than messing with Cocoon's web.xml?
Upayavira wrote:
This may be the way used my most Cocoon users at the moment, yes.
However, many Cocoon users just want to start Cocoon, they're not fussed
about a servlet container, that's just a complication. For those, the
OSGi approach will work.
For the more aware, and perhaps
Upayavira wrote:
Vadim Gritsenko wrote:
Well, we have briefly talked about the fact that we need to support
both scenarios. We need to be able to run the Cocoon servlet within
an OSGi framework, and this will probably be the default option, and
we also
I can not imagine who or in what
Hi,
I'm writing a custom DOM-based transformer (extends
AbstractDOMTransformer), but I cannot figure out, how to produce output
with no whitespace. It's propably very simple thing...
Anyone?
-Tuomo
Vadim Gritsenko wrote:
Upayavira wrote:
Vadim Gritsenko wrote:
Well, we have briefly talked about the fact that we need to support
both scenarios. We need to be able to run the Cocoon servlet within
an OSGi framework, and this will probably be the default option, and
we also
I can not
Vadim Gritsenko wrote:
Upayavira wrote:
Vadim Gritsenko wrote:
...
(don't forget command line, portlet, or any other 3rd party
environments too)
Yes, and I've not seen how it can be otherwise (i understand that it's
possible to use current osgi http service for an RD process, i'm
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Upayavira wrote:
Vadim Gritsenko wrote:
(don't forget command line, portlet, or any other 3rd party
environments too)
Yes, and I've not seen how it can be otherwise (i understand that it's
possible to use current osgi http service for an
Wicksteed, Charles wrote:
Hi,
A new toSAX() method was introduced in
org/apache/cocoon/components/source/SourceUtil.java in version 165317,
when some refactoring was done to clean up the exception handling. This
causes a problem when you try to call toSAX() from Flowscript with
certain
51 matches
Mail list logo
