Bug 150274 - new server file template fails to add servlet-api on project classpath
new server file template fails to add servlet-api on project classpath
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: Code
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Milan Kuchtiak
issues@javaee
MAVEN
: API, API_REVIEW_FAST
: 153787 (view as bug list)
Depends on:
Blocks: 89008 153787
  Show dependency treegraph
 
Reported: 2008-10-15 18:57 UTC by Milos Kleint
Modified: 2010-01-12 02:12 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
suggested api change along with implementaion (20.99 KB, text/plain)
2009-01-06 13:55 UTC, Milos Kleint
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2008-10-15 18:57:42 UTC
the servlet file template (and possibly other templates) shall check if servlet-api jar classes are on classpath and if
not, then add it.

primarily an issue for maven based projects that don't have (and cannot have) app server bits on classpath and often
don't even have an app server associated.
Comment 1 Jayashri Visvanathan 2008-11-26 01:39:30 UTC
Changing to an enhancement request when we are ready for full maven support
Comment 2 Milos Kleint 2008-11-26 06:14:44 UTC
please reevaluate, the maven support becomes part of standard distribution this week, therefore creating a servlet and
get compilation error is a bug.
Comment 3 Milos Kleint 2008-11-26 07:52:56 UTC
a P2 issue #153787 either depends on this one or is duplicate
Comment 4 Matthew Bohm 2008-11-26 17:12:39 UTC
I'm taking over servlet from scratch, so mkleint please give more detail (as much as possible) about where the change
needs to occur. (We also may want to discuss offline.) Marking incomplete.
Comment 5 Milos Kleint 2008-11-26 19:17:56 UTC
there needs to be some kind of procedure/api that will instruct the maven support that servlet-api (or other j2ee api)
needs to be added on classpath at the moment of finishing the new file wizard for servlet and other j2ee templates.

The primary actor here is the wizard iterator of the servlet template (or other templates) which need to identify the
project that the file is being added to and act accordingly (make sure the project is compilable after the file template
is created)

An pre-existing solution to the problem is ClassPathExtender/ClassPathModifier api. 
+ a generic solution, tested to work
- servlet.jar is not a library and we need one according to the j2ee level (right?)

Another approach could be to create a new api that would maven projects implement and the template iterator call.
Something that would intstruct maven projects to add dependencies on classpath.

eg. 
interface J2eeContainerEnhancer {
    void enhancej2eeEnvironment(<enumeration of technologies to support>);
}

we can chat about the solution offline via phone if you prefer.
Comment 6 Matthew Bohm 2008-11-26 22:16:28 UTC
According to mkleint, this is for 7.0. So changing target milestone.
Comment 7 Petr Jiricka 2008-11-27 09:31:09 UTC
Cc'ing also Milan and Trey. I think Milos's idea with J2eeContainerEnhancer is reasonable. This would be useful not only
for the servlet wizard, but also in other cases:
- Other wizards, such as JSP, Tag file, Taglib descriptor, Filter, WebApp Listener etc.
- Web frameworks: when adding a web framework to a project, it is reasonable to add servlet/JSP API to the project classpath
Comment 8 Milan Kuchtiak 2008-11-27 10:38:30 UTC
The issue is related to most of the web wizard templates, including :

- servlet
- filter
- servlet listener

Some of them reqires servlet.jsp API (e.g. tag handler)

Note some of the wizards are not even working due to missing servlet.api on classpath
(e.g. Web Application listener wizards)

Increasing priority to P2
Comment 9 Milan Kuchtiak 2008-11-27 10:40:02 UTC
*** Issue 153787 has been marked as a duplicate of this issue. ***
Comment 10 Trey Spiva 2008-12-01 16:33:21 UTC
I also see the benefits of 3rd party modules to enhance the a projects classpath.  However I do not see what the J2eeContainerEnhancer will provide over 
using the  ClassPathExtender/ClassPathModifier.  Well I do see one thing,  the Enhancer would first check if the jar file is currently in the classpath before 
adding the jar to the classpath.  But that sounds like how the ClassPathExtender/ClassPathModifier should work.
Comment 11 Milos Kleint 2008-12-02 15:26:53 UTC
classpath modifier/extender requires all the jar files to be shipped with netbeans for all the j2ee versions.
eg. 3 servlet-apis etc. The suggested api will work with symbolic token and will allow maven support to place the
correct jars on the project's classpath.

