Not every type - just those that we have tried to define a host
interface for. They will be in the Tuscany namespace anyway, it's
just a question of whether they are together in the host-api jar, or
spread amongst a load of other very small jars.
How about we say that it's OK to add them to host-api provided they
only depend on "standard" interfaces (such as javax.rmi, javax.jms,
org.osgi) rather than on any implementation of those interfaces? "Non-
standard" ones (that introduced a dependency on something such as
JINI or say a specific JMS implementation) would go into separate
modules.
We can then mark the dependencies as "provided" as they are likely to
be present in the host environment anyway (e.g. any J2EE server will
automatically provide most of javax...).
--
Jeremy
On Aug 27, 2006, at 10:50 PM, Jim Marino wrote:
Hmm, the converse to that is we have to put an XHost in the Tuscany
namespace for every type. I don't think this is that unmanageable
as OSGi does this. The actual service implementation would be in
the project for the host, while the interface would be in a
separate project which a binding would depend on.
Jim
On Aug 27, 2006, at 10:44 PM, Jeremy Boynes wrote:
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]
---------------------------------------------------------------------
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]
