[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[wtp-dev] Re: Server API change proposal
|
From our brief discussion @ eclipsecon heres a snippet of a note on
that clarifies some ideas I mentioned from a Geronimo runtime
perspective. Keep in mind these are just ideas and not direction.
But I'd like to see if it makes sense to extract some of these
concepts and apply them to the server tools framework. The primary
question is wether these would be implemenentation details of the G
server adapter or wether this "build your own server/runtime - app-
centric" approach makes sense to integrate into the framework so that
other adopters could make use of it.
1. User downloads a full Geronimo instance and does initial
customization using the installer. Pretty much like the paradigm
described above.
2. User downloads a bootstrap agent (much like Cygwin) and then
chooses either the pacakges they want (specific OSS projects) or the
features they want (JMS, Servlet 2.4, EJB 1.1, Spring, etc.) The
downloaded agent would resolve the required dependencies and suck
down the appropriate parts and configure the runtime.
3. Similar paradigm to above but rather than running a single server
instance they would specify a target location to export a server
image that would be bootable. The instance they operate from is an
AppServer factory and not an AppServer instance. The interfaces
would include a GUI (nice user interface, dynamic resolution of
dependencies, etc.) as well as a command line utility that could
build the instances required for a specific set of applications.
4. A variation on the above would also install the application
artifacts and create disposable runtimes. Users could then take
these images and distribute them in a cluster and they would be fully
functional containers but are designed to be disposed of after use.
The paradigm of defining and iterating a server instance doesn't
exist in this mode. The "disposable" instances would be able to
federate into a managable cluster from an operations perspective but
would be limited to starting and stopping the servers and pulling
runtime statistics.
- sachin
On Mar 22, 2006, at 9:24 AM, Konstantin Komissarchik wrote:
“registered to module/facet id + server/runtime id”
We should probably utilize the eclipse expressions framework here.
We already have a project property tester for facets. We would have
to write one for the runtime.
For the ordering, I think we can do something similar to what we do
for facets. Each delegate could specify which delegates it depends
on. We could then sort the list in the dependency order. Such a
system would be a lot less fragile than doing it based on an
ordinal number manually assigned to each delegate.
- Konstantin
From: Ted Bashor
Sent: Tuesday, March 21, 2006 6:27 PM
To: Thomas Yip; 'General discussion of project-wide or
architectural issues.'
Cc: Konstantin Komissarchik; 'Gorkem Ercan'; 'Sachin Patel';
'Timothy Deboer'
Subject: RE: Server API change proposal
One thing I would add is that the Publish process and the Archive
Export process should be very, very similar from an extension/api
point of view.
For both processes, I’d suggest that the WTP framework should be
based on running an ordered list of delegates registered to module/
facet id + server/runtime id. WTP would include some default/
reference delegate implementations – e.g. ones that assemble an
EAR, WAR, or EJB in a directory, ones that deploy to Tomcat, etc.
-Ted
From: Thomas Yip
Sent: Monday, March 20, 2006 7:01 PM
To: General discussion of project-wide or architectural issues.
Cc: Ted Bashor; Konstantin Komissarchik; Gorkem Ercan; Sachin
Patel; Timothy Deboer
Subject: Server API change proposal
Introduction
This proposal briefs the limitation we see with current server
publish API, and it suggests a solution. We had a short discussion
during a conference call on Mar 13th, 2006. (mainly around the
ServerBehaviourDelegate). The problem is also related to https://
bugs.eclipse.org/bugs/show_bug.cgi?id=123676
Current API
We learned the original design was driven by a need of a very
simply publish mechanism.
an adopter should able to implement a simply delegate and do the
publish work.
publish tasks was intent to be simple task.
most methods can be overridden.
BEA use-cases
We found the current API is not ideal for BEA needs.
We delay much of publish process until user do an explicit publish
action (menu item publish, or Run on Server).
We generates *.java file based on annotation of Java file in
publish time. We trigger project rebuild during process.
We insert information into application descriptors (web.xml,
application.xml) based on files on the project.
Generated artifacts can cause changes to the EAR or other modules
in the same application.
Publish application by application.
Publish failure should be isolated between modules.
For us, the publish process is better described as a 3 steps
process: Assembly (artifact generation), Packaging (we package
virtually), and Distribution (calls JSR-88 to distribute the
application to the server).
Limitation
The current SPI was driven by the need of simple publishing. The
publish process iterates module by a flattend module list (not
application by application.)
Because that most methods can be overridden, we can achieve our
goal reasonably well. However, it incurs maintenance risk, because
are not really implementing the delegate’s SPI. For example,
if a fix or an enhancement is made to PublishOperation, our server
adapter lag behind, and enhancement will not be supported.
We short circuit a few methods, such as publishModules() (which is
a violate the interface). If any of the methods is called by new
code that we haven’t overridden, it causes unexpected behaviour.
Because of the different design goal, we don’t implement the full
spec of ServerBehaviourDelegate. While such changes might not be
likely, an adopter should not be required to implement their
delegate in a way to violate the SPI contract.
SolutionRequired changes
We can eliminate the problem by the following changes:
Introduce another delegate. Let’s call it
BaseServerBehaviourDelegate for now. The current
ServerBehaviourDelegate should make extended of
BaseServerBehaviourDelegate. Most generic methods can be push up.
(such as state settings, module controls, resource delta
maintaince. But, it leaves out
code related to published module list, and the kind.
PublishOperation, and
all the publish methods. Introduce an adapter interface to indicate
PublishOperation is supported.
The changes will maintain compatibility for all current adopter,
and the original design goal. It enables adopter with different
needs to have full control of the publish process.
Either, makes publish operation optional. Push down
PublsihOperation related code to the original ServerBehaviour
Delegate.
Or, factors out PublishOperation into utility class or method.
Or, made PublishOperation not depends on the flatten module path
(IModule[] representing the sub module and its parents).
Introducing another extension point for UI to replace the hard-
coded publishTask page fragment. Move UI for publishOperation as an
extension.
A brief study of the code indicated that we should able to
implement it in a way that it doesn’t affect existing adopter.
Optional changes
A few optional changes can be introduced to ease the work of an
adopter.
Publishing application-by-application is common to many servers. We
might want to introduce another BehaviourDelegate.
Generic server is already use application-by-application approach.
We should look into merging the requirements.
Going further, we can also introduce the 3 steps publish process
for adopter with complicated publish use-case.
--------------------
Thomas Yip
Senior Software Engineer
BEA Systems
Email: tyip@xxxxxxx YIM: thomasleaf Phone: (206) 926-2906
Blog: http://theBigGrid.com/
"The complexity you remove can never fail." Burt Rutan.
______________________________________________________________________
_ Notice: This email message, together with any attachments, may
contain information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary,
copyrighted and/or legally privileged, and is intended solely for
the use of the individual or entity named in this message. If you
are not the intended recipient, and have received this message in
error, please immediately return this by email and then delete it.
