Carsten Ziegeler skrev:
I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all of them are
stored in the jar and on deployment
Reinhard Poetz skrev:
Maven brings a lot of advantages to standardize the development
process but also makes development of applications more difficult as
you spread your applications over different artifacts.
In the light of this I think we should revert our removal of the
per-sitemap
Carsten Ziegeler skrev:
Reinhard Poetz wrote:
How does OSGi solve this?
Since OSGi4 declarative services are supported. Think of Spring dependency
injection but considering interface/implementation relations. You can use the
OSGi configuratonAdmin service to change an injected component or a
Carsten Ziegeler skrev:
Reinhard Poetz schrieb:
Carsten Ziegeler wrote:
Reinhard Poetz wrote
I have just committed it but didn't update SitemapLanguage.java accordingly.
A brief look reveals that you do not support all lifecycle interfaces.
Aren't SingleThreaded and ThreadSafe enough. We
Ralph Goers skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have
Peter Hunsberger skrev:
On 5/17/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
snip/
2. This works only as long as the user wants to use the same
implementation for a component. Switching to an own implementation with
an own configuration is not possible.
Any idea on how to solve
Ralph Goers skrev:
Daniel Fagerstrom wrote:
No, I meant something different than the mechanism today, something
that works like the PropertyOverrideConfigurer in Spring. Say that you
have a configuration file like:
store logger=core.store
parameter name=maxobjects value=1000
Carsten Ziegeler skrev:
Giacomo Pati wrote:
b) might work, but since you want it to be the default ClassLoader I
expect problems users forgot about wrapping their stuff in web.xml.
Yes, that's true - but apart from that what do you think about the idea?
As, we want to make Cocoon
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Giacomo Pati wrote:
b) might work, but since you want it to be the default ClassLoader I
expect problems users forgot about wrapping their stuff in web.xml.
Yes, that's true - but apart
After the recent refactoring of Cocoon where part of cocoon-core is
moved to the new cocoon-bootstrap, we have two packages: o.a.c.servlet
and o.a.c.util, that are split into two blocks. This means that we
cannot work on Cocoon3 anymore.
With OSGi, dependencies are at the package level. If
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
After the recent refactoring of Cocoon where part of cocoon-core is
moved to the new cocoon-bootstrap, we have two packages: o.a.c.servlet
and o.a.c.util, that are split into two blocks. This means that we
cannot work on Cocoon3 anymore.
Sorry
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I'm sorry if you felt attacked, I had no intension to attack you or
anyone else. There was a problem that needed to be solved so that I
could continue to work.
Ok, perhaps I overreacted a little bit. Sorry for that.
Of course I could have
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
It's already there :) In the webapp under samples/spring. The last time
I checked it (some weeks ago) it worked using:
http://localhost:/samples/spring.
Thanks, I found the samples and they still work :-)
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
But a listener has the advantage that the context is
available to other servlets (!= Cocoon) as well.
yes, then it makes sense indeed.
Besides that using a listener means that we separate the component
management from
Joerg Heinicke skrev:
Hello,
I'd like to introduce some people of our community and invite them for
becoming committers of the Cocoon project. Three people do I have in
mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston.
+3
/Daniel
Reinhard Poetz skrev:
Carsten Ziegeler wrote:
Ralph Goers wrote:
I have no problem with this release as a first step, but I'd
hesitate to even call it 2.2M1. OTOH, if I had an idea of what our
subsequent milestones are this might make more sense to me.
Good point! Now, if you something
Carsten Ziegeler skrev:
Some time ago we discussed very lengthy that our core interface, the
Processor, is not the best interface we ever invented. The processor
should be the main entrance to the Cocoon processing engine.
As I need a simple way of adding my own processor in my project, I
Carsten Ziegeler skrev:
Sylvain Wallez wrote:
However, a few remarks:
- how is Processor different from Servlet?
The interface is similar. The difference is configuration and who
manages the component. If a processor is a component we can use all nice
features of spring for that and I
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Don't think this is the best way to do it. The current
MountTableProcessor means that you only can mount SitemapProcessor and
no other kinds of controllers, as it explicitly manage the creation of
the SitemapProcessors. IMO it is better
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Are you using so many sitemap processors so that becomes a problem? We
have something like that today. The tree processor is configured as a
component, or will a Spring bean configuration be much more verbose?
No, the spring bean config
Reinhard Poetz skrev:
What do people think about making Java 5, which was released almost _2
years ago_, the minimum requirement for trunk?
Quoting Bruno from the Daisy list, I'd say that we can benefit from
some new features too: ... we can make use of features like generics,
the enhanced
Reinhard Poetz skrev:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
+1
/Daniel
Reinhard Poetz skrev:
I propose switching to servlet API 2.4 in *trunk*. This shouldn't
cause any problems as a stable version of Tomcat (5.0.16), the
reference implementation for servlet containers, is available since
Dec, 4th 2003.
+1
/Daniel
Joerg Heinicke skrev:
On 08.08.2006 18:47, Jorg Heymans wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic 8.1.
Joerg Heinicke skrev:
On 10.08.2006 11:41, Daniel Fagerstrom wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
-0, because this means eliminating cocoon 2.2 on older application
servers eg weblogic
Jorg Heymans skrev:
...
I'ld say we stop argueing about this and use our time more
constructively to experiment with the retroweaver. I hear it has an ant
task, integrating it into our build process should be a breeze then.
This seem like a reasonable proposal to me.
To
Andrew Savory skrev:
Hi,
Daniel Fagerstrom wrote:
To summarize how I understand the situation:
Joerg's main reason for the veto against using Java 5 in Cocoon 2.2
is that we would risk losing some of our user base.
I would be happier hearing this argument after a poll of the user list
Joerg Heinicke skrev:
On 15.08.2006 17:28, Jason Johnston wrote:
I am interested (and I think the community needs to know) what
Joerg's criteria for approving an eventual move to 1.5 would need to
be, in some measurable way. I'm sure he would agree that at some
point in the future moving to
Andrew Stevens skrev:
From: Sylvain Wallez [EMAIL PROTECTED]
...
All this discussion makes me sad, as it gives the impression the overall
Cocoon developer community doesn't want to move forward and is
frightened by moves that would cause some disruption among _some_ users.
Not so much
Carsten Ziegeler skrev:
Leszek Gawron wrote:
...
One VERY important question concerning cocoon core? Why is it based on
spring's BeanFactory and not on ApplicationContext?
I propose to switch from CocoonBeanFactory to CocoonApplicationContext.
WDYT?
I'm +1 for this - the original
Carsten Ziegeler skrev:
...
Yes, that's true - now there are some problems here (as always). I
started to implement a spring 2.0 xml namespace handler which would
allow to plugin the old avalon configuration into a spring
configuration using an own xml element, like avalon:components
Thorsten Scherler skrev:
Hi all,
http://marc.theaimsgroup.com/?t=11555856531r=1w=2
I know we had the light/diet discussion many times but the forrest
community has an emerging need for a very small cocoon. The forrest
community is talking about a new forrest implementation that is not
Leszek Gawron skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
Leszek Gawron wrote:
...
One VERY important question concerning cocoon core? Why is it based
on spring's BeanFactory and not on ApplicationContext? I propose to
switch from CocoonBeanFactory to CocoonApplicationContext
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
Yes, that's true - now there are some problems here (as always). I
started to implement a spring 2.0 xml namespace handler which would
allow to plugin the old avalon configuration into a spring
configuration using
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I don't think it should be a problem for the OSGi stuff. It is probably
easy to refactor it so that it use your new stuff.
Great :) At least in theory I have solved all problems; I hope to finish
the stuff and commit it in the next few
Leszek Gawron skrev:
Daniel Fagerstrom wrote:
Why not expose core also with a lighter interface?
I can't follow you here, what lighter interface?
Let's define that interface and allow block that do not use spring use
instead of ApplicationContext.
Ok, I understand.
My view
Carsten Ziegeler skrev:
Leszek Gawron wrote:
...
- you won't even be able to define a new cforms widget definition
because they don't use the new service selector that allows to span
components over several files.
While some things are trivial to fix some are not and all definitely
need
It seem like the Spring-OSGi integration work is taking of quite
seriously http://www.osgi.org/blog/2006/08/osgi-and-spring_29.html. Key
players from both OSGi, Spring and some large companies are working on it.
For Cocoon I think the way to go forward is that we make the part of the
blocks
hepabolu skrev:
My first reaction was: can't we fit all of them in?
On second thoughts: I cannot choose between the various talks, but
given the subject of Daniel's talk and my experience with the
complexity of his talk of last year, I propose that his talk be moved
to the Hackathon. I
Jean-Baptiste Quenot skrev:
And FWIW I added an interesting topic for the Hackaton:
See http://wiki.apache.org/cocoon/GT2006Hackaton
--
[Jean-Baptiste Quenot] Try to replace Maven 2 with Ant and Ivy
You are of course free to experiment with whatever you feel like. But
IMO it would be to
Jean-Baptiste Quenot skrev:
* Reinhard Poetz:
Also don't forget that releasing a Cocoon artifact has become
very simple.
Could you be a little more specific?
Last time I tried following the instructions in README.txt, the
build was successful after 111 minutes. That is very
Jorg Heymans skrev:
On 28 Sep 2006, at 21:16, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
The simplest solution to that is that we just create a new catalog
named e.g. optionalblocks and move all of the blocks but the few that
actually are actively developed or used from blocks
Jean-Baptiste Quenot skrev:
I think time has come for Lars Trieloff to become a Cocoon
committer
+1
/Daniel
Antonio Gallardo skrev:
Renaud Richardet escribió:
I get the following errors:
cocoon-block-forms-compile:
Compiling 379 source files to
/home/ren/cocoon-2.1.10-dev/blocks/forms/dest
/home/ren/cocoon_2_1_x/src/blocks/forms/java/org/apache/cocoon/forms/util/JavaScriptHelper.java:213:
cannot
Bertrand Delacretaz skrev:
At http://wiki.apache.org/cocoon/GT2006Presentations
Speakers, please add your stuff (or links to it) there!
How do I do that? I tried to attach my presentation, but I can't see it
and didn't succeed in getting the MIME type right.
/Daniel
Joerg Heinicke skrev:
On 06.10.2006 00:57, Antonio Gallardo wrote:
Why actually? What has unwrap to do with pipeline processing? If it
is because it is only used there then it makes only sense to move it
there if you also make it private. Otherwise it is a public method
and it should be seen
I have committed the code I described at the GT
(http://wiki.apache.org/cocoon-data/attachments/GT2006Notes/attachments/12-CocoonBlocks.pdf).
So now we have a Spring based block architecture that is usable already
in 2.2 (of course there is still a lot of testing and stabilization work
left to
A technical question for the Spring experts:
In the current implementation of the blocks fw the BlockServlet is a
Spring managed component, but it gets init and destroy methods are
called in the DispatcherServlet. After having fought a little bit more
about it (and experienced some subtle
Joerg Heinicke skrev:
On 06.10.2006 11:35, Daniel Fagerstrom wrote:
For the JavaFlow the Abstract.Contunable.processPipelineTo uses
PipelineUtil.processToStream, it might be a good idea to copy the code
to JavaFlow to get rid of the dependency on Floscript.
The PipelineUtil in its current
FYI
---BeginMessage---
I'm very pleased to say that the Spring-OSGi project is now up and
running in its new home.
We have a website: http://www.springframework.org/osgi. On this site
you'll find links to a nice readable version of the specification,
and a basic sample
Alexander Klimetschek skrev:
Hi Daniel,
I am playing around with the new blocks protocol and the BlockServlets.
Cool!
I have two blocks A and B, B inherits from A and then there is a
webapp that uses both blocks. The webapp has the DispatcherServlet
configured in the web.xml and the
Alexander Klimetschek skrev:
Just a follow up: blockContextURL cannot point to an absolute path in
the local file sytem yet:
b) the blockContextURL should point to the source-folder (like in the
sitemap generated by the deployer) so that reloading works on the
developer's working directory
Arje Cahn skrev:
...
The discussion about a new design for our website is great, but I feel there are
much bigger mistakes that we have to get straightened out before the
shinyness of
our website is of any importance. We need to decide where we put
what, as it's
currently spread all over
Ross Gardler skrev:
Daniel Fagerstrom wrote:
...
Second we need some (simple) way to suggest news. I think we should
suggest possible news items at the dev-list by having a special
headers prefix like [news].
I'd suggest just letting (self-registered) people add a news item to
Daisy
Vadim Gritsenko skrev:
Renaud Bruyeron wrote:
Therefore I would really like to be able to isolate the pipeline from
the rest of cocoon, and be able to configure and instantiate it alone.
I would like to do things like this:
Generator producer = MyFactory.newGenerate(...);
XMLConsumer
Alexander Klimetschek skrev:
Hi Daniel,
a problem during development when using the blocks-protocol is that you
don't see a stacktrace when some problem occurs inside the block called
via the BlockSource. You get an empty XML/HTML stream sent to the browser.
As far as I can see, the nice
Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
If we want to factor out the pipeline functionality to an own block
that doesn't depend on the rest of Cocoon it will certainly be a lot
of work. But I think it would be worthwhile anyway as it would
increase usability and make
was Re: [jira] Created: (COCOON-1943) [Patch] Parameters in
blocks-protocol URIs get decoded too early
Alexander Klimetschek (JIRA) skrev:
...
(A little bit Off-topic): The general point here is that I am calling a form that is handled in the
super block. Since you cannot pass on request
Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
...
I still think it would be a good idea to
have postable sources and especially to make the block protocol postable.
Regarding the API side of the blocks protocol, it would be nice, to be
able to call it from the sitemap without much
Lars Trieloff skrev:
Hi Daniel,
I was already starting to create a parametrizable BlockSource and
BlockConnection, when Alexander got the idea of creating an InputSource
that would be less invasive to the blocks-fw code.
How do you think should a postable source work? Don't you think
Lars Trieloff skrev:
Hi Daniel,
A drawback with using the some extension of the VPCs for inter block
communication is that it ties the communications to the specific
sitemap component APIs, so they are not usable for communication with
non sitemap blocks.
What I would propose is to create
Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
What I would propose is to create some new pipeline components that
calls postable sources, and make the block protocol postable. Then we
have four cases for the different combinations of XML or non XML input
and output respectably:
non XML
Lars Trieloff skrev:
Hi Daniel,
I've just noted that uploads with CForms are not working with the Blocks
Framework. The reason is a bug in
org.apache.cocoon.environment.http.HttpRequest.get() that checks for a
wrapped MultipartHttpServletRequest.
Checking for a class doesn't seem to be a
Joerg Heinicke skrev:
On 28.10.2006 12:16, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?view=revrev=468669
Log:
Improve error reporting by using a CascadingIOException instead of an
ordinary IOException. Due to Alexander Klimetschek.
Modified:
Alexander Klimetschek skrev:
Hi,
I am trying to improve the exception handling for the new blocks. The
problem is that you don't see the exceptions thrown inside a called
blockservlet. Apart from changing the BlockConnection to throw a
CascadingIOException,
Fixed that. I didn't spent much
Lars Trieloff skrev:
Checking for a class doesn't seem to be a good idea I think we should
check for an interface instead.
Implemented.
Maybe we instead could make the DispatcherServlet less intrusive on
the request object by modifying the getServletPath() and getPathInfo()
on the
Vadim Gritsenko skrev:
Daniel Fagerstrom wrote:
Alexander Klimetschek skrev:
the ResourceReader must throw any IOException caught in generate()
(line 349). This is currently not done because it looks like there
are cases, where a failed generate should be silently ignored. The
debug message
Alexander Klimetschek skrev:
Hi Daniel,
we are noticing that the blocks protocol is currently quite slow. We did
not yet got a proper profiling setup, so I am asking if you know what
the bottlenecks might be and how to resolve them.
While I have not optimized the code there is no obvious
Carsten Ziegeler skrev:
I just remove the sitemap-additions directory. While doing so I thought
that our current name for Avalon configuration is not very good: we
simply use xconf whereas for Spring we use spring (and not bean or
something like that).
So what about using avalon instead of
Leszek Gawron skrev:
Joerg Heinicke wrote:
On 03.11.2006 23:17, Carsten Ziegeler wrote:
With the help from Leszek we now have a Cocoon version in trunk which
does not need any deployment plugin. This means you can just drop the
jar files into WEB-INF/lib and are done! So it doesn't matter if
Leszek Gawron skrev:
Daniel Fagerstrom wrote:
Leszek Gawron skrev:
Joerg Heinicke wrote:
On 03.11.2006 23:17, Carsten Ziegeler wrote:
With the help from Leszek we now have a Cocoon version in trunk which
does not need any deployment plugin. This means you can just drop the
jar files into WEB
Created-By: Apache Maven
Built-By: Daniel Fagerstrom
Build-Jdk: 1.5.0_06
One possibility would to have a block specific manifest entry with the
block name:
Cocoon-Block-Name: cocoon-batik-impl
/Daniel
Jorg Heymans skrev:
Daniel Fagerstrom wrote:
We could use the artifactId from the
META-INF/maven/org.apache.cocoon/cocoon-block-name/pom.properties file.
pom.properties is included by default, but it's inclusion can be
disabled. For this I think the manifest entry would be a better
Leszek Gawron skrev:
Daniel Fagerstrom wrote:
Might be that it will not that easy to create a mock servlet context
that contain exactly what is needed for creating beans in a
XmlWebApplicationContext. In my experience getting the different
context used within Cocoon is never easy. But I can
Leszek Gawron skrev:
...
The amount of mocking (and additional work to mimic the actual webapp)
makes me think that it would probably be much easier if I just set up a
jetty server programmatically and interface cocoon using commons http
client.
I have found minimal mock setups for servlets
Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
One possibility is that there is some fault in the component handling
so that the block servlet component or tree processor is recreated
instead of reused in some cases.
This seems to be the real problem. There are new ResourceReader
Lars Trieloff skrev:
Results from a JMeter-drilling test: accessing
http://localhost:8080/cocoon/cocoon-blocks-fw-sample3/sub/test in 10
parallel threads using the cocoon-blocks-fw-sample.
- 1 DispatcherServlet
- 4 BlockServlet
- 4 SitemapServlet
- 6 TreeProcessor
- 6 EnvironmentHelper
Seem
Alexander Klimetschek skrev:
Alexander Klimetschek schrieb:
Looking in the RequestProcessor that is called by the standard
SitemapServlet, it calls ProcessingUtil.cleanup(), while leaving the
processing of a request. I don't call that in the corresponding code
in the
Alexander Klimetschek skrev:
Hi,
while looking at the o.a.c.sitmap.SitemapServlet I saw that the
check-reload property for the TreeProcessor is manually set to true
instead of reading it from some properties. So I suppose (and testing
has proofed this) that the sitemap will always be
It is because I put some experimental configuration files
(META-INF/cocoon/spring/cocoon-forms-sample-blockSer
vlet.xml etc) in some of the sample blocks to test them in the blocks
framework. These configuration files are based on the assumption that
the block resources are unpacked in the
Should be fixed now.
/Daniel
Daniel Fagerstrom skrev:
It is because I put some experimental configuration files
(META-INF/cocoon/spring/cocoon-forms-sample-blockSer
vlet.xml etc) in some of the sample blocks to test them in the blocks
framework. These configuration files are based
It is now possible to use Cocoon without deployer and to use it in
Eclipse with e.g. the Jetty plugin.
To run Cocoon in Eclipse the shielded mode must, AFAICS, be turned of
(this is because we need the classpath provided by Eclipse with
dynamically build class files and resource and not the
Sylvain Wallez skrev:
Jeremy Quinn wrote:
Do we have virtual pipeline components yet ?
I guess so in 2.2...
I do not know much about them . AFAIU resources can only be called
from the sitemap in which they exist . virtual pipeline components
are a concept similar to
Sylvain Wallez skrev:
Daniel Fagerstrom wrote
We had virtual sitemap components one and a half year ago. But since
then a lot have happened in the system so I find it hard to believe
that they still work.
If someone is interested enough I could help fixing them. But I lost
interest in them
Rice Yeh skrev:
Hi,
In studying the document
http://wiki.apache.org/cocoon-data/attachments/GT2006Notes/attachments/12-CocoonBlocks.pdf
http://wiki.apache.org/cocoon-data/attachments/GT2006Notes/attachments/12-CocoonBlocks.pdf,
I like to have a real feeling of it. So I try the
Carsten Ziegeler skrev:
...
Please cast your votes for using latest rhino in 2.1.x.
+1
/Daniel
Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
blockcontext:/blockname/ - resolves to a file source that contain the
COB-INF directory of the block.
What is the blockname? I tried the name of the directory (like
previously in /blocks/my-block/ = my-block), a name=my-block
Carsten Ziegeler skrev:
Giacomo Pati wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
My goal is having a completly self-reloading Cocoon application that also
includes the block dispatching mechanism and not only at sitemap level. (As a
side note: We shouldn't consider
Alexander Klimetschek skrev:
Joerg Heinicke schrieb:
Component inheritance is a standard functionality of Spring's
ApplicationContext implementations. So this should be no problem at all.
Although this is not yet used in any way with the blocks. Two blocks,
where one inherits from another,
Mark Lundquist skrev:
On Nov 21, 2006, at 12:36 PM, Mark Lundquist wrote:
On Nov 21, 2006, at 12:21 PM, Daniel Fagerstrom wrote:
Testing again, it happens to me also when I do a mvn package
after a mvn clean, if I do a second mvn package it works.
Yes, OK
Daniel Fagerstrom skrev:
Mark Lundquist skrev:
On Nov 21, 2006, at 12:21 PM, Daniel Fagerstrom wrote:
Testing again, it happens to me also when I do a mvn package after
a mvn clean, if I do a second mvn package it works.
Yes, OK... the second time worked.
Now then, how do I run the webapp
Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
Alexander Klimetschek skrev:
Another requirement what just popped up is to allow groups of
servlets that use the same classloader. This is useful if you have
some Servlets and jsps that ought to be used together, because the
multiple
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
Seem like a good solution to me. I would prefer putting this
functionality in a ShieldingBlockServlet that extends the BlockServlet
though. If we put to much extras in the BlockServlet it will be hard
for people to understand what it does
Mark Lundquist skrev:
On Nov 21, 2006, at 10:02 AM, Daniel Fagerstrom wrote:
You need -Dalldists also to activate the compilation of the dist
modules (take a look at the profile information in
http://svn.apache.org/repos/asf/cocoon/trunk/dists/pom.xml). I haven't
verified that it actually
Alexander Klimetschek skrev:
Daniel Fagerstrom schrieb:
...
This could be complemented by giving access to the original request
parameters. For this case we need a call stack where each block
protocol call pushes a new request object, and where all parameter
lookup is done through the stack
Carsten Ziegeler skrev:
Alexander Klimetschek wrote:
The optimal solution would be the OSGi support (!?), but this is too
much work and won't be part of cocoon 2.2. My patch is a lot simpler,
just fixing the BootstrapClassLoaderManager and the blocks-fw (where I
just implemented the
Mark Lundquist skrev:
On Nov 21, 2006, at 4:22 PM, Daniel Fagerstrom wrote:
To remove the use of the cocoon deployer you remove the following
snippet from the pom for cocoon-dist-samples:
Right, yeah... I had just tried that, as a matter of fact, and... it
worked, and now I got
Carsten Ziegeler skrev:
...
Definitly - now, what about adding the jasper engine to the classpath of
the webapp
by putting it in web-inf/lib?
Looking at this scenario, I have the feeling that sooner or later you
hit similar problems in other cases as well. As soon as you access
something the
Rice Yeh skrev:
Hi,
There are many methods not supported in BlockCallHttpServletRequest
yet, like getLocale(). We are converting our project to use
cocoon-blocks-fw-impl but many of our sitemaps use LocaleAction which
calls getLocale() in request. Just like to know whether these methods
901 - 1000 of 1344 matches
Mail list logo
