Hi Christian,
I think that the easiest way is:
1/ in the default jre.properties comment the package with issues (JAXB, etc)
2/ in Karaf, by default, we provide a core-spec/core-api feature to
install the "correct" bundle (for JAXB, etc).
In that case, we completely override the JRE packages an
Hi
Thanks for working on this. This is a good idea so people can adjust
it to their RDMBS of choice.
On Fri, Dec 23, 2011 at 1:40 AM, pglebow wrote:
> I've submitted a JIRA and a patch relating to JdbcMessageIdRepository in the
> camel-sql component:
>
> https://issues.apache.org/jira/browse/CA
Hi
Yes we love contributions. Please create a JIRA and provide a patch.
http://camel.apache.org/contributing.html
On Thu, Dec 22, 2011 at 6:58 PM, ychawla wrote:
> Hi Phil,
> I saw the same behavior for a Mail Server we are going against. I am
> thinking it would be great to have a configurati
On 12/23/11 9:55 AM, Daniel Kulp wrote:
On Friday, December 23, 2011 8:57:22 AM Willem Jiang wrote:
That is why we doesn't install xml-spec-api feature by default.
But current Karaf 2.2.4 doesn't do it by default :(
Honestly, I really think we should restore the specs and jaxb-impl into the
de
My .2 is that I haven't really used this stack commercially ever without at
least some of the CXF
features, I know that cxf is large, sure but since the cxf defaults when setup
right provides better than
jre settings for quite a few things, faster stax parsing etc etc.
I kinda sorta wanna see
On Friday, December 23, 2011 8:57:22 AM Willem Jiang wrote:
> That is why we doesn't install xml-spec-api feature by default.
> But current Karaf 2.2.4 doesn't do it by default :(
Honestly, I really think we should restore the specs and jaxb-impl into the
defaults. Right now, we're in a state w
That is why we doesn't install xml-spec-api feature by default.
But current Karaf 2.2.4 doesn't do it by default :(
On Fri Dec 23 07:53:07 2011, Christian Müller wrote:
May it's a stupid idea, but if an OSGI containder decide to hide some
packages from the JRE (for good reasons), shouldn't it in
I've submitted a JIRA and a patch relating to JdbcMessageIdRepository in the
camel-sql component:
https://issues.apache.org/jira/browse/CAMEL-4822
The existing JdbcMessageIdRepository is not compatible with MS SQL Server
(insert of a Timestamp is not supported by this database) and it was very
di
May it's a stupid idea, but if an OSGI containder decide to hide some
packages from the JRE (for good reasons), shouldn't it install the bundles
by default which provides the hidden packages so that we can trust the
javax.xml.xxx packages are available - via the JRE or a bundle...
Best,
Christian
I think they are to be removed in 3.0.0. Minor releases should mainly
add features while major releases may remove features.
Christian
Am 22.12.2011 20:11, schrieb Glen Mazza:
Incidentally, a search on the Camel trunk source code is yielding 202
@deprecated tags -- has anyone checked to see
Incidentally, a search on the Camel trunk source code is yielding 202
@deprecated tags -- has anyone checked to see if any of those tagged
methods can be removed in the jump from 2.8.3 to 2.9? (Or is it only
3.x, 4.x, 5.x, etc. releases in which deprecated methods may be removed?)
Regards,
Gl
Hi Phil,
I saw the same behavior for a Mail Server we are going against. I am
thinking it would be great to have a configuration on the endpoint like
'useDispositionForAttachmentRetrieval'.
There can a check around this block:
if (disposition != null && (disposition.equalsIgnoreCase(Part.ATT
CAMEL-4812 is already fixed.
I'm tackling CAMEL-4810.
I identified a couple of others issues ;)
Regards
JB
On 12/22/2011 05:33 PM, Christian Müller wrote:
JB, could you please have a look into [1] and [2]. There we added the
dependency to the Karaf http and eventadmin feature. In one commit w
On Thursday, December 22, 2011 6:28:23 PM Ioannis Canellos wrote:
> > To load these API bundle or not depends on whether OSGi container export
> > these packages or not by default,
> > It is not easy to support these two use case in a single apache-camel
> > features.xml, So I added xml-specs-api f
JB, could you please have a look into [1] and [2]. There we added the
dependency to the Karaf http and eventadmin feature. In one commit without
a version range and in the other one with a version range. Could you please
update one of them to allign this.
[1] https://issues.apache.org/jira/browse/
>
> To load these API bundle or not depends on whether OSGi container export
> these packages or not by default,
> It is not easy to support these two use case in a single apache-camel
> features.xml, So I added xml-specs-api feature in the apache-camel
> features.xml.
>
A solution that comes to m
OK, I will keep you posted on IRC about the fix on Karaf features.
Regards
JB
On 12/22/2011 04:56 PM, Hadrian Zbarcea wrote:
Great, because I can start another build tonight or tomorrow. I just
removed the tag and dropped the staging repository. In hindsight I think
it was a bit of a mistake, I
Great, because I can start another build tonight or tomorrow. I just
removed the tag and dropped the staging repository. In hindsight I think
it was a bit of a mistake, I could have used it for the release testing
scripts but I guess a previous release would do too.
Hadrian
On 12/22/2011 10
Agree Hadrian.
I'm testing all Camel features and raising the corresponding Jira. I
think I can be able to fix all issues today.
Regards
JB
On 12/22/2011 04:25 PM, Hadrian Zbarcea wrote:
I think there were enough -1s to cancel this vote and redo this release.
The artifacts were ok, the only
I think there were enough -1s to cancel this vote and redo this release.
The artifacts were ok, the only issues found were only related to OSGi.
I'll look into automating the release sanity in an OSGi environment as
well, as it may help with identifying such issues earlier.
One more note: plea
FYI, I'm also working on Karaf profiles (but for Karaf 3.0) which will
be able to handle the jre.properties (and lot of others).
Regards
JB
On 12/22/2011 03:57 PM, Christian Schneider wrote:
Not exactly. Most of the packages are exported by Karaf by default. The
problem is that these exports n
Not exactly. Most of the packages are exported by Karaf by default. The
problem is that these exports need to be replaced by better versions for
cxf to work.
See Dan´s Blog : http://www.dankulp.com/blog/2011/11/apache-cxf-in-osgi/
To make things easier for users I added a template jre.propertie
Long discussion in the past about jre.properties and package that we
take from JRE or Specs/API bundles, etc :)
On 12/22/2011 03:53 PM, Christian Müller wrote:
Ok, than we "only" have to allign with the Karaf guys whether or not they
export the JDK pakages in question. At present, they don't an
Ok, than we "only" have to allign with the Karaf guys whether or not they
export the JDK pakages in question. At present, they don't and we have to
install they before we install the camel features. I'm right?
Best,
Christian
In any case, features is a Karaf specific feature ;)
So if we use features, we already assume to be Karaf centric :)
Regards
JB
On 12/22/2011 03:35 PM, Christian Müller wrote:
I'm wondering if we are really OSGI container independend. Some of the
camel features depend on the http, eventadmin o
On Thursday, December 22, 2011 3:35:02 PM Christian Müller wrote:
> I'm wondering if we are really OSGI container independend. Some of the
> camel features depend on the http, eventadmin or spring feature wich are
> provided by Karaf. They may do not exist in other OSGI container.
Well, the featur
I'm wondering if we are really OSGI container independend. Some of the
camel features depend on the http, eventadmin or spring feature wich are
provided by Karaf. They may do not exist in other OSGI container.
Best,
Christian
We may not just support karaf by default. We need to avoid install the
bundle which the exports package are same with JRE exports package. That
is why we doesn't include the xml-specs-api feature by default.
I think we should add FAQ and a known issue description in the release
note for it.
As you know The stax and jaxws-api are part of the JDK6. If these
package are exported from JRE, we may face some trouble if we install
the package bundle at the same time. That is why we remove there bundle
from camel-core feature in CAMEL-4671[1]
To load these API bundle or not depends on
The root cause of these problems is the xml-specs-api feature which was
introduced after the RC and needs to be installed before camel is installed.
If you install this feature before installing the camel feature almost
everything is ok (the eventadmin thing is another problem).
So, I am -1 one on
I'm -1 on this release. These problems make it MUCH harder to use Camel in
OSGi. Anyone that is using Camel in OSGi will need to go through a bunch of
extra steps to get their applications running. i don't consider this a
"minor" issue.
Dan
On Wednesday, December 21, 2011 11:58:11 PM
Hi Christian,
Great & thanks for you support :-)
Don't get into hurry & let's first bring the 2.9.0 final release out the
door (with or without the OSGi features-fix stuff).
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-Trunk-Code-Cleanup-tp5071594p5094179.ht
Yes, I think so, I'm testing with both versions.
Regards
JB
On 12/22/2011 10:53 AM, Christian Schneider wrote:
I just found that camel 2.8.3 has the same issues.
Christian
Am 22.12.2011 10:32, schrieb Christian Schneider:
-1
features:install for many camel modules gives dependency errors.
B
I just found that camel 2.8.3 has the same issues.
Christian
Am 22.12.2011 10:32, schrieb Christian Schneider:
-1
features:install for many camel modules gives dependency errors.
Besides camel-rss I also found camel-jaxb and camel-jibx to give errors.
Of course there are workarounds but as we
Thanks for the update Christian.
I'm testing all Camel features to have a clean overview about the situation.
I will keep you posted soon.
Regards
JB
On 12/22/2011 10:32 AM, Christian Schneider wrote:
-1
features:install for many camel modules gives dependency errors. Besides
camel-rss I als
Hey Babak,
I will do it. I'm a bit busy at present because we are releasing Camel
2.9.0 and facing a few problems. Give me a few days...
Christian
Sent from a mobile device
Am 22.12.2011 09:33 schrieb "bvahdat" :
> Hi,
>
> As I have already attached the first patch for [1] that would be great if
-1
features:install for many camel modules gives dependency errors. Besides
camel-rss I also found camel-jaxb and camel-jibx to give errors.
Of course there are workarounds but as we already found the problem I
think we should first fix those issues. Fixing those issues in
servicemix is not ap
Hi,
As I have already attached the first patch for [1] that would be great if a
commiter would assist me on
this ticket for applying the gradual patches into the trunk one after the
other.
As soon as this first patch is applied I will update my workspace and dig
into the "next round".
[1] https:
38 matches
Mail list logo
