ant elder wrote:
On Wed, Oct 1, 2008 at 6:21 AM, Jean-Sebastien Delfino
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
ant elder wrote:
On Mon, Sep 29, 2008 at 5:01 PM, Jean-Sebastien Delfino
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
ant elder wrote:
On Thu, Sep 11, 2008 at 5:37 PM, Jean-Sebastien Delfino
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>> wrote:
<snip>
I'll create a branch to make progress on this Equinox
porting
effort
without breaking everybody else. As I said before
it'll probably
take a few weeks to get most Tuscany samples and
itests up and
running, but I'd like to try to have a few core itests and
maybe a
Web Service or two working in the next few days.
Its been a few weeks now, what are the plans and time
frames for
merging this branch back into the mainstream trunk?
...ant
Still making progress on the Equinox bringup, going slowly as I'm
busy at work. Getting the whole runtime really working end to
end in
Equinox is going to require changes in many different places
in the
code, so don't expect miracles it's going to take time. Some
of the
changes may be possible to merge to trunk already if people
want to
help with that.
-- Jean-Sebastien
The problem with helping is that its difficult to work out what
are the changes. I've done a diff of the sca-equinox branch to
the trunk which is at:
http://people.apache.org/~antelder/temp/sca-equinox.diff
<http://people.apache.org/%7Eantelder/temp/sca-equinox.diff>.
Its huge, and lots of the changes seem quite unrelated to OSGi
class loading. Some changes from trunk get merged to the branch,
some don't, others get modified and then merged, there's also
what looks like new development not directly related to
OSGi/Equinox that goes into the branch but not trunk. If this
branch is to show what changes are needed for Equinox then
wouldn't it be clearer if the only changes in the branch were
directly related to Equinox? With the diff so huge now how can
this ever get merged to trunk?
...ant
I've always had trouble too working off flat diffs like that.
Merging / porting individual commits from the history should be
easier. That's what I've been doing to pull some changes from trunk,
and it's really easy once you've done it a few times and have
defined your merge processes with the Svn, diff, patch tools etc. If
you're interested in trying it, for more complicated cases (like
when I started to create the android branch) I've also found Git
very powerful at handling merges. Working off the history should
also help you pick only the changes that are not going to break the
trunk at this point, or pick them in a more convenient sequence for
example.
If that helps I could try to document the steps that I've been
following for various merge cases but I'm busy these days so it'll
probably take some time before I get to it.
If people want to help, at the moment I'm seeing issues with many
'dirty' cross module dependencies (tapping directly into impl
classes instead of going through the SPI.
An example is dependencies on o.a.t.sca.contribution.impl, causing this:
warning: Unresolved resource
META-INF/services/org.apache.tuscany.sca.node.SCANodeFactory found
in 15 org.apache.tuscany.sca.node.impl INSTALLED
severe: SCA Node could not be created
java.lang.reflect.InvocationTargetException
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
at
calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: org.osoa.sca.ServiceRuntimeException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
at
org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
... 25 more
Caused by: java.lang.reflect.InvocationTargetException
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:597)
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
... 26 more
Caused by: java.lang.IllegalStateException:
org.osgi.framework.BundleException: The bundle could not be
resolved. Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
at
org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
... 31 more
Caused by: org.osgi.framework.BundleException: The bundle could not
be resolved. Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
... 33 more
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
4.213 sec <<< FAILURE!
testDummy(calculator.CalculatorTestCase) Time elapsed: 4.153 sec
<<< ERROR!
org.apache.tuscany.sca.node.equinox.launcher.LauncherException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:174)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:83)
at
calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:44)
at junit.framework.TestCase.runBare(TestCase.java:132)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
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:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: java.lang.reflect.InvocationTargetException
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:155)
... 20 more
Caused by: org.osoa.sca.ServiceRuntimeException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:146)
at
org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:116)
... 25 more
Caused by: java.lang.reflect.InvocationTargetException
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:597)
at
org.apache.tuscany.sca.node.SCANodeFactory.newInstance(SCANodeFactory.java:128)
... 26 more
Caused by: java.lang.IllegalStateException:
org.osgi.framework.BundleException: The bundle could not be
resolved. Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:227)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getFirstServiceDeclaration(EquinoxServiceDiscoverer.java:191)
at
org.apache.tuscany.sca.extensibility.ServiceDiscovery.getFirstServiceDeclaration(ServiceDiscovery.java:83)
... 31 more
Caused by: org.osgi.framework.BundleException: The bundle could not
be resolved. Reason: Missing Constraint: Import-Package:
org.apache.tuscany.sca.contribution.service.impl; version="1.4.0"
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer.getServiceDeclarations(EquinoxServiceDiscoverer.java:225)
... 33 more
I'm starting to fix node-impl to only reference SPIs but I've not
been able to find what's causing the above exception, given that the
unresolved contribution.impl package is exported+imported right now
(as a workaround, but the workaround doesn't seem to work).
So if anybody has ideas about that exception, please let me know...
Thanks
--
Jean-Sebastien
So this branch is really a fork isn't it?
...ant
Is that a question or a statement? I don't really understand how you
come up to that conclusion.
It's not a fork, it's a branch to work through breaking changes (and
pretty complex changes I must say) which should allow our runtime to
correctly work as a set of modular bundles in an Equinox/OSGi environment.
I'm hoping that this work can somehow benefit Tuscany, by providing
code, patterns or maybe just a set of techniques that the project can
implement to work in Equinox/OSGi. It'll be up to the Tuscany community
to take a look and decide what can be reused or if it's just something
to study and learn from.
At the moment that Equinox port is still pretty broken, I've made
changes to start to clean up the dependencies on assembly.builder.impl
and contribution.service.impl for example, but there are many other
similar cross-bundle dependencies on implementation packages which will
take time to clean up.
--
Jean-Sebastien
