This sounds extremely fine grained, almost to the point of taking
modularity to the point of two, possibly three, projects per service
which I think is unmanageable.
We should keep the RMI binding as an extension for sure. But that
binding has an need for a physical service (RMIHost) whose
implementation should be provided by the host environment as only the
host knows how to create and schedule work from physical endpoints
(sockets).
We have a M-1-N situation here, multiplied by the potential number of
host services. I think we should keep all host interface classes
(like RMIHost and ServletHost) in host-api so that host providers are
at least aware of the host services extensions may require (they
always have the option of not implementing them).
--
Jeremy
On Aug 27, 2006, at 10:14 PM, Jim Marino wrote:
I think we still have the same problem of piling everything into
one project. We may wind up with a project having only one class
(the interface) but this may be the best solution since it avoids
having people update the Tuscany namespace with their extensions.
Jim
On Aug 27, 2006, at 10:08 PM, Jeremy Boynes wrote:
Would host-api be the right place for RMIHost?
--
Jeremy
On Aug 27, 2006, at 7:28 PM, Jim Marino wrote:
I came across a couple of things related to the RMI binding
today. Venkat, when you get a chance, could you take a look at
these?
- Shouldn't RMIHost be in a separate extension package other than
SPI? This question relates to bindings in general. I would like
to avoid changing SPI for every new type of host provider we have.
- The RMI exception hierarchy should extend from
TuscanyRuntimeException, TuscanyException, or an SCA exception
if application code is involved (e..g RemoteServiceException).
Examples can be found at:
http://incubator.apache.org/tuscany/codeguidelines.html#Exception%
20Handling
- There are a couple of PMD violations in the binding package.
When you get a chance, can you take care of them? (mvn -
Psourcecheck)
Thanks,
Jim
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
