Agree,

I already raised the related Jira and I'm working on Felix 3.0.8 tests.

Regards
JB

On 02/24/2011 10:25 AM, Gert Vanthienen wrote:
Jean-Baptiste,

Let's give it a go first -- if we can get things working that way,
it's rather straightforward to create a new release and get it out.
If this doesn't fix the issue at all, we should probably look into
another solution or add a very big, red box on the release notes that
tells people how to get around it.  The important thing is that we can
get something delivered that users can actually use...

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Thu, Feb 24, 2011 at 9:52 AM, Jean-Baptiste Onofré<[email protected]>  wrote:
Thanks for the update Gert.

I'm gonna make a try following your instructions.

Anyway, what do we decide ?
Promote the release as it is ?
Cancel the release and override the Felix Framework in the ServiceMix lib
folder ?

Regards
JB

On 02/24/2011 09:46 AM, Gert Vanthienen wrote:

L.S.,

Unfortunately, at Apache, Felix is the default container configured
for Apache ServiceMix, so this issue would be impacting any odd user
that comes along and just tries to run the examples.  I don't think we
can release this in its current state.

What seems to work on my machine:
- upgrade to Felix 3.0.8  by adding it to the system folder and
updating the config.properties file (no need to re-release karaf for
that, we can just do the update for ServiceMix 4.3.0)
- install the camel-cxf and camel-nmr components by default from the
featuresBoot property

If I then wipe my data folder, the examples seem to work fine for me.
Could some other folks give this a go as well?  If we have a known
workaround, I'd recut the release to implement the workaround and
remove the few minor inconsistencies we found so far (-SNAPSHOTs in
web example, missing import in example, ...)

Like I said in a previous mail, we really want to get rid of these
long release cycles, but I don't think we should ship a non-working
ServiceMix just to do that.  Let's make that a top priority right
after this release though - with the lessons learned here, I'm
convinced we can improve our build/release process to facilitate an
easier 4.4.0 release as soon as Camel 2.7.0 is out.

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Thu, Feb 24, 2011 at 9:37 AM, Claus Ibsen<[email protected]>
  wrote:

Hi

My impression is that Felix is still a bit buggy, but they are working on
it.
And the community is listening and we have people in this community we
help out there as well.
So I am confident that over time Felix has the potential to be the
default container and work really great.

Currently Equinox is the default container, and so far I think its
more known that Felix and people are more confortable using that.

So I am all in favor of +1. (non binding)
Its almost 1 year ago SMX 4.2 was released.




On Thu, Feb 24, 2011 at 9:20 AM, Jean-Baptiste Onofré<[email protected]>
  wrote:

The problem is it's not really ServiceMix related.
The issue is in Apache Felix.

ServiceMix 4.3.0 is powered by Karaf 2.1.3, so it uses Apache Felix
framework 3.0.2.
If we want to update to new Felix framework version (for example 3.0.8),
we
need to release Karaf 2.1.5 with this update.
Anyway, the first step is to check if Felix Framework 3.0.8 fix the
problem.

Regards
JB

On 02/24/2011 09:17 AM, Charles Moulliard wrote:

This issue is not only related to exercises but will be for persons
who will deploy their projects on ServiceMix where they will use
Camel, CXF, ...

We must deliver a quality product and this is not really a problem if
we postpone of some days. This release is under construction since a
couple of months.

Regards,

Charles

On Thu, Feb 24, 2011 at 9:08 AM, Jean-Baptiste Onofré<[email protected]>
  wrote:

I don't remember if it worked before or not.

If you prefer, I can:
- rollback the release
- fix the examples-cxf-nmr (modifying the POM)
- remove the examples-camel-nmr, camel-cxf from the distribution

I don't wanna wait having all examples fixed (we already postpone this
release several times).

WDYT ?

Regards
JB

On 02/24/2011 08:59 AM, Charles Moulliard wrote:

This is not an excellent idea to promote a product with regression
and
explain that Felix cannot be used ....

