[jira] Assigned: (COCOON-1978) JXTemplate often fail a method call without giving any error
[
https://issues.apache.org/jira/browse/COCOON-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leszek Gawron reassigned COCOON-1978:
-
Assignee: Leszek Gawron
JXTemplate often fail a method call without giving any error
Key: COCOON-1978
URL: https://issues.apache.org/jira/browse/COCOON-1978
Project: Cocoon
Issue Type: Bug
Components: Blocks: Templating
Affects Versions: 2.2-dev (Current SVN)
Reporter: Simone Gianni
Assignee: Leszek Gawron
When calling a method on an instance in JXTemplate, if that method does not
exist (or JX cannot find the proper method based on parameters), it fails
without any error. IMO it should raise an error, or at least should raise it
in dev mode, because not having a debugger it takes hours to figure out why
it's not working.
As an example, take a JX and try to call a method that does not exist :
jx:set var=any
value=${obj.getSomethingThatDoesNotExist(cocoon.request)}/
Any will simply be null. Moreover, even if any is then used :
${any.getSomethingElse()}
Again it will fail without any error, resulting simply in an empty string,
making it even harder.
Being a non compiled language already makes it difficult to make sure calls
are correct, having this silent fail behavior makes it even harder, and if
you add also the non typized nature it can make it a nightmare.
Anyway, I don't know if there is a way to fix this in cocoon or if it is a
Jexl design problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Webapp does not run in trunk...
...because a dependency in database block's pom is missing and also a
getter in LibraryManagerImpl
[]s
Gustavo
Index: pom.xml
===
--- pom.xml (revision 581520)
+++ pom.xml (working copy)
@@ -2022,6 +2022,11 @@
version2.0.6/version
/dependency
dependency
+groupIdorg.springframework/groupId
+artifactIdspring-jdbc/artifactId
+version2.0.6/version
+ /dependency
+ dependency
groupIdstax/groupId
artifactIdstax-api/artifactId
version1.0/version
Index:
blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/binding/library/LibraryManagerImpl.java
===
---
blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/binding/library/LibraryManagerImpl.java
(revision 581520)
+++
blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/binding/library/LibraryManagerImpl.java
(working copy)
@@ -164,6 +164,11 @@
{
this.cacheManager = cacheManager;
}
+
+public CacheManager getCacheManager()
+{
+return cacheManager;
+}
public void setSourceResolver( SourceResolver sourceResolver )
{
Index: blocks/cocoon-databases/cocoon-databases-impl/pom.xml
===
--- blocks/cocoon-databases/cocoon-databases-impl/pom.xml (revision
581520)
+++ blocks/cocoon-databases/cocoon-databases-impl/pom.xml (working copy)
@@ -62,6 +62,10 @@
groupIdorg.apache.excalibur.components/groupId
artifactIdexcalibur-datasource/artifactId
/dependency
+dependency
+ groupIdorg.springframework/groupId
+ artifactIdspring-jdbc/artifactId
+/dependency
!-- Specify transitive dependencies to avoid MNG-2782 with JDK1.4.2. --
dependency
groupIdorg.springframework/groupId
Welcome to the Cocoon GT 2007
Hi all, for those who are already here and for who is still coming, here are a few indications : - If you need to get here, ask your hotel reception the shortest way to the Bioparco, which is inside the Villa Borghese park. - Once you get there, you don't have to enter by the main entrance, but by the offices gate, which is located in the small building on the right of the main entrance. There are some signs on the way. - As soon as you enter the Bioparco, you'll notice to elephants :D. The room is on the left of the elephants, near the lions :D - In the room there is wireless connection, without any need for password. - There are plenty of power plugs, if you need more just ask we will provide. - At the bar you can ask whatever you want to drink, we have coke, fanta, sprite, italian beer, water, american coffee, espresso coffee, tea, ice tea, milk. This is the lunch program for these days : - Wed : pizza, served in the room. - Thu : lots of Italian typical food, mozzarella, prosciutto, salame and the like, served in the room. - Fri : pasta, served in the Lake Oasis, few meters away from the room. This evening, for those of you who decided to participate to the extra dinner, we are going to get a Bus at 18:30 and move to Ariccia. There we are going to eat at a Fraschetteria. We will be back at around 23:00 at trastevere, where we can grab a beer. On our way back we will go by bus to the Colosseum and the Piazza San Pietro if we manage to. For everything you need, please just ask to me (I'm the one near the picture of the pink greater flamingo). Simone
Re: Cocoon 2.2 documentation online!
Reinhard Poetz said the following on 2/10/07 18:08: hepabolu wrote: Reinhard Poetz said the following on 28/9/07 16:26: While I was creating all the release artifacts of Cocoon 2.2RC2 I also published our 2.2 docs. See http://cocoon.apache.org/2.2/ I have to say that I'm really proud of seeing this long-term effort finally materializing :-) Thanks to all the involved helping hands! Excellent work! I just noticed that the 'subprojects' link on the right leads to the directory, rather than the index.html file. hmm, on which page do you notice this behaviour? For me it works ... On all of them. I just tested the main page, the one with the picture of the graphic of the architecture (Spring framework) and some others I can't remember. Bye, Helma
org.apache.cocoon.el.impl.AbstractExpression.AbstractExpression(String language, String expression)
does anybody actually use language parameter? AbstractExpression.getLanguage() is in fact never used. The expression compiler selection is being made up front so the AbstractExpression.language may serve only for informational purposes. comments? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
COCOON-1978
https://issues.apache.org/jira/browse/COCOON-1978 this pure JEXL code: // mistaken variable name String jexlExp = fuu; org.apache.commons.jexl.Expression expression = ExpressionFactory.createExpression(jexlExp); // Create a context and add data JexlContext jc = JexlHelper.createContext(); jc.getVars().put(foo, new Foo() ); // Now evaluate the expression, getting the result Object o = expression.evaluate(jc); System.out.println( o ); actually produces null when no foo variable is found in context instead of throwing. JEXL javadoc does not show any direct method to change this behaviour. Is there anything we can do? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: svn commit: r581188 [1/9] - in /cocoon/site/site: ./ community/ css/ devinfo/ images/ images/logos/ link/ news/
[EMAIL PROTECTED] wrote: publish new 'pmc site' Added: cocoon/site/site/1164_1_1.html (with props) cocoon/site/site/1178_1_1.html (with props) ... Just wondering - do we have any of old URLs preserved? Or htaccess redirects for old URLs? Vadim
Still fighting with Continuum
Hi Cocooners! Could people being moderators for our list (dev) take a look at this[1] comment? Emaanuel claims that e-mail should arrive to our list but I do not see it. Is it my omission? [1] https://issues.apache.org/jira/browse/INFRA-1316#action_12532051 -- Grzegorz
[jira] Assigned: (COCOON-2134) StringTemplateParserVariableResolver does not implement Disposable interface
[ https://issues.apache.org/jira/browse/COCOON-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leszek Gawron reassigned COCOON-2134: - Assignee: Leszek Gawron (was: Grzegorz Kossakowski) StringTemplateParserVariableResolver does not implement Disposable interface Key: COCOON-2134 URL: https://issues.apache.org/jira/browse/COCOON-2134 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Leszek Gawron Priority: Critical Fix For: 2.2-dev (Current SVN) As Csaba Kazó pointed out in comment on COCOON-2106 StringTemplateParserVariableResolver doesn't implement Disposable interface. This may lead to following error: java.lang.ClassCastException: org.apache.cocoon.components.treeprocessor.variables.StringTemplateParserVariableResolver cannot be cast to org.apache.avalon.framework.activity.Disposable at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.dispose(ConcreteTreeProcessor.java:333) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2134) StringTemplateParserVariableResolver does not implement Disposable interface
[ https://issues.apache.org/jira/browse/COCOON-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leszek Gawron closed COCOON-2134. - Resolution: Fixed removed Disposable interface VariableResolverFactory does not register StringTemplateParserVariableResolver for disposal StringTemplateParserVariableResolver does not implement Disposable interface Key: COCOON-2134 URL: https://issues.apache.org/jira/browse/COCOON-2134 Project: Cocoon Issue Type: Bug Components: - Components: Sitemap Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Assignee: Leszek Gawron Priority: Critical Fix For: 2.2-dev (Current SVN) As Csaba Kazó pointed out in comment on COCOON-2106 StringTemplateParserVariableResolver doesn't implement Disposable interface. This may lead to following error: java.lang.ClassCastException: org.apache.cocoon.components.treeprocessor.variables.StringTemplateParserVariableResolver cannot be cast to org.apache.avalon.framework.activity.Disposable at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.dispose(ConcreteTreeProcessor.java:333) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Cocoon 2.2 documentation online!
hepabolu wrote:
On all of them. I just tested the main page, the one with the picture of
the graphic of the architecture (Spring framework) and some others I
can't remember.
I added the missing .htaccess file (though I still find it strange that it
worked for me yesterday ...)
Thanks for reporting!
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Webapp does not run in trunk...
Gustavo N. Fernandes wrote: ...because a dependency in database block's pom is missing and also a getter in LibraryManagerImpl Can you point what samples are not working, which are fixed by this patch? Thanks, Vadim
Re: Webapp does not run in trunk...
After doing a clean checkout and mvn -Dmaven.test.skip=true -P allblocks install mvn jetty:run on webapp dir the webapp does not launch at all, giving a 503 error on browser. The errors occurs in blocks database and forms. Gustavo Vadim Gritsenko wrote: Gustavo N. Fernandes wrote: ...because a dependency in database block's pom is missing and also a getter in LibraryManagerImpl Can you point what samples are not working, which are fixed by this patch? Thanks, Vadim
Moving root.pom into a sub directory
I think we should move the root.pom into a sub directory like parent or pom. This will make updates and releases of the root pom easier as for these opperations only a single directory with a single file needs to be checked out. If noone objects, I'll change this. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Moving root.pom into a sub directory
Carsten Ziegeler wrote:
I think we should move the root.pom into a sub directory like parent
or pom. This will make updates and releases of the root pom easier as
for these opperations only a single directory with a single file needs
to be checked out.
If noone objects, I'll change this.
+1
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: Moving root.pom into a sub directory
Carsten Ziegeler wrote: I think we should move the root.pom into a sub directory like parent or pom. This will make updates and releases of the root pom easier as for these opperations only a single directory with a single file needs to be checked out. If noone objects, I'll change this. Can you this instead? svn co -N https://svn.apache.org/repos/asf/cocoon/trunk cocoon-pom Vadim
Re: Moving root.pom into a sub directory
Vadim Gritsenko wrote: Carsten Ziegeler wrote: I think we should move the root.pom into a sub directory like parent or pom. This will make updates and releases of the root pom easier as for these opperations only a single directory with a single file needs to be checked out. If noone objects, I'll change this. Can you this instead? svn co -N https://svn.apache.org/repos/asf/cocoon/trunk cocoon-pom This would only solve the checkout problem. But a release of the root pom would (checkout and more important) tag the whole tree. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Moving root.pom into a sub directory
Carsten Ziegeler wrote: Vadim Gritsenko wrote: Carsten Ziegeler wrote: I think we should move the root.pom into a sub directory like parent or pom. This will make updates and releases of the root pom easier as for these opperations only a single directory with a single file needs to be checked out. If noone objects, I'll change this. Can you this instead? svn co -N https://svn.apache.org/repos/asf/cocoon/trunk cocoon-pom This would only solve the checkout problem. But a release of the root pom would (checkout and more important) tag the whole tree. In this case no objections! Vadim
Re: Webapp does not run in trunk...
Gustavo N. Fernandes wrote: After doing a clean checkout and mvn -Dmaven.test.skip=true -P allblocks install mvn jetty:run on webapp dir the webapp does not launch at all, giving a 503 error on browser. The errors occurs in blocks database and forms. This is strange - it starts and works here for me, and I also run it with all blocks. Does anybody else see this problem? Could it be a problem with Maven version - which one do you use? Vadim Gustavo Vadim Gritsenko wrote: Gustavo N. Fernandes wrote: ...because a dependency in database block's pom is missing and also a getter in LibraryManagerImpl Can you point what samples are not working, which are fixed by this patch? Thanks, Vadim
[jira] Created: (COCOON-2137) XSD Schemas for CForms Development
XSD Schemas for CForms Development -- Key: COCOON-2137 URL: https://issues.apache.org/jira/browse/COCOON-2137 Project: Cocoon Issue Type: New Feature Components: Blocks: Forms Reporter: Gabriel Gruber Priority: Minor A common pitfall in developing cforms applications is the misuse of certain cforms tags. A schema for the forms files (definition, binding, template) would greatly help in writing forms code faster and more accurate and minimizing syntax errors in the first place. I have started writing such schemas for the binding and definition files and added notations out of the current (2.1.10) cforms documentation. those schemas are quite completet (well almost). I also added starting points for this schemas: - i18n transformer - jx template generator furthermore form template generator (and form instance) would be interesting. the major problem with the template is that we are heavily mixing different xml gramars here and state-of-the-art xml editors (like oxygen) have their problems with providing auto-complete features here. the code-completion (assistance) feature for the form-definition and form-binding works quite well. it also has the added benefit, that the important bits of the cocoon forms docs are being displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2137) XSD Schemas for CForms Development
[ https://issues.apache.org/jira/browse/COCOON-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabriel Gruber updated COCOON-2137: --- Attachment: clean-xsd-public.zip XSD Schemas for CForms Development -- Key: COCOON-2137 URL: https://issues.apache.org/jira/browse/COCOON-2137 Project: Cocoon Issue Type: New Feature Components: Blocks: Forms Reporter: Gabriel Gruber Priority: Minor Attachments: clean-xsd-public.zip A common pitfall in developing cforms applications is the misuse of certain cforms tags. A schema for the forms files (definition, binding, template) would greatly help in writing forms code faster and more accurate and minimizing syntax errors in the first place. I have started writing such schemas for the binding and definition files and added notations out of the current (2.1.10) cforms documentation. those schemas are quite completet (well almost). I also added starting points for this schemas: - i18n transformer - jx template generator furthermore form template generator (and form instance) would be interesting. the major problem with the template is that we are heavily mixing different xml gramars here and state-of-the-art xml editors (like oxygen) have their problems with providing auto-complete features here. the code-completion (assistance) feature for the form-definition and form-binding works quite well. it also has the added benefit, that the important bits of the cocoon forms docs are being displayed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Webapp does not run in trunk...
Vadim Gritsenko wrote: Gustavo N. Fernandes wrote: After doing a clean checkout and mvn -Dmaven.test.skip=true -P allblocks install mvn jetty:run on webapp dir the webapp does not launch at all, giving a 503 error on browser. The errors occurs in blocks database and forms. This is strange - it starts and works here for me, and I also run it with all blocks. Does anybody else see this problem? Could it be a problem with Maven version - which one do you use? Vadim Maven version: 2.0.7 Java version: 1.6.0_02 OS name: linux version: 2.6.22-gentoo-r2 arch: i386 []s Gustavo
RE: COCOON-1978
The problem is that the JexlContext jc returns a java.util.Map vars via its method getVars() from which the expression.evaluate method gets its variables via vars.get(key). As a Map returns null, if the key does not exist in the Map, there is no way to distinguish between a variable with a null value and a non-existent variable. A possible way to solve this is to write an own implementation of the JexlContext returning an implementation of Map which throws an exception for non-existent keys. Note however that this is not in accordance with the Java API for the Map interface. The thing is that the JexlContext returns a Map of variables i.s.o. implementing an own get(var) method, which does the job and which can easily be overridden. This would also make it a lot easier to implement lazy evaluation of variables. Another possibility would be to change the Jexl implementation, but that would require some more effort. Rob Berens -Original Message- From: Leszek Gawron [mailto:[EMAIL PROTECTED] Sent: woensdag 3 oktober 2007 11:32 To: dev@cocoon.apache.org Subject: COCOON-1978 https://issues.apache.org/jira/browse/COCOON-1978 this pure JEXL code: // mistaken variable name String jexlExp = fuu; org.apache.commons.jexl.Expression expression = ExpressionFactory.createExpression(jexlExp); // Create a context and add data JexlContext jc = JexlHelper.createContext(); jc.getVars().put(foo, new Foo() ); // Now evaluate the expression, getting the result Object o = expression.evaluate(jc); System.out.println( o ); actually produces null when no foo variable is found in context instead of throwing. JEXL javadoc does not show any direct method to change this behaviour. Is there anything we can do? -- Leszek Gawron http://www.mobilebox.pl/krs.html CTO at MobileBox Ltd.
Re: svn commit: r581188 [1/9] - in /cocoon/site/site: ./ community/ css/ devinfo/ images/ images/logos/ link/ news/
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
publish new 'pmc site'
Added:
cocoon/site/site/1164_1_1.html (with props)
cocoon/site/site/1178_1_1.html (with props)
...
Just wondering - do we have any of old URLs preserved? Or htaccess
redirects for old URLs?
no, unfortunatly not.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Cocoon web cache
Hello everybody! I developed a portal using cocoon (i love cocoon :-D). Now i need to configure something that can help to caching pages Do you now something about this question? Do you know if cocoon support web caching and in which way??? many thanks!!! -- View this message in context: http://www.nabble.com/Cocoon-web-cache-tf4562544.html#a13021482 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: Still fighting with Continuum
Grzegorz Kossakowski wrote: Hi Cocooners! Could people being moderators for our list (dev) take a look at this[1] comment? Emaanuel claims that e-mail should arrive to our list but I do not see it. Is it my omission? [1] https://issues.apache.org/jira/browse/INFRA-1316#action_12532051 I have not received any mails from continuum for moderation. It must be stuck somewhere else higher up. Jorg
