Re: New Spring Maintenance policy
I'd doubt a petition by itself would make them change the policy. Probably they no longer can afford time, money or other resource to support community version of spring. If they are trying to make a business out of it it is quite obvious that they won't pop up asking for someone to take over. Nevertheless, It might help indicating to them that their behaviour might endanger any business perspective implied so that they are more willing to keep a sufficient level of support. I personally do think there is no need for immediate action. But in the worst case we will be in a similar situation as when the current team around spring had declared their retirement from spring project: A new team needs to take over. So let's have a close watch at further development of the issue Rainer Reinhard Pötz schrieb: Rainer Pruy wrote: A clear statement along only the most current release will receive maintenance efforts would have been much easier and clearer (and would get broader acceptance by the community). That the whole thing was not put that way contributes to the impression that users should be convinced into a support contract. Thanks Rainer, that's more or less the same that I wanted to say. Maybe SpringSource can be convinced to change their policy into this direction. WDOT, would a petition help for that purpose? -- Rainer Pruy Geschäftsführer Acrys Consult GmbH Co. KG Untermainkai 29-30, D-60329 Frankfurt Tel: +49-69-244506-0 - Fax: +49-69-244506-50 Web: http://www.acrys.com - Email: [EMAIL PROTECTED] Handelsregister: Frankfurt am Main, HRA 31151
Re: New Spring Maintenance policy
Hi, yes, all the wording is quite confusing. The statement cited by Peter is trying to convince readers into believing it will affect only old releases, but there nowhere is a guarantee put up that there will be a new release within the 3month period. And the policy puts up that 3 month period per release without referring to later releases. A clear statement along only the most current release will receive maintenance efforts would have been much easier and clearer (and would get broader acceptance by the community). That the whole thing was not put that way contributes to the impression that users should be convinced into a support contract. Rainer Joerg Heinicke schrieb: On 24.09.2008 00:00, Sylvain Wallez wrote: Yeah. I read this as 3 months after release n+1 is out, release n becomes closed source. I'm wondering how long it will take for forks to appear that will provide open source bug fixes to old releases. I don't think that's n+1 but n: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. They wouldn't talk about initial stability issues anymore if it were n+1. Joerg
Re: [2.1] AbstractCachingProcessingPipeline and cocoon CLI
Hi,
sorry for intruding this discussion.
just from what I can take from this discussion:
Wouldn't it be easier to enclose this into a generalized Environment
implementation
that does support Environment.getTopRequest() and is stored with ObjectModel in
place of those different REQUEST_OBJECT instances -
all different?
That way you could also have some getCurrentRequest() or getNthRequest(int n)
or any other operation that has to deal with request
environments and knowledge about can be kept more local.
Just my 0,02 EUR
Rainer
Vadim Gritsenko schrieb:
On Aug 22, 2008, at 8:57 AM, Thorsten Scherler wrote:
On Fri, 2008-08-22 at 08:18 -0400, Vadim Gritsenko wrote:
On Aug 22, 2008, at 3:35 AM, Thorsten Scherler wrote:
How about:
} else {
-Object lock =
env.getObjectModel().get(HttpEnvironment.HTTP_REQUEST_OBJECT);
+Object lock =
env.getObjectModel().get(ObjectModelHelper.REQUEST_OBJECT);
try {
transientStore.store(lockKey, lock);
} catch (IOException e) {
This way we always lock the same object.
Exactly this thing I was trying to explain - it will not work because
instead of using top level request you are suggesting to use current
sub-request.
Sorry I am not really following. As understand you we cannot use
ObjectModelHelper.REQUEST_OBJECT since we cannot be sure that is not a
sub-request (a request for the exact same resource in a concurrent
situation).
Exactly.
If the lock is null for a HttpEnvironment.HTTP_REQUEST_OBJECT then we
are in CLI mode.
(patch quoted above does not have lock == null comparison anymore,
that's why it is dangerous for HTTP env)
In CLI ASAIK there is no concurrent situation meaning
the problem cannot occur. However since the issue is talking about
includes that may occur.
Yes. You can still use IncludeTransformer in CLI. So deadlock can happen.
Having a typical call from the cli gives for the env.getObjectModel():
HashMap values:
[null,
[EMAIL PROTECTED],
link-collection=[],
[EMAIL PROTECTED],
null, null, null, null,
[EMAIL PROTECTED],
null, null,
[EMAIL PROTECTED],
[EMAIL PROTECTED],
null, null, null]
So which object you would suggest to lock?
You wrote Suitable alternative would be to lock against top most
command line request.
To what you are referring with top most command line request?
That would be CommandLineRequest. Following HTTP environment analogy,
that would be CommandLineEnvironment.CLI_REQUEST_OBJECT.
Vadim
salu2
Take a look at EnvironmentWrapper (which is used e.g. in SitemapSource):
// create new object model and replace the request object
Map oldObjectModel = env.getObjectModel();
if (oldObjectModel instanceof HashMap) {
this.objectModel = (Map)((HashMap)oldObjectModel).clone();
} else {
this.objectModel = new HashMap(oldObjectModel.size()*2);
Iterator entries = oldObjectModel.entrySet().iterator();
Map.Entry entry;
while (entries.hasNext()) {
entry = (Map.Entry)entries.next();
this.objectModel.put(entry.getKey(), entry.getValue());
}
}
this.request = new
RequestWrapper(ObjectModelHelper.getRequest(oldObjectModel),
requestURI,
queryString,
this,
rawMode);
this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT,
this.request);
Vadim
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Just another 0.01€ in the same direction: most developing users (esp. the ones developing cocoon itself) would qualify as hackers. Those are used to associate special meanings with groups of version numbers as a number of other projects follow similar rules (e.g. Linux for long used that even/odd numbering scheme). However, as Cocoon will (and should) attract non hacker users, on a first view, what will indicate to them, that version 3.1.2 is not superior to 3.0.9? (superior aka later or more mature) While I personally am quite fine with any versioning scheme, I do think, it is absolutely necessary to have a policy document explaining it to accidental users. And this nearly at the same time they will detect something like cocoon does exist at all. Rainer Sylvain Wallez schrieb: Reinhard Pötz wrote: Versioning --- For Cocoon 2 there have been proposals that all odd versions are development/alpha versions and all even versions are stable releases. I like this idea and propose that we follow this versioning schema in Cocoon 3: All 3.0.x releases are marked as development versions and we clearly explain this on the website and the READMEs of all artifacts. When we believe that the community and the technology are stable, we do a 3.1.0 release. I think this is less confusing than appending alpha, beta or milestone postfixes. I would say the contrary. Let's not forget that most of our users aren't hard-core developers (they love Cocoon because they can do complex stuff without programming) and they aren't used to this odd/even versioning scheme that comes from the Linux kernel. Rather than that, it seems to me that most of the normal (i.e. non hard-core hacker) people consider a version without any beta, milestone or other suffix as an official stable release. A well-known example is Firefox that goes through a series of milestones, beta and RC version before releasing a stable version with the same number. Eclipse does the same. Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on vacation, but I really think this is too early. Cocoon 2.2 is just out and we announce a 3.0. This will most probably lead people to consider 2.2 as a transition to 3.0 and just not use it, and thus just look elsewhere. Stated clearly, I have fears that just as Maven almost killed the developer community for 2.2, announcing a 3.0 now will kill the user community. My 0.02 euros. Sylvain
Re: Find a new name for Corona
Just my 0,02 cents... I always considered Cocoon to mean more than pipelines, sitemap and alike Thus I don't think using Cocoon 3.0 being an apropriate name. What about Cocoon Pipe (ok, not exaktly) or Cocoon Bones Rainer Reinhard Pötz schrieb: Bertrand Delacretaz wrote: On Wed, Jul 30, 2008 at 5:28 PM, Reinhard Pötz [EMAIL PROTECTED] wrote: :-( that's bad. Any other suggestions? I still think that Cocoon 3.0 could be the name, if people are going to invest a significant effort in what's Corona today. For Sling we'd like to use the pipelines implementation, so some of us Sling folks are planning to contribute and help maintain that. I am not interested in the other parts at the moment. We already have 2.1 and 2.2 which are fairly different products, Cocoon 3.0 would be a lightweight embeddable thing that captures the essence of Cocoon in a way that's better suited to many of today's environments. Clearly an evolution, even though some parts will be missing, as those new environments provide them. I'm still not convinced that we should name it Cocoon 3.0 _now_ (quoting myself from a few days ago): [...] Before we make the decision if Corona should become Cocoon 3.0 we should learn more what other people think about it. (Currently it's only 3 people who use it!) IMO the best way to find this out is by shipping alpha releases under a codename. This gives us the freedom to decide later without spoiling version numbers. [...] When Corona is able to attract a stable community proves itself useable to a wider audience, we can start to ship it as Cocoon 3.0. Or is it only me who needs to be convinced of shipping Corona as Cocoon 3.0?
Re: Layered software designs
Reinhard Poetz schrieb: Carsten Ziegeler wrote: The question is now if we need support for caching in the low level apis or if it is possible to have a layered approach - which would make the entry barrier much easier. Yes, this layered approach is what I'm aiming for. All the reactions in this thread make me think that everybody, who has commented on this mailing list so far (except Carsten), believes that we want to throw away good things that have profed to be useful in many situations. Rest assured, that's not the case. Carsten and I only want to break up this all-or-nothing situation that we (still) have now. What I want to see is a concise pipeline API that comes with only little overhead in terms of its learning curve and its dependencies on third-party software. Usually this means that we stick with standard APIs as much as possible - and I think this rule applies for our situation too. This means that the user of the API only needs to learn as little as possible. When he wants more, we offer additional modules that help him. Since he has a concrete need, the motiviation to learn something new is much higher than when he has to learn everything right from the beginning. If you want to learn how this whole concept *might* apply for a next generation Cocoon, have a look at Steven's and my Exploring Corona mail from last week (http://marc.info/?l=xml-cocoon-devm=120611990603725w=2). The idea of Corona is having a concise core that doesn't have any dependencies on a particular component container (Spring, OSGi, etc.), source resolving mechanisms or environment (http, java only, etc.) or even the type of the components (XML-SAX event stream, XML-Stax event stream, binary streams, etc.) that are linked together in a pipeline. A simple scenario could be: Pipeline API + java.net.URL + XML-SAX components A more advanced scenario could consist of Pipeline API + Sourceresolve + XML-SAX components + Sitemap Engine or maybe you need the full stack that corresponds to Cocoon Core 2.2 - here you are: Pipeline API + Sourceresolve + HTTP-enabled + Sitemap Engine + Spring XML-SAX componnents This layered approach makes Cocoon easily embeddable in any Java application and Cocoon's learning curve becomes more gradual. Is such a situation only appealing to Carsten, Steven and me? It's appealing to me also. However, I'm not sure I did get the layers correctly. I did see: Pipeline API: responsible for composing different components, introduces the notion of Producer/Consumer and first and last component Sitemap API: responsible for executing pipelines Spring: responsible for setting up layers and identifying implementations to wildcard functionality (not really a layer for itself?) URI API (had no better term at hand): responsible for interpreting protocol strings for resource access. Currently two implementations in dicussion: URL and SourceResolver Pipeline Components? really a layer or just implementations of Pipeline API Can we line out the intended or existing layers? I do feel this would help focussing the discussion. We then can have a track reflecting actual layers, a track exploring interaction among layers (e.g caching, configuration...), and a track pondering implementation aspects. Rainer
Re: Layered software designs
Reinhard Poetz schrieb: Dev at weitling wrote: But (maybe I have missed some mails) how do you want to make this Pipeline API? E.g. a SAX-based pipeline is something different than image data running through several filters. How do you want to prevent the use of a SAX-events generating component together with an image data transformer? What about something like it's used in clipboards: each component offers a list of importable and exportable formats? See http://marc.info/?l=xml-cocoon-devm=120611990603725w=2 Do the explanations that this mail answer your question? They answer a number of questions. Nevertheless, the question of connection type is still open. Ok, the answer given is it is up to the components to ensure compatibility. However, what does this mean practically? Will there be different Interfaces for different type of data to e processed. (SAX events will use SAX interfaces, image data will use others) Or will there be some tagging where a component be asked for a list of types it will be able to process? (An image resizer will state PNG JPEG and GIF as being acceptable inputs for consumer side and PNG the type being produced, or something along?) And compatibility will be assumed if a linked pair of producer and consumer share a common tag string? Thus answering the type question might effect back to the API definitions... Rainer
Re: Exploring Corona
It is essential to keep the different layers straight here. The example is somewhere at the level of the pipeline api or probably sitemap api implementation.. Here caching is a question of the implementation of the components. It actually will depend on different implementations of generators, transformers or serializers (cache-enabled or not). URL cache support is an issue for implementing the cache support within a component. e.g. the FileGenerator might use .getLastModified() or alike methods for determining cache control info for its own cacheability... Also the transformer might use such information for determining whether the script used is still valid. Thus, it is not really surprising that the example will not really benefit from cache parameter info methods provided from URL implementations - it's a different layer. However, e.g. when trying to decide whether the cached result of the FileGenerator() *component* is still valid, it will come handy to have information on whether the file did change in between. Rainer Ralph Goers schrieb: Consider this: URL baseUrl = new URL(file:///C:/temp/); Pipeline pipeline = new NonCachingPipeline(); pipeline.addComponent(new FileGenerator(new URL(baseUrl, xyz.xml)); pipeline.addComponent(new XSLTTransformer(new URL(baseUrl, xyz.xslt)); pipeline.addComponent(new XMLSerializer()); pipeline.invoke(new InvocationImpl(System.out)); This simple pipeline has these potentially cacheable components; xyz.xml, xyz.xslt, the result of the XSLT transformation, and the final result of the pipeline. As it relates to the pipeline I don't see how the URL.getLastModified() really helps as it could apply to any of these items, two of which aren't even URLs. Ralph Steven Dolg wrote: Carsten Ziegeler schrieb: Steven Dolg wrote: How about: URL url = new URL(some url); UrlConnection connection = url.openConnection(); connection.getLastModified(); Not sure it this really works in all cases, but appears to be quite suitable and easily extensible. Yes, this works for many cases, but not for cases like where you have an expiry date etc. What do you mean by easily extensible? url.openConnection() actually returns a subclass of URLConnection depending on the protocol of the URL. So own protocol implementations can return own subclasses that implement this (and other methods) accordingly. And - at least theoretically - provide additional methods for handling specific stuff, e.g. expiration dates. Carsten
Re: PipelineEvents eat children
I must state, I never really thought of matchers and selectors as applicable to
non-primary components.
I think, I can imagine tons of reasons causing such extension of current
functionality to grow into a nightmare of semantic changes
and incompatibilities.
However, this request and the discussion show that is is important with cocoon
documentation to distinguish clearly
what is a (sitemap) component and what are sub-elements that provide to using
/ configuring / etc. such components. As a consequence
this will lead to adding an error message to processing sitemap definitions for
flagging whenever a top level element within a
decisional element is not a (sitemap) component.
(Reading the docs always does lead your thought in such direction, but it
probably will help explicitly stating the difference somewhere.)
I do not see a binding reason to provide support for configuration variability
by means of decisional sitemap elements.
However, I doubt, adding an input module will easily provide same level of
reuse as would be available with decision semantics of
matchers/selectors. Or is there an input module that provides some generally
available if-the-else or even switch semantics, or
actually valuation of expressions on some other input module values? (xpath or
jexl expressions? is it in 2.2? admittedly, I never tried)
So, while I do see (and agree) with the structural cleanness of the input
module approach,
that causes immediate need for more powerful input modules.
Rainer
Joerg Heinicke schrieb:
On 19.02.2008 21:17, [EMAIL PROTECTED] wrote:
Compare these examples:
map:select
map:when test=first
map:transform
map:parameter name=choice value=first/
/map:transform
/map:when
map:otherwise
map:transform
map:parameter name=choice value=other/
/map:transform
/map:otherwise
/map:select
And:
map:transform
map:select
map:when test=first
map:parameter name=choice value=first/
/map:when
map:otherwise
map:parameter name=choice value=other/
/map:otherwise
/map:select
/map:transform
Differentiating the elements may make sense to Cocoon devs, but is not
obvious to Cocoon users. The second example is obviously better code:
shorter with decision-making closer to the effect. The differentiation
only exists due to Cocoon storing the PipelineEvents for the second
phase of processing.
Solprovider and I already discussed this on the users mailing list [1] -
though it seems he does not agree to my reasoning. My main point against
this functionality is a conceptional difference: Example 1 is about
selecting pipeline components while example 2 is about configuration.
IMO it should not be possible to conditionally inject different sets of
parameters.
The original requirement Solprovider had was to inject a different
parameter *value* based on the outcome of the resource exists
selector. My argument was that the correct approach of dynamically
evaluating a parameter value is an input module - even though he can't
reuse the existing resource exists selector in that case. Using an
input module would be without any repeating code in the sitemap:
map:transform
map:parameter name=choice value={exists:whatever}/
/map:transform
Additionally the input module would be reusable while the code in the
sitemap would be that bloated whenever this functionality is needed. So
even for maintenance reasons this approach seems to be preferable.
Also compared with Spring we are consistent. Spring does not provide any
conditionals in their configuration files. Instead they provide dynamic
evaluation of property placeholders though - just like our input modules.
That's why I'm strongly against adding this functionality to the
sitemap.
(I have held back this mail (for nearly 24 hours) so that others could
form their own view. But it seems not too many people are interested ...)
Joerg
[1] http://marc.info/?t=12030050381r=1w=4
--
Rainer Pruy
Managing Director
Acrys Consult GmbH Co. KG
Untermainkai 29-30, D-60329 Frankfurt, Germany
Phone: +49-69-244506-0 - Fax: +49-69-244506-50
Web: http://www.acrys.com - Email: [EMAIL PROTECTED]
Registered: Frankfurt am Main, HRA 31151
Re: Rename cocoon:rcl to cocoon:wrap-block
Then cocoon:prepare or (more verbose) cocoon:prepare-run does sound appropriate Jason Johnston schrieb: Reinhard Poetz wrote: Felix Knecht wrote: Reinhard Poetz schrieb: After having seen quite a few people wonder what 'cocoon:rcl' means, I propose to change it to some better name. The general idea is that this Maven goal creates a web application which wraps the block and makes it runable as a 'normal' web application in a web container. Additionally it enables the usage of the reloading classloader (commons-jci) which made me name it 'cocoon:rcl'. I propose to use 'cocoon:wrap-block' instead. Though it's longer I think it's closer to the actual meaning and hence less confusing. If we want to keep the name short, we could even add a shortcut 'cocoon:wb'. WDOT? Other proposals? cocoon:run Actually it doesn't run the block but only creates the environment (i.e. a web application that wraps a block) for it. cocoon:package cocoon:assemble (Though package has a specific connotation in the Maven world of creating a jar/war/etc. ... does this goal do that as well?)
Re: New expressions' syntax
Grzegorz Kossakowski schrieb:
Rainer Pruy pisze:
Daniel Fagerstrom schrieb:
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
...
Simply choosing {} is not a solution because there will be no smooth
migration path for two reasons:
a) some JX may break as proved above
b) it's all or nothing situation, if someone (or we) decides to
switch to new expressions their existing applications simply break
Such radical step has its own benefits but I'm not sure if it's
exactly what you would agree with.
We are not forcing anyone to use the new unified ELs, we just offer
people to do that if they feel like it. It is just a configuration
setting.
/Daniel
Hmm, leaving me wonder, whether such configuration can be decided upon
on a per block basis.
Otherwise, if I'd choose using new EL I would be prevented from using
blocks that stick to old world and vice-versa?
I'm not sure if we have mechanism for per block configuration but I fear
you may be right. AFAIK, main merit of Cocoon's (future) OSGi
integration is blocks isolation.
That's why I had this intuitive to enable people mix old and new syntax.
Any thoughts?
Yes, OSGi might simplyfy per block configuration and thus reducing on
the problem.
OTH, I just read in the Default Expression Language thread, it might
be necessary for supporting sevaral languages in parallel.
With this, indicating the language used with a certain syntactic scope
is no longer responsibility of a (per block) configuration only.
While at xml element level, an EL can be indicated using a special
attribute, this does not help with mixed content or attributes of such
elements.
From my point of view, this does require a special syntax for
expressions/string templates. Leading to a setup where a given syntax
({}, ${},%{},etc.) can be bound to an EL by the configuration, providing
a means for compatibility with old syntax bindings.
For the future I'd prefer a syntax that allows for indicting an EL by
expression/string template. A simplified syntax could be used for a
default EL also set with the (block level) configuration.
Not having thought it to the end, I currently imagine a syntax of say
%tag{...} where tag is a (prebound) indicator of an EL and {...} can
be used for default EL. This would also provide for a trivial escaping
if there is a verbatim EL that uses the expession/template as verbatim
value. (Ok, granted, it only will work for cases where balanced {}
will occur, other cases will need a per character escape means or a way
of specifying that a complete string or expression is to be used verbatim).
Just a view stray thoughts...
Rainer Pruy
Re: New expressions' syntax
Daniel Fagerstrom schrieb:
Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
...
Simply choosing {} is not a solution because there will be no smooth
migration path for two reasons:
a) some JX may break as proved above
b) it's all or nothing situation, if someone (or we) decides to
switch to new expressions their existing applications simply break
Such radical step has its own benefits but I'm not sure if it's
exactly what you would agree with.
We are not forcing anyone to use the new unified ELs, we just offer
people to do that if they feel like it. It is just a configuration setting.
/Daniel
Hmm, leaving me wonder, whether such configuration can be decided upon
on a per block basis.
Otherwise, if I'd choose using new EL I would be prevented from using
blocks that stick to old world and vice-versa?
Rainer Pruy
