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 73353 - allow different spec versions for different module types
Summary: allow different spec versions for different module types
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 5.x
Hardware: All Windows XP
: P3 blocker (vote)
Assignee: Pavel Buzek
URL:
Keywords:
Depends on:
Blocks: 73354
  Show dependency tree
 
Reported: 2006-03-07 20:26 UTC by Pavel Buzek
Modified: 2006-04-04 22:39 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Buzek 2006-03-07 20:26:56 UTC 
I am asking for a review for a backward compatible API change. It was already
reviewed by the netbeans J2EE team.

There is a problem with JBoss server which supports EJB3 but not for Web 2.5.

Generally you can take some EJB container and put it together with a Web
container that complies with another J2EE spec version (JBoss | Genronimo |
JOnAS + Tomcat | Jetty). It does not comply with the spec but it works.

Currently there is no way to express this and the result is that the IDE will
let you create a 2_5 web module for jboss and try to deploy it but it will not
work (e.g. injection does not work). Also a 1.5 EAR file can be created and it
will create a 2_5 web app - again, will not work.

I propose to a new method. It will have no impact on plugins that do not
implement it.

    /**
     * Return a list of supported J2EE specification versions for
     * a given module type.
     * Use J2EE specification versions and module types defined in the {@link
org.netbeans.modules.j2ee.deployment.devmodules.api.J2eeModule}
     * class.
     *
     * Implement this method if the server supports different versions
     * of spec for different types of modules.
     * If this method is not implemented by the plugin the IDE
     * will use the non parametrized version of
     * getSupportedSpecVersions.
     *
     * @return list of supported J2EE specification versions.
     */
    public Set <String> getSupportedSpecVersions(Object moduleType) {
        return getSupportedSpecVersions();
    }
Comment 1 Pavel Buzek 2006-03-07 20:29:20 UTC 
target 5.5
Comment 2 _ ludo 2006-03-07 20:42:35 UTC 
At a spec level (support for Java EE 5 specification), I would oppose to this
change (or hack) in principle, since it helps App Server vendors to not fully
implement the features and still benefit from the grey area in term of product
positioning.
In any case, I think a review from the Java EE 5 spec leads and Nb Marketing
management is a must since it has a impact (maybe legal as well) on the J2EE and
Java EE 5 name branding. Make sure their views on this are captured somewhere.
Eventually, JBOSS will be Java EE 5 compliant (maybe soon), so this API change
will not be needed at all.
Comment 3 Pavel Buzek 2006-03-07 21:10:16 UTC 
This is an API review, please keep the comments at a technical level. There is
an existing situation that we have to face. Jboss 4.0.3 was release a long time
ago and we are not going to get web 2.5 into it. If you have an alternative
proposal for how to solve it I would like to hear it. If you want to speak to
marketing about support of jboss or to j2ee spec leads about jboss support of
web api 2.5 please do not use this issues.
Comment 4 Sherold Dev 2006-03-08 15:17:51 UTC 
The proposal looks OK to me.
Comment 5 Vince Kraemer 2006-03-08 19:18:59 UTC 
q: where is this method being added?  I cannot tell.

c: politics aside, would this be a good place to call out the finer-grain specs
and tools supported by the server for a module type?

For example: haven't we had issues where a server might support JAX-WS 2.0...

The return value for this proposed API is a might broad brush when we already
have use-case where we need to do some detail work anyway.

c: this proposal is trying to cover up the fact that we are treating two servers
as a single entity...
Comment 6 Pavel Buzek 2006-03-08 19:43:01 UTC 
> q: where is this method being added?  I cannot tell.

The method would go in:
org.netbeans.modules.j2ee.deployment.devmodules.api.J2eePlatorm
and
org.netbeans.modules.j2ee.deployment.plugins.api.J2eePlatformImpl

> c: politics aside, would this be a good place to call out the finer-grain
> specs and tools supported by the server for a module type?
> For example: haven't we had issues where a server might support JAX-WS 2.0...
> The return value for this proposed API is a might broad brush when we already
> have use-case where we need to do some detail work anyway.

The method I proposed covers different spec versions of different module types.
There are methods in J2eePlatform and J2eePlatformImpl for supported tools, java
platform, classpath, etc. If you see a need to have any of them different for
different types of modules then you should probably create a variant of these
other methods that takes module type as a parameter.

> c: this proposal is trying to cover up the fact that we are treating two servers
> as a single entity...

Depends on what you call a "server", but I do not think these are different
servers. A server can have multiple containers. Jboss uses tomcat as a web
container, but you start a jboss, you do not explicitly start each container.
You deploy to jboss, not explicitly to tomcat. So in some way it is one server.
Same like glassfish has an ejb container and a web container. We have been
treating this as one server. I do not see a reson to change that.
Comment 7 Pavel Buzek 2006-04-01 04:02:36 UTC 
Thanks for review. Since I do not see any disagreement about the technical
solution I will apply the proposed change.