[swordfish-dev] Chat transcript 30/10/2008

[Oliver Wolf <oliver.wolf@xxxxxxxxx>]

Title: [swordfish-dev] Chat transcript 30/10/2008

[START Transcript 30/10/2008]

Volodymyr Zhabiuk
The integration test have passed
But maybe we should consider the possibility to load bundles from the target platform instead of the local maven repository?
Dietmar, what's your opinion?
BTW did your merge the planner implementation from the swordfish.core?
We also need to discuss the  necessity of the public Class<?> getType() method in the Interceptor interface

Oliver Wolf
@volodymyr: regarding CM: What do you mean by "should i create the test case before cm is implemented"? We're going to use the Equinox CM implementation, so it's already implemented.  Maybe I wasn't exact enough in my wording... it's not really a test case, but exploration... create a simple test component that implements ManagedService and see how it can be configured with the ConfigurationAdmin service

Volodymyr Zhabiuk
Ok. Will do

Dietmar Wolz
Hi Volodymyr, sorry, my skype window wasn't updated. If we want to use the maven osgi test framework, we have to use maven. Perhaps we find a way hoe we can keep our targep platform consistent with maven (master pom containing version numbers, maven deployment in the target platform project pom, ...)
Will do now the merge from core, I volunteered to do so, but maybe I missed your ok
The getType() method in Interceptor is necessary because getClass() is not usable for a spring osgi proxy object. Alternatively an getId() would be possible, but we need some means to identify Interceptors inside the filtering process.
Try to replace getType() ba getClass() in the integration test and you see what I mean

Volodymyr Zhabiuk
Currently I'm investigating the opportunity to get the actual type from the JDKAopProxy
It seems to be possible

Dietmar Wolz
This would indeed change the necessity of a getType() method

Volodymyr Zhabiuk
We can get the serviceReference from the jdkAopProxy
(ImportedOsgiServiceProxy) proxy).getServiceReference()
So the spring DM may inject the bundleContext if the bean implements the BundleContextAware interface. We can retrieve the actual interceptor instance in the following way
bundleContext.getService(((ImportedOsgiServiceProxy) proxy).getServiceReference());
@Dietmar: Didn't understand your statement <<If we want to use the maven osgi test framework, we have to use maven. Perhaps we find a way hoe we can keep our targep platform consistent with maven (master pom containing version numbers, maven deployment in the target platform project pom, ...)>>
This is just the spring osgi test framework. And it should be configurable enough to load bundles from any place, not only from the local maven repo. This way we may use the bundles from the targetPlatform, which were downloaded manually and currently can not be accessed from the public maven repos
Basically we need to conduct the integration testing against the SwordfishTargetPlatform

Dietmar Wolz
@Volodymyr: checked in some modifications of the api (SwordfishException is RuntimeException) as part of the refactoring. Before adding javadocs please checkout the new version

Volodymyr Zhabiuk
sure
thanks

Dietmar Wolz
The spring osgi testing framework is not configurable in the sense that the maven dependency can be simply removed

Volodymyr Zhabiuk
So you state that the spring osgi test framework can load bundles only from the local maven repo?

Dietmar Wolz
coud you please try out to apply your ImportedOsgiServiceProxy) proxy).getServiceReference() technique to TestFilterStrategy (replacing getType()?) and check in the result if it works?

Volodymyr Zhabiuk
Sorry but I'm busy right now with the configuration stuff

Dietmar Wolz
pring osgi test framework can load bundles only from the local maven repo, and also the extension from guiliome I took from the smx4 kernel related to version consistency
just after the configuration stuff is finished

Volodymyr Zhabiuk
Don't know, I have tested this technique in the Swordfish osgi environment for the interceptors.
It works
I'm not sure that we need to use spring osgi test framework if it's not mature enough to load bundles from the configurable places

Dietmar Wolz
So how would you do osgi integration tests which perform equally under maven and the ide and use a single source for the bundle versions? We can build the target platform later using maven to ensure consistency

Volodymyr Zhabiuk
This is a good idea, but currently we  can not compose the targetPlatform using maven
It would be great if we could specify the bundle location by the system property

