Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[swordfish-dev] Chat transcript 6/11/2008

Title: Chat transcript 6/11/2008
[START Transcript 6/11/2008]

Volodymyr Zhabiuk
@Dietmar: You have created the unit test org.eclipse.swordfish.core.planner.PlannerTest. But basically it doesn't test any functionality. Should I remove it?

Dietmar Wolz
no it shouldn't be removed since it shows how I think local unit tests could be formulized using a local spring application context. Of course PlannerTest should and will be extended - feel free to do so if you like - any functionality which can be tested independent from osgi could be tested locally

Volodymyr Zhabiuk
@Dietmar: LocalMavenRepositoryLocator is not need to be packaged into the spring jar. We can use delegation instead of inheritance
public class LocalMavenRepositoryLocator implements ArtifactLocator {
    private LocalFileSystemMavenRepository delegate;
public Resource locateArtifact(String groupId, String artifactId, String version, String type) {
 Resource localMavenBundle = delegate.locateArtifact(groupId, artifactId, version, type); // init() is private
 localMavenBundle = delegate.localMavenBundle(groupId, artifactId, version, type);// I know that this method is protected. But we may use reflection
 return localMavenBundle;
}
...
}
Does it solve the problem?

Dietmar Wolz
No objection, as long as it works. Make sure that the correct locateArtifact is called

Volodymyr Zhabiuk
Ok. Thanks

Dietmar Wolz
I fear there could be osgi import problems, so use the integration test to check if everything is ok

Volodymyr Zhabiuk
Sure.
Yesterday after refactoring I checked the implementation on the Swordfish TargetPlatform and everything worked well

Andrey Kopachevsky
I'm currently working under integragion tests: testInterceptorRegistration and testStrategies failed
so test in generally works, you can update planner.test to check this out

Dietmar Wolz
will do
trying to do maven install for core.planner
Downloading: http://s3.amazonaws.com/maven.springframework.org/release/org/springframework/spring-context/2.5.1/spring-context-2.5.1.jar
any explanation for that? we want to use spring 2.5.5

Volodymyr Zhabiuk
SMX4 uses this version of the spring framework
it's the transitive dependency

Dietmar Wolz
ok
now I get java.lang.IllegalStateException: Unable to find dependency information for: org.apache.servicemix.nmr/org.apache.servicemix.nmr.api/version
which means there is no dependency in the plannert.test pom.xml to smx4 core. Didn't you have the same problem?
why do we have this dependency at all? I know you needed to uncomment                 getBundle("org.apache.servicemix.nmr", "org.apache.servicemix.nmr.api"),
but why?

Volodymyr Zhabiuk
As discussed with Andreas, we need to access smx EndpointRegistry via the SwordfishContext
As far as i remember it belongs to nmr.api

Dietmar Wolz
But if I comment out getBundle("org.apache.servicemix.nmr", "org.apache.servicemix.nmr.api") there seems no problem, can you check this at your site

Andrey Kopachevsky
@dietmar we have org.apache.servicemix.nmr.api as mandatory dependency for org.apache.servicemix.jbi.api, so it should be downloaded and added in your dependency file automatically
so try to clean and rebuild

Dietmar Wolz
anyway, there are the two red tests I will investigate

Volodymyr Zhabiuk
Curently I'm also working on the integration testing

Dietmar Wolz
The interceptor is not registered properly which means something is wrong with the listeners
is core.api removed from the api project? have you checked in this change?

Andrey Kopachevsky
yes
I chaned package name on core.planner.api in planner.test MANIFEST.mf
otherwise there are was unresolved import exception in tests

Dietmar Wolz
ok, was a problem with eclipse not updating correctly. seems that the (now empty) core package is still in svn
now I cannot compile the api project, there is no dependency to smx core in the pom, why does this work at your site?

Volodymyr Zhabiuk
did you update the parent pom.xml?
BTW LocalMavenRepositoryLocator in the eclipse.swordfish package works
So we don't need to use the patched spring jar anymore

Dietmar Wolz
what about the task 2) remove (again, sorry) getType from interceptor and set a type property in planner.InterceptorListener using volodymyrs technique and use this propety in planner.test.TestFilterStrategy instead of getType ?

Volodymyr Zhabiuk
Now the InterceptorRegistry returns actual instances instead of proxies
@Dietmar: I will look, why these 2 tests are failing

