Re: [Corona] PIpeline API
Torsten Curdt tcurdt at apache.org writes: The question if those configuration are needed in a generic form in the API. (I doubt it) As I would expect them to be implementation specific a configuration callback that sets up the pipeline might be a way around this? I guess we are on the same position on this one, setup and clean up are usually implementation specific and should therefore not be part of the API. Even for the finish() method it might be necessary to pass a context or parameters. Already passing it in setup() might be an option, but then you force the component to have special handling for thread-safety. Carsten Ziegeler cziegeler at apache.org writes: I added now a finish method which is called by the pipeline implementation. This keeps me free from any configuration hassels with the various containers. Some want to use spring, some others something different. But that's exactly what these container are there for. And perhaps someone doesn't want to use a container at all, just instantiate the objects, run the pipeline and that's it. By just instantiating the objects you know exactly with which implementation you work - and which setup and finish method you are supposed to call. Therefore I really think that these lifecycle methods belong to the api. That's what I don't agree with :-) I see no other reliable way of closing resources. A listener/callback approach would be cleaner for the API, but more complex. Question is if it needs to be part of the API at all. Joerg
Can I get editing permissions set up on Daisy?
Hi guys, while rolling our projects on to Cocoon 2.2, I have found a few improvements I can make to the docs, my Daisy account is currently listing me as a guest. Could someone up me to editing status ? Thanks for your help! PS Any word on the Get Together this year ? -- View this message in context: http://www.nabble.com/Can-I-get-editing-permissions-set-up-on-Daisy--tp18482022p18482022.html Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [Corona] PIpeline API
Joerg Heinicke wrote: A listener/callback approach would be cleaner for the API, but more complex. Question is if it needs to be part of the API at all. We're not talking about component configuration here, we are talking about providing runtime/environment information for a pipeline run. Think of the request/response object for the servlet case. I think it's more convenient to pass this information through the api, than providing some callback. And then is the question, how does a component get the object it cann call as a callback? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [Corona] Pipeline API
Joerg Heinicke wrote:
Torsten Curdt tcurdt at apache.org writes:
The question if those configuration are needed in a generic form in
the API. (I doubt it) As I would expect them to be implementation
specific a configuration callback that sets up the pipeline might be a
way around this?
I guess we are on the same position on this one, setup and clean up are usually
implementation specific and should therefore not be part of the API. Even for
the finish() method it might be necessary to pass a context or parameters.
Already passing it in setup() might be an option, but then you force the
component to have special handling for thread-safety.
Carsten Ziegeler cziegeler at apache.org writes:
I added now a finish method which is called by the pipeline implementation.
This keeps me free from any configuration hassels with the various
containers. Some want to use spring, some others something different.
But that's exactly what these container are there for.
And perhaps someone doesn't want to use a container at all, just
instantiate the objects, run the pipeline and that's it.
By just instantiating the objects you know exactly with which implementation you
work - and which setup and finish method you are supposed to call.
Therefore I really think that these lifecycle methods belong to the api.
That's what I don't agree with :-)
I see no other reliable way of closing resources.
A listener/callback approach would be cleaner for the API, but more complex.
Question is if it needs to be part of the API at all.
Can you provide an example how your ideas would materialize as Java code?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: [Corona] PIpeline API
Hi Cocoon devs, I'd be very interested in a pipeline API for Sling, so I'd like to understand this discussion. Please excuse any unqualified remarks :) Carsten Ziegeler schrieb: A listener/callback approach would be cleaner for the API, but more complex. Question is if it needs to be part of the API at all. We're not talking about component configuration here, we are talking about providing runtime/environment information for a pipeline run. Think of the request/response object for the servlet case. I think it's more convenient to pass this information through the api, than providing some callback. And then is the question, how does a component get the object it cann call as a callback? Just for my understanding: Is the context (runtime/environment) information used by the pipeline itself, or only by the pipeline components? From an SoC point of view I'd assume that the pipeline implementation is independent from the execution environment. I'd imagine it to handle only pipelining aspects: * wiring components together * passing events * caching * … ? If this is the case, wouldn't it be more appropriate to pass the context information to the pipeline components without bothering the pipeline object itself? Or is it intended that the pipeline is seen as a black box after it has been set up, to simplify the parameterization of all its components? Thanks for any clarification! -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: AW: AW: Client-side validation in CForms
Hi Chris
Thanks for this, it should speed me up a bit, I hope : )
Simple client-side validation based on datatype is working here.
Dojo's constraints and filters are working too, so as a proof of
concept it is working well.
One issue(?): when a field is invalid (while you are typing) you will
see one of Dojo's generic i18n error messages until you have submitted
the bad data to Cocoon, only then will you see the cform's error
messages. Not sure if there will ever be a workaround for this ...
So currently, the main problem is that you'd have to specify the same
validation twice ..
model :
fd:field id=name required=true
fd:hintPlease name your datasource/fd:hint
fd:helpdivThis is breally/b helpful advice!!/div/fd:help
fd:datatype base=string/
fd:validation
fd:regexp pattern=C.*
fd:failmessageSorry, the PMC really does insist the name
should begin with the letter 'C'./fd:failmessage
/fd:regexp
/fd:validation
/fd:field
template (eg. with filters applied on the client) :
ft:widget id=name
fi:styling propercase=true trim=true regExp=^C.*/
/ft:widget
Obviously it is ghastly to specify the same validation twice, so the
next sensible step IMHO is to get the validation info generated out to
the template in a form that can be processed by xslt into appropriate
constraints for dojo.
eg: {min: 10, max: 1, places: 0} etc.
The main problem is going to be handling expressions . specially
stuff that points to other objects :
fd:validation
fd:range min=number1 + 1
These are the constraints for Number types :
pattern: String?
override [formatting pattern] (http://www.unicode.org/reports/tr35/#Number_Format_Patterns
) with this string
type: String?
choose a format type based on the locale from the following:
decimal, scientific, percent, currency. decimal by default.
places: Number?
fixed number of decimal places to show. This overrides any
information in the provided pattern.
round: Number?
5 rounds to nearest .5; 0 rounds to nearest whole (default). -1
means don't round.
currency: String?
an [ISO4217](http://en.wikipedia.org/wiki/ISO_4217) currency code,
a three letter sequence like USD
symbol: String?
localized currency symbol
locale: String?
override the locale used to determine formatting rules
The constraints for Ranges :
min: Number?
the lowest value allowed
max: Number?
the highest number allowed
Hopefully we can pull out a usable subset of cforms validation and
present it to the client-side.
I'll let you guys mull it over for a while :)
Thanks again
regards Jeremy
On 14 Jul 2008, at 14:45, Christofer Dutz wrote:
snip/
I think generating the validation-output needed for client side-
validation
shouldn't be a big problem, since it’s the same for almost all
widgets the
class having to be patched should be the simple Widget base-classes.
I would
volunteer implementing it, but only if it is really wanted.
Chris
snip/
The status of documentation publishing
Hi, I just wanted to let you know that documentation publishing (and contributions publishing) has not been forgotten but it faced some serious issues. I've implemented support for Flash files for our documentation infrastructure (Daisy export plug-in) but these changes seem to confuse Maven greatly. Documentation publishing is mostly a manual process now which is a very tedious thing as you can probably imagine. Therefore I decided to publish some things that I could recall that have been modified and focus on fixing the issues we have. New docs should appear within an our or two on main site, if you find anything unpublished that you would like to see on our site (e.g. your own changes) just give me an addresses to the pages and I'll take care of publishing by doing it manually. Thanks to all for the patience and work on Cocoon's documentation. -- Best regards, Grzegorz Kossakowski
Re: [Corona] PIpeline API
Carsten Ziegeler wrote: Peter Hunsberger wrote: On Tue, Jul 15, 2008 at 5:42 AM, Reinhard Pötz [EMAIL PROTECTED] wrote: Are you talking about passing the input parameters as parameters of the setup() method? void setup(MapString, Object inputParameters) I'd be fine by this. I hate seeing Maps used as dumping grounds for randomly typed objects. Could you use something that gives a little more strong typing? Perhaps more like a ServletContext though I don't think I'd go that far in this case? I agree that strong typing would be great - but the pipeline api does not define any concrete key/object for the map. So this is use-case specific. Therefore I think a map is the best we can come up. Trying to catch up on this discussion. What parameters are we talking about exactly? Are these pipeline parameters? What's the need for that? Can't we just give the parameters they need individually to every pipeline component, thus allowing per-component strongly typed and well defined contracts? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [Corona] PIpeline API
Andreas Hartmann pisze: Just for my understanding: Is the context (runtime/environment) information used by the pipeline itself, or only by the pipeline components? From an SoC point of view I'd assume that the pipeline implementation is independent from the execution environment. I'd imagine it to handle only pipelining aspects: * wiring components together * passing events * caching * … ? I agree here. Thanks Andreas for reminding me my own thoughts (that are similar to yours) that I had at ApacheCon when Reinhard was explaining Corona's design. Now I can join the discussion. :-) If this is the case, wouldn't it be more appropriate to pass the context information to the pipeline components without bothering the pipeline object itself? Or is it intended that the pipeline is seen as a black box after it has been set up, to simplify the parameterization of all its components? Even if it's the case, should be this black box pipeline just one of the possible implementations? Then it would be a pipeline implementation that sets up components and passes what's needed. In some cases that would make a perfect sense. -- Best regards, Grzegorz Kossakowski
Spring Configurator parser without logging
Hi, Just working on this filtering stuff and I wonder if there is any good reason to not have a logger in AbstractSettingsElementParser andSettingsElementParser classes. I would like to log some things in these classes. Any objections? -- Grzegorz
CForms: 2.2 and XML binding with namespaces
Hi, As can be seen from the live Cocoon demo [1], CForms binding to XML documents using namespaces doesn't work anymore in 2.2. Load binding fails silently, while save binding throws... org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces. I can't see an open issue in Jira for this - I'm happy to create one and will take a look and see if I can find a fix. But first perhaps someone more knowledgeable than I could shed some light on why this may have broken and what could be done to fix it... Having this working again would be very useful for me :) Thanks, Robin [1] http://cocoon.zones.apache.org/demos/trunk/samples/forms/ binding-06namespaced-XML.flow smime.p7s Description: S/MIME cryptographic signature
Re: The status of documentation publishing
Hi, On Wed, Jul 16, 2008 at 3:48 AM, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: ...I just wanted to let you know that documentation publishing (and contributions publishing) has not been forgotten but it faced some serious issues Reminds me that there was no response to my request for an alternate backup of the Daisy stuff, see http://markmail.org/message/jojhpmlqwoqlz4l6 -Bertrand
Re: [Corona] PIpeline API
On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez [EMAIL PROTECTED] wrote: ...Can't we just give the parameters they need individually to every pipeline component, thus allowing per-component strongly typed and well defined contracts?.. I'm also catching up on this thread but I tend to agree with the above suggestion, i.e. something like Transformer t = new XsltTransformer(); t.setXslt(cocoon:/mytransform.xsl); t.setRequestParameters(request.getParameterMap()); ... looks clearer than Transformer t = new XslTransformer(opaqueMapOfParameters); And the second form could be added later, if needed for some other reason. I didn't even look at Corona lately, no idea how things work currently, just trying to explain how I'd like things to be. -Bertrand
Re: [Corona] PIpeline API
Bertrand Delacretaz wrote: On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez [EMAIL PROTECTED] wrote: ...Can't we just give the parameters they need individually to every pipeline component, thus allowing per-component strongly typed and well defined contracts?.. I'm also catching up on this thread but I tend to agree with the above suggestion, i.e. something like Transformer t = new XsltTransformer(); t.setXslt(cocoon:/mytransform.xsl); t.setRequestParameters(request.getParameterMap()); ... Ok, in this case you can't use Transformer as the class type. This would be: XsltTransformer t = ... Now, it seems that we are still mixing up things here. As I said, I'm not talking about configuration of the components. The stylesheet from above is a configuration. We're talking about information about the current environment for executing the already configured pipeline. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [Corona] PIpeline API
Carsten Ziegeler schrieb:
Bertrand Delacretaz wrote:
On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez [EMAIL PROTECTED]
wrote:
...Can't we just give the parameters they need
individually to every pipeline component, thus allowing per-component
strongly typed and well defined contracts?..
I'm also catching up on this thread but I tend to agree with the above
suggestion, i.e. something like
Transformer t = new XsltTransformer();
t.setXslt(cocoon:/mytransform.xsl);
t.setRequestParameters(request.getParameterMap());
...
Ok, in this case you can't use Transformer as the class type. This
would be:
XsltTransformer t = ...
Now, it seems that we are still mixing up things here. As I said, I'm
not talking about configuration of the components. The stylesheet from
above is a configuration.
We're talking about information about the current environment for
executing the already configured pipeline.
IIUC the request parameters in the above example would belong to the
execution environment, wouldn't they?
I'd imagine something like this:
public void parameterizeTransformers(Request req, Pipeline pipeline) {
for (Iterator i = pipeline.getTransformers().iterator(); … ) {
Transformer t = (Transformer) i.next();
if (t instanceof WebappXsltTransformer) {
WebappXsltTransformer xsltTr = (WebappXsltTransformer) t;
if (xsltTr.useRequestParameters()) {
xsltTr.setXsltParams(req.getParameterMap());
}
}
}
}
IMO passing the execution environment to a pipeline component depends
very much on the nature of the environment, and also on the nature of
the individual components. I'm not sure if it should be attempted to
find a generic API for this. Wouldn't it be sufficient to let the client
code handle this? I guess this is what Torsten and Jörg had in mind when
they suggested a callback mechanism:
public class ServletPipelineInvoker {
protected Pipeline createPipeline() {
Pipeline pipeline = new NonCachingPipeline();
pipeline.addListener(this);
return pipeline;
}
/**
* Called before pipeline execution.
* @see PipelineListener.contextualizePipeline(Pipeline)
*/
public void contextualizePipeline(Pipeline pipeline) {
parameterizeTransformers(this.request, pipeline);
}
}
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
Re: [Corona] PIpeline API
Andreas Hartmann schrieb:
Carsten Ziegeler schrieb:
Bertrand Delacretaz wrote:
On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez [EMAIL PROTECTED]
wrote:
...Can't we just give the parameters they need
individually to every pipeline component, thus allowing per-component
strongly typed and well defined contracts?..
I'm also catching up on this thread but I tend to agree with the above
suggestion, i.e. something like
Transformer t = new XsltTransformer();
t.setXslt(cocoon:/mytransform.xsl);
t.setRequestParameters(request.getParameterMap());
...
Ok, in this case you can't use Transformer as the class type. This
would be:
XsltTransformer t = ...
Now, it seems that we are still mixing up things here. As I said, I'm
not talking about configuration of the components. The stylesheet from
above is a configuration.
We're talking about information about the current environment for
executing the already configured pipeline.
IIUC the request parameters in the above example would belong to the
execution environment, wouldn't they?
I'd imagine something like this:
public void parameterizeTransformers(Request req, Pipeline pipeline) {
for (Iterator i = pipeline.getTransformers().iterator(); … ) {
Transformer t = (Transformer) i.next();
if (t instanceof WebappXsltTransformer) {
WebappXsltTransformer xsltTr = (WebappXsltTransformer) t;
if (xsltTr.useRequestParameters()) {
xsltTr.setXsltParams(req.getParameterMap());
}
}
}
}
Now all these examples assume that the calling code knows the components.
For my use case - and it's the same with the Cocoon sitemap - I've a
description of a pipeline (think of the sitemap) which has just the name
of the pipeline components to chain. A generic code instantiates these
pipeline components - through a service registry - and does not know
anything about these components apart from the fact that they are
pipeline components.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: [Corona] PIpeline API
Carsten Ziegeler schrieb:
Andreas Hartmann schrieb:
Carsten Ziegeler schrieb:
Bertrand Delacretaz wrote:
On Wed, Jul 16, 2008 at 5:14 AM, Sylvain Wallez
[EMAIL PROTECTED] wrote:
...Can't we just give the parameters they need
individually to every pipeline component, thus allowing per-component
strongly typed and well defined contracts?..
I'm also catching up on this thread but I tend to agree with the above
suggestion, i.e. something like
Transformer t = new XsltTransformer();
t.setXslt(cocoon:/mytransform.xsl);
t.setRequestParameters(request.getParameterMap());
...
Ok, in this case you can't use Transformer as the class type. This
would be:
XsltTransformer t = ...
Now, it seems that we are still mixing up things here. As I said,
I'm not talking about configuration of the components. The
stylesheet from above is a configuration.
We're talking about information about the current environment for
executing the already configured pipeline.
IIUC the request parameters in the above example would belong to the
execution environment, wouldn't they?
I'd imagine something like this:
public void parameterizeTransformers(Request req, Pipeline pipeline) {
for (Iterator i = pipeline.getTransformers().iterator(); … ) {
Transformer t = (Transformer) i.next();
if (t instanceof WebappXsltTransformer) {
WebappXsltTransformer xsltTr = (WebappXsltTransformer) t;
if (xsltTr.useRequestParameters()) {
xsltTr.setXsltParams(req.getParameterMap());
}
}
}
}
Now all these examples assume that the calling code knows the components.
For my use case - and it's the same with the Cocoon sitemap - I've a
description of a pipeline (think of the sitemap) which has just the name
of the pipeline components to chain. A generic code instantiates these
pipeline components - through a service registry - and does not know
anything about these components apart from the fact that they are
pipeline components.
I completely agree here.
Specific situations might allow specific solutions, e.g. providing
listeners/callbacks while creating the individual components.
However a more general solution that also supports more general
scenarios like the one described above (components are created by a
service/factory/etc.) should also be available.
I wouldn't mind having a general purpose setup/teardown (or
preExecution/postExecution, etc.) method defined and called by the
pipeline API itself.
Might not be a good example, but JUnit provides such methods for unit
tests and does not delegate this to another framework/container that
might or might not be available, since this is a genuine requirement for
certain tasks to be solved with the framework.
However the listener approach also appears to be appealing to me.
Although I'm not entirely sure this would be as easy to use as the
lifecycle methods proposed before (especially when a pipeline is built
by the sitemap engine or service/factory).
Steven
Carsten
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (106 issues) Subscriber: cocoon Key Summary COCOON-2217 HttpServletResponseBufferingWrapper throws NPE when response body is empty https://issues.apache.org/jira/browse/COCOON-2217 COCOON-2216 IncludeCacheManager can not perfom parallel includes https://issues.apache.org/jira/browse/COCOON-2216 COCOON-2212 jx:attribute does not check name is correct before proceeding https://issues.apache.org/jira/browse/COCOON-2212 COCOON-2211 Support for jx:element https://issues.apache.org/jira/browse/COCOON-2211 COCOON-2210 The field 'type' in GenerateNode in corona-sitemap should not be final https://issues.apache.org/jira/browse/COCOON-2210 COCOON-2197 Making the cocoon-auth-block acegi-security-sample work https://issues.apache.org/jira/browse/COCOON-2197 COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each other https://issues.apache.org/jira/browse/COCOON-2173 COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination page https://issues.apache.org/jira/browse/COCOON-2162 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the servlet protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB
Re: The status of documentation publishing
Bertrand Delacretaz pisze: Hi, On Wed, Jul 16, 2008 at 3:48 AM, Grzegorz Kossakowski [EMAIL PROTECTED] wrote: ...I just wanted to let you know that documentation publishing (and contributions publishing) has not been forgotten but it faced some serious issues Reminds me that there was no response to my request for an alternate backup of the Daisy stuff, see http://markmail.org/message/jojhpmlqwoqlz4l6 Yes, I've seen your e-mail and wanted to take care of backup already but still these issues with docs publishing has changed my plans. When I'm done with this nasty things happening right now I'll contact you and we'll decide how to proceed with the backup process. -- Grzegorz Kossakowski
Re: Objects inherited in subrequests
imran pisze:
Hello all
Grzegorz as u wrote...
Therefore I would like to propose introduction of a new scope called
request-inheritable which
would allow beans (like ObjectModel) to be inherited but by cloning.
can you please elaborate on that ... coz thats where we are stuck ...
if u have a look at the AbstractInterpreter.java file
public void forwardTo(String uri, Object bizData,
WebContinuation continuation,
Redirector redirector)
throws Exception {
if (SourceUtil.indexOfSchemeColon(uri) == -1) {
uri = cocoon:/ + uri;
final Map objectModel =
this.processInfoProvider.getObjectModel();
FlowHelper.setWebContinuation(objectModel, newObjectModel,
continuation);
FlowHelper.setContextObject(objectModel, newObjectModel,
bizData);
if (redirector.hasRedirected()) {
throw new IllegalStateException(Pipeline has already
been processed for this request);
}
// this is a hint for the redirector
objectModel.put(cocoon:forward, true);
redirector.redirect(false, uri);
} else {
throw new Exception(uri is not allowed to contain a scheme
(cocoon:/ is always automatically used));
}
}
so the instance of newObjectModel is the one from the bean factory ...
and if u have multithreading then all the threads change that
objectmodel simultaneously and then finally the objectmodel coming to
the JXTemplategenerator(Injected by spring) is not thread specific ...
in the setup method of the generator class we replace the objectmodel
injected by spring with the one passed with that method ... after doing
this the errors are not that frequent .. but they are still there :( ..
its still being modified by some other threads ...
Could you please let us know how do u intend to implement ur proposed
solution
Just wanted to let you know that I know this stuff really well (I've worked on ObjectModel last
summer) so surely can give you some tips and precise instructions.
This won't happen now as I'm leaving but I'll try to explain my thoughts tomorrow after I check
everything against Cocoon's source code.
--
Best regards,
Grzegorz Kossakowski
[jira] Updated: (COCOON-2220) Dojo slider does not create value changed events
[ https://issues.apache.org/jira/browse/COCOON-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hugh Sparks updated COCOON-2220: Attachment: SliderDemo.zip Here is a simple Cocoon 2.2 block that demonstrates the issue. Dojo slider does not create value changed events Key: COCOON-2220 URL: https://issues.apache.org/jira/browse/COCOON-2220 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Hugh Sparks Priority: Minor Attachments: SliderDemo.zip When a value changed listener is associated with a dojo slider widget, the function is never called. This might be related to the on-value-changed does not work issue reported in COCOON-1858. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2220) Dojo slider does not create value changed events
Dojo slider does not create value changed events Key: COCOON-2220 URL: https://issues.apache.org/jira/browse/COCOON-2220 Project: Cocoon Issue Type: Bug Components: Blocks: Forms Affects Versions: 2.2-dev (Current SVN) Reporter: Hugh Sparks Priority: Minor Attachments: SliderDemo.zip When a value changed listener is associated with a dojo slider widget, the function is never called. This might be related to the on-value-changed does not work issue reported in COCOON-1858. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2221) Flowscript debugger is broken
Flowscript debugger is broken - Key: COCOON-2221 URL: https://issues.apache.org/jira/browse/COCOON-2221 Project: Cocoon Issue Type: Bug Components: - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Hugh Sparks Starting with the Cocoon 2.2 from the svn trunk. I enabled the debugger by editing cocoon-flowscrsipt.xconf Everything was built using Maven 2.0.9. I'm using jdk 1.6.0-05 Running the flowscript calculator sample, a crash occurs due to a java.lang.IllegalStateException. The same error occurs with other flowscript samples. A stack trace is attached in the next posting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2221) Flowscript debugger is broken
[ https://issues.apache.org/jira/browse/COCOON-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hugh Sparks updated COCOON-2221: Attachment: Flowscript traceback.htm Browser traceback after running a flowscript sample with the debugger enabled. Flowscript debugger is broken - Key: COCOON-2221 URL: https://issues.apache.org/jira/browse/COCOON-2221 Project: Cocoon Issue Type: Bug Components: - Flowscript Affects Versions: 2.2-dev (Current SVN) Reporter: Hugh Sparks Attachments: Flowscript traceback.htm Starting with the Cocoon 2.2 from the svn trunk. I enabled the debugger by editing cocoon-flowscrsipt.xconf Everything was built using Maven 2.0.9. I'm using jdk 1.6.0-05 Running the flowscript calculator sample, a crash occurs due to a java.lang.IllegalStateException. The same error occurs with other flowscript samples. A stack trace is attached in the next posting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[proposal] Corona: A Cocoon subproject
Dear Cocoon PMC,
as I said in a separate thread recently, it's time for Corona to move
out of the whiteboard of Cocoon in order to increase its visibility and
to allow releases. Corona has reached a state where it is already useful
but there is a lot of room for others to enhance and improve it.
So far Corona has been developed by Steven and me (+ some additions by
Carsten recently) which doesn't qualify for being a diverse community.
In order to change this I want to propose Corona to become a subproject
of Cocoon under the oversight of the Cocoon PMC.
For that purpose I think that it would be a good idea to follow the
procedure of the Incubator and nominate at least 2 additional PMC
members who help us to grow the community and do all the legal checks
when Corona is released (I'd love to see a alpha-1 release this summer.)
Therefore I kindly want to ask two other Cocoon PMC members to
become mentors for Corona and help to get it going.
I also propose that Corona is being moved to
https://svn.apache.org/repos/asf/cocoon/corona. The initial set of
committers should consist of Carsten, Steven and me - every Cocoon
committer can get write access by simply asking for it on this list.
Additionally I'd also like to see a separate Jira project for Corona.
Are there any objections if ask infra in behalf of the Cocoon PMC to
create one for us?
Finally this brings me to my last question: Do we want or do we have to
change the name Corona? For the legal part of this question, who can I
ask to get a final yes or no?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
