Trails

Ken, can you elaborate on this?
What exactly is not working?

Please excuse the delay(s) I have been pre-empted.

This bug replicates the awaited OGNL issue.

It appears expression compiler is broken for OGNL.

I logged this bug to try and generate some fluff surrounding it's impact on trails but either way the solution remains with OGNL.... trails is fine.

Our OGNL logic has been taken out by OGNL expression compiler bugs.

My workaround was tyo turn off tapestry caching to off

I rigged my eclipse jvm with this

-Dorg.apache.tapestry.disable-caching=true

see final comment on this ...
http://jira.opensymphony.com/browse/OGNL-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_31169

But our web app is at a crawl with caching off... but OGNL seems to work.

Expression compiler is hosed... until a patch comes.

We can close this but it points to the impact and details... it's your call.

welcome back

Strange... even though I am operating at KALLE's ognl rev and other pom rev's... with caching turned off... I did happen to receive an exctraneous classcastexception that I did not see before. So there may be transient pot holes whereby ognl fails even with caching disabled.

The main construct that flushed this out for us was the extra <DIV> placed in ObjectTable.html in order to generically detect a BLOB and render it as an image in the table column.

That was the construct that flushed out the OGNL issue. It seemed that OGNL could not articulate across multiple <DIV> tags... which happens to be the manner in which you recommend folks to implement custom editors.

OGNL could not operate expressions within the 2nd DIV... see below.

<table jwcid="table">
<div jwcid="linkColumnValue@Block">
<a jwcid="editLink@EditLink" model="ognl:object" href="#"><span jwcid="linkInsert@Insert" value="ognl:objectthis.linkProperty"/></a>
</div>

<div jwcid="blobColumnValue@Block">
<!-- render if the descriptor supports and actually has a blob -->
<span jwcid="@If" condition="ognl:column.propertyDescriptor.supportsExtension(@org.trails.descriptor.BlobDescriptorExtension@class)">
<span jwcid="@TrailsDownload"
descriptor="ognl:column.propertyDescriptor"
model="ognl:object"
bytes="ognl:objectthis.column.propertyDescriptor.name"
/>

</span>
</div>
</table>

This was just a CCE in the AST chain. It has nothing to do with the multiple DIV tags.
The first call to the OGNL expression "page.classDescriptor" is compiled against the ModelPage class, when the same expression is used from HibernateListPage the AST visitor throws a CCE.
The solution was easy, pulling up getClassDescriptor to TrailsPage as an abstract method did the trick.
Fixed in svn rev 737.

I had a request since this is still a bit fresh...

Since trails uses OGNL fairly intensively... and that this problem was due to a base class interface breach.

Alejandro, would you be kind enough to elaborate on the following:

1. Was this issue bad OGNL usage? Or Is this a limitation to OGNL?
2. Can you elaborate on general rule of OGNL usage with base interfaces?
3. Is this a limitations of OGNL expression compiler? Why didn't the expression compiler catch the breach?

Thanks

• Was this issue bad OGNL usage?
  No, it wasn't.

• Or Is this a limitation to OGNL?
  Yes, this is a new OGNL limitation.

• Can you elaborate on general rule of OGNL usage with base interfaces?
  The new 2.7.0 version of OGNL compiles every single ognl expression to executable bytecode. The first time you "invoke" the expression, it is compiled using as a reference the type of the object you use to invoke it. If then, using the same expression, you want to use an object of a different type, you need to share at least a common interface or superclass between the two types to be able to correctly traverse up the AST and cast the statement to the base class or interface the method being invoked is ultimately declared in.

• Is this a limitations of OGNL expression compiler?
  Yes.

• Why didn't the expression compiler catch the breach?
  I don't know, I think that is not that easy to know beforehand, when you are claiming the AST, that you won't find a match. Although the exception error message could be better.