On Aug 15, 2006, at 2:28 PM, Meeraj Kunnumpurath wrote:
Thanks Jeremy.
That was indeed a long email and also very informative. I take your
point that the components should be testable in isolation without
needing an SCA runtime to be available. The objective of unit
testing a component is to excercise all the code paths within the
component without worrying about its extrenal dependencies.
However, the dependencies need to be adequately mocked to realise
all the permutations of behaviour as defined by the contracts for
the dependencies, that would influence the internal behaviour of
the component being tested. From that perspective, using
SCATestCase class is an ant-pattern in the true spirit of testing
components in isolation.
+1
However, the SCATestCase class is relavant from an integration
testing perspective, where the componet is tested for its behaviour
in the context of a runtime. This is more applicable for testing
things that are more closely related to Tuscany like binding and
container extensions.
That was the intention behind it. It would use an installed version
somewhere to boot the runtime (using extensions present in that
runtime) and then deploy the application component to it to do
integration tests.
However, the motive behind my original email was the ability to run
the Tuscany runtime within an IDE, similar to how you would run
Tomcat within Eclipse for example. Debugging is only one use case
for this. I know there are implications around classloader
hierarchies and the like. However, some of those things have been
covered quite neatly on your post on module restructuring for
classloader changes. I thought on a longer term, we could also
extend this to provide richer functionality within the IDE, a
tuscany user can use to compose his services and use bindings,
containers etc from a Tuscany installation
I think this requires integration with an IDE in some way (e.g. as a
Eclipse or IDEA plugin) just like Tomcat is done. I think this would
be a very valuable contribution to have.
Another thing I have been wondering was rather than assuming
extension, boot libraries etc relative to the location from where
the launcher was loaded, would it be cleaner to have the ability to
override the locations for boot libraries, extensions etc using
system properties (I think this is already implemnted to a certain
extend using installDir, bootDir etc). The runtime should be
bootable from a minimum set of JARs on the system classloader and
from there onwards a child hierarchy of classloaders are built to
ensure isolation between the various deployed artefacts. In a
managed environment like a JEE container, this would start from the
EAR or WAR classloader.
The principle I was using here is that there would be ways to
configure the bootstrap process and the system scdl that it deployed.
For the launcher, this would be done on the command line in the form
of system properties or command arguments. The minimal set of JARs
would be very small - basically launcher and now hostutil. The
fishing the launcher is doing is for the case where those properties
are not specified so the launcher tries to find defaults based on
assumptions on how the installation directory is structured.
The webapp should work the same, with a minimal set added to the
webapp classloader (webapp and hostutil) and the rest coming from
assumptions about how a webapp would be laid out or from parameters
passed to the webapp.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
