Issue Subscription
Filter: COCOON-open-with-patch (88 issues)
Subscriber: cocoon
Key Summary
COCOON-1800 upload file with chinese filename when use upload widget repeater
http://issues.apache.org/jira/browse/COCOON-1800
COCOON-1794 [PATCH] Propagation of namespaces to a
Excuse the cross-post but it seems important for both projects.
El mié, 15-03-2006 a las 01:41 +, [EMAIL PROTECTED] escribió:
...
--- Additional Comments From [EMAIL PROTECTED] 2006-03-15 01:41 ---
Created an attachment (id=17896)
--
Daniel Fagerstrom wrote:
I have worked on implementing the blocks framework in terms of OSGi
for some time. Not everything is working yet, but I think it is time
to start discussing the involved ideas.
snip/
A Servlet Service
-
A bundle that provides a servlet, can
My own reflections on this is whether or not this is still Cocoon.
It seems to me that you are creating a framework for managing web
applications based upon servlets, OSGi and the URLConnections. This
doesn't seem all that specific to Cocoon - it seems more general than
that, and potentially more
Le 15 mars 06 à 11:46, Thorsten Scherler a écrit :
...or better ask is there already such a RequestReader in cocoon?
I can find find in
cocoon-2.1.x/src/blocks/webdav/samples/davmap/sitemap.xmap:
!-- Read the request for binaries PUT --
!--
map:match pattern=request/read
Le 15 mars 06 à 13:31, Upayavira a écrit :
...So, my question: Is this still cocoon, or is it becoming
something more
general than that (e.g. that could become a Felix sub-project) - thus
gaining a far wider adoption?..
Same feelings here - what you describe sounds way cool, but maybe
Upayavira wrote:
My own reflections on this is whether or not this is still Cocoon.
It seems to me that you are creating a framework for managing web
applications based upon servlets, OSGi and the URLConnections. This
doesn't seem all that specific to Cocoon - it seems more general than
that,
Sylvain Wallez wrote:
A bundle that provides a servlet, can register it as a service with a
declaration like [5]:
scr:component name=cocoon.servlet3
scr:implementation
class=org.apache.cocoon.blocks.osgi.TestServlet/
scr:service
scr:provide interface=javax.servlet.Servlet/
Le 15 mars 06 à 14:38, Reinhard Poetz a écrit :
...We should develop it under our project for now and when we know
more about all the consequences we can still move it to another
community or start to build a new one so that other projects that
don't need this Cocoon-thing can reuse it
Sylvain Wallez wrote:
A *very* important point IMO for the acceptance of all this by
developers is to be able do deploy a directory. This to have fast
roundtrips, without having to go through the compile/package/deploy cycle.
Felix has recently added the possiblity to add bundles which are
Daniel Fagerstrom wrote:
Conclusion
==
It should be noted that I haven't referred to any Cocoon specifics
above. That is one of the neat things about the architecture. It is
completely orthogonal to and independent of the rest of Cocoon and it
could be used together with any
Bonjour Bertrand,
Bertrand Delacretaz wrote:
Le 15 mars 06 à 11:46, Thorsten Scherler a écrit :
...or better ask is there already such a RequestReader in cocoon?
Would be nice. Please check the implementation: it works, but I cannot
guarantee that it's correctly implemented.
I can
Le 15 mars 06 à 15:31, Renaud Richardet a écrit :
...Bertrand Delacretaz wrote:
...It's defined in the main sitemap in the Cocoon default build:
map:reader logger=sitemap.reader.resource name=resource pool-
max=32 src=org.apache.cocoon.reading.ResourceReader
Hum, this is the
Ralph Goers wrote:
Please Daniel, don't take this personally as it isn't really directed at
you. Part of it is directed at myself as I haven't had any significant
amount of time to contribute to this work. I guess I'm just wondering if
I'm the only one who is feeling this way? If so, I'll
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Personally, the long waiting for this blocks system is having very
unfortunate effects on our community. We need to change that. Take the
development of blocks off the front stage, and let it happen quietly
somewhere until there's something clear
Upayavira wrote:
Ralph Goers wrote:
Please Daniel, don't take this personally as it isn't really directed at
you. Part of it is directed at myself as I haven't had any significant
amount of time to contribute to this work. I guess I'm just wondering if
I'm the only one who is feeling this
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Personally, the long waiting for this blocks system is having very
unfortunate effects on our community. We need to change that. Take the
development of blocks off the front stage, and let it happen quietly
somewhere until
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features
of 2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward. Unfortunately this is tight to many other changes like the
Spring based container
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward. Unfortunately this is tight to many other changes
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
Do that, and nothing other than 2.1 will ever happen. Getting real
blocks is a big thing. It looks like a lot of work, everyone has
always known that. Now that there is a little bit of momentum in the
blocks
Bertrand Delacretaz wrote:
How about backporting the Spring-based container and the new
configuration features to 2.1.x, and make that Cocoon 2.3, without
touching the current trunk?
The current 2.2 would then stay as is, people could work on it until
it stabilizes, and when it's
* Bertrand Delacretaz:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration
features of 2.2 in 2.1.x, like the includes for xconf and
properties. This alone is a big step forward. Unfortunately
this is tight to many
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward. Unfortunately this is tight to many
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
Do that, and nothing other than 2.1 will ever happen. Getting real
blocks is a big thing. It looks like a lot of work, everyone has
always known that. Now that there is a little bit of momentum
Le 15 mars 06 à 16:25, Jean-Baptiste Quenot a écrit :
* Bertrand Delacretaz:
...How about backporting the Spring-based container and the new
configuration features to 2.1.x, and make that Cocoon 2.3,
without touching the current trunk?
Good idea. But I guess you are talking about
My feelings about the blocks and OSGi are vented here already: too few
people know that is going on and what to do and although these features
are big promises, at the moment they are just that: promises.
Is it possible to get the best of both worlds and do something like this:
- evolve 2.1.X
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
snip/
I would like to see blocks and Cocoon 2.1.X move along in parallel, and
as soon as blocks are sufficiently mature and stable, they merge. The
current state of affairs with a tiny minority working on blocks (however
cool) and nothing
Reinhard Poetz wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward.
* hepabolu:
- evolve 2.1.X to include (Carsten's idea) the new configuration
features of 2.2 and Spring (and Maven 2 build?).
Maven 2 build would be great, but there is a problem with
deployment. AFAICT we will be able to have the Maven build ready
once we have a simple way to choose blocks
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
snip/
I would like to see blocks and Cocoon 2.1.X move along in parallel, and
as soon as blocks are sufficiently mature and stable, they merge. The
current state of affairs with a tiny minority working on blocks (however
Le 15 mars 06 à 16:28, Reinhard Poetz a écrit :
...I have no problem with a backport in general, but why exactly
*now* when Daniel writes a mail that he has solved all problems
that required a lot of research work and Daniel and I only need
some more weeks of implementation work?...
Reinhard Poetz wrote:
I have no problem with a backport in general, but why exactly *now* when
Daniel
writes a mail that he has solved all problems that required a lot of research
work and Daniel and I only need some more weeks of implementation work?
I guess the mail was just a
* Carsten Ziegeler:
Author: cziegeler
Date: Wed Mar 15 06:55:25 2006
New Revision: 386086
URL: http://svn.apache.org/viewcvs?rev=386086view=rev
Log:
Add processForm method for forms without continuations
Carsten,
I have already introduced a function for forms without
Ok, here is a simple plan to continue.
Please note, that the current trunk has several new things: a new core
which can be seen as a follow-up to 2.1.x, the blocks stuff and the
maven build. We can use trunk as a direct follow-up to 2.1.x without blocks!
As Bertrand suggested we should start
Ross Gardler wrote:
Bruno Dumon wrote:
The goal of all this would be that the basic facts about each component
are taken from the source code, and longer (user-oriented) documentation
could then be added in Daisy (in a document part that is left alone by
this tool).
Super cool!
yes,
Jean-Baptiste Quenot schrieb:
* Carsten Ziegeler:
Author: cziegeler
Date: Wed Mar 15 06:55:25 2006
New Revision: 386086
URL: http://svn.apache.org/viewcvs?rev=386086view=rev
Log:
Add processForm method for forms without continuations
Carsten,
I have already introduced a
Carsten Ziegeler said the following on 15-03-2006 17:00:
At the same time the blocks stuff can continue and we are not blocking
any development.
WDYT?
+1
Bye, Helma
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Who _really_ is following the blocks thread anyway other than the core
developers? I want someone else for the rest of us to follow.
So, what else do you want that you can't do in 2.1 and are unwilling
to do in 2.2?
--
Peter Hunsberger
Il giorno 15/mar/06, alle ore 17:00, Carsten Ziegeler ha scritto:
Ok, here is a simple plan to continue.
snip/
WDYT?
I like it. I share Upayavira's and others' frustration at not
understanding (our fault entirely) what is going on in trunk and
being able to help.
Ugo
--
Ugo
* Carsten Ziegeler:
Jean-Baptiste Quenot schrieb:
* Carsten Ziegeler:
Author: cziegeler
Date: Wed Mar 15 06:55:25 2006
New Revision: 386086
URL: http://svn.apache.org/viewcvs?rev=386086view=rev
Log:
Add processForm method for forms without continuations
I have
Jean-Baptiste Quenot schrieb:
* Carsten Ziegeler:
Jean-Baptiste Quenot schrieb:
* Carsten Ziegeler:
Author: cziegeler
Date: Wed Mar 15 06:55:25 2006
New Revision: 386086
URL: http://svn.apache.org/viewcvs?rev=386086view=rev
Log:
Add processForm method for forms without continuations
I
Hello,
I'm trying to compile the JCR block and followed the instructions
in src/blocks/jcr/readme.txt. However, build fails complaining
that it cannot find JCR classes. So I moved lib/local/jcr-1.0.jar
to lib/core and it works... until the « validate-jars » task that
is failing in turn
Le 15 mars 06 à 17:40, Jean-Baptiste Quenot a écrit :
...it works... until the « validate-jars » task that
is failing in turn because this JAR is not in jars.xml...
IIRC you can deactivate validate-jars with an option in (local.)
build.properties
-Bertrand
smime.p7s
Description: S/MIME
Carsten Ziegeler wrote:
Ok, here is a simple plan to continue.
Please note, that the current trunk has several new things: a new core
which can be seen as a follow-up to 2.1.x, the blocks stuff and the
maven build. We can use trunk as a direct follow-up to 2.1.x without blocks!
As Bertrand
Hi,
I'm new to the list and posted a few days ago on the user list. I am
especially interested in dynamic pipelines and content aware pipelines,
as these are for me the two biggest restrictions of the parts of cocoon
I am currently using. I spent some time reading the archives and found a
Le 15 mars 06 à 17:00, Carsten Ziegeler a écrit :
...At the same time the blocks stuff can continue and we are not
blocking
any development...
+1 on your plan!
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't destabilize
the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It
just cannot affect that as there are no dependencies from the
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
I have worked on implementing the blocks framework in terms of OSGi
for some time. Not everything is working yet, but I think it is time
to start discussing the involved ideas.
snip/
A Servlet Service
-
A bundle that provides a
Upayavira skrev:
My own reflections on this is whether or not this is still Cocoon.
It seems to me that you are creating a framework for managing web
applications based upon servlets, OSGi and the URLConnections. This
doesn't seem all that specific to Cocoon - it seems more general than
that,
Daniel Fagerstrom wrote:
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't destabilize
the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It
just cannot affect that as there are no
Daniel Fagerstrom wrote:
snip/
Inter Block Communication
=
The servlets (sitemaps) in the different blocks need to be able to call
each other. Also it simplifies reuse of blocks if one block can extend
another one (or rather that a servlets in one block can extend a
[
http://issues.apache.org/jira/browse/COCOON-1724?page=comments#action_12370644
]
Antonio Gallardo commented on COCOON-1724:
--
fb:group is basically the replacement of the former wd:struct [1].
We can find some docs ([2] and [3]) in our wiki
52 matches
Mail list logo
