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

[Jim Idle]

Upgrade toplink is your best bet and the one most likely to work, or implore
the authors to do so, or download stringtemplate source and build it
yourself having changed dependencies (but that may not work).

 

Jim

 

From: stringtemplate-interest-bounces at antlr.org
[mailto:stringtemplate-interest-bounces at antlr.org] On Behalf Of Taille,
David
Sent: Wednesday, November 17, 2010 12:59 PM
Cc: stringtemplate-interest at antlr.org
Subject: Re: [stringtemplate-interest] StringTemplate and toplink using
incompatible versions of antlr

 

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/e4bfa6c1/attachment.html