On Sep 11, 2008, at 11:39 AM, Donald Woods wrote:
As a "user" I hate how the Plugin portlet and cmdline show plugins
that can't/shouldn't be installed on my Tomcat JEE5 or Minimal
server....
Seems that we're confusing/complicating everyone's life for a
framework assembly scenario that should be handled in the code:
- If a plugin lists tomcat or jetty as a depend, but the server has
the opposite container installed, then it should not be installable.
- If a plugin lists tomcat or jetty as a depend, but the server has
neither installed, then the plugin is installable.
The same logic would be applied to axis2 and cxf depends.
Thats a capability that IMO cannot be reasonably be pushed onto the
dependency system, or the "requires" system. We could push it onto
the obsoletes system but I doubt people would like it. As I've said
repeatedly in the past we need another system to deal with this.
The closest analogy I can think of is separation of duty constraints
in an rbac system.
I think what we are thinking about is rules like "you can only have
one of {jetty, tomcat} installed" and "you can only have one of {cxf,
axis2} installed}. Note that this may not be a great formulation
because if we come up with say a resin integration we'd like to have
the rule on old servers magically update to "you can only have one of
{jetty, tomcat, resin} installed". Also note that our existing javaee
servers don't follow the "you can only have one of {cxf, axis2}
installed" rule.
The closest to a solution I've thought of is to have a set of rule-
keys associated with each plugin such as web-container or webservice-
container and then have rules like "only one web-container". I think
this would satisfy the "new implementation" problem illustrated above
by the hypothetical resin plugin but I don't know what to do about the
"we want both installed but only one running" problem. For that
matter maybe we only want contraints on what will start, not what will
run. If we have both cxf and axis installed, why not supply just one
ee server with both jetty and tomcat installed and use tomcat instead
of jetty with a command line flag, like we do with cxf/axis2?
Whenever I start thinking about this it rapidly seems like we'd need a
big logic engine to provide a reasonable solution so I fall back on
user discretion. I'm happy to keep discussing it however.
thanks
david jencks
-Donald
David Jencks wrote:
On Sep 11, 2008, at 11:13 AM, Donald Woods wrote:
OK, it's because of wanting to install on a framework assembly....
Guess we're stuck with this for 2.1, but never liked this
approach, especially given we are providing Tomcat and Jetty
versions of each sample and most do truly prereq a web container...
I disagree with this approach for 2.2 since we'll have plugin
profiles that users should be using instead of starting with the
framework assembly.
what? why does the existence of the framework profile change the
reasoning? You need enough of a server to install plugins, then
everything else required for the app is pulled in. The framework
profile defines this minimal server. The framework profile just
makes it easier to assemble servers, it doesn't change how to add
stuff to a server. I don't see any relevance of any of the other
profiles since they are designed to help with assembling servers
with specific capabilities, which is irrelevant to the process of
installing plugins into a frameworks server.
not sure how coherent this is but I don't understand what you are
saying at all.
thanks
david jencks
-Donald
Joe Bohn wrote:
We had this discussion a while ago (along with a lot of other
samples issues). The results were summarized in the wiki status
page: http://cwiki.apache.org/GMOxPMGT/geronimo-samples-212-release-work-items.html
Here's the thread where it was discussed:
http://tiny.cc/uVkbL
Joe
Donald Woods wrote:
Seems that only one of the samples has the tomcat/jetty
prerequisite set. Why? Shouldn't we include this setting so
the Plugin portlet will only allow the appropriate samples to be
installed?
-Donald