On Thu, Feb 24, 2011 at 8:52 AM, Jean-Baptiste
Onofré<[email protected]>
  wrote:

This one is solved switching to Equinox in place of Felix.

Change etc/custom.properties by adding:

karaf.framework=equinox

Regards
JB

On 02/24/2011 08:52 AM, Charles Moulliard wrote:

Installing camel-cxf generates the following error too -->

karaf@root>          features:install camel-cxf
Refreshing bundles org.apache.servicemix.bundles.xmlbeans (112),
org.apache.servicemix.bundles.velocity (41), org.apache.cxf.bundle
(119), org.apache.servicemix.bundles.cglib (69)
ERROR: JarContent: Unable to read bytes.
(java.lang.IllegalStateException: zip file closed)
java.lang.IllegalStateException: zip file closed
        at java.util.zip.ZipFile.ensureOpen(ZipFile.java:403)
        at java.util.zip.ZipFile.getEntry(ZipFile.java:148)
        at java.util.jar.JarFile.getEntry(JarFile.java:208)
        at
org.apache.felix.framework.util.JarFileX.getEntry(JarFileX.java:61)
        at



org.apache.felix.framework.cache.JarContent.getEntryAsBytes(JarContent.java:120)
        at



org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1738)
        at



org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:716)
        at

org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
        at



org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        at



org.apache.cxf.bus.spring.BusApplicationListener.onApplicationEvent(BusApplicationListener.java:65)
        at



org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:97)
        at



org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:303)
        at



org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1007)
        at



org.springframework.osgi.context.support.AbstractOsgiBundleApplicationContext.doClose(AbstractOsgiBundleApplicationContext.java:197)
        at



org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$501(AbstractDelegatedExecutionApplicationContext.java:69)
        at



org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$2.run(AbstractDelegatedExecutionApplicationContext.java:214)
        at



org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
        at



org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalClose(AbstractDelegatedExecutionApplicationContext.java:210)
        at



org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.close(DependencyWaiterApplicationContextExecutor.java:379)
        at



org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.doClose(AbstractDelegatedExecutionApplicationContext.java:236)
        at



org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:970)
        at



org.springframework.osgi.extender.internal.activator.ContextLoaderListener$1.run(ContextLoaderListener.java:524)
        at



org.springframework.osgi.extender.internal.util.concurrent.RunnableTimedExecution$MonitoredRunnable.run(RunnableTimedExecution.java:60)
        at



org.springframework.scheduling.timer.DelegatingTimerTask.run(DelegatingTimerTask.java:70)
        at java.util.TimerThread.mainLoop(Timer.java:512)
        at java.util.TimerThread.run(Timer.java:462)


On Thu, Feb 24, 2011 at 7:59 AM, Jean-Baptiste
Onofré<[email protected]>
  wrote:

Team,

I would like to promote the release but my latest tests on
examples
don't
look fine

- features:install examples-cxf-nmr
NoClassDefFoundError: javax.xml.namespace.QName not found from
bundle
[cxf-nmr]

- features:install examples-camel-nmr
It works, but several
IllegalStateException: zip file closed (coming from Felix
Framework
util)
and a
ClassNotFoundException:
org.apache.servicemix.nmr.api.service.ServiceHelper

The other examples features look good (including
camel-nmr-blueprint).

Could somebody make some tries ?
Anyway, it's clear that the examples should be updated to use
Blueprint
in
place of Spring beans (I think it's more clear for the users) for
ServiceMix
4.4.0.

I think that we can promote the release as it's but we should add
an
appendix concerning examples.

Thanks
Regards
JB

On 02/20/2011 09:46 AM, Jean-Baptiste Onofré wrote:

Hi,

We solved 115 issues in this release:





https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311208&version=12315741


Staging repository:





https://repository.apache.org/content/repositories/orgapacheservicemix-026/

The RELEASE-NOTES file is included in the release and up to date.

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

Thanks,
Regards
JB







--
Claus Ibsen
-----------------
FuseSource
Email: [email protected]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/


Reply via email to