J Aaron Farr wrote:
On Mon, 2003-09-08 at 20:12, Stephen McConnell wrote:
Farr, Aaron wrote:
Spit, grumble, spit ...!
:)
Issue (2) - assuming we seperate ${merlin.home} from the repository, e.g. ${merlin.repository}, and we default to using ${merlin.home}/apps, there is nasty downside (as I found out back with an early incarnation
of Merlin 2) - its drop dead easy to destroy info by simply launching a container and have it write over data in a system wide shared repository. The much better solution is to plan deployment scenarios. For example, with James running as an NT service, I declare an explicit home directory that I know is explicity under James control and will not be impacted by any other concurrent deployment of James.
Are you declaring the home directory via a custom context parameter or
via some special command line parameter?
Command line parameter -home established a constructor argument that is applied to the DefaultKernelContext.
Issue (3) - the Phoneix "apps" directory is actually a combination of two seperate and distinct notions in Merlin. The "apps" directory serves as an active deployment directory (drop you sar file here), and
the working home directory. In Merlin there is a deployment path (possibly containing multiple directories and executable jar files), and a seperate home directory. These two aspects should be kept seperate in all respects.
Okay, I can see that separating the ideas can be advantageous.
On a separate note, I think there might be something to say for the simplicity of "drop your app here" deployment style. It's 1. Simple 2. Familiar (like .war and .ear files) 3. Easy for apps which aren't using maven or don't have all their dependencies up in maven repositories.
Personally I think maven & repositories is the way to go, but support for other situations would be nice.
I agree - and what is in the back of my mind is local repository chains. Imagine you zip you application up - and the zip archive structure is a repository structure. You put this somewhere, and in you kernel.xml you declare that the repository hosts path includes you zip file. Now imagine merlin unpacking you zip file behind the scenes and uses it just like it was another on-line repository. That's a solution that gives us drop-dead-easy-braindead-installation-of-apps + maintenance of the repository object model.
However ....
I do think that there is room for improvement. Currently the working directory is based on the merlin deployment home (specified by -home
and defaulting to ${user.dir}) plus the "/home" suffix. If I do something
like the following:
$ merlin -home apps my-deployment-dir
I end up with a deployment home of
${user.dir}/apps/home
I think the general user experience would be better (and closer to the phoenix model) if the resulting deployment home was
${user.dir}/apps
Consequently the path to urn:avalon:home would be:
$(user.dir}/apps/${partition.name}/${component.name}
The difference here is that "${user.dir}/home" would be the default deployment home and that any -home command line parameter would override
that value. I.e. - no appending of "/home".
How does that sound?
Better.
I think
$ merlin -home some/dir/path/here block.xml
should really end up as:
urn:avalon:home = some/dir/path/here/${partition}/${component}
In other words, drop the ${user.dir} simply because if I want ${user.dir} then just dropping the leading slash of any directory path should give me that. It also allows for something like:
$ merlin -home $MERLIN_HOME/apps block.xml
for those of us who insist on such madness. :)
How does that sound?
+1
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
