[stringtemplate-interest] StringTemplate and toplink using incompatible versions of antlr

[Taille, David]

Hi all,

I'm considering using StringTemplate v3 within a JEE application to build mails and other human-readable pieces of text, but from within a business logic layer (as opposed to the presentation layer).
The app uses EJB for all non-presentation layers ; those that do database accesses use toplink 10, which internally uses antlr 2.7.2.

If I use StringTemplate (which uses antlr 2.7.7) in EJBs where toplink is not used, everything is ok -- EJB classloaders are setup in the appServer so that everyone sees the "right" antlr...

But if I try to use StringTemplate in a toplink-aware EJB, most time toplink's antlr get loaded first (due to the peculiars of our use cases), and I get errors when using StringTemplate because it doesn't see 2.7.7 antlr...
--> So I must be very very careful about where we'll use the templating engine.

(Of course, I'm not willing to upgrade toplink's antlr since I have no garantee this wouldn't break something somewhere)
(also, ditching toplink is not an option)

More over, we also have to "package" some parts of our app in a JSE context, where we don't have one classLoader per component (i.e. EJB).
Using StringTemplate v3 as is would not work properly in that case.

The bottom line is : I hesitate to opt for StringTemplate because of antlr conflicts issues.

I guess I could :
a) use a version of StringTemplate that is old enough to cope with antlr 2.7.2
     -- tried it, apparently works, but... sad to get stuck with an old lib!

b) wrap StringTemplate and antlr 2.7.7 in a small library we would write and use a custom class loader in there to explicitly pick the right antlr flavor
   -- quite an unusual piece of code in the middle of an otherwise "normal" application
   + raises deployment and configuration issues *or* leads to uncomfortable assumptions on where the right classes live

c) rebuild a version of StringTemplate where antlr 2.7.7 packages would be e.g. suffixed by "277" : antlr.* --> antlr277.*

Since antlr is quite a common framework, I thought perhaps my problem could be quite common also, which would --maybe ;-) -- let ST maintainers consider doing c) themselves, once for all of us ...
What do you think about that ? Am I way too demanding ;-) ?

Any other idea to help me keep off FreeMarker ?

Thanks for your time.
David



Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20101117/6e50565a/attachment.html