Oliver Wolf
i basically agree, but i think for the time being we should be able to live the few limitations the spring osgi framework currently has. the advantage of being able to run the same testcases both from the ide and as part of a headless build outweights the disadvantage of a local maven repo only
it doesn't mean that we'll have to go with it forever... maybe some day a better way of executing osgi testcases in a maven environment is available somewhere
but for now, i'd suggest we use it. we'll have to provide out own public maven repo with the eclipse-approved 3rd party deps anyway
reg. your refactoring... dietmar and me have discussed the planner design over lunch
seems like there are basically 2 approaches:
1) the planner "knows" that there can be multiple strategies both for sorting and filtering, invokes them in sequence and knows how to deal with errors
2) the planner only knows about exactly one sorting and one filtering strategy, but this strategy (and this is the default) might be able to delegate this task to a sequence of user supplied strategies and take care of handling error situations
the idea of 2) is to have the design explicitly reflect the fact that invoking a sequene of strategies is again a strategy (defined as: a way to achieve a result).
i feel that 2) might seem a bit overengineered and i'm a tad more in favour of 1), but we came to the conclusion that it's purely an implementation issue and doesn't affect and public apis, so it's always easy to change late
since the implementation and testcases for 2) exist, we should start with that and refactor late if needed

Volodymyr Zhabiuk
Actually it affects public apis and cannot be changed in future
In the planner interface for the second approach public void setSortingStrategies(List<SortingStrategy> sortingStrategies);
for the first one public void setSortingStrategy(SortingStrategy sortingStrategy);

Oliver Wolf
you're right, but i don't consider Planner a public API since it's nothing that we expect users to provider their own implementations for. that's why we factored the strategies out into public interfaces... i'm aware that this is not reflected in the package structure yet.... we're going to introduce a new package org.eclipse.swordfish.core.api to hold all the internal interfaces that should not be publicly accessible

Dietmar Wolz
refactored and checked in the new api structure

Volodymyr Zhabiuk
@Oliver: I'm fine with the 2nd approach. It's not very important
But in general I'm concerned about the tendency to make everything more complex than actually needed
Especially if it could be easily refactored to introduce new features

Oliver Wolf
@volodymyr: i'm with you on that one and i appreciate very much that you strive to keep things simple
i think once we have the first set of features done we should take some time to go through everything again and honestly ask ourselves whether we really need all this flexibility
hopefully, we'll have the chance to get some feedback from people outside the project at some point

Volodymyr Zhabiuk
Yep. It would be great
I have commited two sample projects to show that the managedService can not be notified from the other bundle unless the managedService bundle location is specified explicitly
IF the config consumer and provider reside in one bundle evertthing works well
Let's speak about the Configuration api
The configuration consumer might look like this

public interface ConfigurationConsumer {
   public String getPid();
   public void onConfigurationReceived(Map<String, ?> configurationData);
}
 
The configuration provider may change the configuration data via 

public interface SwordfishContext {
   public EndpointRegistry getEndpointRegistry();
   
   public void updateConfiguration(String pid, Map<String, ?> configurationData);
   
   ....
}
 
The SwordfishContext will be injected automatically if the bean implements SwordfishContextAware interface
The same as in Spring
I discussed the SwordfishContext idea with Andreas

[END]

Want to join the chat? 
http://www.skype.com/go/joinpublicchat?skypename=ranyart99&topic=Swordfish%20Developers&blob=Gu7tZh64gTuo551Icz6_iwhXVeXxQ0K4yEzI5XFwGdWIQ_-miteLtgSBILodJ8koN6Uwy9PiotEU5ewRYFqEJeUtl1Yhfc1ipuVwOFz0SWN9HwMZAeikprh0R_8


-- 
Wir bieten Trainings zu SOA:
Jetzt online auf unserer Homepage informieren und schnell buchen!
 
 
Oliver Wolf
Tel.:    +49 228-182 19059
Fax:    +49 228-182 19093
Mobil:  +49 160 98931313
oliver.wolf@xxxxxxxxxx
 
 
SOPERA GmbH - Open Source SOA
Subscription Services, Support & Maintenance, Training,
Technical SOA Consulting & Customized Development
www.sopera.com
 
SOPERA GmbH · Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter Spiegel
Standort Bonn: Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 15336
Standort München: Hohenlindnerstraße 11b · 85622 München
 
 
Vertraulichkeitshinweis: Diese Nachricht und jeder übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, den Sender unverzüglich hiervon in Kenntnis zu setzen.