2079 - Tomcat base dir??? 关注
Ok I figured out how to setup the tomcat home, but now there is Tomcat base directory which gets filled in to the same thing as Tomcat home... what the heck is Tomcat Base Directory, and what do you expect there?
Seems it doesn't do anything, it's a replica of the Tomcat path, and if you modify it to include conf, you get an error which tells you that path/conf/conf does not exist, so it seems that it's an artifact of the changing gui in the EAP and can be ignored.
+1 for moving Tomcat home to IDE settings, keep moving more stuff over there. The Tomcat path, the Tomcat Base Dir are useless there now. That removes 2 more fields, but it looks like this is the direction you're going in.
Also +1 on the launch browser, but I filed a bug on that already because there is a weird disjoint... why would I setup the browser to open at relative dir / when the context of Tomcat is set to /foo? I think that you can probably get rid of where the browser opens, but there might be a weird reason why people might want to open a web app where it's not running? Is this JB thinking ahead that SOME person is going to complain that they can't change it? :)
At the very least I would like the browser open default to context path, again simpler. My first impression was that OH, I can open the browser at / and see the app and it will load the context there... yeah me fool, but this is what I thought it would do because of how it's presented.
This is intended to be the base directory to get custom Tomcat options
(pointing to Tomcat home by default).
Robert S. Sfeir wrote:
IntelliJ Labs / JetBrains Inc.
"Develop with pleasure!"
On Fri, 04 Jun 2004 20:46:07 +0400, Robert S. Sfeir wrote:
It's supposed to fix this bug :
I haven't tried 2079 yet, but I'm hoping I can now set a path to a dir
that contains personal conf, temp etc directories.
Interesting. Weird, and I think it's going to confuse people. Maybe because of the label name?
Can this stuff be moved to the config of Tomcat with the catalina home dir location, or is there a reason why this needs to be module specific?
I'm just trying to make the module setup simpler and quicker, we're adding more things that are a bit confusing unless you're using some customized setup. I'm not saying the customized setup is not important, just that it's not used as often as an OOB one.
I assumed the path entered here would be used to set the value of CATALINA_BASE prior to launching Tomcat. This doesn't appear to be the case though - the path is ignored and the console output in the Run toolwindow shows that CATALINA_HOME and CATALINA_BASE are set to the same value.
Now that setting environment variables works correctly I can set CATALINA_BASE and CATALINA_TMPDIR this way and everything works as expected, which is great.
So, what's supposed to be entered here, and how is the value used?
I agree. I think that using unintuitive descriptions is confusing. If its purpose is to set CATALINA_BASE then label it that way. If someone is using Tomcat then I'd like to think they'll have read the documentation and at least recognise the name even if they don't know what it's for (and therefore know where to go and look to find out).
Making it module-specific gives the flexibility of being able to use different Tomcat config files for each module. Some people might like being able to specify different policy files, server.xml, tomcat-users.xml etc. (assuming a one-web-module-per-application project). Not something I've had a need to do.
That's true, but I also think it's difficult to say how easy module setup might be when all of the config options actually work properly. I think you're right with this one though. Configuring things like CATALINA_BASE would be better placed on the Advanced tab rather than on the Server tab.
There are only certain environment variables that Tomcat uses - perhaps these could be pre-filled with the values appropriate for the value of CATALINA_HOME but have a widget for choosing a non-default path if the user prefers to do that?
Ok but if you need to run tomcat with specific startup scripts, then I think you just create a new app server, or copy and existing one, and change the scripts for it. That's a MUCH better way to do it, at least I think, because now you have a configuration you can carry into any project and any web module without having to reconfigure it again.
That solution is still module specific, and it simplifies the interface. Nothing lost.