Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

tld placement to support JSP 1.1 and 1.2  RSS feed

 
Jim Stoll
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've got a custom tag library that can/will be used in both 1.1 and 1.2 environments. In the past (JSP 1.1), I put taglib.tld in my JAR file's META-INF directory and then ref'd the JAR directly in the JSP taglib directive or indirectly via a web.xml taglib mapping. I'd now like to package up both a 1.1 and 1.2 version tld though, so that 1.2 folks can use auto-discovery, etc - but don't think that I can put both taglib.tld (1.1 DTD, generically-named) and MySuperTagLib.tld (same library, but 1.2 DTD, specifically named) under META-INF, as I worry that a 1.2 environment will discover both, leading to some conflict or confusion or other. #1, is there some mechanism in place that will resolve such a situation for me? #2, if not, what is the 'standard' approach? I'd rather keep the tld packaged up in the JAR vs making users pull it out and put it somewhere under the HTML root directory...
Thanks for any help/info!
Jim
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do they have different URIs?
 
Jim Stoll
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, that's sort of part of my question - I can set them up w/ different URIs (though I haven't found the taglib/uri element in the tld in the 1.1 environment to have any effect, at least not in Oracle9iAS/OC4J...), but ideally, I'd like someone to be able to treat/use the library transparently between 1.1 and 1.2. (which, in its simplest form, means that I should probably just stick w/ a 1.1 tld, generically named taglib.tld and placed in META-INF, I suppose...)
I just haven't been able to find anything on this (and I've looked pretty far and wide, maybe I'm blind?!?!?), so am wondering what others do, and if there's some 'standard' approach?
Thanks,
Jim
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66141
141
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The stanrdard approach is to give them differing URIs. JSTL 1.0 and JSTL 1.1 for example, have different URIs so that they do not conflict.
As for making your web app completely version-transparent, that's usually not possible unless you do the lowest-common-denominator approach since the web.xml files will have different DTDs.
So to support JSP 1.1 and JSP 1.2 (1.1? pretty ancient -- you should actually be coding to JSP 2.0 at this point), you either need separate web.xml files (where you can take care of your TLD differences), or code everything to 1.1.
Personally, with an ant build script there's no reason that you cannot easily build different war files for the 1.1 vs. 1.2 (vs. 2.0) environments. This will save lots of headaches over trying to get the exact same war file to operate under different specification levels.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hmm, I'd love to code to 2.0 but how to get the company to switch development from a 1.2 container to a 2.0 container?
Had to fight hard enough (well, be sneaky enough really to go ahead and implement it) to get JSTL 1.0 accepted (noone'd ever used it before...).
That's the reality out there. There's a lot of platforms that are restricted to older technology for whatever reason.
Reasons I encountered in the field:
- corporate policy dictating to never use the latest tech. Worst case example I encountered in the field was a company where the board had decided to always use the second last service level of the second last minor version of the second last major version of any product.
So for example they were just migrating from NT3.5 to NT4SP3 when Microsoft introduced XP Pro...
- vendor lockin and the vendor doesn't provide the latest version (yet).
- lack of funding to upgrade to a later release (especially for smaller companies this can be a major problem if the upgrade costs tens of thousands).
- need to support customers using older versions who don't want to or cannot upgrade to the latest and (supposedly) greatest for whatever reason.
 
Jim Stoll
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that ideally I'd be coding to 2.0, but the reality is that many of my customer's production environments are JSP 1.1 environments (Oracle 9iAS 9.0.1/2/3), and moving to a 1.2 environment (9.0.4, aka 10g) isn't on most of their immediate priority lists - 2.0 isn't even on most of their horizons - so I muddle through w/ the 'old' stuff - that's just the real world... (I wish that I could pick and choose only those customers who eat, breathe and live J2EE, but most of them seem focused on other things - making products, money, etc... ;-)
So what I'm hearing is that I should build a MyCoolTaglib_1_1.jar and a MyCoolTaglib_1_2.jar, w/ the tld named/placed in the JAR as appropriate for the JSP version, and if/when a customer upgrades from a 1.1 to a 1.2 JSP environment, move to the 1.2 library (if needed...), as there's no real established means of having a tag JAR that contains both a 1.1 and 1.2 version tld, is that correct? (And then I presume that the smartest thing to do is to use a web.xml taglib declaration so that I only have to change one thing if/when they 'upgrade' the tag library?)
Thanks for everyone's help/input!!
Jim
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!