3:31 p.m.
I'm completley unsure how I should remedy this JIRA issue:
http://jira.jboss.com/jira/browse/JBIDE-405
There are primarily three places ports are stored. The xml files first and
foremost. The XPath editor which can modify the xml files directly. And
finally, the launch configuration arguments.
One implementation of my plugin read strictly from the appropriate xml files
and shoved them into the command line arguments for starting and stopping
the server. But then a user complained that when he modified the command
line args directly, it was still reading from the xml file.
So, it became obvious the xml files should just prime the command args as
starting defaults and after that the user should modify them directly.
However Max is suggesting I add a tab for them. If I add a tab for them,
modifying the fields on the new Ports tab should have what effect exactly?
1) Should modifying a port on such a tab automatically change the command
line arguments for start, stop, and twiddle?
2) Should modifying a port on such a tab change the xml files in the
server's home directory?
3) Should modifying a port in an xml file directly automatically change the
command line arguments?
4) Should modifying a port in an xml file through the xpaths editor in
properties view change the command line arguments?
It seems to me that no matter how I do this, some people are going to be
annoyed, and the easiest answer is to just give the user more control and do
less for them. Maybe I'm just being unambitious. Maybe I'm missing an
obvious answer.
- Rob
2:24 a.m.
I'm completley unsure how I should remedy this JIRA issue:
http://jira.jboss.com/jira/browse/JBIDE-405
:)
There are primarily three places ports are stored.
The xml files first and foremost.
The XPath editor which can modify the xml files directly.
It is more a viewer in this respect, right ?
If it can edit the files (i didn't know that so that sounds cool ;),
then it is still just the xml files.
And finally, the launch configuration arguments.
Just to verify what/if I understand...the form editor I get when a
double click is just an alternate representation of the launch config,
correct ?
One implementation of my plugin read strictly from the appropriate
xml
files and shoved them into the command line arguments for starting and
stopping
the server.
This is only relevant for the stop command, correct ?
Can a user tell JBoss AS the server the port info in the startup script
overriding
what is in the xml files ? (if just JBossAS came with the docs so i
shouldn't be guessing
on this while sitting in the train)
But then a user complained that when he modified the command
line args directly, it was still reading from the xml file.
I guess the command line had the port duplicated ? one from your plugin
and the other from the user ?
So, it became obvious the xml files should just prime the command
args as
starting defaults and after that the user should modify them directly.
well....
However Max is suggesting I add a tab for them. If I add a tab for
them,
modifying the fields on the new Ports tab should have what effect
exactly?
Ok, here is what I imagine:
1) Should modifying a port on such a tab automatically change the
command
line arguments for start, stop, and twiddle?
Provide the tab with the various ports...if they are filled in they will
be used,
if they are not nothing will be appended to the command line.
Ultimate flexibility would be checkboxes for where they would be used, but
let's just start "small" :)
2) Should modifying a port on such a tab change the xml files in the
server's home directory?
Not without asking the user. And what do you do about ports that are
specified redundantly ?
e.g. http port if i recall ?
And in the case that IFF the command line can actually be used to override
what the server
starts with then it should not change them.
3) Should modifying a port in an xml file directly automatically
change
the command line arguments?
Well, you could warn the user and ask if he want them synced.
4) Should modifying a port in an xml file through the xpaths editor
in
properties view change the command line arguments?
See #3
It seems to me that no matter how I do this, some people are going to
be
annoyed, and the easiest answer is to just give the user more control
and do less for them. Maybe I'm just being unambitious. Maybe I'm
missing an
obvious answer.
For me the obvious answer is #1 up there and then to be good you should
provide
a variable e.g. ${serverinfo:httpport}, ${serverinfo:xyz} etc. that can be
used in
the command line arguments if the user so well pleases.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
6692
days inactive
6693
days old
jbosstools-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Max Rydahl Andersen -
Rob Stryker