Dietmar Wolz
volodymyr, please debug onBindIntercepter, there is something wrong with your technique used there WARN [org.springframework.osgi.service.importer.support.internal.collection.OsgiServiceCollection] - serviceChanged() processing failed
java.lang.NoSuchMethodError: org.springframework.osgi.service.importer.ImportedOsgiServiceProxy.getServiceReference()Lorg/osgi/framework/ServiceReference;
at org.eclipse.swordfish.core.planner.InterceptorRegistry.register(InterceptorRegistry.java:28)
at org.eclipse.swordfish.core.planner.InterceptorListener.onBindInterceptor(InterceptorListener.java:20)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.osgi.util.internal.ReflectionUtils.invokeMethod(ReflectionUtils.java:108)
at org.springframework.osgi.config.CustomListenerAdapterUtils.invokeCustomMethods(CustomListenerAdapterUtils.java:154)
at org.springframework.osgi.config.OsgiServiceLifecycleListenerAdapter.bind(OsgiServiceLifecycleListenerAdapter.java:186)
at org.springframework.osgi.service.importer.support.internal.util.OsgiServiceBindingUtils.callListenersBind(OsgiServiceBindingUtils.java:50)
at org.springframework.osgi.service.importer.support.internal.collection.OsgiServiceCollection$Listener.serviceChanged(OsgiServiceCollection.java:106)
at org.eclipse.osgi.framework.internal.core.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:91)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:1248)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:211)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:141)
at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEventPrivileged(Framework.java:1563)
at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEvent(Framework.java:1538)
at org.eclipse.osgi.framework.internal.core.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:122)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.createServiceRegistration(BundleContextImpl.java:666)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:617)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:685)
at org.eclipse.swordfish.core.planner.test.PlannerITest.testInterceptorRegistration(PlannerITest.java:247)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:164)
at org.springframework.osgi.test.AbstractOsgiTests.osgiRunTest(AbstractOsgiTests.java:553)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:193)
at org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:178)
at org.springframework.osgi.test.internal.support.OsgiJUnitTestAdapter.osgiRunTest(OsgiJUnitTestAdapter.java:76)
at org.springframework.osgi.test.internal.support.OsgiJUnitService$1.protect(OsgiJUnitService.java:101)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at org.springframework.osgi.test.internal.support.OsgiJUnitService.runTest(OsgiJUnitService.java:98)
at org.springframework.osgi.test.internal.support.OsgiJUnitService.executeTest(OsgiJUnitService.java:71)
at org.springframework.osgi.test.internal.support.OsgiJUnitService.runTest(OsgiJUnitService.java:45)
at org.springframework.osgi.test.JUnitTestActivator.executeTest(JUnitTestActivator.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.osgi.test.AbstractOsgiTests.invokeOSGiTestExecution(AbstractOsgiTests.java:397)
at org.springframework.osgi.test.AbstractOsgiTests.runBare(AbstractOsgiTests.java:206)
at org.springframework.osgi.test.AbstractOsgiTests$1.protect(AbstractOsgiTests.java:184)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at org.springframework.osgi.test.AbstractOsgiTests.run(AbstractOsgiTests.java:181)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
INFO [org.eclipse.swordfish.core.planner.test.PlannerITest] - Interceptors: []
DEBUG [org.springframework.aop.framework.JdkDynamicAopProxy] - Creating JDK dynamic proxy: target source is EmptyTargetSource: no target class, static

Oliver Wolf
@volodymyr: as far as i understood from dietmar, you're now trying to replace the service proxy by the actual service implementation object... i'm not sure if this is really a good idea, because then the registry will continue to hold a reference to the service even if the bundle is deinstalled

Volodymyr Zhabiuk
@Oliver: Sure we should discuss that
@Dietmar: ok I will try to debug and fix that tests

Dietmar Wolz
see for instance http://stochastyk.blogspot.com/2008/05/spring-dm-and-osgi-service-proxy.html
When you refer a service using osgi:reference, spring-dm creates a proxy over the service and injects the proxy into your code. This proxy protects the users of the service from the lifecycle of the service. So if the underlying service goes down, your code need not be aware that it should look up and bind to a new service.
you definitely loose useful functionality when accessing the service directly - perhaps the old idea of just setting a type property should be considered again

Oliver Wolf
@dietmar i second that... setting the type property makes the whole way dealing with inteceptors more uniform. everything is a property, but some are guaranteed by the core to be set.

Volodymyr Zhabiuk
Could we take the following measures instead of injecting the actual instances:
1) The interceptor registry may add the property 'type' while registering the interceptor(So the interceptor's class name  can be retrieved as an interceptor's property)
2) using notation  <osgi:service ref="loggingInterceptor" auto-export="interfaces"/>. It means that the interceptor will be published as an osgi service with all the interfaces it implements

Dietmar Wolz
ok, but why would you register the service for all implemented interfaces? Seems sufficient it is registered as Interceptor

Oliver Wolf
@volodymyr: agreed, but 2) cannot be guaranteed since any implementor of an interceptor is free to register the interceptor in any way he likes, even without using spring. so 1) will be the only reliable method

Volodymyr Zhabiuk
ok

Andrey Kopachevsky
I've commited exception listener refactored according latest discussions
and moved example listener realization in separate samples project.
It's name org.eclipse.swordfish.exceptionlistener

Volodymyr Zhabiuk
@dietmar: The test is failing because of the classloading issue inside the org.eclipse.osgi.framework.internal.core.BundleContextImpl. Need to spend more time to investigate
By the way it's a good practice to write each test method in the way that it is completely isolated from the previous tests. In our integration test interceptors registered in one test method are taking into account in another
If you don't mind I will refactor that

Dietmar Wolz
don't mind

[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.
 

Back to the top