On Jan 26, 2004, at 3:43 PM, Aaron Mulder wrote:
On Mon, 26 Jan 2004, Dain Sundstrom wrote:I would prefer the tool ask the provider for the desired location for the streams to be stored, which would also allow the provider to have the file name end with .xml, and allow the configurations to be seamlessly portable between tools.
But the streams are only ever stored on the user's disk, and the
provider cannot select an appropriate location there. The storage is only
as a convenience for the user (as demonstrated by your EJB-to-EAR
example). When just configuring and deploying, the plan is never saved to
disk, only generated from the DConfigBeans and passed directly to the
DeploymentManager implementation.
That is just what I prefer, but heck the spec is final. I would bet the normal case is the user/developer saves it to disk every time, otherwise every time they want to (re)deploy they would need to do all the configuration again.
I'll chat with Jeremy later. I really want to see this spec work, which means the vendors need to actually try to support this (and not take the easy out), and the end users need to find the tools useable. I'm concerned that the non-vendor supplied tools will be clunky, so people will only use vendor tools. I hope it works out, but I'm currently fairly pessimistic. Anyway, I am confident this will work for us as we are the vendor and can supply our own tools.
Netbeans has a tool already. I don't think it's unnecessarily
clunky. In fact, I don't see what advantages a vendor's own tool could
really have here. I guess I'll just have to show you a good tool and then
you'll believe me. :)
I'll have to see. I wonder how well it works with the other vendor's servers.
Let me ask you this: would the ideal tool for you be:
- command-line - web-based - standalone Swing - Swing IDE plug-in
An idea tool for me would be ant. Maybe a swing tool to edit the config and an ant task to replay the config to a target server.
-dain
