Nice idea. BTW: why not to add also common/classes with possibility to
copy&paste classes?

OTOH besides the UI we also need API. Something like 

public interface TomcatCustomizer {
  /** This methods is called before server is started and
    * allows to perform customization such as adding libraries.
    */
  public void customizeInstallation (TomcatXInstallation install);

  /** This methods is called before web app is deployed and
    * is intended as a callback that can do additional setup.
    */
  public void customizeInstance (TomcatXInstance install);
}

Then we can use bridges (eager modules) for interaction with Tomcat.

I agree this is a good idea. I only don't understand how 
tag libraries can be put into the shared directories. How 
will then the apps discover these taglibs ? Isn't there 
something else needed which tells the app about the 
taglib ? 

See also: 
- JSP 2.0 spec proposed final draft, sections 7.2 and 7.3

- http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-
loader-howto.html

Hi all, 




glad you like it! 




As for the tag library question, the TLD must be present in 
the web module for the JSPs to be able to locate it, but 
the tag handlers can be anywhere on the server. So a common 
design pattern is to extract the TLD into say WEB-INF/tlds. 
Then you can put the jar handler in a shared location on 
the server, to avoid bloating the web app, and to make it 
easier to upgrade the tag library if there is a bug fix in 
a tag handler. 




It's unfortunate that the TLD still needs to be inside the 
web module (I've seen quite a lot of developer feedback on 
this) so it'd be good if the next rev of the spec has the 
JSP compiler provide a shared location for TLDs also.

I put my TLD file in the jar.  Place it inside the META-INF "folder" and reference it as 
follows:

<%@ page language="java" errorPage="/error/error.jsp" %>
<%@ taglib uri="/myTags.tld" prefix="ms" %>

The name of the jar file is myTags.jar, but it's seen above as .tld.  I have no idea why 
this works, but Tomcat 3 and up is happy with it while NetBeans is not.  (JBuilder 
supports it, why not NetBeans?  :)

Oops.  My mistake.  You have to have this in web.xml in order for it to work:

  <taglib>
    <taglib-uri>/myTags.tld</taglib-uri>
    <taglib-location>/WEB-INF/lib/myTags.jar</taglib-location>
  </taglib>

And the TLD must have the path in the jar of "/META-INF/taglib.tld" in which case it 
works just fine in NetBeans to use:

<%@ page language="java" errorPage="/error/error.jsp" %>
<%@ taglib uri="/myTags.tld" prefix="ms" %>

Glad I remembered.

Hi Inertia, 

I think you may have misunderstood the reason that this 
issue was filed. We are concerned with supporting 
developers who for various reasons do not want to put the 
jar with the tag handlers inside the web module itself (or 
for that matter other libraries that developers may wish to 
share between different web modules without deploying them 
into each). 

To Petr and Radim, for what it's worth I have been informed 
that since Tomcat 5 (or perhaps Jasper 2) my last comment 
that the TLD needs to be in the web module is no longer 
true. The whole tag library jar can be in a shared 
location, provided the taglib directive must have its uri 
attribute set to the value of the URI element in the TLD.

I tried what Ana said that Tomcat 5 allows putting taglibs to shared
locations, and I can confirm it works. Tried with the mailer tag
library, which needs 7 additional jars. I put the libraries to
Tomcat's shared/lib directory, and it worked.

I suggest the following sketch of a solution for NetBeans 4.0 (Projects):

- All libraries used by the web module (even those that are placed in
common/lib and shared/lib) will be required to be registered as the
project's resources. That way, they will be available to the compiler

- Each deployment profile will be able to specify, which libraries
should be used in which way. This may be dependent on the target
server instance, selected for this profile. So for Tomcat, the options
would be:
i. Place in WEB-INF/lib
ii. Place in common/lib
iii. Place in shared/lib
iv. Do not deploy (applicable if it is assumed that the library is
already on the server)

Items i. and iv. are common to all servers, the ones in between are
server-specific. For each library, there is UI, which chooses one of
these options.

(this UI is really Radim's idea, we just talked about it over lunch)

Suggestion sounds fine to me. 

I believe I saw some proposal for the resources where the 
project resources tab provided the options of deploying 
with the web module and deploying to the server. This of 
course does not allow us to differentiate different 
mechanisms for deploying onto specific servers. 

I don't feel strongly about either approach. The one you 
suggested might require a bit more knowledge on behalf of 
the user - one could perhaps argue that all users care 
about is *that* the library is deployed on the server, not 
how it got there. 

What are the plans for production builds - are they done 
with respect to a particular deployment profile? Or is the 
inclusion of libraries in a production build handled at a 
separate stage, a la war packager? 

Adding Pavel to cc, as I'd like to know his opinion. What Ana writes
actually is a problem, meaning that the solution I proposed won't
work. If a jar is to be copied to WEB-INF/lib, then this must be done
at build time, not at deploy time. Currently, building the app is not
server-specific, so there has to be a server-independent setting for this.

So whether the jar should be copied to WEB-INF/lib must be settable
either in the project's Resources, or in the Build Steps.

Maybe the customizer of the resource:
http://ui.netbeans.org/usability/April_21_03/recommendations.html#resources_cp_dialog
could specify this, either directly in this dialog, or in the dialog
which appears after you click the "Edit..." button.

Component owner changed

FYI: there should be an API in j2eeserver module to allow modules to
expose a list of libraries they want to deploy to a server and an api
for server to actually deploy them.

I cannot make this one in 3.6, let's get back to it in future.