Exception when starting Kernel with latest sources from master
Martin Krasser
I just tested the latest version on master and found the following
exception during Kernel startup:
Exception in thread "main" java.lang.NoSuchMethodError:
org.springframework.beans.factory.support.DefaultListableBeanFactory.setSerializationId(Ljava/lang/String;)V
at
org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:128)
at
org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:465)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:395)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:197)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:172)
at
org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:158)
at sample.camel.Boot.<init>(Boot.scala:20)
....
at se.scalablesolutions.akka.kernel.Main.main(Kernel.scala)
That's most likely related to the merge-in of the spring branch which
uses spring 3.0 but camel depends on spring 2.5.6. I'll look more
detailed into it but don't have very much time left today. Is it to late
when I'll look into it tomorrow morning (if I can't fix it today)?
-Martin
--
Martin Krasser
Blog: http://krasserm.blogspot.com
Twitter: http://twitter.com/mrt1nz
Martin Krasser
Now, only spring 3.0 jars are on the classpath, no more mixtures of
spring 2.5 and 3.0 jars. I updated the dependencies in
AkkaProject.scala and will commit it to master soon.
-Martin
Jonas Bonér
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>
>
--
Jonas Bonér
twitter: @jboner
blog: http://jonasboner.com
work: http://scalablesolutions.se
code: http://github.com/jboner
code: http://akkasource.org
also: http://letitcrash.com
Martin Krasser
> Thanks a lot Martin. Oddly enough, I didn't get this when running the Kernel.
>
This likely depends on the order of the classpath entries whether the
exception is thrown or not. At least AkkaParent.removeDupEntries creates
a classpath in a non-predictable order (via Map.values.toList) and it
happened that the classpath generated in my environment unveiled the
problem. However, having a random order of classpath entries shouldn't
be a problem. The actual problem is that the generated distribution
contains contains different versions of the same artifact. This wasn't
only the case for spring 2.5 and 3.0; at the moment this is also the
case for the following artifacts:
- commons-codec
- commons-io
- commons-logging
- jackson-core-asl
- jsr-311-api
- stax-api
It may be that in these special cases this will not cause any issues but
we can never be sure unless we enforce the highest version of these
artifacts (if possible). I'm new to both sbt and Ivy so I can't say ATM
how to do that. I remember that Maven is doing that automatically when
including the runtime dependencies in an assembly descriptor.
-Martin
Jonas Bonér
all the other versions of Scala than 2.7.7 but I have not done that
for the other libs. Perhaps that needs to be done. But is a pain to
maintain.
On 21 March 2010 07:55, Martin Krasser <kras...@googlemail.com> wrote:
> Jonas Bonér schrieb:
--
Martin Krasser
wondering if sbt provides means for doing that automatically. In the
meantime, I browsed the sbt docs but couldn't find any hints (I've also
seen your post on the simple-build-tool mailing list regarding removal
of duplicates). Seems that the only way to resolve this issue ATM is to
exclude conflicting versions manually. I'll do that and commit it to master.
Am 21.03.2010 18:18, schrieb Jonas Bon�r:
> Right. This is bad. As you can see in the build file I manually remove
> all the other versions of Scala than 2.7.7 but I have not done that
> for the other libs. Perhaps that needs to be done. But is a pain to
> maintain.
>
> On 21 March 2010 07:55, Martin Krasser<kras...@googlemail.com> wrote:
>
>> Jonas Bon�r schrieb:
Jonas Bonér
> I've seen the manual exclusions in the build file but I was just wondering
> if sbt provides means for doing that automatically. In the meantime, I
> browsed the sbt docs but couldn't find any hints (I've also seen your post
It was Mark Harrah (sbt founder) that suggested the remove duplicates
method. So I don't think it has yet.
> on the simple-build-tool mailing list regarding removal of duplicates).
> Seems that the only way to resolve this issue ATM is to exclude conflicting
> versions manually. I'll do that and commit it to master.
Thanks a lot.
>
> Am 21.03.2010 18:18, schrieb Jonas Bonér:
>>
>> Right. This is bad. As you can see in the build file I manually remove
>> all the other versions of Scala than 2.7.7 but I have not done that
>> for the other libs. Perhaps that needs to be done. But is a pain to
>> maintain.
>>
>> On 21 March 2010 07:55, Martin Krasser<kras...@googlemail.com> wrote:
>>
>>>
>>> Jonas Bonér schrieb:
--
Martin Krasser
- commons-codec (1.2, 1.3 -> 1.3)
- commons-io (1.2, 1.4 -> 1.4)
- commons-logging (1.0.4, 1.1.1 -> 1.1.1)
- jackson-core-asl (1.1.1, 1.2.1 -> 1.2.1)
- jsr311-api (1.1, 1.1.1 -> 1.1.1)
- stax-api (1.0.1, 1.0-2 -> 1.0-2)
Kernel starts up properly, I also tried to run one of the REST examples
and the Camel examples - no issues found.
Am 21.03.2010 19:03, schrieb Jonas Bon�r:
> On 21 March 2010 18:57, Martin Krasser<kras...@googlemail.com> wrote:
>
>> I've seen the manual exclusions in the build file but I was just wondering
>> if sbt provides means for doing that automatically. In the meantime, I
>> browsed the sbt docs but couldn't find any hints (I've also seen your post
>>
> It was Mark Harrah (sbt founder) that suggested the remove duplicates
> method. So I don't think it has yet.
>
>
>> on the simple-build-tool mailing list regarding removal of duplicates).
>> Seems that the only way to resolve this issue ATM is to exclude conflicting
>> versions manually. I'll do that and commit it to master.
>>
> Thanks a lot.
>
>
>> Am 21.03.2010 18:18, schrieb Jonas Bon�r:
>>
>>> Right. This is bad. As you can see in the build file I manually remove
>>> all the other versions of Scala than 2.7.7 but I have not done that
>>> for the other libs. Perhaps that needs to be done. But is a pain to
>>> maintain.
>>>
>>> On 21 March 2010 07:55, Martin Krasser<kras...@googlemail.com> wrote:
>>>
>>>
>>>> Jonas Bon�r schrieb:
Jonas Bonér
>>>>> Jonas Bonér schrieb:
--
Martin Krasser
dealing with redundant libs. Instead of simply excluding them during
packaging, the individual sub-projects (modules) are now forced to use
the higher version of redundant libs. This ensures that unit tests use
the same library version that are also present in the distribution. All
automated tests are still passing - so everything should be fine with
the 0.7 release.
>>>>>> Jonas Bon�r schrieb:
Jonas Bonér
--
Jonas Bonér
http://jayway.com
http://akkasource.org
On Mar 22, 2010, at 7:59, Martin Krasser <kras...@googlemail.com>
wrote:
> Although too late for the 0.7 release, I committed an improvement
> for dealing with redundant libs. Instead of simply excluding them
> during packaging, the individual sub-projects (modules) are now
> forced to use the higher version of redundant libs. This ensures
> that unit tests use the same library version that are also present
> in the distribution. All automated tests are still passing - so
> everything should be fine with the 0.7 release.
>
>>>>>>> Jonas Bonér schrieb: