Re: JSP integration
On 13.07.2007 20:38, Andrew Stevens wrote: In our existing 2.1.x app, I got it working by creating a new JSPEngine implementation that looks up the RequestDispatcher for the supplied URL and calls include or forward directly on that (instead of using JSPEngineImplNamedDispatcherInclude to look up "JSP 1.2 Processor" servlet, which I'd been doing on WAS 5.x). What about Grek's idea? Creating a Cocoon-controlled servlet that does exactly this? I also had to remove the "*.jsp" servlet mapping from the Cocoon servlet, so JSPs are now run directly by the container instead of going through Cocoon first. I don't get it. How does this match with the above? Why do you need a JSPEngine implementation if Cocoon does not handle the JSP requests anyway? Joerg
Re: JSP integration
On 13.07.2007 16:58, Grzegorz Kossakowski wrote: I really have no experience with JSP and I don't know how its servlet is initialized and how it works. If you could explain what could be a possible problem I would try to answer according to my knowledge. Me neither. My last project was the first with JSP and that's purely in the portlet environment. So no request dispatcher or other stuff. You can have a look at the implementation of the 2.1's JSP block and the different JSPEngine implementations [1]. This kind of integration always caused many different kinds of problems, some things (forward and include) were not supported at all. As a side-note: If particular servlet must be managed by servlet container can't we create servlet (as a Spring bean) that would forward all requests to the JSP servlet using request dispatcher: http://www.jguru.com/faq/view.jsp?EID=206736 ? No idea. Never worked on that level. Joerg [1] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/jsp/java/org/apache/cocoon/components/jsp/
Re: 2.2 does not build with JDK1.4.2
On 13.07.2007 15:30, Joerg Heinicke wrote: What's so specific about this spring-dao.jar or it's pom that only for it this property is retrieved? How does this dependency come in at all? It's not a direct dependency of Cocoon. Aren't all direct and transitive dependencies supposed to be declared in our POM? Joerg
Re: Division of Cocoon's JIRA project
On 13.07.2007 15:46, Grzegorz Kossakowski wrote: I don't know the process in detail but the most important work is related to the fact that components are not migrated and have to be recreated manually. Of course, we won't need all of them because many components will be replaced by own project. Other things that come to mind is updating our poms, writing JIRA welcome page: https://issues.apache.org/jira/browse/COCOON, creating versions and so on. Lots of tedious work. I'd be happy to take advantage of your help! What are your plans? I'd be able to start on Monday, I guess. I can do the Jira things. Haven't worked with Maven yet, so that's probably not my part. The first steps is to be done by infra anyway, isn't it? Joerg
Re: Random thoughts on object model
On 13.07.2007 15:36, Grzegorz Kossakowski wrote: Sitemap use its own EL handling implementation. My main goal is to refactor EL usage in Cocoon so one set of interfaces and mechanisms is used everywhere. This will bring consistency across all the Cocoon and easier usage. That's why we need to introduce map language. In a fact, map language exists already there, we just need to refactor it so it fits in unified architecture. Makes sense, thanks for the explanation :-) Joerg
Re: Clarification on converter concept
On 13.07.2007 17:06, Grzegorz Kossakowski wrote: How your MapBasedPropertyEditorRegistrar knows path at which particular editor should be registered? Hmm, that's indeed getting a problem. Not with the MapBasedPropertyEditorRegistrar itself, it handles nested maps. The key of the first map is the data type, the key of the second one the path. This needs to get flattened on PropertyEditorRegistrar.registerCustomEditors(PropertyEditorRegistry) to match PropertyEditorRegistry.registerCustomEditor(Class type, String path, PropertyEditor editor). It now gets a problem since there seems to be no obvious way to automatically register editors with path - except some more complex way of (mis)using the bean's name. Hmm, what about (adapting the EL registry way): with both path and variant being optional. This still lacks the registering for our third criteria, the locale. So I wonder if we don't need a different style of registering anyway. Spring configurator stuff is really handy and has no Cocoon dependencies so its wise to use it. Joerg, you seem to sit inside Spring community, have you considered giving Carsten a present by promoting his stuff? I really think it should get more attention. :-) Hmm, was the first time I had a look into it today. I can't say if this all is of general use. Do you think of moving this stuff or parts of it to Spring (that would be actually up to Carsten IMO) or just get more users to it? For the latter it would be good to have documented what's there and how it is supposed to be used. The documentation at Daisy is a bit spare. Joerg
RE: JSP integration
Reposted, since I didn't get a copy from the list and don't see it in the
archives. Apologies if you've seen it already.
> Date: Thu, 12 Jul 2007 11:31:51 +0200
> From: [EMAIL PROTECTED]
>
> Joerg Heinicke pisze:
> > On 02.07.2007 20:19, Andrew Stevens wrote:
> >
> >> And then inspiration hit - why not instead create a new input Source
> >> for JSPs?
> >>
> >> And then I started to over-think it :-) Why only JSPs? Why not
> >> servlets too? How does this differ from the context: source type?
> >> Surely someone must have thought of doing this before - is there no
> >> similar facility already? What about in Cocoon 2.2 - would the
> >> servlet/blocks framework that keeps getting discussed cater for this
> >> anyway? At which point I figured the best thing to do was to dump my
> >> thoughts to the list and see if anyone had any feedback or
> >> suggestions...
> >
> > Hi Andrew,
> >
> > your ideas sound absolutely reasonable. I appreciate every improvement
> > to the integration of JSP or servlets in general though I don't use it
> > myself (yet). In 2.1 I would really opt for a new source. I only wonder
> > if this is necessary at all in 2.2. I got the impression (just from
> > mailing list) it should be quite easy to integrate Cocoon with other
> > servlets but somebody with actual knowledge might add more details here.
> > What I for example would really like to have is a CocoonView for
> > Spring's ViewRendererServlet or use Cocoon as replacement for the
> > ViewRendererServlet.
>
> Yep, you are right Joerg and Andrew, servlet-service-fw is the way to go.
>
> Basically, you need to register JSP servlet as Spring bean, then you can
> connect to it from other servlet (Cocoon block) using its bean's Id
> and use servlet:/ source for this. Take a look at:
> [1] for servlet configuration as spring bean
> [2] for demo servlet itself
Ah, that might be a problem then. In Websphere 6 (and presumably later
versions too), the JSP engine isn't actually a servlet any more - they use a
new "server extension" architecture to handle requests for JSPs (I assume
through some interception mechanism). In our existing 2.1.x app, I got it
working by creating a new JSPEngine implementation that looks up the
RequestDispatcher for the supplied URL and calls include or forward directly on
that (instead of using JSPEngineImplNamedDispatcherInclude to look up "JSP 1.2
Processor" servlet, which I'd been doing on WAS 5.x). **
How would that fit into the servlet-service-fw?
Andrew.
** NB I also had to remove the "*.jsp" servlet mapping from the Cocoon
servlet, so JSPs are now run directly by the container instead of going through
Cocoon first. It means you can't have Cocoon map "whatever.jsp" requests to
some other pipeline that doesn't call the JSP engine, but we weren't doing that
anyway. Without it, however, pipelines like
would go into an endless loop as the "foo/{1}.jsp" request is also directed
through Cocoon and matches the same pipeline...
> All needed functionality is already there and working, it's a matter of
> providing sample and (really preferably) some documentation how to
> utilize servlet-service-fw functionality to integrate with JSP.
>
> [1]
> http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/resources/META-INF/cocoon/spring/cocoon-servlet-service-demo1-servletService.xml?view=markup
> [2]
> http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-sample/src/main/java/org/apache/cocoon/servletservice/demo1/DemoServlet.java?view=markup
>
> --
> Grzegorz Kossakowski
> http://reflectingonthevicissitudes.wordpress.com/
_
Try Live.com - your fast, personalised homepage with all the things you care
about in one place.
http://www.live.com/?mkt=en-gb
Re: Clarification on converter concept
On 13.07.2007 10:31, Grzegorz Kossakowski wrote: In a state full scenario we are keeping the form object in e.g. a session, so the form template generator could store the associations between property paths and formating variants in the form object as well. Doesn't that tie both CForms and CTemplate together? My understanding is that this approach ties CForms to EL and CTemplate to EL so EL functionality becomes a bridge for two way communication. This is indeed more exact. I considered EL being part of CTemplate :-) I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and its state. FormsTransformer? It has a template approach as well [1], but no EL at all. Actually I'm not very keen on any templating approach at all. I don't like to first provide data to some template context and second retrieve it from there in the template. IMO it's much better to have a complete push approach and only encroach if it is necessary (like XSLT templates). (My diploma thesis was about this btw.) A possible implementation for this is to convert the form model into an XML representation and let a quite generic XSLT do the rest. With this approach no EL come into play. This also means there is a separate object-to-string step. In a stateless scenario, we could instead store the assoications in the form page. IMO it should always work this way, not like the above one for stateful form-processing. This would make whole processing easier to follow, wouldn't it? Difference should not be that big since it's more an implementation detail than something that should concern the user. My main reasoning was the decoupling of EL and CForms. And actually we are back to the Spring way using the path, aren't we? There is only the minor difference of using the full path vs. the anchor. The anchor adds additional flexibility since it can be specified in contrary to the generated path. My impression is that there is a more serious difference between the concepts. While using Daniel's approach you attach converter to the certain path by choosing its variant when you actually pull the data. It doesn't matter if you pull it in form model or template. Spring approach is about attaching everything in advance. That's true. It's the controller that decides which converters get applied, not the view. The "minor difference" I talked about was from the registry POV. Something is just asking for a converter, the only difference is the string which is used for retrieving the converter then. Then it turns out that Daniel's proposal is about registering several converters for every possible path and use variant to choose one from the list (if default is not satisfying). Since, it's all about registering for every possible path (assuming that there is suitable converter for each object) and registering more than one converter it's conceptually different from Spring's approach. Hmm, not really. Even with the current default implementation you can register multiple converters per path differing in the type. You just add another criteria. What's different is the more complex understanding of "path" since you might include the variant in it. Seems to be only a matter of registry implementation how it stores and finds converters. I hope that paragraph didn't confuse things even more... I needed to read it twice but I think I got the message :-) So how far are we from an overall agreement and Grek implementing this for us ;-) I would happy to do it, but I'd be very grateful if we come with strong and detailed agreement. I didn't want to put any pressure on you ;-) Just wondered what the open issues are we still have. Joerg [1] http://cocoon.apache.org/2.1/userdocs/publishing/templating.html
Re: Random thoughts on object model
Reinhard Poetz pisze: Daniel Fagerstrom wrote: Maybe other people have different or more positive experience of branching? Not really :-( Keeping trunk and branch in sync is a lot of work. In the end, use your judgement and do what you think is best. I agree with this. Grek, if you think that your commits affect Cocoon trunk in a way so that it becomes unuseable for all others then consider branching. I (we) learned from history that an unusable trunk is a very bad thing for a community. If you see any chance to keep trunk working, don't branch. FYI: I had to create a branch for Object Model refactorings. It was really impossible to keep things unbroken while refactoring and my attempt to prove it's opposite resulted in wasted three days. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Object Model-related changes in Template generator
On 12.07.2007 16:34, Grzegorz Kossakowski wrote: it's rather JXPath-specific feature. Namespace table is also very specific to JXPath I understand your concerns. Unfortunately, it's hard to give any advice without knowing the internals. public Event execute(final XMLConsumer consumer, ExpressionContext expressionContext, ExecutionContext executionContext, MacroContext macroContext, Event startEvent, What are all these contexts about? Couldn't they somehow be merged? What are their life cycles? Are they all different? Isn't for example the namespace context quite similar to a variable context? Or asked in different words: Isn't a namespace prefix something like a variable? From a short look on the code (only via ViewVC, no Eclipse) similar stuff seems to happen with Java packages for Rhino (FlowObjectModelHelper.addJavaPackages()). I wonder if this makes sense for all cases. Decoupled from the names and concepts used in the current implementation: What is actually needed to evaluate an expression? The expression itself and the context it is evaluated in. This expression context stores all information in it the expression can or needs to access like for example the namespaces. From what I see there is only one expression context during the rendering of a template at the moment. It might be necessary to create one expression-specific per expression. They can then also be expression language specific and Expression.evaluate() could retrieve expression language specific information like namespaces from it. The current ExpressionContext would get a very simple interface not aware of concepts like namespaces. Since those "things" need to get injected on instantiation of the ExpressionContext there also needs to be somthing that keeps track of those "things". These track-keepers have different information needs per expression language, so they need to be registered somewhere. Hmm, this sounds like a major change - maybe not even reasonable without knowing how it is really supposed to work. Does it make sense? Maybe you should really go with the simple and "fat" solution for the moment since those expression language specifics are "in" at the moment anyway. Joerg
Re: [jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
Hi Niclas, as a commiter you can commit it. :) Best Regards, Antonio Gallardo. Niclas Hedhman (JIRA) escribió: [ https://issues.apache.org/jira/browse/COCOON-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niclas Hedhman updated COCOON-1301: --- Reporter: Niclas Hedhman (was: Niclas Hedhman) [Patch] Image Operation Reader -- Key: COCOON-1301 URL: https://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip, pom.xml I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation & Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF.
Re: Clarification on converter concept
Joerg Heinicke pisze: Grzegorz Kossakowski apache.org> writes: I mentioned that snippet as an example how registry could work; my aim was to show that we use declarative approach instead of registering converters/ property editors manually. Ah, got it. :-) Though the names are a bit irritating. Aren't the ExpressionCompilers actually the factories and isn't the ExpressionFactory more of a registry? It's also a bit strange that the Expressions must be aware of the prefix they are mapped to (Expression.getLanguage() + constructors of implementations). Any reason for that? Good point about names. I'll consider to rename this classes since I don't consider them as any public API (it was used in template block only to date). When it comes to prefix and getLanguage() method, I don't know really. Eclipse tells me that this method is not us anywhere in Cocoon so I think it redundant. Before removing it I'll try to search archives. This stuff is really work in progress and comes as legacy so I don't know answers for all questions... Something similar exists for the PropertyEditors, the PropertyEditorRegistrar [1]. You are only supposed to implement it yourself which more or less means to add the PropertyEditors programmatically. Since I did not want to do this, I wrote a MapBasedPropertyEditorRegistrar (matching more or less DefaultExpressionFactory) which I could at least configure from Spring. spring-configurator's BeanMap seems to go one step further and searches for all implementations of a particular interface in the application context. How your MapBasedPropertyEditorRegistrar knows path at which particular editor should be registered? Spring configurator stuff is really handy and has no Cocoon dependencies so its wise to use it. Joerg, you seem to sit inside Spring community, have you considered giving Carsten a present by promoting his stuff? I really think it should get more attention. :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: JSP integration
Joerg Heinicke pisze: On 12.07.2007 05:31, Grzegorz Kossakowski wrote: How is that supposed to work with JSPs where Jasper (when using Tomcat) needs to kick in and compile the JSPs? From what I understand other servlets need to be registered in Cocoon (or the underlying Spring container). Doesn't that make it a servlet container in a servlet container? This approach still seems to suffer from the "almighty Cocoon" syndrome (doing everything itself, not delegating stuff to e.g. the servlet container). Your impression seems to be right. However, I believe that one of main goals while designing cocoon-servlet-service was to stay as transparent as possible. I guess that if we let servlet container to manage servlets we wouldn't get enough flexibility we need but it would be better if Daniel could comment as a creator of whole stuff. I really have no experience with JSP and I don't know how its servlet is initialized and how it works. If you could explain what could be a possible problem I would try to answer according to my knowledge. As a side-note: If particular servlet must be managed by servlet container can't we create servlet (as a Spring bean) that would forward all requests to the JSP servlet using request dispatcher: http://www.jguru.com/faq/view.jsp?EID=206736 ? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Grzegorz Kossakowski apache.org> writes: > >> Yes, there is still a registry but neither EL user nor EL > >> implementation must care about it. > > > > This looks like a registry for expression languages, not for converters. > > How is it related? > > I mentioned that snippet as an example how registry could work; my aim was to > show that we use declarative approach instead of registering converters/ > property editors manually. Ah, got it. :-) Though the names are a bit irritating. Aren't the ExpressionCompilers actually the factories and isn't the ExpressionFactory more of a registry? It's also a bit strange that the Expressions must be aware of the prefix they are mapped to (Expression.getLanguage() + constructors of implementations). Any reason for that? Something similar exists for the PropertyEditors, the PropertyEditorRegistrar [1]. You are only supposed to implement it yourself which more or less means to add the PropertyEditors programmatically. Since I did not want to do this, I wrote a MapBasedPropertyEditorRegistrar (matching more or less DefaultExpressionFactory) which I could at least configure from Spring. spring-configurator's BeanMap seems to go one step further and searches for all implementations of a particular interface in the application context. Joerg [1] http://static.springframework.org/spring/docs/2.0.x/api/ org/springframework/beans/PropertyEditorRegistrar.html
Re: JSP integration
On 12.07.2007 05:31, Grzegorz Kossakowski wrote: > Basically, you need to register JSP servlet as Spring bean, then you can > connect to it from other servlet (Cocoon block) using its bean's Id and use > servlet:/ source for this. > > All needed functionality is already there and working, it's a matter of > providing sample and (really preferably) some documentation how to > utilize servlet-service-fw functionality to integrate with JSP. How is that supposed to work with JSPs where Jasper (when using Tomcat) needs to kick in and compile the JSPs? From what I understand other servlets need to be registered in Cocoon (or the underlying Spring container). Doesn't that make it a servlet container in a servlet container? This approach still seems to suffer from the "almighty Cocoon" syndrome (doing everything itself, not delegating stuff to e.g. the servlet container). Joerg
Re: Division of Cocoon's JIRA project
Joerg Heinicke pisze: What actual work needs to be done with the division process? Maybe I can jump in. I don't know the process in detail but the most important work is related to the fact that components are not migrated and have to be recreated manually. Of course, we won't need all of them because many components will be replaced by own project. Other things that come to mind is updating our poms, writing JIRA welcome page: https://issues.apache.org/jira/browse/COCOON, creating versions and so on. Lots of tedious work. I'd be happy to take advantage of your help! What are your plans? I'd be able to start on Monday, I guess. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Random thoughts on object model
Joerg Heinicke pisze:
Grzegorz Kossakowski apache.org> writes:
I assume that one can configure the map: language to be the default EL,
and that the default EL can be used without a prefix, so that we keep
back compatibility?
Yes, default EL could be configured
Just wondering: Why introduce it at all? Is it just a prefix for what is
currently there ({1}, {../1})?
Sitemap use its own EL handling implementation. My main goal is to refactor EL usage in Cocoon so one set of interfaces and mechanisms is
used everywhere. This will bring consistency across all the Cocoon and easier usage. E.g. today it's rather hard to use input module in
template, after my refactorings input modules will be replaced by EL mechanisms and if you create your own EL implementation you will be
able to use it everywhere.
That's why we need to introduce map language. In a fact, map language exists already there, we just need to refactor it so it fits in
unified architecture.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: 2.2 does not build with JDK1.4.2
On 13.07.2007 06:23, Carsten Ziegeler wrote:
>> Actually in Jan you filed yourself a bugreport
>> http://jira.codehaus.org/browse/MNG-2782 where ${project.version} was
>> resolved to 2.4.1. (You were then still using JDK1.4.2?)
> Yes, I used 1.4.2
>
>>
>> I guess that is due an endorsed Xalan/Xerces problem.
> Yepp.
>From what I understand from all those uncountable and cross-linked Maven issues
is that they somehow retrieve a wrong system propery. And somehow the Xalan or
Xerces coming with JDK 1.4.2 sets this property. What's so specific about this
spring-dao.jar or it's pom that only for it this property is retrieved? Maybe
it's just a change necessary in the pom that might keep Maven away from that
property.
Joerg
Re: Division of Cocoon's JIRA project
Grzegorz Kossakowski apache.org> writes: > > No, as far as I know we can't do it without them anyway. Maybe just > > re-ask with the "offer" to use the COCOON prefix? > > I could do that but I have no free time to handle division process now. I want > to make some progress on my GSoC work. > > Let it be that I'll try to push things forward with COCOON prefix but I'll not > set any schedules for now. What actual work needs to be done with the division process? Maybe I can jump in. Joerg
Re: Random thoughts on object model
Grzegorz Kossakowski apache.org> writes:
> > I assume that one can configure the map: language to be the default EL,
> > and that the default EL can be used without a prefix, so that we keep
> > back compatibility?
>
> Yes, default EL could be configured
Just wondering: Why introduce it at all? Is it just a prefix for what is
currently there ({1}, {../1})?
Joerg
Re: Clarification on converter concept
Joerg Heinicke pisze: In a state full scenario we are keeping the form object in e.g. a session, so the form template generator could store the associations between property paths and formating variants in the form object as well. These associations are then available to use when parsing the input from the post. And we can make sure that the right variant of the converter is used. Doesn't that tie both CForms and CTemplate together? Imagine using only one of both - which would break the concept. My understanding is that this approach ties CForms to EL and CTemplate to EL so EL functionality becomes a bridge for two way communication. I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and its state. In a stateless scenario, we could instead store the assoications in the form page. We could e.g. add it to the property path in the name attribute: "tasks.2.startDate#short". Then the post parser can use the variant info for choosing the right converter. That's an interesting approach. IMO it should always work this way, not like the above one for stateful form-processing. Same feelings here. This would make whole processing easier to follow, wouldn't it? And actually we are back to the Spring way using the path, aren't we? There is only the minor difference of using the full path vs. the anchor. The anchor adds additional flexibility since it can be specified in contrary to the generated path. My impression is that there is a more serious difference between the concepts. While using Daniel's approach you attach converter to the certain path by choosing its variant when you actually pull the data. It doesn't matter if you pull it in form model or template. Spring approach is about attaching everything in advance. I only really don't know if that flexibility is good. I mean you talked about scattered locale handling. This solution now tends to scattered variant handling IMO. I also don't know how it conforms with Parr's requirements for a template language. Doesn't this variant selection go very much into the direction of assumption about the data type? I can live with this concept but actually I prefer the path stuff of Spring much more since this is completely transparent to the template. It also completely decouples the object-to-string conversion from the templating while with the "select a variant"-approach in the template the conversion can not be done without the template. Both are good points. I would be very interested in Daniel's response... It would be like having id selectors but not class selectors in CSS. I think this comparison is misleading. IMO path and variant are really similar concepts. It's only the way where/how they were specified and so the converter is selected. I support Daniel's view. You can apply certain variant to several different paths. Actually, the point is that we could treat Daniel's proposal in Spring terms. Then it turns out that Daniel's proposal is about registering several converters for every possible path and use variant to choose one from the list (if default is not satisfying). Since, it's all about registering for every possible path (assuming that there is suitable converter for each object) and registering more than one converter it's conceptually different from Spring's approach. I hope that paragraph didn't confuse things even more... The new approach using PropertyEditorRegistrar externalizes this into another component. But that one has no access to the request information and so can not even create locale-specific converters. What I know asked myself: How I am supposed to do this at all with Spring? I will file an issue at Spring's Jira requesting an improvement about a locale-aware registry. My hope is that this might get fixed for Spring 2.1 since I consider this really important and generic enough to be of use in Spring in general. Then we do not even need to modify/ replace this part of Spring's converter infrastructure. Otherwise I would reuse as much as possible of this infrastructure though. It's only the registry part that needs modification/ replacement. Therefore dropping the complete infrastructure does not make much sense IMO. So how far are we from an overall agreement and Grek implementing this for us ;-) I would happy to do it, but I'd be very grateful if we come with strong and detailed agreement. I started to implement Object Model several days ago without detailed vision and the whole development turned out to be fairly painful because I found hard to design something that covers so broad subject like universal Object Model usable for whole Cocoon. I hope it will be easier with converters because all this struggle scared me a little bit. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Joerg Heinicke pisze: On 10.07.2007 10:30, Grzegorz Kossakowski wrote: It will be bean's ID pointing that this particular bean implements "short" variant. We use powerful Spring configurator[1] stuff for doing the trick, see this[2] for an example: class="org.apache.cocoon.components.expression.DefaultExpressionFactory"> type="org.apache.cocoon.components.expression.ExpressionCompiler"/> The expressionCompilers property is a Map. Yes, there is still a registry but neither EL user nor EL implementation must care about it. This looks like a registry for expression languages, not for converters. How is it related? I mentioned that snippet as an example how registry could work; my aim was to show that we use declarative approach instead of registering converters/property editors manually. Can you please elaborate on this and add it to this other branch why actually? Maybe there is a different understanding which lead to different impressions on this. Ok, I'll do it. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: 2.2 does not build with JDK1.4.2
Alfred Nathaniel wrote:
> On Wed, 2007-07-11 at 07:50 +0200, Carsten Ziegeler wrote:
>> Hi,
>>
>> did you try maven 2.0.7 with jdk 1.4.2?
>>
>> While building Cocoon with 2.0.7 and jdk1.5, I noticed that the version
>> for the spring-dao was resolved to 2.0.4which fortunately is
>> available :(
>>
>> Carsten
>
> Nope, same problem with maven 2.0.7.
>
> Actually in Jan you filed yourself a bugreport
> http://jira.codehaus.org/browse/MNG-2782 where ${project.version} was
> resolved to 2.4.1. (You were then still using JDK1.4.2?)
Yes, I used 1.4.2
>
> Reading http://docs.codehaus.org/display/MAVEN/Refactoring+Interpolation
> I gather the problem it is deeply rooted in maven and may be tackled
> only with maven 2.1.x.
Yes, unfortunately - I still don't get why maven does not simply replace
the properties on deployment. sigh.
>
>
> I guess that is due an endorsed Xalan/Xerces problem.
Yepp.
>
> This is really getting out of hands. I am now dumping 1.4.2.
:)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
[jira] Updated: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
[ https://issues.apache.org/jira/browse/COCOON-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht updated COCOON-2089: - Attachment: i18n_errorless.patch Patch how the error can be avoided. > ServletService-FW handles missing i18n catalogue files incorrect > > > Key: COCOON-2089 > URL: https://issues.apache.org/jira/browse/COCOON-2089 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Felix Knecht > Attachments: i18n_errorless.patch > > > ServletService throws an exception when a specific language catalogue in a > connected block is not found, even when a general catalogue exists. > Forcing the error: > - Run the cocoon-webapp with the form samples > - Choose following link: > http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE > - Click on the "Submit Query" button > You will see the errors in the log file: > btpool0-3 ERROR cocoon - Bundle > not loaded: > Exception > org.apache.cocoon.CascadingIOException: Error during resolving of the input > stream > at - > file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 > OTH when you copy the > cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml > into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the > cocoon-forms-sample root sitemap to use the local message.xml catalogue file > instead of the one from the cocoon-forms-impl block you don't get an error > and the general catalogue (messages.xml) is silently used instead of the > missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
ServletService-FW handles missing i18n catalogue files incorrect Key: COCOON-2089 URL: https://issues.apache.org/jira/browse/COCOON-2089 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Felix Knecht ServletService throws an exception when a specific language catalogue in a connected block is not found, even when a general catalogue exists. Forcing the error: - Run the cocoon-webapp with the form samples - Choose following link: http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE - Click on the "Submit Query" button You will see the errors in the log file: btpool0-3 ERROR cocoon - Bundle not loaded: Exception org.apache.cocoon.CascadingIOException: Error during resolving of the input stream at - file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 OTH when you copy the cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the cocoon-forms-sample root sitemap to use the local message.xml catalogue file instead of the one from the cocoon-forms-impl block you don't get an error and the general catalogue (messages.xml) is silently used instead of the missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
