j2ee running: VM Parameters

Hi,

does anybody else find the new way to pass VM parameters (especially -D ones) to
a Tomcat process a little too awkward? The possibility to pass environment variables
is a little too generic IMO. There are a few points I have issues with:

- To pass VM arguments I have to know how the startup scripts of Tomcat work, i.e.
that they use a variable named "JAVA_OPTS". In the "Run" tab it is possible to create
this variable. However, editing a variable with long values is a pain in this small
table cell. This needs at least an additional edit dialog like it was in 4.0.

- In the "Debug" tab, the JAVA_OPTS are not editable at all. No way to define any additional
VM option as far as I can see.

- The environment variables are not shared between the Run and Debug configuration.
That's pretty bad because it will make the whole thing behave differently when those
vales are not totally in sync. Those things are hard to catch.

My suggestion: Since it's not a totally generic Run configuration anyway (it's still called
"Tomcat"), the usage should be much easier. The environment variables table should actually
be a table to edit VM parameters in a convenient way. Is there any use for generic env. vars
at all?

Actually I'm not too fond of the way to start the server via its supplied scripts. I think
the way to start it in 4.0, with the possibility to include the module classpath, was more
straight forward to use. It was much easier before to run a webapp that just consisted of a
web.xml that declared some servlet that's somewhere in my project: I didn't have to care
about what files to deploy where, just a single click and IDEA could run the webapp. Not to
mention the time it currently takes to build a 10Mb .war file or to copy the stuff to the
exploded dir.

Anybody else?

Sascha

PS: In case I can't make friends with the new method, would it be theoretically possible
to convert the 4.0 Tomcat plugin to work with 4.1?

12 comments
Comment actions Permalink

On Tue, 08 Jun 2004 11:25:27 +0200, Sascha Weinreuter wrote:

does anybody else find the new way to pass VM parameters (especially -D
ones) to a Tomcat process a little too awkward? The possibility to pass
environment variables is a little too generic IMO. There are a few
points I have issues with:

- To pass VM arguments I have to know how the startup scripts of Tomcat
work, i.e. that they use a variable named "JAVA_OPTS".


Knowing how it works is no bad thing IMO.

In the "Run" tab it is possible to create this variable. However,
editing a variable with long values is a pain in this small table cell.
This needs at least an additional edit dialog like it was in 4.0.

- In the "Debug" tab, the JAVA_OPTS are not editable at all. No way to
define any additional VM option as far as I can see.


I think that the wrong variable has been used here - those options
should be put in JPDA_OPTS rather than JAVA_OPTS. In the meantime, you
should be able to use CATALINA_OPTS to pass other properties to the VM.

- The environment variables are not shared between the Run and Debug
configuration. That's pretty bad because it will make the whole thing
behave differently when those vales are not totally in sync. Those
things are hard to catch.


Yes, I was surprised to see it work this way. On the other hand, not
being able to have different values might be more annoying. Maybe an
option to keep them synched or not would be useful?

My suggestion: Since it's not a totally generic Run configuration anyway
(it's still called "Tomcat"), the usage should be much easier.


I don't disagree that things should be as easy as possible, but since it's
specific to Tomcat, what's wrong with having a UI that deals with the
things Tomcat uses?

The environment variables table should actually be a table to edit VM
parameters in a convenient way. Is there any use for generic env. vars
at all?


Yes, there's definitely a need for generic environment variables.
Personally, I want to be able to set values for CATALINA_BASE and
CATALINA_TMPDIR so I can share a single Tomcat installation via a
read-only filesystem.

Having a table to edit individual properties for the VM would certainly be
easier than trying to cram them into a single small text field though.
IDEA could then pass them all using JAVA_OPTS.

Actually I'm not too fond of the way to start the server via its
supplied scripts. I think the way to start it in 4.0, with the
possibility to include the module classpath, was more straight forward
to use. It was much easier before to run a webapp that just consisted of
a web.xml that declared some servlet that's somewhere in my project: I
didn't have to care about what files to deploy where, just a single
click and IDEA could run the webapp. Not to mention the time it
currently takes to build a 10Mb .war file or to copy the stuff to the
exploded dir.


I'm not sure I understand your comment about the web.xml file.

I disagreed with removing the option to include the module classpath when
it was raised here recently. As you say, what's the point of building a
.war or copying a load of jars if they're on the module classpath already?

--
Mark Scott


0
Comment actions Permalink

Mark Scott wrote:

On Tue, 08 Jun 2004 11:25:27 +0200, Sascha Weinreuter wrote:

>>does anybody else find the new way to pass VM parameters (especially -D
>>ones) to a Tomcat process a little too awkward? The possibility to pass
>>environment variables is a little too generic IMO. There are a few
>>points I have issues with:
>>
>>- To pass VM arguments I have to know how the startup scripts of Tomcat
>>work, i.e. that they use a variable named "JAVA_OPTS".


Knowing how it works is no bad thing IMO.


Sure, being a curious person myself I absolutely agree with that. But that does
not mean that the IDE that is supposed to ease my life requires me to remember
this stuff in the moment I want it to run a server process.

>>In the "Run" tab it is possible to create this variable. However,
>>editing a variable with long values is a pain in this small table cell.
>>This needs at least an additional edit dialog like it was in 4.0.
>>
>>- In the "Debug" tab, the JAVA_OPTS are not editable at all. No way to
>>define any additional VM option as far as I can see.


I think that the wrong variable has been used here - those options
should be put in JPDA_OPTS rather than JAVA_OPTS. In the meantime, you
should be able to use CATALINA_OPTS to pass other properties to the VM.


See, that's where the problem starts. If there were no script files, there would
be no confusion about what env variables to use ;)

