>> >> 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. I have worked on the project to add Hibernate mapping to the Eclipse IDE before and would be happy to help creating a plug-in if there is interest in this. However, I don't know enough about IntelliJ to attempt that plug-in. Jeremy Boynes <[EMAIL PROTECTED]> 08/15/2006 05:58 PM Please respond to [email protected] To [email protected] cc Subject Re: Debugging the runtime, was: IDE Plugins 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] ----------------------------------------- CONFIDENTIALITY STATEMENT: This e-mail transmission contains information that is intended to be confidential. It is intended only for the addressee named above. If you receive this e-mail in error, please do not read, copy, or disseminate it. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.
