RE: Eclipse RCP apps and Tuscany
Here's a big long winded explanation on how we got Tuscany to work with
Eclipse for now while other solutions are looked at.
This is all based on the 1.01 branch in the repository. Also, we have no
idea if this is the right or wrong way to do things. But, it's working for
us right now so...
Any feedback would be appreciated.
Tuscany resource loading in Eclipse RCP
Problem:
Tuscany loads composite configuration files using the class loader
getResource() method,
but in the eclipse RCP environment, a special class loader is used that
locates the resources
by the bundle (plugin) they are located in. The URL returned by
getResource() is in the form:
"bundleresource://plugin##/resourceName" instead of an absolute file path
starting with "file://".
Since this special type is not handled, Tuscany can not locate any
resources.
Solution:
Eclipse provides a means to add a ClassLoadingHook, which is an interface
that provides methods
that can be implemented to create and use a custom class loader for a
particular bundle (plugin).
The ClassLoaderHook is added to the system by implementing and adding a
HookConfigurator implementation.
A plugin must be created that depends on the org.eclipse.osgi plugin.
Note that all of the classes needed to setup the custom class loader are
marked with restricted access
by eclipse, but may still be implemented and used.
HookConfigurators are loaded by OSGI prior to the bundle loading.
A HookConfigurator (org.eclipse.osgi.baseadaptor.HookConfigurator) has an
addHooks() method which passes in a HookRegistry object. The
addClassLoadingHook() method is used to pass in the new ClassLoadingHook
(org.eclipse.osgi.baseadaptor.hooks.ClassLoadingHook) created.
Within the ClassLoadingHook implementation, the main method of interest is
createClassLoader() which should be used to create a custom class loader
that will properly return the file URLs from getResource() (mentioned
below). All other methods can return null or false accordingly.
A custom class loader could be returned for all plugin bundles, or for
particular bundles based on the use case desired. For adding it to only the
plugin bundles containing Tuscany configuration files, the BaseData object
can be used to determine the bundle name using data.getSymbolicName().
To create the custom class loader, extending the default used by the eclipse
RCP seemed the best approach to not lose any other components of the class
loader. That class is DefaultClassLoader
(org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) and the only
method that needs to be overridden is getResource(String). The constructor
method must take the same arguments as DefaultClassLoader, and those are the
parameters passed into createClassLoader() in the ClassLoadingHook.
To properly check that the resource being returned was listed with the
custom "bundleresource" prefix, the following code can be used:
public URL getResource(String name) {
URL resource = super.getResource(name);
if (resource == null) {
return null;
}
try {
URLConnection connection = resource.openConnection();
if (connection instanceof BundleURLConnection) {
BundleURLConnection bundleConn = (BundleURLConnection)
connection;
//Gets the absolute File path URL
return bundleConn.getFileURL();
}
}
catch (IOException e) {
// Ignore Exception.
}
return resource;
}
Configuration file:
The final addition to the plugin in the inclusion of a
hookconfigurators.properties" at the base level of the plugin which includes
the following line: hook.configurators=FullClassName
FullClassName is the class name of the HookConfigurator implementation in
the plugin.
Exporting and Use The plugin must now be exported and include the
manifest.mf file, the classes, and the hookconfigurators.properties file.
The plugin must be exported as a JAR (not a folder) and the version number
must be appended on the end (which should happen automatically) in the form
pluginId_version.jar The exported plugin must be placed in the target
platform in the same folder as the org.eclipse.osgi plugin to work properly.
At runtime, for the plugin to be recognized as an extension, one of the
following options must be performed:
1) Config.ini
Add this line to the config.ini of the application:
osgi.framework.extensions=plugin_id_name
2) Runtime VM argument
Add the following line to the VM arguments
-Dosgi.framework.extensions=plugin_id_name
For more details regarding Eclipse Adapter Hooks, see:
http://wiki.eclipse.org/Adaptor_Hooks
-Jason
> -Original Message-
> From: Jason Clark [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 9:11 AM
> To: tuscany-user@ws.apache.org
> Subject: RE: Eclipse RCP apps and Tuscany
>
> We found a work-around, but it involves using some classes from the
> Eclipse
> internal package, which is frowned upon by them. It's more of a fix for
> eclipse than making the
RE: Eclipse RCP apps and Tuscany
We found a work-around, but it involves using some classes from the Eclipse internal package, which is frowned upon by them. It's more of a fix for eclipse than making the app OSGi friendly though. I'll get more details and post them soon. -Jason > -Original Message- > From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 20, 2007 6:38 AM > To: tuscany-user@ws.apache.org > Subject: Re: Eclipse RCP apps and Tuscany > > Jason Clark wrote: > > We tried launching Tuscany in an RCP application but ran into a lot of > > class loading problems. In particular, for finding resources using > > Thread.currentThread().getContextClassLoader and > > ClassLoader.getResource, i.e. getting the classLoader from the thread or > > class. Has anyone run into this problem before? > > > > > > > > -Jason Clark > > > > Rajini is currently working on making the Tuscany runtime OSGi-friendly > and has run into similar problems. > > What you describe is a good and increasingly common use case for > Tuscany, I think we should have a sample plus an integration test using > Tuscany from RCP. > > Are you interested in contributing a test case? Then we can fix the > runtime to make it work, and once the test case is in the build we can > make sure that it continues to work over time :) > > -- > Jean-Sebastien > > - > 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]
Re: Eclipse RCP apps and Tuscany
Jason Clark wrote: We tried launching Tuscany in an RCP application but ran into a lot of class loading problems. In particular, for finding resources using Thread.currentThread().getContextClassLoader and ClassLoader.getResource, i.e. getting the classLoader from the thread or class. Has anyone run into this problem before? -Jason Clark Rajini is currently working on making the Tuscany runtime OSGi-friendly and has run into similar problems. What you describe is a good and increasingly common use case for Tuscany, I think we should have a sample plus an integration test using Tuscany from RCP. Are you interested in contributing a test case? Then we can fix the runtime to make it work, and once the test case is in the build we can make sure that it continues to work over time :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cannot obtain composite service directly
Adrian Mos wrote: Hi Luciano, Thanks for your help! Indeed, if I use /$promoted$. it actually works (in my case "InnerWeatherComponent/$promoted$.InnerWeatherService"). However as you mention in your older post, we should definitely be able to just look up the directly. The current workaround means that the client must know the actual component promoting the service and if the composite writer decides to wire the service differently (to another component exposing the same interface), the client must know about it. Therefore, in the current situation, the composites do not "hide" their internal structure properly and in my view this is not completely aligned with the SCA "philosophy". It's a bug, getService(interface, InnerWeatherService) should work if InnerWeatherService is declared in a top-level composite (i.e. a composite added to the domain level composite). Could you please open a JIRA issue for this? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WS-Security support for WS binding
On Nov 20, 2007 3:30 PM, Jeff Davis <[EMAIL PROTECTED]> wrote: > Hi, > > > > I'm trying to determine whether the WS Binding supports WS-Security such > as the UsernameToken profile? From what I can gather, I only found HTTP > basic authentication support? > > > > If WS-Security isn't currently supported, is that on the roadmap? > > > > Thanks! > > > > Jeff > > > > Btw., Tuscany is an amazing accomplishment! > > Hi Jeff. Venkat's our expert at this and he's in a different time zone so I just took a look at the secure service sample he has in trunk in subversion [1]. Looking at it it seems that UsernameToken is supported. For example, There is a policy intent in the definitions.xml file [2] Communitcation thro this binding required Authentication. and a statement of policy that supports this intent UsernameToken helloworld.ServerPWCBHandler This is associated with the application in the helloworld.composite file [3] http://helloworld#wsdl.interface(HelloWorld)" /> http://localhost:8085/HelloWorldService"/> Looking back at the 1.0 release this sample was included so you should be able to try it out. Generally we are using Apache Rampart to provide our WS-Security support and the idea with policies of course is that the framework allows new policies to be defined fairly easily so if there are things that you need that are not supported then lets discuss here and work out how to enable them. Regards Simon [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service-secure/ [2] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service-secure/src/main/resources/definitions.xml [3] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-ws-service-secure/src/main/resources/helloworldws.composite
WS-Security support for WS binding
Hi, I'm trying to determine whether the WS Binding supports WS-Security such as the UsernameToken profile? From what I can gather, I only found HTTP basic authentication support? If WS-Security isn't currently supported, is that on the roadmap? Thanks! Jeff Btw., Tuscany is an amazing accomplishment!
Release and debug versions
Hello. I have some problems with running samples in SCA Native Incubator-M3 on Windows XP. I ran binary distribution sample - all was ok. Then I build Incubator-M3 project sourse distribution sample in MS VC++ 2005 with release solution configuration. Then I ran it - all was ok. Then I build Incubator-M3 project sourse distribution sample in MS VC++ 2005 with debug solution configuration. Then I ran it - the process was broken with this comment: "6044:4460 Unsupported implementation type: http://www.osoa.org/xmlns/sca/1.0#CPP Implementation calculator_client: exception caught: Exception Class: SystemConfigurationException Description: Implementation type not supported: http://www.osoa.org/xmlns/s ca/1.0#CPPImplementation Origin: File:c:\tuscany_sca_sourse\runtime\core\src\tuscany\sca\model\mod elloader.cpp Line:383 Function:tuscany::sca::model::ModelLoader::addComponent Path: File: c:\tuscany_sca_sourse\runtime\extensions\cpp\src\osoa\sca\comp ositecontext.cpp Line: 101 Function: osoa::sca::CompositeContext::getCurrent" I think that this exception follow from type of solution configuration. The debug case is not runnable because of the dll-files in core of Tuscany, which was build with release solution configuration. My questions are: 1. How building with debug differ from release? 2. Hou to run samples after debug-case of building? 3. Hou can I debug my own samples? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Java SDO] What should we be attacking?
What should we be concentrating our efforts on in SDO Java. I posted a while back to suggest we think about the content of a next release. We've had a few fixes go in recently, but I'd like to see more consideration of release content before we crank the handle. It would be great to see a balance of new features and bug fixes. For my part I want to get back to ... TUSCANY-1527Allow for custom data binding of DataObjects in a Swing UI TUSCANY-1493Snapshot mapping framework to convert DataObjects to and from Java objects as soon as I can. And I believe that at least 1527 can move beyond proof of concept in my sandbox, and become part of the trunk. I've been taking a pass through the SDO java JIRA backlog, and seeing from my perspective what's simple / tricky / big / high priority etc, etc. Of course simplicity is in the eye of the beholder, for example, I don't view the OSGi topic as simple as I don't have experience there, but someone out there may find it so; if so please speak up. The same goes for priority, etc. As you might imagine, in my estimation there are no simple high priority JIRAs left, but there are a few simple medium priority ones, or simple low priority ones that would be good to just get out of the way. These are Simple Starters === TUSCANY-1360New SDOUtil: Getting the enumeration facet TUSCANY-1178DynamicTypesFromSchemaTestCase expecting *Object types to be created TUSCANY-1263XMLEqualityChecker too strict TUSCANY-1359New SDOUtil: Upper and lower bound on properties where 'isMany' is true TUSCANY-1384SequenceAddOpenTest.setUp() needs to check if type exists before creating it TUSCANY-1545Change default XML encoding to "UTF-8". TUSCANY-1659SDO DateConversion test cases fail under linux Particular Skills JIRAs = For anyone with JavaJet experience there's TUSCANY-1483Static SDO generator: problem with elements named internal* which would be simple For someone with maven build experience there TUSCANY-257 recently added file Interface2JavaGenerator.java is not compatible with JDK 1.4 For someone with Grobu-Utils and maven skills there's ... TUSCANY-1182Add multi-threaded test case for data object creation Someone with Axis2 skills TUSCANY-1038SDO databinding for Axis2 (This may be better done within the Axis2 project) OSGi Skills TUSCANY-1293SDO does not work with OSGi Biting off something a bit Bigger For somebody wanting something a bit bigger to take on there's TUSCANY-1192Preserve demand created global properties TUSCANY-1361New Util: Validation TUSCANY-1021CopyHelper and EqualityHelper should handle ChangeSummary TUSCANY-1817Improve SDO test infrastructure to re-use/re-execute most dynamic tests as static tests This isn't a full list, and I may post more soon. Please feel free to disagree with my assessment and speak up with your own priorities. Better still step forward to help fix something. I'd be only too pleased to help you understand what's required. Kelvin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