>>- The environment variables are not shared between the Run and Debug
>>configuration. That's pretty bad because it will make the whole thing
>>behave differently when those vales are not totally in sync. Those
>>things are hard to catch.


Yes, I was surprised to see it work this way. On the other hand, not
being able to have different values might be more annoying. Maybe an
option to keep them synched or not would be useful?


I agree, but it depends on the use case. Generally I'd say that I want to debug
an application in exactly the same way as it is run and produces the error(s) I
want to debug. Yes, an option for this would fit any case.

>>My suggestion: Since it's not a totally generic Run configuration anyway
>>(it's still called "Tomcat"), the usage should be much easier.


I don't disagree that things should be as easy as possible, but since it's
specific to Tomcat, what's wrong with having a UI that deals with the
things Tomcat uses?


I'd see it the other way around: The current UI has almost the complexity to
use any server. In my case, Tomcat just happens to be a tool to run some
things conveniently from inside IDEA. I do not modify startup scripts or anything
like that so I have no need for Tomcat specific things; I want them to be handled
internally.

>>The environment variables table should actually be a table to edit VM
>>parameters in a convenient way. Is there any use for generic env. vars
>>at all?


Yes, there's definitely a need for generic environment variables.
Personally, I want to be able to set values for CATALINA_BASE and
CATALINA_TMPDIR so I can share a single Tomcat installation via a
read-only filesystem.

>

Having a table to edit individual properties for the VM would certainly be
easier than trying to cram them into a single small text field though.
IDEA could then pass them all using JAVA_OPTS.


OK, agreed.

>>Actually I'm not too fond of the way to start the server via its
>>supplied scripts. I think the way to start it in 4.0, with the
>>possibility to include the module classpath, was more straight forward
>>to use. It was much easier before to run a webapp that just consisted of
>>a web.xml that declared some servlet that's somewhere in my project: I
>>didn't have to care about what files to deploy where, just a single
>>click and IDEA could run the webapp. Not to mention the time it
>>currently takes to build a 10Mb .war file or to copy the stuff to the
>>exploded dir.


I'm not sure I understand your comment about the web.xml file.


That may be a little specific to my case: In a few projects I do not have
full-blown web-applications. The project just includes a few servlets that
provide a "transport layer" for a protocol implementation. In 4.0, I had a
single web.xml that defined a servlet and a servlet mapping and I could run
it with very few steps and without worrying about deploying anything.

I disagreed with removing the option to include the module classpath when
it was raised here recently. As you say, what's the point of building a
.war or copying a load of jars if they're on the module classpath already?


I can somehow understand that IDEA is reluctant to support a non-standard way
of doing things, i.e. to build a .war file that may not run out-of-the box, but
since I believe that most people do release-builds and -tests with Ant anyway,
I'd like to have at least the possibility to have IDEA work in a way that's as
easy to setup as possible.

Sascha

0
Comment actions Permalink

I don't use the tomcat plugin, but I definitely think it's awkward judging by the amount of knowledge you need to have.

For orion (yeah, bragging time I'm afraid), the goal is that all you need to do is point at your orion directory, and select what modules to deploy when you run.

0
Comment actions Permalink

Hi,

In fact simple web application could be run with Pallada without such
heavy manipulations (just do no change exploded directory in the
wizard). Tomcat is configured by its home dir selection.
We will add possibility to add additional VM parameters so that you are
not forced to go to the 'Advanced' tab.

Sascha Weinreuter wrote:

Hi,

does anybody else find the new way to pass VM parameters (especially -D
ones) to
a Tomcat process a little too awkward? The possibility to pass
environment variables
is a little too generic IMO. There are a few points I have issues with:

- To pass VM arguments I have to know how the startup scripts of Tomcat
work, i.e.
that they use a variable named "JAVA_OPTS". In the "Run" tab it is
possible to create
this variable. However, editing a variable with long values is a pain in
this small
table cell. This needs at least an additional edit dialog like it was in
4.0.

- In the "Debug" tab, the JAVA_OPTS are not editable at all. No way to
define any additional
VM option as far as I can see.

- The environment variables are not shared between the Run and Debug
configuration.
That's pretty bad because it will make the whole thing behave
differently when those
vales are not totally in sync. Those things are hard to catch.

My suggestion: Since it's not a totally generic Run configuration anyway
(it's still called
"Tomcat"), the usage should be much easier. The environment variables
table should actually
be a table to edit VM parameters in a convenient way. Is there any use
for generic env. vars
at all?

Actually I'm not too fond of the way to start the server via its
supplied scripts. I think
the way to start it in 4.0, with the possibility to include the module
classpath, was more
straight forward to use. It was much easier before to run a webapp that
just consisted of a
web.xml that declared some servlet that's somewhere in my project: I
didn't have to care
about what files to deploy where, just a single click and IDEA could run
the webapp. Not to
mention the time it currently takes to build a 10Mb .war file or to copy
the stuff to the
exploded dir.

Anybody else?

Sascha

PS: In case I can't make friends with the new method, would it be
theoretically possible
to convert the 4.0 Tomcat plugin to work with 4.1?



--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

On 2004-06-08 10:35:12 -0400, Hani Suleiman <hani@formicary.net> said:

I don't use the tomcat plugin, but I definitely think it's awkward
judging by the amount of knowledge you need to have.

For orion (yeah, bragging time I'm afraid), the goal is that all you
need to do is point at your orion directory, and select what modules to
deploy when you run.


Hani, I wish they would follow your example. I've been griping by how
complicated they make things to run a stupid Tomcat app.

For some reason I don't see the changes I'm suggesting, so either I'm
the only one who thinks that way (apparently not since others are
piping in now), or they have gone down the road too far to turn back
with release coming up fairly quickly.

R

0
Comment actions Permalink

Man we don't need MORE things we need less things or at least a way to
see less until we need more! You're adding more to satisfy the need of
the few, but complicating the life of the many. Think of what it's
going to be like when you release this and the mass amount of support
you're going to need because you've made app server setup some dang
complex.

R

On 2004-06-08 11:34:11 -0400, Maxim Mossienko
<Maxim.Mossienko@jetbrains.com> said:

Hi,

In fact simple web application could be run with Pallada without such
heavy manipulations (just do no change exploded directory in the
wizard). Tomcat is configured by its home dir selection.
We will add possibility to add additional VM parameters so that you are
not forced to go to the 'Advanced' tab.

Sascha Weinreuter wrote:

>> Hi,
>>
>> does anybody else find the new way to pass VM parameters (especially -D
>> ones) to
>> a Tomcat process a little too awkward? The possibility to pass
>> environment variables
>> is a little too generic IMO. There are a few points I have issues with:
>>
>> - To pass VM arguments I have to know how the startup scripts of Tomcat
>> work, i.e.
>> that they use a variable named "JAVA_OPTS". In the "Run" tab it is
>> possible to create
>> this variable. However, editing a variable with long values is a pain
>> in this small
>> table cell. This needs at least an additional edit dialog like it was in 4.0.
>>
>> - In the "Debug" tab, the JAVA_OPTS are not editable at all. No way to
>> define any additional
>> VM option as far as I can see.
>>
>> - The environment variables are not shared between the Run and Debug
>> configuration.
>> That's pretty bad because it will make the whole thing behave
>> differently when those
>> vales are not totally in sync. Those things are hard to catch.
>>
>> My suggestion: Since it's not a totally generic Run configuration
>> anyway (it's still called
>> "Tomcat"), the usage should be much easier. The environment variables
>> table should actually
>> be a table to edit VM parameters in a convenient way. Is there any use
>> for generic env. vars
>> at all?
>>
>> Actually I'm not too fond of the way to start the server via its
>> supplied scripts. I think
>> the way to start it in 4.0, with the possibility to include the module
>> classpath, was more
>> straight forward to use. It was much easier before to run a webapp that
>> just consisted of a
>> web.xml that declared some servlet that's somewhere in my project: I
>> didn't have to care
>> about what files to deploy where, just a single click and IDEA could
>> run the webapp. Not to
>> mention the time it currently takes to build a 10Mb .war file or to
>> copy the stuff to the
>> exploded dir.
>>
>> Anybody else?
>>
>> Sascha
>>
>> PS: In case I can't make friends with the new method, would it be
>> theoretically possible
>> to convert the 4.0 Tomcat plugin to work with 4.1?


0
Comment actions Permalink

+1000
Gear it towards the simple app and then add the simple part on later.
Catch the low hanging fruit first.
Steve

Robert Sfeir wrote:

Man we don't need MORE things we need less things or at least a way to
see less until we need more! You're adding more to satisfy the need of
the few, but complicating the life of the many. Think of what it's
going to be like when you release this and the mass amount of support
you're going to need because you've made app server setup some dang
complex.

R

On 2004-06-08 11:34:11 -0400, Maxim Mossienko
<Maxim.Mossienko@jetbrains.com> said:

>> Hi,
>>
>> In fact simple web application could be run with Pallada without such
>> heavy manipulations (just do no change exploded directory in the
>> wizard). Tomcat is configured by its home dir selection.
>> We will add possibility to add additional VM parameters so that you
>> are not forced to go to the 'Advanced' tab.
>>
>> Sascha Weinreuter wrote:
>>
>>> Hi,
>>>
>>> does anybody else find the new way to pass VM parameters (especially
>>> -D ones) to
>>> a Tomcat process a little too awkward? The possibility to pass
>>> environment variables
>>> is a little too generic IMO. There are a few points I have issues with:
>>>
>>> - To pass VM arguments I have to know how the startup scripts of
>>> Tomcat work, i.e.
>>> that they use a variable named "JAVA_OPTS". In the "Run" tab it is
>>> possible to create
>>> this variable. However, editing a variable with long values is a pain
>>> in this small
>>> table cell. This needs at least an additional edit dialog like it was
>>> in 4.0.
>>>
>>> - In the "Debug" tab, the JAVA_OPTS are not editable at all. No way
>>> to define any additional
>>> VM option as far as I can see.
>>>
>>> - The environment variables are not shared between the Run and Debug
>>> configuration.
>>> That's pretty bad because it will make the whole thing behave
>>> differently when those
>>> vales are not totally in sync. Those things are hard to catch.
>>>
>>> My suggestion: Since it's not a totally generic Run configuration
>>> anyway (it's still called
>>> "Tomcat"), the usage should be much easier. The environment variables
>>> table should actually
>>> be a table to edit VM parameters in a convenient way. Is there any
>>> use for generic env. vars
>>> at all?
>>>
>>> Actually I'm not too fond of the way to start the server via its
>>> supplied scripts. I think
>>> the way to start it in 4.0, with the possibility to include the
>>> module classpath, was more
>>> straight forward to use. It was much easier before to run a webapp
>>> that just consisted of a
>>> web.xml that declared some servlet that's somewhere in my project: I
>>> didn't have to care
>>> about what files to deploy where, just a single click and IDEA could
>>> run the webapp. Not to
>>> mention the time it currently takes to build a 10Mb .war file or to
>>> copy the stuff to the
>>> exploded dir.
>>>
>>> Anybody else?
>>>
>>> Sascha
>>>
>>> PS: In case I can't make friends with the new method, would it be
>>> theoretically possible
>>> to convert the 4.0 Tomcat plugin to work with 4.1?


0
Comment actions Permalink

I don't use the tomcat plugin, but I definitely think
it's awkward judging by the amount of knowledge you
need to have.

For orion (yeah, bragging time I'm afraid), the goal
is that all you need to do is point at your orion
directory, and select what modules to deploy when you
run.


I think Maxim's correct when he says that's pretty much the case with Tomcat too. If you're not doing anything fancy/perverse/deliberately awkward then all you have to do is point to Tomcat's home directory, choose a context path and a choose a module deployment option. It's arguably awkward because (as Robert Sfeir points out) you can do each of these things in a different place (although it seems to me you can also do them in only two tabs on the Run/Debug config dialog).

0
Comment actions Permalink

make that "add the complex part on later"

Steven Citron-Pousty wrote:

+1000
Gear it towards the simple app and then add the simple part on later.
Catch the low hanging fruit first.
Steve

Robert Sfeir wrote:

>> Man we don't need MORE things we need less things or at least a way to
>> see less until we need more! You're adding more to satisfy the need
>> of the few, but complicating the life of the many. Think of what it's
>> going to be like when you release this and the mass amount of support
>> you're going to need because you've made app server setup some dang
>> complex.
>>
>> R
>>
>> On 2004-06-08 11:34:11 -0400, Maxim Mossienko
>> <Maxim.Mossienko@jetbrains.com> said:
>>
>>> Hi,
>>>
>>> In fact simple web application could be run with Pallada without such
>>> heavy manipulations (just do no change exploded directory in the
>>> wizard). Tomcat is configured by its home dir selection.
>>> We will add possibility to add additional VM parameters so that you
>>> are not forced to go to the 'Advanced' tab.
>>>
>>> Sascha Weinreuter wrote:
>>>
>>>> Hi,
>>>>
>>>> does anybody else find the new way to pass VM parameters (especially
>>>> -D ones) to
>>>> a Tomcat process a little too awkward? The possibility to pass
>>>> environment variables
>>>> is a little too generic IMO. There are a few points I have issues with:
>>>>
>>>> - To pass VM arguments I have to know how the startup scripts of
>>>> Tomcat work, i.e.
>>>> that they use a variable named "JAVA_OPTS". In the "Run" tab it is
>>>> possible to create
>>>> this variable. However, editing a variable with long values is a
>>>> pain in this small
>>>> table cell. This needs at least an additional edit dialog like it
>>>> was in 4.0.
>>>>
>>>> - In the "Debug" tab, the JAVA_OPTS are not editable at all. No way
>>>> to define any additional
>>>> VM option as far as I can see.
>>>>
>>>> - The environment variables are not shared between the Run and Debug
>>>> configuration.
>>>> That's pretty bad because it will make the whole thing behave
>>>> differently when those
>>>> vales are not totally in sync. Those things are hard to catch.
>>>>
>>>> My suggestion: Since it's not a totally generic Run configuration
>>>> anyway (it's still called
>>>> "Tomcat"), the usage should be much easier. The environment
>>>> variables table should actually
>>>> be a table to edit VM parameters in a convenient way. Is there any
>>>> use for generic env. vars
>>>> at all?
>>>>
>>>> Actually I'm not too fond of the way to start the server via its
>>>> supplied scripts. I think
>>>> the way to start it in 4.0, with the possibility to include the
>>>> module classpath, was more
>>>> straight forward to use. It was much easier before to run a webapp
>>>> that just consisted of a
>>>> web.xml that declared some servlet that's somewhere in my project: I
>>>> didn't have to care
>>>> about what files to deploy where, just a single click and IDEA could
>>>> run the webapp. Not to
>>>> mention the time it currently takes to build a 10Mb .war file or to
>>>> copy the stuff to the
>>>> exploded dir.
>>>>
>>>> Anybody else?
>>>>
>>>> Sascha
>>>>
>>>> PS: In case I can't make friends with the new method, would it be
>>>> theoretically possible
>>>> to convert the 4.0 Tomcat plugin to work with 4.1?
>>
>>
>>
>>

0
Comment actions Permalink

Hi,

Please, be more specific why you need to go to the 'advanced' tab.
Appropriate startup/shutdown scripts are selected by choosing the Tomcat
home directory.

Robert Sfeir wrote:

Man we don't need MORE things we need less things or at least a way to
see less until we need more! You're adding more to satisfy the need of
the few, but complicating the life of the many. Think of what it's
going to be like when you release this and the mass amount of support
you're going to need because you've made app server setup some dang
complex.

R

On 2004-06-08 11:34:11 -0400, Maxim Mossienko
<Maxim.Mossienko@jetbrains.com> said:

>> Hi,
>>
>> In fact simple web application could be run with Pallada without such
>> heavy manipulations (just do no change exploded directory in the
>> wizard). Tomcat is configured by its home dir selection.
>> We will add possibility to add additional VM parameters so that you
>> are not forced to go to the 'Advanced' tab.
>>
>> Sascha Weinreuter wrote:
>>
>>> Hi,
>>>
>>> does anybody else find the new way to pass VM parameters (especially
>>> -D ones) to
>>> a Tomcat process a little too awkward? The possibility to pass
>>> environment variables
>>> is a little too generic IMO. There are a few points I have issues with:
>>>
>>> - To pass VM arguments I have to know how the startup scripts of
>>> Tomcat work, i.e.
>>> that they use a variable named "JAVA_OPTS". In the "Run" tab it is
>>> possible to create
>>> this variable. However, editing a variable with long values is a pain
>>> in this small
>>> table cell. This needs at least an additional edit dialog like it was
>>> in 4.0.
>>>
>>> - In the "Debug" tab, the JAVA_OPTS are not editable at all. No way
>>> to define any additional
>>> VM option as far as I can see.
>>>
>>> - The environment variables are not shared between the Run and Debug
>>> configuration.
>>> That's pretty bad because it will make the whole thing behave
>>> differently when those
>>> vales are not totally in sync. Those things are hard to catch.
>>>
>>> My suggestion: Since it's not a totally generic Run configuration
>>> anyway (it's still called
>>> "Tomcat"), the usage should be much easier. The environment variables
>>> table should actually
>>> be a table to edit VM parameters in a convenient way. Is there any
>>> use for generic env. vars
>>> at all?
>>>
>>> Actually I'm not too fond of the way to start the server via its
>>> supplied scripts. I think
>>> the way to start it in 4.0, with the possibility to include the
>>> module classpath, was more
>>> straight forward to use. It was much easier before to run a webapp
>>> that just consisted of a
>>> web.xml that declared some servlet that's somewhere in my project: I
>>> didn't have to care
>>> about what files to deploy where, just a single click and IDEA could
>>> run the webapp. Not to
>>> mention the time it currently takes to build a 10Mb .war file or to
>>> copy the stuff to the
>>> exploded dir.
>>>
>>> Anybody else?
>>>
>>> Sascha
>>>
>>> PS: In case I can't make friends with the new method, would it be
>>> theoretically possible
>>> to convert the 4.0 Tomcat plugin to work with 4.1?




--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

Hi,

Anyway we need to choose Tomcat directory. Please, be more specific what
other configuration items you found unusable in last EAP builds.

Steven Citron-Pousty wrote:

+1000
Gear it towards the simple app and then add the simple part on later.
Catch the low hanging fruit first.
Steve

Robert Sfeir wrote:

>> Man we don't need MORE things we need less things or at least a way to
>> see less until we need more! You're adding more to satisfy the need
>> of the few, but complicating the life of the many. Think of what it's
>> going to be like when you release this and the mass amount of support
>> you're going to need because you've made app server setup some dang
>> complex.
>>
>> R
>>
>> On 2004-06-08 11:34:11 -0400, Maxim Mossienko
>> <Maxim.Mossienko@jetbrains.com> said:
>>
>>> Hi,
>>>
>>> In fact simple web application could be run with Pallada without such
>>> heavy manipulations (just do no change exploded directory in the
>>> wizard). Tomcat is configured by its home dir selection.
>>> We will add possibility to add additional VM parameters so that you
>>> are not forced to go to the 'Advanced' tab.
>>>
>>> Sascha Weinreuter wrote:
>>>
>>>> Hi,
>>>>
>>>> does anybody else find the new way to pass VM parameters (especially
>>>> -D ones) to
>>>> a Tomcat process a little too awkward? The possibility to pass
>>>> environment variables
>>>> is a little too generic IMO. There are a few points I have issues with:
>>>>
>>>> - To pass VM arguments I have to know how the startup scripts of
>>>> Tomcat work, i.e.
>>>> that they use a variable named "JAVA_OPTS". In the "Run" tab it is
>>>> possible to create
>>>> this variable. However, editing a variable with long values is a
>>>> pain in this small
>>>> table cell. This needs at least an additional edit dialog like it
>>>> was in 4.0.
>>>>
>>>> - In the "Debug" tab, the JAVA_OPTS are not editable at all. No way
>>>> to define any additional
>>>> VM option as far as I can see.
>>>>
>>>> - The environment variables are not shared between the Run and Debug
>>>> configuration.
>>>> That's pretty bad because it will make the whole thing behave
>>>> differently when those
>>>> vales are not totally in sync. Those things are hard to catch.
>>>>
>>>> My suggestion: Since it's not a totally generic Run configuration
>>>> anyway (it's still called
>>>> "Tomcat"), the usage should be much easier. The environment
>>>> variables table should actually
>>>> be a table to edit VM parameters in a convenient way. Is there any
>>>> use for generic env. vars
>>>> at all?
>>>>
>>>> Actually I'm not too fond of the way to start the server via its
>>>> supplied scripts. I think
>>>> the way to start it in 4.0, with the possibility to include the
>>>> module classpath, was more
>>>> straight forward to use. It was much easier before to run a webapp
>>>> that just consisted of a
>>>> web.xml that declared some servlet that's somewhere in my project: I
>>>> didn't have to care
>>>> about what files to deploy where, just a single click and IDEA could
>>>> run the webapp. Not to
>>>> mention the time it currently takes to build a 10Mb .war file or to
>>>> copy the stuff to the
>>>> exploded dir.
>>>>
>>>> Anybody else?
>>>>
>>>> Sascha
>>>>
>>>> PS: In case I can't make friends with the new method, would it be
>>>> theoretically possible
>>>> to convert the 4.0 Tomcat plugin to work with 4.1?
>>
>>
>>
>>


--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0
Comment actions Permalink

I agree, even though this will probably leave me out in the cold.

Norris Shelton
Sun Certified Java Programmer




Robert Sfeir wrote:

Man we don't need MORE things we need less things or at least a way to
see less until we need more! You're adding more to satisfy the need
of the few, but complicating the life of the many. Think of what it's
going to be like when you release this and the mass amount of support
you're going to need because you've made app server setup some dang
complex.

>

R

>

On 2004-06-08 11:34:11 -0400, Maxim Mossienko
<Maxim.Mossienko@jetbrains.com> said:

>
>> Hi,
>>
>> In fact simple web application could be run with Pallada without such
>> heavy manipulations (just do no change exploded directory in the
>> wizard). Tomcat is configured by its home dir selection.
>> We will add possibility to add additional VM parameters so that you
>> are not forced to go to the 'Advanced' tab.
>>
>> Sascha Weinreuter wrote:
>>
>>> Hi,
>>>
>>> does anybody else find the new way to pass VM parameters (especially
>>> -D ones) to
>>> a Tomcat process a little too awkward? The possibility to pass
>>> environment variables
>>> is a little too generic IMO. There are a few points I have issues with:
>>>
>>> - To pass VM arguments I have to know how the startup scripts of
>>> Tomcat work, i.e.
>>> that they use a variable named "JAVA_OPTS". In the "Run" tab it is
>>> possible to create
>>> this variable. However, editing a variable with long values is a
>>> pain in this small
>>> table cell. This needs at least an additional edit dialog like it
>>> was in 4.0.
>>>
>>> - In the "Debug" tab, the JAVA_OPTS are not editable at all. No way
>>> to define any additional
>>> VM option as far as I can see.
>>>
>>> - The environment variables are not shared between the Run and Debug
>>> configuration.
>>> That's pretty bad because it will make the whole thing behave
>>> differently when those
>>> vales are not totally in sync. Those things are hard to catch.
>>>
>>> My suggestion: Since it's not a totally generic Run configuration
>>> anyway (it's still called
>>> "Tomcat"), the usage should be much easier. The environment
>>> variables table should actually
>>> be a table to edit VM parameters in a convenient way. Is there any
>>> use for generic env. vars
>>> at all?
>>>
>>> Actually I'm not too fond of the way to start the server via its
>>> supplied scripts. I think
>>> the way to start it in 4.0, with the possibility to include the
>>> module classpath, was more
>>> straight forward to use. It was much easier before to run a webapp
>>> that just consisted of a
>>> web.xml that declared some servlet that's somewhere in my project: I
>>> didn't have to care
>>> about what files to deploy where, just a single click and IDEA could
>>> run the webapp. Not to
>>> mention the time it currently takes to build a 10Mb .war file or to
>>> copy the stuff to the
>>> exploded dir.
>>>
>>> Anybody else?
>>>
>>> Sascha
>>>
>>> PS: In case I can't make friends with the new method, would it be
>>> theoretically possible
>>> to convert the 4.0 Tomcat plugin to work with 4.1?
>>
>
>

0

Please sign in to leave a comment.