app server run configurations opinion needed

We are refactoring Tomcat/Weblogic integrations to make them look more or less similar.
Now Tomcat configuration allows to "run" web module. That means start Tomcat server and deploy that module there.
Weblogic integration allows to configure server and list of modules to deploy.
The question is: which method is preferable, i.e. what are we running, module or server ?

1) We are running app server. In that case run configuration consists of
- particular app server settings: paths, startup parameters etc
- list of j2ee modules to deploy when server starts
2) We are running j2ee module. In that case configuration consists of
- j2ee module to run
- link to server where to deploy this module

In 1st option you have ability to deploy several j2ee modules of choice on server startup. In 2nd option you will have to create
application module to pack some modules to be deployed together.
In 2nd option it will not be easy to start bare server, without deploying anything there.

Please comment on this.
--
regards,
Alexey Kudravtsev
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"



5 comments
Comment actions Permalink

Definitely #1. We have several modules to deploy.

"Alexey Kudravtsev (JetBrains)" <cdr@intellij.com> wrote in message
news:c6quo8$k76$1@is.intellij.net...

We are refactoring Tomcat/Weblogic integrations to make them look more or

less similar.

Now Tomcat configuration allows to "run" web module. That means start

Tomcat server and deploy that module there.

Weblogic integration allows to configure server and list of modules to

deploy.

The question is: which method is preferable, i.e. what are we running,

module or server ?
>

1) We are running app server. In that case run configuration consists of
- particular app server settings: paths, startup parameters etc
- list of j2ee modules to deploy when server starts
2) We are running j2ee module. In that case configuration consists of
- j2ee module to run
- link to server where to deploy this module

>

In 1st option you have ability to deploy several j2ee modules of choice on

server startup. In 2nd option you will have to create

application module to pack some modules to be deployed together.
In 2nd option it will not be easy to start bare server, without deploying

anything there.
>

Please comment on this.
--
regards,
Alexey Kudravtsev
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

>
>
>


0
Comment actions Permalink

I would say most often we are in teh #2 scenario. There is a
pre-existing server and we want to deploy a new app to that server.
Once I set up the app server (tomcat) I don't want anything messing with
the conf files unless I do it manually. The only exception might be
adding the context to server.xml
Thanks for asking,
Steve

Alexey Kudravtsev (JetBrains) wrote:

We are refactoring Tomcat/Weblogic integrations to make them look more or less similar.
Now Tomcat configuration allows to "run" web module. That means start Tomcat server and deploy that module there.
Weblogic integration allows to configure server and list of modules to deploy.
The question is: which method is preferable, i.e. what are we running, module or server ?

1) We are running app server. In that case run configuration consists of
- particular app server settings: paths, startup parameters etc
- list of j2ee modules to deploy when server starts
2) We are running j2ee module. In that case configuration consists of
- j2ee module to run
- link to server where to deploy this module

In 1st option you have ability to deploy several j2ee modules of choice on server startup. In 2nd option you will have to create
application module to pack some modules to be deployed together.
In 2nd option it will not be easy to start bare server, without deploying anything there.

Please comment on this.


0
Comment actions Permalink

Alexey Kudravtsev (JetBrains) wrote:

1) We are running app server. In that case run configuration consists of
- particular app server settings: paths, startup parameters etc
- list of j2ee modules to deploy when server starts
2) We are running j2ee module. In that case configuration consists of
- j2ee module to run
- link to server where to deploy this module

In 1st option you have ability to deploy several j2ee modules of choice on server startup. In 2nd option you will have to create
application module to pack some modules to be deployed together.
In 2nd option it will not be easy to start bare server, without deploying anything there.


They're not two different options, I think: in both cases you need some
sort of EAR<->server mapping (or WAR<->server mapping, as the case may
be). "starting" a J2EE module would start the corresponding server (if
configured), and starting a server would would start the J2EE modules
configured to run on that server. Both cases require a similar (or even
the same) configuration step. I don't see why it's an either/or situation.

Incidentally, this is something WSAD does fairly well: you define a
server configuration (similar to IDEA's 'Run configurations'), and tell
it what J2EE (EAR's) to run on it. Alternatively, you 'Launch' a
WAR/EAR, and WSAD starts the associated server. Works quite well. Except
for the stupid publish/deploy step which fails half of the time. Bloody
beast. :-|

CU,
Edwin

0
Comment actions Permalink

I assume when you say 'run a module', you mean an application. The only two cases where it makes sense to 'run' j2ee stuff is for a war, or an ear. I don't imagine many people need/want to run standalong ejb jars.

I'm pretty happy with the current web integration layer. I'm pretty much able to do everything I need to to have the orion plugin able to deploy to the server and work its magic without the user needing to do anything on the command line. I'd hope that for the full j2ee plugin, I am able to interrogate the api to find ejb modules and suchlike, and have the plugin behave similarly.

For me personally, I probably have a slight preference to running the server, rather than the module (plugin would write appropriate config files for the server). The reason is that hot deployment works for 99% of the time, but when it does (that last 1%, it's REALLY annoying). Plus in my case Orion's startup is so fast that it really doesn't matter. Having said that, I have no problem with either approach as long as the api is open enough!

0
Comment actions Permalink

Option #1 gives me the ability to have a base module which might do the basic part of my app, then deploy further modules as I write them to test multiple apps interacting together. Having the option of one or more in a simple way will always be better for me.

Of course, if we never end up getting the ability to write a plugin for our app server of choice, it makes option 1 pretty sucky, and option 2 the preferred path.

Knowing you're opening the API up, I'd say #1.

R

0

Please sign in to leave a comment.