JBossIDE / JEE5 features for JBossAS

[mculpepper]

Hey everyone..

Since there's no dev forum for just the "app server" alone, I'm posting here in the IDE dev forums. I'm looking for a nice wishlist/feature set for what should be in our next-gen server adapter for JBossAS. I am hoping that most of these features will make it into JBossIDE 2.0 by the JavaOne time frame... If it's not doable by then we will probably just defer it to a later release, but any ideas are definately welcome.

Thanks, look forward to the discussion..

[mculpepper]

Just to get it out of the way, the most basic/obvious things we will have:

- An adaptation of WTP 1.0 Server Tools
- Start/Stop JBoss in both Run & Debug modes
- Publishing (Deploy) support
- Simple configuration that supports frequently changed ports, and configuration.
- Server Runtime support for Web apps/EJB3 apps/JSF apps/etc

[starksm64]

Some features I want to see are:

* an ability to create custom jboss configurations ala the installer that can be associated with a project. If I'm just testing a subset of features I can create a minimal configuration that just includes the associated services/jars.

* logical deployment mappings. Instead of actually have to create a ear, ejb jar, war, etc. just define a logical archive that uses the project elements as they are. This is really a configuration of the vfs aspect for the deployment.

* related to both of these is an integration with an optimized metadata representation. We want a notion of a preparsed metadata representation of all metadata associated with a deployment. This includes the annotations, xml overrides, admin configuration, etc. This optimized representation is something that the server just sucks into memory without any parsing. The example of an ide integration is a change to a single annotation in a deployment being updated in the optimized metadata representation so that it does not need to be rebuilt by the server.

[mculpepper]

an ability to create custom jboss configurations ala the installer that can be associated with a project. If I'm just testing a subset of features I can create a minimal configuration that just includes the associated services/jars.

I really like this idea.. does the installer contain some sort of mapping of SAR->service name or is it just statically defined? Also -- it would be nice if the IDE took this a step further and told you when service XXX requires service YYY so you get some level of dependency analysis (i.e.. check EJB3, and the aop jdk5 deployer gets automatically checked)

logical deployment mappings. Instead of actually have to create a ear, ejb jar, war, etc. just define a logical archive that uses the project elements as they are. This is really a configuration of the vfs aspect for the deployment.

This is actually a benefit of moving to webtools. They got rid of the packaging idea and break up a project into "artifacts" which the server adapter is responsible for deploying. This functionality will basically be a superset of the Packaging functionality currently found in JBossIDE 1.5 (although I doubt we will get rid of it because it is still very useful).

related to both of these is an integration with an optimized metadata representation. We want a notion of a preparsed metadata representation of all metadata associated with a deployment. This includes the annotations, xml overrides, admin configuration, etc. This optimized representation is something that the server just sucks into memory without any parsing. The example of an ide integration is a change to a single annotation in a deployment being updated in the optimized metadata representation so that it does not need to be rebuilt by the server.

I also really like this idea -- isn't this something that ON has already tried to solve? also -- we should keep in mind that one of my goals for our new adapter is to be backwards compatible with at the least 3.2 series, so if we can keep any configuration metadata central to the IDE, that would be a huge step for compatibility. thoughts?

[burrsutter]

Something that I never did get working...the hot keys for XDoclet, Packaging and Deployment/Redeployment don't seem to function if your focus is in the editor window. Plus, many IDEs redeploy upon save - Ctrl-S. If I remember correctly JBoss IDE required me to hit Ctrl-S, Ctrl-Shift-F1, Ctrl-Shift-F2 and Ctrl-Shift-F3 (assuming focus was in the right location) do save a change and redeploy.
This could have been user error.
Server Start, Stop, Restart, Debug Start, Debug Stop and Debug Restart are all very important, especially being able to visually see what mode you are in.

Sorry, I was supposed to add this to Jira but didn't.

Burr

[starksm64]

I really like this idea.. does the installer contain some sort of mapping of SAR->service name or is it just statically defined? Also -- it would be nice if the IDE took this a step further and told you when service XXX requires service YYY so you get some level of dependency analysis (i.e.. check EJB3, and the aop jdk5 deployer gets automatically checked)

See the jboss-4.0.x/buid/installer/install.xml. It defines packs that identity a component to install along with its dependencies:

 <pack name="ejb3-deployer"
 installGroups="all,ejb3"
 group="J2EE/Deployers"
 required="no">
 <description>The EJB3.0 Container/Deployer. Note: this requires a JDK5
 to run the jboss server.
 </description>
 <fileset dir="@{project.root}/ejb3/output/lib/ejb3.deployer"
 targetdir="$INSTALL_PATH/server/$SERVER_CONFIG/deploy/ejb3.deployer">
 <!-- include all from ejb3.deployer -->
 </fileset>
 <fileset dir="@{project.root}/ejb3/output/lib"
 targetdir="$INSTALL_PATH/server/$SERVER_CONFIG/deploy">
 <include name="ejb3-interceptors-aop.xml"/>
 </fileset>

 <fileset dir="@{jboss.dist}/server/all"
 targetdir="$INSTALL_PATH/server/$SERVER_CONFIG">
 <include name="deploy/ejb-timer-service.xml"/>
 </fileset>
 <depends packname="hibernate"/>
 <depends packname="minimal"/>
 <depends packname="naming"/>
 <depends packname="security"/>
 <depends packname="jca-service"/>
 <depends packname="jboss-aop-jdk50-deployer"/>
 <depends packname="jboss-remoting"/>
 </pack>

The installGroups and group further classify the pack for selecting categories of packs based on a higher level selection like jms, clustering, etc. The packs simply have to be defined correctly, and with the correct granularity and dependcies. A graph can be built from this. We have custom listeners in the installer which can produce graphs of this info for reuse in the ide.

[starksm64]

I also really like this idea -- isn't this something that ON has already tried to solve? also -- we should keep in mind that one of my goals for our new adapter is to be backwards compatible with at the least 3.2 series, so if we can keep any configuration metadata central to the IDE, that would be a huge step for compatibility. thoughts?

No, its not related to what ON or the profile service of jboss5 is trying to do. Its just an optmized representation of the deployment metadata that ordinarily would have to be parsed from both the class annotation as well as any xml overrides. The metadata would just be some binary file that could be in the root META-INF directory of the dpeloyment. If a vfs configuration does not exist that understands how to make this available to the deployers, it would just be ignored.