Comment 12 Trey Spiva 2008-12-02 19:25:49 UTC
Wouldn't be better to update the modifier/extender to handle these usecases?  The reason I ask is that this requirement sounds like something that will be 
needed by most projects.  
Comment 13 Milos Kleint 2008-12-03 10:08:26 UTC
one of them is deprecated, the other one could be possibly used. I suggested a special api as the j2ee server specific
jars are the only usecase now (together with maven projects)

One thing I forgot to mention. On my side I need to learn that the jars are part of the j2ee server somehow as I need to
prevent the jars to be part of the war file. That's done by defining a dependency scope of "provided".
Comment 14 Matthew Bohm 2008-12-11 23:20:16 UTC
mkleint and I spoke offline. The current plan--with the details still preliminary--is that he will add a new abstract
class to the org.netbeans.spi.java.project.classpath package (in the java.project module) similar to the
ProjectClassPathModifierImplementation class in that package. The new class will specify one or more methods whereby new
resources can be added to the classpath, but instead of accepting a Library[] or URL[]/URI[], the methods will accept a
String name or String[] of names representing the resources to be added. He will also write a new concrete class that
extends this new abstract class; the concrete class will live in one of the maven modules. Also, he will write one or
more methods for use by clients (such as the web.* modules) that accept a String name or String[] of names representing
the resources to be added; he will likely add these to org.netbeans.api.java.project.classpath.ProjectClassPathModifier.
Accordingly, I will make calls into the new client methods to add the servlet api and any related resources whenever the
user adds a new servlet, servlet filter, or jsp to a maven project.

We welcome any input on this plan, and, as previously mentioned, the details are preliminary. mkleint will begin this
work in January or potentially February.

mkleint, let me know if I got any of this wrong.
Comment 15 Petr Jiricka 2008-12-12 07:19:35 UTC
> I will make calls into the new client methods to add the servlet api and any related resources whenever the
> user adds a new servlet, servlet filter, or jsp to a maven project.

This is one case, but I believe that this API should also be used when creating a new Web-Maven project from scratch, so
it works out of the box, even if I don't create the web components using NetBeans wizards.

Comment 16 Milan Kuchtiak 2008-12-12 08:49:33 UTC
In new web archetepes (J2EE 1.4 and java ee 5), proposed by mkleint, servlet api is there.
I'd also add servlet.jsp API otherwise any simple JSP code will be error badged, e.g. :

 <% out.println("Hello World"); %>   
Comment 17 Milos Kleint 2009-01-06 08:57:10 UTC
reassigning to myself
Comment 18 Milos Kleint 2009-01-06 13:55:45 UTC
Created attachment 75492 [details]
suggested api change along with implementaion
Comment 19 Milos Kleint 2009-01-06 14:04:51 UTC
I've added the new api to the j2ee.core.utilities module. it's advantage is that it's a friend api module (thus limits
scope and eases the compatibility constraints) and is used by almost all j2ee modules already. it has only a few
dependencies of it's own which is a plus too.

I've added the api, implemented it for servlet-api and jsp-api apis in the maven modules and web.core module uses the
api for servlet and taghandler file templates.

please review
Comment 20 Milos Kleint 2009-01-12 06:49:38 UTC
thanks for review, I will integrate shortly
Comment 21 Milos Kleint 2009-01-12 07:28:56 UTC
http://hg.netbeans.org/main/rev/9f1dc4721536

mbohm, please proceed with evaluation of other templates and adding the boiler place code in teh template iterators. If
you figure you need more than servlet-api and jsp-api, let me know
Comment 22 Quality Engineering 2009-01-12 17:33:24 UTC
Integrated into 'main-golden', will be available in build *200901121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/9f1dc4721536
User: Milos Kleint <mkleint@netbeans.org>
Log: #150274 add a new friend contract between project type (maven) and the file generating codebase to notify the projecttype to add certain application server apis on project's classpath.
implemented the interface in maven.j2ee and used it in web.core's Servlet and Taghandler file templates
Comment 23 Vince Kraemer 2009-02-04 14:48:43 UTC
prepare for replan
Comment 24 Milan Kuchtiak 2009-04-02 16:03:30 UTC
AFAIK, all wizards in web category, EJB category and persistence category were implemented to use this API.
I consider this particular API issue completed.

I also reported 2 tasks for SOAP and REST services wizards to implement this API:
issue 161782
issue 161783


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo