This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 59269 - Make j2ee platform libraries available for any project
Summary: Make j2ee platform libraries available for any project
Status: NEW
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Petr Hejl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-26 09:07 UTC by llturro
Modified: 2007-08-30 17:34 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description llturro 2005-05-26 09:07:19 UTC
I'm keeping tag-libraries and subsystem libraries appart from the main web
application. Currently they are defined with the generic 'Java Library', despite
being 'Web Modules'. In order to compile for the servlet API I need to manually
create a ServletJSP library, pointing at both APIs in bundled Tomcat. This
library definition is hardly attached to NB intallation folder, therefore,
updating means redefining the library.

Being this a common scenario, why Bundled Tomcat isn't exposed as a library? It
would facilitate the creation of those 'Web Modules', making them portable among
NB versions. Do I miss something?
Comment 1 Tomas Zezula 2005-05-26 09:39:24 UTC
Wrong module, reassigning.
Comment 2 zikmund 2005-05-26 10:27:54 UTC
What to do in case that you deploy your WebApp to SunAppServer? Should we
compile against Bundled Tomcat or AppServer JAR files?

I would prefer add possibility to add 'All server JAR files' of any server to
Java project classpath (if possible).
Comment 3 llturro 2005-05-26 11:10:46 UTC
Not bad, but it doesn't change the fact. You could compile using Bundled Tomcat
library and deploy into SJSAS, JBoss, etc. Using Bundled Tomcat keeps easy
adding servlet and JSP APIs. Maybe 'Bundled Tomcat' isn't the right name and
changing that to 'Servletx.x/JSPx.x' would be a better idea. Or even better,
moving those apis out of Tomcat and back to a standard library. The real thing
is that we want both APIs available, not the implementing container.
Comment 4 rayjhax 2005-05-31 20:25:09 UTC
Would someone please explain clearly how to make this transision to use Bundled Tomcat on libraries 
which which previously used the jsp20 and servlet24 libraries, so we can start using the released 
version of 4.1.  I have asked in the nbusers forum and gotten zero response.  I don't care if I have to 
slightly change the project settings.  The project was created as a simple java jar, which used these 
libraries to implement a taglibrary.  The only option I can think of that we are left with is making binary 
copies of the servlet and jsp libraries in an extra directory in the project.  Why should this be necessary?  
It clearly is not a web project itself since it has no web pages, etc. and should be bundled as a jar, not 
as a war.  It gets used by multiple other web applications.  I see no explanation of how to carry forward 
here.  How would I compile using Bundled Tomcat Library, when it does not appear in the library list 
(short of manually adding it as a library on the machine of every user).
Comment 5 rayjhax 2005-05-31 20:43:36 UTC
I work from Linux, Mac, etc. and experience the problem so I have changed Platform and OS to All.

This also works fine in the beta version and is preventing us from using the final release, which I would 
have thought was a regression, rather than a feature request, but I'll leave that up to the judgement of 
someone else, maybe something removed between beta and final release can be rationalized as a 
misfeature of the beta (I sure miss the feature :-).
Comment 6 llturro 2005-06-01 10:21:44 UTC
rayjhax, to workaround this problem with servlet/jsp apis, i created a new
library with
[NBInstall]/netbeans-4.1/enterprise1/jakarta-tomcat-5.5.7/common/lib/servlet-api.jar
and jsp-api.jar. Because this path depends on NB version, I copied those
libraries into a generic folder and build up the library from there.
Comment 7 Sherold Dev 2005-06-01 10:53:22 UTC
Rayjhax, I would also recommend you the same workaround.

Marking as 4.2-candidate and moving to j2eeserver.
Comment 8 rayjhax 2005-06-01 16:02:05 UTC
As I began to indicate before, I believe this would involve forcing every user to perform the library 
addition manually whenever they reinitialize the program's settings (it tends to corrupt itself fairly 
frequently), which is not a reasonable option.

The library feature seems completely worthless to me (at least I have not discovered how to make it 
useful) for this reason, except for useful libraries that come pre-installed, (none left in 4.1 final 
release).  If there is a better way to use the libraries option than that, I need a clear explanation of how 
since they do not seem to me to be stored in any part of the settings that are reasonable to share 
between users (especially users of different platforms) at least last time I tried to define them.  That is 
why it is so important to have basic ones defined at installation for standard things such as jsps and 
servlets that are supplied as part of the package anyway.
Comment 9 zikmund 2005-08-16 17:32:02 UTC
Won't be part of 4.2 - it needs non-trivial changes in Libraries management. It
is not still clear how to solve it.