RE: JavaFlow/ CocoonFroms java.lang.VerifyError: Cocoon 2.1.5.1
I've had the same problem in 2.1.5.1. I reported a bug here: http://archives.real-time.com/pipermail/cocoon-devel/2004-July/035779.ht ml I had the problem that when I use: doSomethingWithClass(Product.class);// fails doSomethingWithClass(Product.getClass()); // ok, does not fail Bart. -Original Message- From: Andreas Schmid [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 9:23 PM To: [EMAIL PROTECTED] Subject: JavaFlow/ CocoonFroms java.lang.VerifyError: Cocoon 2.1.5.1 As far as i know this bug was already posted by stephan coboos, and fixed in a daily snapshot in Version 2.1.4 This happens, when is try to wrtite a timestamp to a bean (means a long value) in javaflow. e.g long myLong = 12345; MyBean bean = new MyBean(); bean.setMyLong(myLong); form.load(bean); form.show(); form.save(bean); this.getLogger.error(bean.getMyLong); Right now when i try to startup cocoon in my Tomcat (5.x) the javaflow will not be loaded an an exception listed below is thrown by Tomcat. Can anyone help me ? THX Andreas Schmid 2004-08-09 20:24:19 StandardWrapperValve[Cocoon]: Servlet.service() for servlet Cocoon threw exception java.lang.VerifyError: (class: net/projektinter/gui/flow/tree/EditTreeNodeFlow, method: doEditTreeNode signature: ()V) Attempt to split long or double on the stack at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1647) at java.lang.Class.privateGetPublicMethods(Class.java:1770) at java.lang.Class.getMethods(Class.java:824) at org.apache.cocoon.components.flow.java.JavaInterpreter.initialize(JavaIn terpreter.java:96) at org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(Java Interpreter.java:130) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invo ke(CallFunctionNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:49) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P ipelineNode.java:126) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:101) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:336) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:277) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun tNode.java:103) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:49) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P ipelineNode.java:126) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:101) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:336) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:277) at org.apache.cocoon.Cocoon.process(Cocoon.java:639) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1098) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo ntext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:5 20) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardCon textValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo ntext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:5 20) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :137) at
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27467. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27467 Upgrade all source files to ASF 2.0 license [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 06:40 --- Should be finished. If you find some files without a proper license header, feel free to re-open this issue.
DO NOT REPLY [Bug 25359] - [Roadmap] General - NEXT release
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25359. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25359 [Roadmap] General - NEXT release This bug depends on bug 27467, which changed state: What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27467. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27467 Upgrade all source files to ASF 2.0 license [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
DO NOT REPLY [Bug 25384] - Call pipeline from within a Cron job
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25384. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25384 Call pipeline from within a Cron job [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 06:45 --- I close this issue because there is a solution available in the cron block and refactored by Sylvain.
DO NOT REPLY [Bug 25358] - [Roadmap] General - FUTURE releases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25358. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25358 [Roadmap] General - FUTURE releases This bug depends on bug 25384, which changed state: What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 25384] - Call pipeline from within a Cron job
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25384. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25384 Call pipeline from within a Cron job [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
DO NOT REPLY [Bug 25281] - Make it possible to use continuations in clustered environments
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25281. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25281 Make it possible to use continuations in clustered environments --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 06:48 --- This seems to be more difficult than expected. See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109194779712277w=2 for details and more links.
Re: Preparation of board report
Vadim Gritsenko wrote:
David Crossley wrote:
Also remember that it is the chair's report to the board, so you
don't need agreement from us about what you tell them.
Also remember that chair is chosen by community, and if chair goes
against community will, he will get replaced by community :-)
So, community should take part in creating report, and chair should
take leading role (and RFC on report's draft).
Exactly. I am the messenger between Cocoon and the board, and although I
have some good ideas of what has to be said, I want you all to be able
to bring in concerns that I may have missed or badly expressed.
Now about the detailed contents, I know the report's primary purpose is
to notify the board about problems, but I think a short description of
the good things that happened is important also, so that the board
doesn't receive only bad news ;-)
Keep up great job, Sylvain :-)
Thanks!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
DO NOT REPLY [Bug 25325] - Intercepted flowscripts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25325. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25325 Intercepted flowscripts --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 06:52 --- There is an initial implementation available in scratchpad. Unfortunatly it has a low priority on my Cocoon todo list and I'll drop if for now. Maybe things change in fall.
DO NOT REPLY [Bug 25325] - Intercepted flowscripts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25325. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25325 Intercepted flowscripts [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
DO NOT REPLY [Bug 27147] - Cocoon Forms field styling: selection lists with optgroups
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27147. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27147 Cocoon Forms field styling: selection lists with optgroups [EMAIL PROTECTED] changed: What|Removed |Added Summary|Woody field styling:|Cocoon Forms field styling: |selection lists with|selection lists with |optgroups |optgroups
Re: Hibernate question
Il giorno 10/ago/04, alle 04:14, Vadim Gritsenko ha scritto: even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? It would not be an issue as long as classes compiled against Hibernate are not included into Spring JAR which is (in this imaginary situation) used by Cocoon. Anything else becomes grey area, and as such, most probably should be avoided all together. Spring's ORM support is distributed as a separate jar (spring-orm.jar) and is not needed to use the rest of spring (core, mvc, AOP, etc.). This should cover our asses in case we bundle Spring with Cocoon. OTOH, If you are using Hibernate you are agreeing to the terms of the LGPL anyway, but if you want to use, say, OJB, which is supported in Spring 1.1, you'd have to include spring-orm.jar in your application and that includes also code compiled against Hibernate's interfaces. Would that force you to distribute your code under the (L)GPL? I don't know, but in any case you could always strip all Hibernate-dependent classes from the jar and keep only the OJB-dependent ones. Anyway, IANAL but this is getting painful :( Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: JavaFlow/ CocoonFroms java.lang.VerifyError: Cocoon 2.1.5.1
I found a workaround for this: as long as you declare the var global (menas a class var) the error does not happen. Maybe this helps you continuing work as long as the bug is not fixed. CYA Andreas Schmid Bart Molenkamp wrote: I've had the same problem in 2.1.5.1. I reported a bug here: http://archives.real-time.com/pipermail/cocoon-devel/2004-July/035779.ht ml I had the problem that when I use: doSomethingWithClass(Product.class);// fails doSomethingWithClass(Product.getClass()); // ok, does not fail Bart. -Original Message- From: Andreas Schmid [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 9:23 PM To: [EMAIL PROTECTED] Subject: JavaFlow/ CocoonFroms java.lang.VerifyError: Cocoon 2.1.5.1 As far as i know this bug was already posted by stephan coboos, and fixed in a daily snapshot in Version 2.1.4 This happens, when is try to wrtite a timestamp to a bean (means a long value) in javaflow. e.g long myLong = 12345; MyBean bean = new MyBean(); bean.setMyLong(myLong); form.load(bean); form.show(); form.save(bean); this.getLogger.error(bean.getMyLong); Right now when i try to startup cocoon in my Tomcat (5.x) the javaflow will not be loaded an an exception listed below is thrown by Tomcat. Can anyone help me ? THX Andreas Schmid 2004-08-09 20:24:19 StandardWrapperValve[Cocoon]: Servlet.service() for servlet Cocoon threw exception java.lang.VerifyError: (class: net/projektinter/gui/flow/tree/EditTreeNodeFlow, method: doEditTreeNode signature: ()V) Attempt to split long or double on the stack at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1647) at java.lang.Class.privateGetPublicMethods(Class.java:1770) at java.lang.Class.getMethods(Class.java:824) at org.apache.cocoon.components.flow.java.JavaInterpreter.initialize(JavaIn terpreter.java:96) at org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(Java Interpreter.java:130) at org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invo ke(CallFunctionNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:49) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P ipelineNode.java:126) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:101) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:336) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:277) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(Moun tNode.java:103) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:49) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.i nvoke(PreparableMatchNode.java:130) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(P ipelineNode.java:126) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode. invokeNodes(AbstractParentProcessingNode.java:72) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke( PipelinesNode.java:101) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:336) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreePro cessor.java:277) at org.apache.cocoon.Cocoon.process(Cocoon.java:639) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1098) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo ntext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:5 20) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardCon textValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveCo ntext.java:104) at
DO NOT REPLY [Bug 25359] - [Roadmap] General - NEXT release
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25359. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25359 [Roadmap] General - NEXT release This bug depends on bug 27467, which changed state: What|Old Value |New Value Status|CLOSED |REOPENED Resolution|FIXED |
DO NOT REPLY [Bug 27467] - Upgrade all source files to ASF 2.0 license
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27467. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27467 Upgrade all source files to ASF 2.0 license [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 07:32 --- :-) the insert_license.pl script advises that there are 17 new files without a license. I will fix them sometime soon. People, please be more careful.
DO NOT REPLY [Bug 30554] New: - StreamGenerator and chunked encoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30554. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30554 StreamGenerator and chunked encoding Summary: StreamGenerator and chunked encoding Product: Cocoon 2 Version: 2.1.5 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Would it be possible to modify StreamGenerator and PostInputStream to allow a post using chunked encoding i.e. where no content length is specified, but the input stream will terminate with -1? Robert Onslow
RE: pluto in Cocoon
-Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 5:28 PM To: [EMAIL PROTECTED] Subject: pluto in Cocoon We would like to support JSR-168 portlets in Cocoon but do not want a full-blown portal - i.e. we want to have some pages that just render regular html and others that have portlets on them. It seems like this should be doable, but I'm not sure how much of the portal engine is required or what classes in the pluto subdirectory are needed. The Javadoc for org.apache.cocoon.portal.pluto(.*) (at least in 2.1.5) isn't particularly helpful in figuring out what the classes do, so any help would be appreciated. If I understand you correctly, you want to strip down the portal engine and remove the unused classes? For using Pluto in Cocoon you need all classes in org.apache.cocoon.portal.pluto(.*) - this is the implementation required by Pluto to connect Cocoon and Pluto. Carsten
why JXTG sucks? was: FreeMarker integration
Antonio Gallardo wrote:
Hi Lezsek:
I will talk about my own experience. We already build 2 fairly
semi-complex forms intensive applications with CForms + JX Template
Generator. The idea is that JXG is used only for some special view
purposes. You prepare the data on a java class and JXT just show them.
We also use it to build reports.
Me too and I really hate it when hitting the wall and starting to hack.
I think this was the idea when JXG born. JXT was not designed as a
repleacement for velocity. In fact the problem with velocity and similars
is the mixed concerns and for this reasons JXT is so simple it gives you
all the necesary tools for the view job. JXT has inside a mix of 2
powerful language.
but this is only a model traversal language. JXTG offers very small
functionality in:
- control statements
- data formatting
- extendability (via taglibs - jx:macro sometimes fails to deliver
functionality as it is limited itself)
I have implemented only a few small projects using jxtg and found some
live examples of these limitations:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
function xmlProducer( value, consumer ) {}
cocoon.session.setAttribute( xmlProducer, xmlProducer );
in jxtg you do:
${cocoon.session.xmlFormatter( mydomainobject.property,
cocoon.consumer )}
or create a macro to hide this awful syntax.
2. same for wiki syntax
3. I had to write a special class to create links that hold all current
request parameters apart from selected ones (i.e. to reload the same
page under different locale).
then use it like a href=${Packages.com.mobilebox.utils.
LinkFormatter.getLinkWithAllReqParamsExcept(
'locale'}amp;locale=enSwitch to english/a
4. There is no jx:attribute functionality so if you want to insert
attributes conditionally you have to duplicate the WHOLE node (which
might be huge)
you are not able to plug any of these extensions (hacks should be
written) to view once and for all so you end up setting your session
attribute for every view that might use it and importing a macros file
in the same jx template. FreeMarker allows to configure so called
shared variables that provide additional functionality. You could
subclass a FreeMarkerGenerator to register any of your additional
functionality without performing such ugly hacks.
All this processing is VIEW specific only. I should not be forced to
create another bizData data representation for every view I come to
implement. This breaks SoC as I might want to create more than one view
of the same data. If I followed your proposal I would have to end up
implementing several bizData representations. This is half a step ahead
from implementing a pure xml generator - try to do that for every view
in your project.In JXTG you can break SoC whereever you like. Browse
cocoon examples and mailing list for constructs like:
jx:set var=ignore value=${performSomeOperationsHere}/
worse :
jx:set var=ignore
value=${Packages.com.mycompany.ClassThatWillMessThingsUp.doIt()}/
Because of this you could not provide your application with the
functionality that your users define parts of the application interface
by editing or providing own templates. This could be the ultimate threat
to your app (especially the open source one as users would know exactly
what code to call to mess up). I wonder if they could bring the whole
system down by simple ${System.exit( 0 )} :))). It would be enough that
method that does this is reachable in classpath.
FreeMarker does not allow that as it wraps data model at the runtime and
you are not allowed to call anything outside of it.
I think velocity stoped to be developed (as was posted in the provided
link) because it stoped to be interesting. People found another ways to
make the job done. I think mainly because XML was on the scene. But
velocity was a very nice language at the time, trying to provide HTML
dynamic building features. Currently, I saw both (velocity and freemaker)
as some kind of JSP, ASP, PHP, etc. I think we (cocoon) are beyond this
technologies while we still use them for some special cases. Note I am not
telling they are useless.
We are not beyond as we have no powerful templating language. JXTG
offers 10% of functionality of FreeMarker or Velocity.
All in all, based on the cocoon nature, I think we can also create a
FreeMaker Generator and use it in Cocoon. I already don't saw the license,
we need to check them if is compatible with AL 2.0.
its BSD, means - compliant.
Although maybe discontinued Velocity still is the top of the templating
languages used for view generation in web applications. Almost all web
frameworks use it. Like with democracy: sucks but there is nothing
better right now.
One of JXTG pros is that every value from data model gets automaticaly
converted to a xml
[GUMP@brutus]: cocoon-2.1/cocoon failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 52 projects, and has been outstanding for 3 runs. Project State : 'Failed', Reason 'Build Failed' The following are affected: - cocoon : Java XML Framework - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-chaperon : Java XML Framework - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-linotype : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-mail : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-php : Java XML Framework - cocoon-block-poi : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-fw : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-scratchpad : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-woody : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - cocoon-lenya : Content Management System Full details are available at: http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [cocoon.jar] identifier set to jar basename: [cocoon] -DEBUG- Jar [cocoon-tests.jar] identifier set to jar basename: [cocoon-tests] -DEBUG- Jar [cocoon-deprecated.jar] identifier set to jar basename: [cocoon-deprecated] -DEBUG- Dependency on avalon-framework exists, no need to add for property avalonapi.jar. -INFO- Made directory [/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040810/test] -INFO- Enable verbose output, due to 3 previous error(s). -INFO- Failed with reason build failed -INFO- Enable debug output, due to build failure. -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040810/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040810/test/output] The following work was performed: http://brutus.apache.org/gump/public/cocoon-2.1/cocoon/gump_work/build_cocoon-2.1_cocoon.html Work Name: build_cocoon-2.1_cocoon (Type: Build) State: Failed Elapsed: 14 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -verbose -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Davalonapi.jar=/usr/local/gump/public/workspace/avalon/framework/api/target/avalon-framework-api-20040810.jar -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-logkit/target/avalon-logkit-20040810.jar -Dversion=20040810 gump-core [Working Directory: /usr/local/gump/public/workspace/cocoon-2.1] CLASSPATH : /usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040810/classes:/usr/local
Re: why JXTG sucks? was: FreeMarker integration
Leszek Gawron dijo:
I have implemented only a few small projects using jxtg and found some
live examples of these limitations:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
function xmlProducer( value, consumer ) {}
cocoon.session.setAttribute( xmlProducer, xmlProducer );
in jxtg you do:
${cocoon.session.xmlFormatter( mydomainobject.property,
cocoon.consumer )}
or create a macro to hide this awful syntax.
We also use session and this kind of stuff is prepared on the flow script
or a helper java class. As I told before JXG just read data. It was not
intended to be forced this way. Bussiness model stuff must be separated.
2. same for wiki syntax
Don't know. I never used something like that. We are more DB oriented
programmers.
3. I had to write a special class to create links that hold all current
request parameters apart from selected ones (i.e. to reload the same
page under different locale).
then use it like a href=${Packages.com.mobilebox.utils.
LinkFormatter.getLinkWithAllReqParamsExcept(
'locale'}amp;locale=enSwitch to english/a
Flowscript again is good for that. JXG is not the right tool for that.
4. There is no jx:attribute functionality so if you want to insert
attributes conditionally you have to duplicate the WHOLE node (which
might be huge)
Flow script job again.
you are not able to plug any of these extensions (hacks should be
written) to view once and for all so you end up setting your session
attribute for every view that might use it and importing a macros file
in the same jx template. FreeMarker allows to configure so called
shared variables that provide additional functionality. You could
subclass a FreeMarkerGenerator to register any of your additional
functionality without performing such ugly hacks.
All this processing is VIEW specific only. I should not be forced to
create another bizData data representation for every view I come to
implement. This breaks SoC as I might want to create more than one view
of the same data. If I followed your proposal I would have to end up
implementing several bizData representations. This is half a step ahead
from implementing a pure xml generator - try to do that for every view
in your project.In JXTG you can break SoC whereever you like. Browse
cocoon examples and mailing list for constructs like:
jx:set var=ignore value=${performSomeOperationsHere}/
worse :
jx:set var=ignore
value=${Packages.com.mycompany.ClassThatWillMessThingsUp.doIt()}/
I never needed something like that and we present sometimes the data in
diferents formats and order. Even sometimes we need to skip some pages
based on the user input, a simple jx:if is enough to make the job done:
jx:if test=${ignore == 'false'}
...
/jx:if
The ignore variable is part of the bizdata that comes from the flowscript.
I know the line between what is VIEW and what is MODEL is very thin. But
we prefer to let the MODEL decide what the user will see. For us JXG is a
template generator, nothing more nor less.
Because of this you could not provide your application with the
functionality that your users define parts of the application interface
by editing or providing own templates. This could be the ultimate threat
to your app (especially the open source one as users would know exactly
what code to call to mess up). I wonder if they could bring the whole
system down by simple ${System.exit( 0 )} :))). It would be enough that
method that does this is reachable in classpath.
FreeMarker does not allow that as it wraps data model at the runtime and
you are not allowed to call anything outside of it.
I think velocity stoped to be developed (as was posted in the provided
link) because it stoped to be interesting. People found another ways to
make the job done. I think mainly because XML was on the scene. But
velocity was a very nice language at the time, trying to provide HTML
dynamic building features. Currently, I saw both (velocity and
freemaker)
as some kind of JSP, ASP, PHP, etc. I think we (cocoon) are beyond this
technologies while we still use them for some special cases. Note I am
not
telling they are useless.
We are not beyond as we have no powerful templating language. JXTG
offers 10% of functionality of FreeMarker or Velocity.
The point is we are moving away of this kind of things. This is what I
think. We try to keep clean sources. A mess of VIEW+MODEL is not good and
that is what we got using velocity...
All in all, based on the cocoon nature, I think we can also create a
FreeMaker Generator and use it in Cocoon. I already don't saw the
license,
we need to check them if is compatible with AL 2.0.
its BSD, means - compliant.
Although maybe discontinued Velocity still is the top of the
Re: why JXTG sucks? was: FreeMarker integration
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto: 1. you cannot parse string from your model as xml, had do use session hacks to do that ( put flowscript function into session, use it via macro in jxtg): I don't think it's the view's responsibility to parse XML. Parse it in the flowscript and pass the resulting DOM to the view. You can do that in bizData without using the session at all. 2. same for wiki syntax Same as above. WRT your other points, I agree that the JXTG is somewhat limiited and clumsy, but don't try to have it do more than what it should, otherwise you're back to XSP. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: why JXTG sucks? was: FreeMarker integration
Antonio Gallardo wrote:
Leszek Gawron dijo:
I have implemented only a few small projects using jxtg and found some
live examples of these limitations:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
function xmlProducer( value, consumer ) {}
cocoon.session.setAttribute( xmlProducer, xmlProducer );
in jxtg you do:
${cocoon.session.xmlFormatter( mydomainobject.property,
cocoon.consumer )}
or create a macro to hide this awful syntax.
We also use session and this kind of stuff is prepared on the flow script
or a helper java class. As I told before JXG just read data. It was not
intended to be forced this way. Bussiness model stuff must be separated.
a template language user should not be forced to create helper classes
and if he/she needs a particular specific functionality it should be
plugged into and not used explicitly.
2. same for wiki syntax
Don't know. I never used something like that. We are more DB oriented
programmers.
Some of my entities have description property which I allow users to
will in with wiki markup so it is nicely rendered on the page.
3. I had to write a special class to create links that hold all current
request parameters apart from selected ones (i.e. to reload the same
page under different locale).
then use it like a href=${Packages.com.mobilebox.utils.
LinkFormatter.getLinkWithAllReqParamsExcept(
'locale'}amp;locale=enSwitch to english/a
Flowscript again is good for that. JXG is not the right tool for that.
Flowscript is a controller, controller should not perform data
formatting. it is view specific functionality. I should be able to
switch jxtemplate to another one simply changing the view uri in
cocoon.sendPage. If that forces me to refine my controller although the
new view uses the same data - it is SoC break.
4. There is no jx:attribute functionality so if you want to insert
attributes conditionally you have to duplicate the WHOLE node (which
might be huge)
Flow script job again.
Not true. View is the one to decide if a piece of data should be
rendered as tag or attribute. You use it this way because you have to
overcome JXTG's lack of that feature.
you are not able to plug any of these extensions (hacks should be
written) to view once and for all so you end up setting your session
attribute for every view that might use it and importing a macros file
in the same jx template. FreeMarker allows to configure so called
shared variables that provide additional functionality. You could
subclass a FreeMarkerGenerator to register any of your additional
functionality without performing such ugly hacks.
All this processing is VIEW specific only. I should not be forced to
create another bizData data representation for every view I come to
implement. This breaks SoC as I might want to create more than one view
of the same data. If I followed your proposal I would have to end up
implementing several bizData representations. This is half a step ahead
from implementing a pure xml generator - try to do that for every view
in your project.In JXTG you can break SoC whereever you like. Browse
cocoon examples and mailing list for constructs like:
jx:set var=ignore value=${performSomeOperationsHere}/
worse :
jx:set var=ignore
value=${Packages.com.mycompany.ClassThatWillMessThingsUp.doIt()}/
I never needed something like that and we present sometimes the data in
diferents formats and order. Even sometimes we need to skip some pages
based on the user input, a simple jx:if is enough to make the job done:
jx:if test=${ignore == 'false'}
...
/jx:if
The ignore variable is part of the bizdata that comes from the flowscript.
I know the line between what is VIEW and what is MODEL is very thin. But
we prefer to let the MODEL decide what the user will see. For us JXG is a
template generator, nothing more nor less.
I am not talking about the need. I also never needed this. But if you
exposed your jx template to be edited by user online he/she could inject
such code and bring your server down. I was amazed of jroller
functionality that allows user to access the template of every part of
his/her blog template to be edited. One has a library of macros to
access blog data model. It's completely up to you how you present it.
Noone needs to alter the data model (which should be entities straight
from database not altered at all) if user prepares a new view for his data.
I think velocity stoped to be developed (as was posted in the provided
link) because it stoped to be interesting. People found another ways to
make the job done. I think mainly because XML was on the scene. But
velocity was a very nice language at the time, trying to provide HTML
dynamic building features. Currently, I saw both (velocity and
freemaker)
as some kind of JSP, ASP, PHP, etc. I think we (cocoon) are beyond
Re: why JXTG sucks? was: FreeMarker integration
Ugo Cei wrote:
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's responsibility to parse XML. Parse it in
the flowscript and pass the resulting DOM to the view. You can do that
in bizData without using the session at all.
2. same for wiki syntax
Same as above.
WRT your other points, I agree that the JXTG is somewhat limiited and
clumsy, but don't try to have it do more than what it should, otherwise
you're back to XSP.
Ugo
I see this functionality on the same level as : jx:formatDate,
jx:formatNumber
I know you are using hibernate in your projects. Assume you have lazily
loaded, big data model passed to your view. some of the properties in
model are strings. At view level, when you traverse your collections you
want pretty print some of your model properties instead of doing only
${object.property}. The property might be at any level of your data
model. Moreover - if you have lazy loading you can provide your every
view with the same huuuge data model so the view decides which part to
use and present.
From this point of view the pretty printer is a part of templating
language. Controller should not know nothing about that as this is a
part of view rendering. If you wanted to pretty print your properties in
flowscript you would have to provide:
a) a wrapper for you entity so it can pretty print your data. This
will break your lazy loading and break the whole
one-big-model-multi-views idea
b) insert pretty printing code in your entity itself. This forces code
duplication and breaks separation of concerns. I do not want my entities
expose a dependency to some kind of wiki parsing library, xml
formatting library, number formatting library, some-very-sophisticated
library.
--
Leszek Gawron [EMAIL PROTECTED]
Re: why JXTG sucks? was: FreeMarker integration
Leszek Gawron wrote:
Ugo Cei wrote:
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's responsibility to parse XML. Parse it
in the flowscript and pass the resulting DOM to the view. You can do
that in bizData without using the session at all.
2. same for wiki syntax
Same as above.
WRT your other points, I agree that the JXTG is somewhat limiited and
clumsy, but don't try to have it do more than what it should,
otherwise you're back to XSP.
Ugo
I see this functionality on the same level as : jx:formatDate,
jx:formatNumber
I know you are using hibernate in your projects. Assume you have
lazily loaded, big data model passed to your view. some of the
properties in model are strings. At view level, when you traverse your
collections you want pretty print some of your model properties
instead of doing only ${object.property}. The property might be at any
level of your data model. Moreover - if you have lazy loading you can
provide your every view with the same huuuge data model so the view
decides which part to use and present.
From this point of view the pretty printer is a part of templating
language. Controller should not know nothing about that as this is a
part of view rendering. If you wanted to pretty print your properties
in flowscript you would have to provide:
a) a wrapper for you entity so it can pretty print your data. This
will break your lazy loading and break the whole
one-big-model-multi-views idea
b) insert pretty printing code in your entity itself. This forces
code duplication and breaks separation of concerns. I do not want my
entities expose a dependency to some kind of wiki parsing library,
xml formatting library, number formatting library,
some-very-sophisticated library.
IMHO the missing features in JX are the attribute problem and that you
can't plug in your own languages. Most of the other problems you
describe should be handled by a framework like CocoonForms.
--
Reinhard
DO NOT REPLY [Bug 30148] - Internal server Error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30148. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30148 Internal server Error --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 11:01 --- The bug was fixed in 2.1.4. Carsten kindly replaced any reference to the StaticBucketMap with a synchronized HashMap (not nice, but it works). This was done in the Excalibur ComponentManager package. Commons-Collections still has the non-threadsafe StaticBucketMap in it.
Re: Upgrading 2.1.6-dev branch
Antonio Gallardo wrote: Hi: I started to upgrade the 2.1.6-dev branch and I don't see the point to upgrade jars there. I feel myself like doing the same work again. My last commits were just a copy paste from the 2.2 branch: http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109214252606989w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109214290714483w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109214378109796w=2 AFAIK, the current 2.2-dev is a bug fix + minor enhancements since 2.1.5.1 So where is the point to update it? It really matter? Will we have a 2.1.6 release at all? 2.2 does contain some non-trivial changes, esp. to the environment handling IIRC. There was a discussion [1] a few days ago about the roadmap for 2.2. I definately think there will be releases in the 2.1.x branch (at least I hope so considering the proposed roadmap for 2.2) and I definately think porting bugfixes, minor enhancements and jar upgrades to 2.1.x is a valuable thing. 1. http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109136664115145w=2 -- Unico
RE: XJ: Integration of XML Processing into Java
Stefano Mazzocchi [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: I saw this go by on the xml-dev list this morning and my first thought was boy, there would be a way to make the sitemap even harder to work with. After looking at it closer I'm not sure exactly how you could make a sitemap with this combination, though from the description one would think it should fit the bill of combining the sitemap and flow exactly. In any case, have a look at: http://www2004.org/proceedings/docs/2p340.pdf For a description of the XJ language. (A solution looking for a problem?) XJ is just like XSP but taken code-side first. Now there's a thought: sitemaps in XSP... Given my level of comfort with XSP, JSP and similar I'm still wondering exactly what problem XJ is supposed to solve.
Re: Upgrading 2.1.6-dev branch
Unico Hommes wrote: Antonio Gallardo wrote: I started to upgrade the 2.1.6-dev branch and I don't see the point to upgrade jars there. I feel myself like doing the same work again. My last commits were just a copy paste from the 2.2 branch: http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109214252606989 http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109214290714483 http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=109214378109796 AFAIK, the current 2.2-dev is a bug fix + minor enhancements since 2.1.5.1 So where is the point to update it? It really matter? Will we have a 2.1.6 release at all? Yes. 2.2 does contain some non-trivial changes, esp. to the environment handling IIRC. In addition to [non-trivial] changes, 2.2 also seen lots of deprecated code removal - which is not to be done in 2.1.6. There was a discussion [1] a few days ago about the roadmap for 2.2. I definately think there will be releases in the 2.1.x branch (at least I hope so considering the proposed roadmap for 2.2) and I definately think porting bugfixes, minor enhancements and jar upgrades to 2.1.x is a valuable thing +1 Vadim 1. http://marc.theaimsgroup.com/?l=xml-cocoon-devm=109136664115145w=2 -- Unico
[RT] Concerns surrounding CocoonNG
Hi, I have with great interest read just about everything regarding the Cocoon sentiment of moving away from Excalibur Component Manager. What strikes me with the proposals 'on the table'; * Spring * Pico * Merlin * Fortress * Geronimo/GBean * Custom (Kernel) is that AFAIU only Geronimo (not verified but assumed) and Merlin (verified) is currently equipped to deal with hot re- deploy of components. _IMHO_, such feature is far from rudimentary, primarily since it needs to deal with 'usage references', i.e. decommission components that holds references to those that are being re-deployed. Since I belong to the 'Merlin camp', I sure am interested to hear; 1. Is compatibility no longer an issue, and that a Cocoon 3 will emerge from a clean slate? Or is a 'gradual' evolution from ECM to something new still the preferred approach? 2. Is the Spring/Pico/Kernel camps considering classloading mentioned above being a non-issue, and delegating the task to Cocoon itself to deal with it? 3. Is there interest in this community of a 'proof-of-concept', showcasing the powers of Merlin, such as classloading, Jar management (Maven style), custom contexts, strong typing, automatic dependency resolution and other features that Cocoon would benefit from? FYI, planned features for Merlin in the coming 6-12month period; * Better JMX integration. * JMS support. * JTA support. * IoC Type 2 and Type 3 dependency resolution. * JavaBeans/Type2 setter injection of parameter values. * User-defined life-cycles per component type. * Improved component-level security. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Patch? - HSSFSerializer NullPointerException in EPStyle.java
This problem relates to the POI block. I was configuring an HSSF
transformation (to Excel) and kept getting a NullPointerException. After
some investigation into the source, I discovered the problem was that
EPStyle was assuming a format was specified and I did not have one in my
gmr:Style. I made a change to have the code handle this case and leave it
as the default General Format. The change is below. If you agree this is a
worthy patch, please let me know what (if anything) I need to do to get the
patch put in the cvs tree.
src\blocks\poi\java\org\apache\cocoon\components\elementprocessor\impl\poi\h
ssf\elements\EPStyle.java
Around line 179 added format!=null :
// If format is non-null and different than General format
if (format!=null !format.equals(_general_format)) {
Re: [RT] Concerns surrounding CocoonNG
Il giorno 10/ago/04, alle 16:05, Niclas Hedhman ha scritto: 1. Is compatibility no longer an issue, and that a Cocoon 3 will emerge from a clean slate? Or is a 'gradual' evolution from ECM to something new still the preferred approach? It depends on who you ask. Personally, I tend to prefer a rewrite over a refactoring in many situations. I am aware that this is not always the best course, but it's my personality and I cannot do anything about it. However, this has nothing to do with backward compatibility. You can do a rewrite from scratch and still maintain 100% compatibility with old interfaces, possibly via an emulation layer. 2. Is the Spring/Pico/Kernel camps considering classloading mentioned above being a non-issue, and delegating the task to Cocoon itself to deal with it? Frankly, I haven't even started considering the issue. I am not equipped with enough knowledge about class loaders and such to proffer an informed opinion. 3. Is there interest in this community of a 'proof-of-concept', showcasing the powers of Merlin, such as classloading, Jar management (Maven style), custom contexts, strong typing, automatic dependency resolution and other features that Cocoon would benefit from? Of course, there is, and I don't think I'm mistaken if I try to interpret the interest of the whole community here. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Concerns surrounding CocoonNG
Niclas Hedhman wrote:
Hi,
I have with great interest read just about everything regarding the Cocoon
sentiment of moving away from Excalibur Component Manager.
What strikes me with the proposals 'on the table';
* Spring
* Pico
* Merlin
* Fortress
* Geronimo/GBean
* Custom (Kernel)
is that AFAIU only Geronimo (not verified but assumed) and Merlin (verified) is currently
equipped to deal with hot re- deploy of components.
_IMHO_, such feature is far from rudimentary, primarily since it needs to deal with
'usage references', i.e. decommission components that holds references to those that
are being re-deployed.
Since I belong to the 'Merlin camp', I sure am interested to hear;
1. Is compatibility no longer an issue, and that a Cocoon 3 will emerge from a clean slate? Or is a 'gradual' evolution from ECM to something new still the preferred approach?
Cocoon 2 was totally incompatible with Cocoon 1, and so could be an
hypothetical Cocoon 3 (as not such plan formally exists today).
Compatibility is of primary importance however for Cocoon 2.1.x series,
and Cocoon 2.2 will remove what is being deprecated in the 2.1.x series.
2. Is the Spring/Pico/Kernel camps considering classloading mentioned above being a non-issue, and delegating the task to Cocoon itself to deal with it?
As I explained in an earlier post, there are two levels of containers:
- the single container for blocks, almost invisible from user code, that
has to deal with hot deploy and classloading issues. In this category
come Merlin, GBeans and our own Kernel
- the container within each block, managing application-level
components, and thus visible to users. We use ECM for this today, and is
where API-less containers such as Spring are studied.
3. Is there interest in this community of a 'proof-of-concept', showcasing the powers of Merlin, such as classloading, Jar management (Maven style), custom contexts, strong typing, automatic dependency resolution and other features that Cocoon would benefit from?
Merlin certainly contains good code, but too many social issues for a
small community. I don't want these issues to pollute the healthy Cocoon
community.
So my personal answer is no. Other people here may have a different
opinion though.
FYI, planned features for Merlin in the coming 6-12month period;
* Better JMX integration.
* JMS support.
* JTA support.
* IoC Type 2 and Type 3 dependency resolution.
* JavaBeans/Type2 setter injection of parameter values.
* User-defined life-cycles per component type.
* Improved component-level security.
How's that different from GBeans+Spring?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Concerns surrounding CocoonNG
Il giorno 10/ago/04, alle 16:32, Sylvain Wallez ha scritto: So my personal answer is no. Other people here may have a different opinion though. Then please disregard the closing sentence in my previous message ;-) Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [RT] Concerns surrounding CocoonNG
On Tuesday 10 August 2004 22:32, Sylvain Wallez wrote: FYI, planned features for Merlin in the coming 6-12month period; * Better JMX integration. * JMS support. * JTA support. * IoC Type 2 and Type 3 dependency resolution. * JavaBeans/Type2 setter injection of parameter values. * User-defined life-cycles per component type. * Improved component-level security. How's that different from GBeans+Spring? I know far too little about Spring in general (i.e. never worked with it) and GBeans in particular (i.e. have not read enough), to be able to provide a good answer. As for Spring, I think the apparent convergence between Merlin and Spring is based on two different starting points. Merlin starting out as a Model-driven architecture, with strong typing, a strong IoC as its base, where as Spring started out with making IoC-style out of JavaBeans. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+
Re: [RT] Concerns surrounding CocoonNG
Niclas Hedhman wrote:
I know far too little about Spring in general (i.e. never worked with it) and GBeans
in particular (i.e. have not read enough), to be able to provide a good answer.
As for Spring, I think the apparent convergence between Merlin and Spring is based on two different starting points. Merlin starting out as a Model-driven architecture, with strong typing, a strong IoC as its base, where as Spring started out with making IoC-style out of JavaBeans.
Mmh... can you elaborate on the meaning of model-driven and _strong_
IOC?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: pluto in Cocoon
Thanks Carsten, I'm not sure if I want/need to strip it down or not. What we want is a normal web site that can also display JSR-168 portlets. We'd like a common layout across all the pages though. I've just started looking at this, but it looks like most of the portlet functionality is handled by the PortalGenerator, so it would appear that this should be fairly easy to do. The PortalGenerator calls a PortalManager, which I haven't really looked at yet. I assume the PortalManager needs the portal configuration to do its work. We also have the case where a single webapp will be hosting multiple portal sites. From what I can tell this should also work since the portal configuration looks like it uses cocoon pipelines. Here, the issue would be how to do personalization differently. The portal documentation says that you can use your own persistence layer but doesn't explain how. So again, any advice would be helpful. Thanks Carsten Ziegeler said: If I understand you correctly, you want to strip down the portal engine and remove the unused classes? For using Pluto in Cocoon you need all classes in org.apache.cocoon.portal.pluto(.*) - this is the implementation required by Pluto to connect Cocoon and Pluto. Carsten
Re: [RT] Concerns surrounding CocoonNG
On 10 Aug 2004, at 15:05, Niclas Hedhman wrote: 2. Is the Spring/Pico/Kernel camps considering classloading mentioned above being a non-issue, and delegating the task to Cocoon itself to deal with it? Kernel: Class re-Loading already work through the conceptualization and implementation of blocks. That was the core issue that I needed to solve for my own personal use of the kernel (not considering Cocoon). Pier smime.p7s Description: S/MIME cryptographic signature
StaticBucketMap, Re: DO NOT REPLY [Bug 30148] - Internal server Error
[EMAIL PROTECTED] wrote: http://issues.apache.org/bugzilla/show_bug.cgi?id=30148. --- Additional Comments From [EMAIL PROTECTED] 2004-08-10 11:01 --- The bug was fixed in 2.1.4. Carsten kindly replaced any reference to the StaticBucketMap with a synchronized HashMap (not nice, but it works). This was done in the Excalibur ComponentManager package. Commons-Collections still has the non-threadsafe StaticBucketMap in it. I took a looong look at the current version of StaticBucketMap [1] but fail to see how it is not thread safe... Can anybody give a guess, what can go wrong in this code? Vadim [1] http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/java/org/apache/commons/collections/map/StaticBucketMap.java?annotate=1.11
RE: Cocoon and JCS (on Gump) (fwd)
Hi, It seems the JCS folks are (now) thinking of preparing a release. Given this will be their first release, and this change will be in the release, does it seem prudent for Cocoon to track this change now, and get as much testing time as possible? regards Adam -- Have you Gump'ed your code today? http://gump.apache.org -- Forwarded message -- Date: Tue, 10 Aug 2004 08:51:42 -0700 From: Smuts, Aaron [EMAIL PROTECTED] Reply-To: Turbine JCS Developers List [EMAIL PROTECTED] To: Turbine JCS Developers List [EMAIL PROTECTED] Subject: RE: Cocoon and JCS (on Gump) Yes. We can release. All the known bug fixes and the improvements that we wanted to get done first have been completed. I need to find out the process. Aaron -Original Message- From: Estefano Eduardo [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 2:13 AM To: Turbine JCS Developers List Subject: RE: Cocoon and JCS (on Gump) I think the problem is that there are no releases of JCS yet, so this is not possible. If you update your cvs repository you may be getting stuff that will break your working code. Isn't JCS stable enough for a Beta version release? This way other applications could know what what they are getting into through the release notes, change logs, etc. -Original Message- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Monday, 09 August, 2004 23:01 To: Turbine JCS Developers List Cc: [EMAIL PROTECTED] Subject: RE: Cocoon and JCS (on Gump) On Mon, 9 Aug 2004, Travis Savo wrote: According to the change log Aaron Smuts made this change on 6/28/2004 in order to make .dispose() visible to the clients of the JCS class. I expect it will be a permanent change because it's reasonable that clients of the JCS class will want to dispose of a region themselves. The only problems I foresee with upgrading this in the field is if there's a class that extends CacheAccess (which you appear to be doing). In this case you will need to upgrade your code, but I expect this to be an isolated and rare occurrence. Assuming that's not the case, I see no problems mixing jars in the field in relationship to this change. Does that answer your question? First, thanks for the answer. Second, API changes happen (fact of life), and Gump (and my questions) are just trying to see if we can mitigate against issues in the field, be early detection and discussion/etc. Frankly, my low level java is insufficient to know if subtleties of access contraints (on a method) make it into the signature, and/or otherwith affect runtime. I could imagine that such a change annoys compilers, but slides through at runtime (in many case). I don't think there is an easy way for anybody to allow a transition path, given this type of change. As such, I suspect the correct approach is to note it, and try to move on. BTW: What would really help is notice of what releases the old 'signature' is in, and what release the new one might be in. Having this be in the RELEASE NOTES could help also. Could you answer that question, and try to remember it for the CHANGES notification. BTW: I'll CC the cocoon community on this one, to see if they are comfortable changing their code. Thanks for your help. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why JXTG sucks? was: FreeMarker integration
Nuno Santos dijo: JXTG is a nice templating tool, but very limited! Why should we be stuck to it if we have a more powerfull templating stuck in the scratchpad? Please, can explain more what we have there? Just curious. Best Regards, Antonio Gallardo
Re: help needed (OWQL)
Halgurt Mustafa-Ali wrote: hi, I am tryong to itegrate OWQL in to the cocoon framework, I implemented a Transformer for that purpose (see the Attachment please). The OWQL tool has a method printAnswerAsXML (String reqxml, PrintWriter pw) do you have an idea how can I convert pw to SAX events? smart-ass-reply mode=probably missing the point how about an xml parser? ;-) /smart-ass-reply -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeMarker integration
Leszek Gawron wrote:
Is anybody interested in FreeMarker integration with cocoon? There is no
single word (Oh there are some freemarker occurences but they do not
stick to the subject) about FreeMarker on the cocoon-dev list. It is BSD
style licensed so there is no problem with shipping it with cocoon I think.
To say the truth: there is NO good templating language to use with cocoon:
1) XSP is just a step ahead from JSP 1.2 and step back from JSP 2.0
(this is just a quick comment - I maybe wrong, anyway: XSP sucks)
2) Velocity is out of question right now - there is even no xml/html
escape utility so a newbie ends up with having a template that could
generate an invalid sax event stream.
3) JX Template generator is fine for simple cases but it lacks a lot of
functionality i.e.:
- control statements are very limited
- you cannot plug in external tag implementations - jx:macro is good
only for simple processing, you can do it only via a ugly session
hack (${cocoon.session.wikifyFunction( --string--,
cocoon.consumer}), so it's very close to any extensions
- you cannot set attribues via something similar to xsl:attribute as
it is quite hard to implement (and might be inefficient)
I would never be able to leave cocoon:
- I cannot imaging my life without flowscript
- cforms is the best implementation for form handling there is. period.
but the view generation is what really bugs me..
have you tried Pier's Garbage? (it's in the scratchpad)
If someone is interested I might try to implement freemarker integration
as the comparison to velocity looks promising:
http://freemarker.sourceforge.net/fmVsVel.html
WDYT?
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Hibernate question
Leszek Gawron wrote: Let's imagine we base cocoon on spring. There was a discussion about including hibernate in cocoon and it failed (licensing). Spring being ASL 2.0 ships with hibernate library, even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? Ouch. yes. Can you outline the dependencies more? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: why JXTG sucks? was: FreeMarker integration
Just Jelly! It has all functionality that JXTG gives you, plus the fact that you can build your own tags either as classes or as macros! On Tue, 2004-08-10 at 16:14, Antonio Gallardo wrote: Nuno Santos dijo: JXTG is a nice templating tool, but very limited! Why should we be stuck to it if we have a more powerfull templating stuck in the scratchpad? Please, can explain more what we have there? Just curious. Best Regards, Antonio Gallardo -- Nuno Santos [EMAIL PROTECTED] Electroplus, lda
Re: why JXTG sucks? was: FreeMarker integration
Why JXTG sucks? Because it's to powerful! http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf (It's not the first time that it is posted here.) rules: view cannot modify the model view cannot perform computations upon dependent data values view cannot compare dependent data values view cannot make data type assumptions data from the model must not contain display or layout information FreeMaker is also mentioned in the document - as example for highest entanglement index. Jörg
Re: Logging all HTTP Requests to a database
Craig, There is a sample RequestListener in the src/Samples directory. It isn't particularly useful, but it is a start. To enable the request listener add the following to cocoon.xconf: component class=com.whatever.MyServletRequestListener logger=core.manager.listener role=org.apache.cocoon.RequestListener /component That's all there is to it. Ralph Craig Christophersen said: Hello; I am looking into doing something similar where I will cache all requests for the session, then commit them to a database(thru middleware) upon exit. I downloaded the new 2.1.5.1 (currently using 2.1.4)version to look into the RequestListener but find little info on it. Any help on how to implement it? I find nothing when searching the Wiki. Craig Christophersen (406)496-6421 [EMAIL PROTECTED]
[HELP] - XUL hello sample
Hi: I am trying to build a xul hello world sample. The problem is I need to setup this doctype using the XML Serializer: !DOCTYPE window and I don't know how to manipulate that. please help. Best Regards, Antonio Gallardo
RE: Unable to find component for hint
Hunsberger, Peter Hunsberger, Peter writes: Sylvain Wallez [EMAIL PROTECTED] asks: sniporiginal problem description/snip I went as far as adding my wrapper class to the jar that contains the base XSLTProcessor but no matter what I do Cocoon gives: org.apache.cocoon.ProcessingException: Lookup of transformer 'xslt-wrappedSaxon7' failed at file://sitemap.xmap:769:100: org.apache.avalon.framework.component.ComponentException: transformers: ComponentSelector could not access the Component for hint [xslt-wrappedSaxon7] (key [xslt-wrappedSaxon7]) Anyone know what I'm missing? Hmm... what if you name the role of the new component org.apache.excalibur.xml.xslt.XSLTProcessor/wrappedSaxon7, and use xslt-processor-rolewrappedSaxon7/xslt-processor-role ? Assuming that you mean to use org.apache.excalibur.xml.xslt.XSLTProcessor/wrappedSaxon7 in the xconf and xslt-processor-rolewrappedSaxon7/xslt-processor-role in the sitemap, that doesn't help. I get the exact same error :-( Correction. If I use org.apache.excalibur.xml.xslt.XSLTProcessor/wrappedSaxon7 in the xconf but keep the class pointing to my class then the org.apache.excalibur.xml.xslt.XSLTProcessor class is invoked (the component is found). Thus, two strange things: the class specification in the xconf is ignored, and class lookup must have some Cocoon compile time dependency (which makes no sense)? Traced this through org.apache.cocoon.transformation.TraxTransformer and found that it in fact sets my class (XSLTProcessorWrapper) for the xsltProcessor. However, my class is subsequently not invoked. I believe there are two possibilities: 1) This has something to do with the tree processor and a hard coded assumption about the xslt processor somewhere; org.apache.excalibur.xml.xslt.XSLTProcessorImpl is always invoked no matter what is specified in the cocoon.xconf. 2) The xslt processor is actually not used and the transformer factory and whatever transformer it sites out is actually invoked to run the transformation directly. Does anyone know how this actually works?
Re: help needed (OWQL)
Vadim Gritsenko wrote: Though job. The lazy way would be to use a PipeStream to pipe the content written to the PrintWriter to a SAX parser running in another thread. That's likely to course trouble in some circumstances. I don't see anything lazy about this :) IMHO, lazy way is to use StringWriter and then parse resulting text with SAX parser using one of the Cocoon's Util classes. I always thought I was lazy. But then: running in another thread. That's likely to course trouble ^^ I thought I even spell-checked the message before sending! J.Pietschmann
Re: [HELP] - XUL hello sample
Antonio Gallardo wrote:
Hi:
I am trying to build a xul hello world sample. The problem is I need to
setup this doctype using the XML Serializer:
!DOCTYPE window
and I don't know how to manipulate that.
please help.
What about declaring a XUL serializer in the sitemap with the proper
doctype configuration?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: DO NOT REPLY [Bug 30046] - Bring the new I18NMatcher in line with LocaleAction
[EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30046. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30046 Bring the new I18NMatcher in line with LocaleAction --- Additional Comments From [EMAIL PROTECTED] 2004-08-09 14:34 --- Added code for checking locale stored in session and in cookie. Full locale checking order now is: * request parameter * session attribute * cookie * sitemap parameter * request locale(s) - optional, depends on use-locale(s) config parameters. * default * blank LocaleAction supports same order but has no sitemap parameter, and has no default locale, and blank locale (because request locale checking is not optional - and will always return some non null locale). Now, about setting locale into the request/session/cookie: this is not as simple as it looks. Problem is that LocaleAction selects first available locale, but I18nMatcher goes through *all* available locales till it finds matching resource. Thus, for one resource it can result in one locale, and for other resource - in other locale, so locale returned by I18nMatcher can not be used for setting into session/cookie. I18nMatcher can be changed to be two-step procedure, (1) select locale, (2) using selected locale search for resource in this locale (with variant - country - language - blank degradation). This modified I18nMatcher will be more compatible with LocaleAction, and then it can be modified to set chosen locale into session/cookie. (on train - can't reply through Bugzilla) I don't quite understand how your two stage procedure would work. As the selection of the locale is fundamentally connected with the available resources. As you work through each method for selecting a locale, you look for a resource using that method, if found, you exit. Otherwise, you try the next method, and if necessary, you degrade from variant/country/language, etc. How could this be done as separate select locale/select resource stages? Regards, Upayavira WDYT? Vadim
Re: why JXTG sucks? was: FreeMarker integration
Joerg Heinicke wrote: Why JXTG sucks? Because it's to powerful! http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf (It's not the first time that it is posted here.) rules: view cannot modify the model view cannot perform computations upon dependent data values view cannot compare dependent data values view cannot make data type assumptions data from the model must not contain display or layout information assume you have a collection of Projects. Each project has a project.description property. This property contains a string that can be parsed by a wiki parser and generate html out of it. How would you implement that. Assume that your controller does NOT know what string properties should be wikified as there are hundreds of this kind of properties and you also have several orthogonal views which query different model parts. if the view cannot perform computations you cannot put it into view layer as some kind of macro if the data cannot contain display or layout information you shouldn't preformat all your project.description properties. Also it is plainly stupid to provide the view with two versions or each property: raw and formatter as the third formatter might come to action. what then ? FreeMaker is also mentioned in the document - as example for highest entanglement index. Jrg I'll read the document and have more comments tomorrow. -- Leszek Gawron [EMAIL PROTECTED]
Re: [RT] Concerns surrounding CocoonNG
Niclas Hedhman wrote:
On Tuesday 10 August 2004 22:55, Sylvain Wallez wrote:
Niclas Hedhman wrote:
I know far too little about Spring in general (i.e. never worked with it)
and GBeans in particular (i.e. have not read enough), to be able to
provide a good answer.
As for Spring, I think the apparent convergence between Merlin and Spring
is based on two different starting points. Merlin starting out as a
Model-driven architecture, with strong typing, a strong IoC as its base,
where as Spring started out with making IoC-style out of JavaBeans.
Mmh... can you elaborate on the meaning of model-driven and _strong_
IOC?
Strong IoC is in reference to ECM that allows you to look up any component on
the fly, no matter if such dependency has been declared or not. Merlin otoh,
will not allow lookup() of non-declared dependencies.
Ah, ok. So this is about security and proper use of dependencies.
It seems to me that dependency injection, compared to lookup, solves
this problem in the an elegant way by suppressing it, since a component
no more has access to a component locator.
Model Driven = Merlin builds a model of all the participating components.
Merlin will satisfy the declared dependencies, implicitly or explicitly,
within the model, prior to deploying (note, deploying != instantiation, as
that is determined by the lifestyle) the components. If the dependencies can
not be fulfilled, deployment will not occur. This approach minimizes the
runtime problem that can occur, with adhoc resolution of component dependency
resolution.
Although this is very good from a robustness point of view, I don't feel
at ease with this as it requires to somehow manage dependencies twice:
in the model where they have to be formally expressed, and in the code
where actual lookup occurs. Again, depencency injection (as opposed to
lookup) avoids this problem.
You said that Merlin is going to support injection, which IMO a very
good thing. My remarks are mainly about the Avalon Framework APIs which
now seem so old-fashioned compared to newer approaches to IOC. Sure,
Avalon kicked ass when it was invented and was very ahead of its time,
but things have evolved since then (dynamic proxies, AOP, etc) and
people have learned from what was brought by Avalon.
I hope this clarifies my PoV.
Yep. Thanks a lot!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: why JXTG sucks? was: FreeMarker integration
Leszek Gawron wrote: Joerg Heinicke wrote: Why JXTG sucks? Because it's to powerful! http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf (It's not the first time that it is posted here.) snip Jrg I'll read the document and have more comments tomorrow. Browsing over the PDF, ahh, recusively-enumerable, turing machines, my brain is about to explode, only because I'm doing this stuff in school *right now*. More comments later, Tony
Re: Hibernate question
Stefano Mazzocchi wrote: Leszek Gawron wrote: Let's imagine we base cocoon on spring. There was a discussion about including hibernate in cocoon and it failed (licensing). Spring being ASL 2.0 ships with hibernate library, even if not - it contains code that was compiled against hibernate interfaces. Wouldn't this be an issue? Ouch. yes. Can you outline the dependencies more? Spring has a support for hibernate OOTB. There are 2 packages dependant on hibernate: org.springframework.orm.hibernate org.springframework.orm.hibernate.support The problem is that the distribution consists of : - either single spring.jar that contains all - or spring-XXX.jar where XXX is core, orm, aop and so on. you could drop whole spring-orm.jar but then you loose all support for any OR framework. I am suprised of one fact: how can Spring be distributed with ASL 2.0 license if it is compiled against LGPL code (and redistributes this code in compiled form also)? Are they in trouble or are we wrong? This is the readme file from spring lib directory: The following libraries are included in the Spring Framework distribution because they are required either for building the framework or for running the sample apps. Note that each of these libraries is subject to the respective license; check the respective project distribution/website before using any of them in your own applications. * ant/ant.jar - Ant 1.6.1 (http://ant.apache.org) - used to build the framework and the sample apps * aopalliance/aopalliance.jar - AOP Alliance 1.0 (http://aopalliance.sourceforge.net) - required for building the framework - required at runtime when using AOP functionality * axis/axis.jar, axis/saaj.jar, axis/wsdl.jar - Apache Axis 1.1 (http://ws.apache.org/axis) - required for running JPetStore * caucho/burlap-2.1.12.jar - Burlap 2.1.12 (http://www.caucho.com/burlap) - required for building the framework - required at runtime when Spring's Burlap remoting support * caucho/hessian-2.1.12.jar - Hessian 2.1.12 (http://www.caucho.com/hessian) - required for building the framework - required at runtime when Spring's Hessian remoting support * cglib/cglib-2.0.1.jar, cglib/asm.jar - CGLIB 2.0.1 with ObjectWeb ASM 1.4 (http://cglib.sourceforge.net) - required for building the framework - required at runtime when proxying full target classes via Spring AOP * cos/cos.jar - Jason Hunter's COS 05Nov02 (http://www.servlets.com/cos) - required for building the framework - required at runtime when using Spring's CosMultipartResolver or CosMailSender * dom4j/dom4j.jar - DOM4J 1.4 XML parser (http://dom4j.sourceforge.net) - required for running Petclinic (by Hibernate) * easymock/easymock.jar, easymock/easymockclassextension.jar - EasyMock 1.1 (http://www.easymock.org) - required for building the test suite * freemarker/freemarker.jar - FreeMarker 2.3 RC4 (http://www.freemarker.org) - required for building the framework - required at runtime when using Spring's FreeMarker support * hibernate/ehcache.jar - EHCache 0.6 (http://ehcache.sourceforge.net) - required for running Petclinic (by Hibernate) * hibernate/hibernate2.jar, hibernate/odmg.jar - Hibernate 2.1.3 (http://www.hibernate.org) - required for building the framework - required at runtime when using Spring's Hibernate support * hsqldb/hsqldb.jar - HSQLDB 1.7.1 (http://hsqldb.sourceforge.net) - required for running JPetStore and Petclinic * ibatis/ibatis-common.jar, ibatis/ibatis-sqlmap.jar, ibatis/ibatis-sqlmap-2.jar - iBATIS SQL Maps 1.3.1 and 2.0 RC5 (http://www.ibatis.com) - required for building the framework - required at runtime when using Spring's iBATIS SQL Maps support * itext/itext-1.02b.jar - iText PDF 1.02 (http://www.lowagie.com/itext) - required for building the framework - required at runtime when using Spring's AbstractPdfView * j2ee/activation.jar - JavaBeans Activation Framework 1.0.1 (http://java.sun.com/products/javabeans/glasgow/jaf.html) - required for building the framework - required at runtime when using Spring's JavaMailSender * j2ee/connector-api.jar - J2EE Connector Architecture 1.5 (http://java.sun.com/j2ee/connector) - required at runtime when using Hibernate's JCA Connector * j2ee/ejb.jar - Enterprise JavaBeans API 2.0 (http://java.sun.com/products/ejb) - required for building the framework - required at runtime when using Spring's EJB support * j2ee/jaxrpc.jar - JAX-RPC API 1.0 (http://java.sun.com/xml/jaxrpc) - required for building the framework - required at runtime when using Spring's JAX-RPC support * j2ee/jdbc2_0-stdext.jar - JDBC 2.0 Standard Extensions (http://java.sun.com/products/jdbc) - required for building the framework on J2SE 1.3 - required at runtime when using Spring's JDBC support on J2SE 1.3 * j2ee/jms.jar - Java Message Service API 1.0.2b (java.sun.com/products/jms) - required for building the framework - required at runtime when using Spring's AbstractJmsMessageDrivenBean * j2ee/jstl.jar - JSP Standard Tag Library API 1.0
Re: [RT] Concerns surrounding CocoonNG
On Wednesday 11 August 2004 04:22, Sylvain Wallez wrote:
Although this is very good from a robustness point of view, I don't feel
at ease with this as it requires to somehow manage dependencies twice:
in the model where they have to be formally expressed, and in the code
where actual lookup occurs. Again, depencency injection (as opposed to
lookup) avoids this problem.
Looking at the actual differences;
public AbcComponent( org.hedhman.niclas.SomeDependency some )
{
m_SomeDependency = some;
}
/** @avalon.dependency type=org.hedhman.niclas.SomeDependency
* key = some
*/
public void service(ServiceManager man )
{
m_SomeDependency = (SomeDependency) man.lookup( some );
}
If there is proper SoII in CDI, the SomeDependency is an interface, and that
leaves room for more than one implementation, in which case both Merlin and
Pico/Nano needs additional meta/code to declare exactly which implementation
to be used.
If there is only one implementation available, Merlin will use that only, as I
believe Pico/Nano will also figure out.
So, the current differences are not as great as some may think. Merlin has
come a long way compared to ECM, but I agree that there are room for further
improvements.
You said that Merlin is going to support injection, which IMO a very
good thing.
We have taken a few steps in that direction already. So called custom
contexts can already be injected via constructors, as can the traditional
Avalon lifecycle objects, such as Logger, Context, ServiceManager,
Configuration and Parameters.
The next step ain't that far away, we are just struggling with some semantics,
especially surrounding the possibility of more than a single constructor,
which Pico says is a no-no, but could be a necessity.
Another 'issue' that CDI imposes is how to deal with aggregations and possibly
custom configuration/parameterization objects, which Pico (unlike Type2) will
need.
All and all, I am fairly positive about the continuation of the Merlin
convergence with other IoC styles, especially if Merlin becomes the Metro
TLP, in which case there no longer exist any 'religious reasons' to stick
with the Avalon-way only.
Cheers
Niclas
--
+--//---+
/ http://www.bali.ac/
/ http://niclas.hedhman.org /
+--//---+
