“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.
Solution
Required 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.