Re: Interdependencies between SAAJ, Activation, and javamail on karaf 4.2.3/karaf 4.2.2
d loader > org.apache.felix.framework.BundleWiringImpl$BundleClassLoader@0x000100162fd8) >at > com.sap.esb.activation.impl.OsgiMailcapCommandMap.createDataContentHandler(OsgiMailcapCommandMap.java:179) >at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:249) >at javax.activation.DataHandler.getContent(DataHandler.java:142) >at javax.mail.internet.MimeMessage.getContent(MimeMessage.java:1454) >at > org.apache.camel.component.mail.MailBinding.extractHeadersFromMail(MailBinding.java:601) > > The culprit seems to be the saaj-impl bundle. So I looked for newer version. > There is a version 1.4.0_1 that is actually registering DataContentHandlers > like > com.sun.xml.messaging.saaj.soap.StringDataContentHandler (without the > internal), which is instead coming from the saaj-api bundle (which wires with > the javax.activation bundle in the stack), so this should work. Unfortunately > the version 1.4.0 imports package version 1.4 or later of package > javax.xml.soap, whereas the saaj-api-1.3 bundle is exporting version 1.3 of > that package. > > Yesterday Jean Baptiste Onofré added version 1.5.1_1-SNAPSHOT to the > servicemix bundles repository, though I don't know why he did so and when he > plans to release that version. > > Are you already aware of this or is this change not related to the Karaf > 4.2.3 release at all? > > Does anyone know any combination of saaj/saaj-impl OSGi bundles that work > with Java 8 on Karaf? > > Best regards > Stephan -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache Karaf (Container) 4.2.0 release (take 2)
This is SLIGHTLY different.I talked to gnodet on IRC about this yesterday as well. He currently doesn’t provide a ContextFactory for JAXB to override what’s in the JDK.Thus, we expected that it would always pick up what’s in the JDK. It looks like in this case, it’s getting some sort of mix or something. com.sun.xml.bind.v2.ContextFactory is not in the JDK (would have “internal” in the name) so somehow it’s picking up a META-INF/services from the jaxbimpl bundle, but the JAXBContext from the JDK cannot access the class. Or something like that. I’m wondering if it’s actually getting a mix of stuff. Maybe an explicit import of jaxb impl class? Maybe jaxb-api coming from two locations? (Jdk and bundle)? Dan > On Apr 5, 2018, at 7:03 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Let me take a look. > > However this is not new and happened in RC1 and RC2. It would have been great > to have such feedback on the RC instead of the first GA. > > I keep you posted. I tested the cxf feature yesterday without problem. Let me > try the cxf-dosgi. > > Regards > JB > > Le 5 avr. 2018 à 12:28, à 12:28, Christian Schneider > <ch...@die-schneider.net> a écrit: >> I just tested with the CXF-DOSGi samples on karaf 4.2.0 and java 8. >> When >> there is an error during xml parsing. >> >> To reproduce install cxf-dosgi samples: >> >> feature:repo-add cxf-dosgi-samples 2.3.0 >> >> feature:install cxf-dosgi-sample-soap-impl >> >> and check the log. >> >> See this for the exception: >> https://paste.apache.org/FFNJ >> >> The code works fine in karaf 4.1.x. >> >> This could be the same thing that Dan reported about the xml parsing. >> As it >> still seems to happen with the new build I am voting -1 for now. >> >> -1 >> >> Christian >> >> >> 2018-04-05 8:03 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >> >>> Hi all, >>> >>> I submit Karaf (Container) 4.2.0 release to your vote. >>> >>> This is the first GA on the 4.2.x series, following M1 and M2. >>> >>> NB: I preferred to postpone the merge of the new examples as it needs >> a >>> little >>> polish. The PR is already available and it will be included in 4.2.1 >> (that >>> we >>> can expect beginning of May depending of 4.2.0 feedbacks): >>> https://github.com/apache/karaf/pull/484 >>> >>> NB: This is take 2, including KARAF-5688 fix >>> >>> Release Notes: >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa? >>> projectId=12311140=12342076 >>> >>> Staging Repository: >>> >> https://repository.apache.org/content/repositories/orgapachekaraf-/ >>> >>> Git Tag: >>> karaf-4.2.0 >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Don't approve the release (please provide specific comments) >>> >>> This vote will be open for at least 72 hours. >>> >>> Thanks, >>> Regards >>> JB >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> >> >> -- >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Computer Scientist >> http://www.adobe.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Karaf (Container) 4.2.0 release
> On Apr 4, 2018, at 11:21 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi Dan, > > do you consider it can wait 4.2.1 or do you want a new 4.2.0 ? I believe it breaks several uses cases for CXF.More importantly as soon as you install CXF, ANYTHING blueprint related breaks. org.apache.aries.blueprint.parser.Parser.parse uses DOM parsing and as soon as xerces is there, blueprint is no longer able to parse any blueprint files. Up to you, but that seems fairly severe to me. Dan > > Regards > JB > > On 04/04/2018 02:54 PM, Daniel Kulp wrote: >> >> Just for the record, found two issues: >> >> 1) Installing CXF (which installs xercesImpl) causes most XML DOM parsing to >> break when run on Java 8. (Java9 is fine) Guillaume already fixed this. >> >> 2) The “finders” that were added don’t include one for JAXB. Thus we’ll >> always end up using the JAXB in the JDK instead. >> >> >> Dan >> >> >> >> 2018-04-03 10:25 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >> >>> Hi all, >>> >>> I submit Karaf (Container) 4.2.0 release to your vote. >>> >>> This is the first GA on the 4.2.x series, following M1 and M2. >>> >>> NB: I preferred to postpone the merge of the new examples as it needs a >>> little >>> polish. The PR is already available and it will be included in 4.2.1 (that >>> we >>> can expect beginning of May depending of 4.2.0 feedbacks): >>> https://github.com/apache/karaf/pull/484 >>> >>> Release Notes: >>> https://issues.apache.org/jira/secure/ReleaseNote.jspa? >>> projectId=12311140=12342076 >>> >>> Staging Repository: >>> https://repository.apache.org/content/repositories/orgapachekaraf-1110/ >>> >>> Git Tag: >>> karaf-4.2.0 >>> >>> Please vote to approve this release: >>> >>> [ ] +1 Approve the release >>> [ ] -1 Don't approve the release (please provide specific comments) >>> >>> This vote will be open for at least 72 hours. >>> >>> Thanks, >>> Regards >>> JB >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Karaf (Container) 4.2.0 release
Just for the record, found two issues: 1) Installing CXF (which installs xercesImpl) causes most XML DOM parsing to break when run on Java 8. (Java9 is fine) Guillaume already fixed this. 2) The “finders” that were added don’t include one for JAXB. Thus we’ll always end up using the JAXB in the JDK instead. Dan 2018-04-03 10:25 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi all, > > I submit Karaf (Container) 4.2.0 release to your vote. > > This is the first GA on the 4.2.x series, following M1 and M2. > > NB: I preferred to postpone the merge of the new examples as it needs a > little > polish. The PR is already available and it will be included in 4.2.1 (that > we > can expect beginning of May depending of 4.2.0 feedbacks): > https://github.com/apache/karaf/pull/484 > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > projectId=12311140=12342076 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachekaraf-1110/ > > Git Tag: > karaf-4.2.0 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [PROPOSAL] Docker feature in Karaf container
JAX-RS whiteboard currently has a few other issues, mostly due to the implementation in Aries. Probably should find some time to work on that. The main issue is that, right now, it embeds parts of CXF but then exports a few packages. Thus, getting it and a “real” CXF application working together is nearly impossible. The Aries implementation really needs to be split so that there is a “whiteboard only” bundle that imports CXF (and other deps) instead of embedding them, and then maybe a separate uber bundle that embeds the stuff if that’s needed for the TCK. Dan > On Jan 19, 2018, at 8:01 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > How about implementing jax-rs services using the OSGi jax-rs whiteboard > spec? So the implementation would be CXF but the code would ideally only be > tied to the jax-rs spec and the jax-rs whiteboard spec. > > Cheers > Christian > > 2018-01-19 13:54 GMT+01:00 Guillaume Nodet <gno...@apache.org>: > >> 2018-01-19 13:45 GMT+01:00 Daniel Kulp <dk...@apache.org>: >> >>> >>> >>>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <gno...@apache.org> >> wrote: >>>> >>>> * investigate the use of JaxRS 2.0 api instead of the CXF dependency >> (to >>>> be more flexible and also because it would create yet another circular >>>> dependency) >>> >>> I’m not sure I get this….. Even if you use the JAX-RS 2.0 API, you >> still >>> need an implementation in order for the API’s to work. I hope the >> chosen. >>> Implementation would remain CXF. >>> >> >> 1./ unless there's a compelling reason to tie the implementation to CXF, >> I'd rather use the standard API instead >> 2./ this does create a circular dependency, as karaf will depend on CXF and >> CXF on Karaf. I know this is not a problem when releasing because we >> always reference an older version of the other project, but still, if this >> can be avoided I think it would be better >> 3./ i'd like CXF to be the default and i don't have any reason to switch to >> a different provider, but that does not mean everyone should be forced to >> use it, as they may have reasons to use a different provider (which could >> also be a non technical reason) >> >> I don't see any difference between choosing a jaxrs provider and choosing a >> servlet provider or a transaction manager. We do usually leave room for >> choice, I'd like to keep it that way, if that's technically possible. >> >> >>> >>> >>> Dan >>> >>> >>> >>>> 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >>>> >>>>> Hi, >>>>> >>>>> Some days ago, we discussed about Decanter 2.0.0 and using "external" >>>>> instances of used engines, like Elasticsearch or Kibana. >>>>> >>>>> Basically, the main reason is that some engines are not easy to embed >> in >>>>> Karaf. It's the case of Kibana as it uses node.js. >>>>> >>>>> However, one of the big advantage of embedded instance of >> Elasticsearch >>> or >>>>> Kibana is that it's very easy to install and use: it's just a >>>>> feature:install command to perform. >>>>> >>>>> So, I would like to provide both advantages: easy to install and use >>> with >>>>> external instances ;) >>>>> >>>>> A first approach would be to create a "exec" bundle starting the >>> instance. >>>>> But we gonna face the "classic" issues depending of the environment. >>>>> >>>>> Maybe some of you remember the karaf-docker PoC I did month ago: >>>>> >>>>> https://github.com/jbonofre/karaf-docker >>>>> >>>>> This is a simple feature that allows you to manipulate docker images: >>>>> bootstrapping, starting/running, ... >>>>> >>>>> I think it would help a lot in Decanter or Cellar: we can just provide >>>>> Karaf Docker commands to bootstrap Elasticsearch, Kibana, OrientDB, >> ... >>>>> As a best effort, we will try to provide embedded instance as >> possible, >>>>> but it won't be the preferred approach. >>>>> >>>>> As karaf-docker is small project and just basically use docker, I >>
Re: [PROPOSAL] Docker feature in Karaf container
> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <gno...@apache.org> wrote: > > * investigate the use of JaxRS 2.0 api instead of the CXF dependency (to > be more flexible and also because it would create yet another circular > dependency) I’m not sure I get this….. Even if you use the JAX-RS 2.0 API, you still need an implementation in order for the API’s to work. I hope the chosen. Implementation would remain CXF. Dan > 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > >> Hi, >> >> Some days ago, we discussed about Decanter 2.0.0 and using "external" >> instances of used engines, like Elasticsearch or Kibana. >> >> Basically, the main reason is that some engines are not easy to embed in >> Karaf. It's the case of Kibana as it uses node.js. >> >> However, one of the big advantage of embedded instance of Elasticsearch or >> Kibana is that it's very easy to install and use: it's just a >> feature:install command to perform. >> >> So, I would like to provide both advantages: easy to install and use with >> external instances ;) >> >> A first approach would be to create a "exec" bundle starting the instance. >> But we gonna face the "classic" issues depending of the environment. >> >> Maybe some of you remember the karaf-docker PoC I did month ago: >> >> https://github.com/jbonofre/karaf-docker >> >> This is a simple feature that allows you to manipulate docker images: >> bootstrapping, starting/running, ... >> >> I think it would help a lot in Decanter or Cellar: we can just provide >> Karaf Docker commands to bootstrap Elasticsearch, Kibana, OrientDB, ... >> As a best effort, we will try to provide embedded instance as possible, >> but it won't be the preferred approach. >> >> As karaf-docker is small project and just basically use docker, I think it >> doesn't require to be a Karaf subproject. >> As we have the karaf scheduler (using Quartz internally), I would like to >> propose to add docker in Karaf container in a dedicated module. >> >> It means that users will be able to do feature:install docker to have the >> docker commands. >> I would like also to add a command and configuration to have "ready to go >> images". Something that will allow users to do: >> >> docker:run elasticsearch >> >> then, elasticsearch will use a ready to go dockerfile. >> >> It would be possible to do: >> >> docker:run mvn:org.apache.karaf.decanter.docker/elasticsearch/6.1.0/docker >> >> Where we can host ready to use "official" dockerfile. >> >> Thoughts ? >> >> Regards >> JB >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > > -- > > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Trim down karaf distributions for 4.2
The PROBLEM with the in-JDK version of the DOM is that just creating a new empty document involved a call to System.getProperty(…) which is a synchronized call. The Apache xerces version does not have that problem. Thus, by removing the xerces jar, performance of certain uses cases will drop with high concurrency. Unfortunately, CXF is one of those use cases. Dan > On Oct 11, 2017, at 2:00 PM, Guillaume Nodet <gno...@apache.org> wrote: > > The point that makes me raise this problem is that the karaf default > distribution uses the Apache versions of xerces and xalan. Fwiw, the > latest xerces release is from 2011 and the latest xalan from 2014, so > they're not the most active. In particular, xalan latest release does not > implement jaxp 1.4. > > One additional point is that those libraries stuff is broken on Java 9, so > one option would be to remove it alltogether which bring us much closer to > Java 9 support ;-) Seriously, I'm not sure I want to spend too much time > allowing pluggability for specs/implementations while the only real > implementation provider is the JDK itself. That's really a lot of work for > no real benefit. > > In addition, the default distribution still install some "legacy" features > such as aries-blueprint, shell-compat, etc... > > So here's a list of propositions for 4.2: > * remove all libraries for specs / impls from apache-karaf distro > * remove support for endorsed / ext libraries in the element > and wherever used > * remove aries-blueprint and shell-compat from default distro > * remove a few features from the karaf-minimal distro. I'm not sure which > one exactly, but I think we should get the zip under 10 Mb. Maybe only > keeping jaas, shell, feature, ssh, bundle, config, deployer and log, also > removing equinox / logback bundles... > > Thoughts ? > > -- > > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Moving to gitbox
> On Sep 12, 2017, at 12:22 PM, Guillaume Nodet <gno...@apache.org> wrote: > > It becomes a read/write github repository, so all features of github are > available instead of just the hosting. > Mainly, this allows using PR and merging them as you would do for any > github repo. Well, infra can SELECTIVELY enable various GitHub features. For CXF, we told them NOT to enable the GitHub issues or Wiki, but those are options if you feel they are useful. CXF has always used JIRA and Confluence and moving off them now would be difficult and, until we got a better feel for the gitbox integration, adding additional bug trackers (aka: enabling issues) just seemed like more work for the project. It is something that can be enabled later if wanted. Basically, baby steps, one step at a time. Basically, the main benefits are: 1) Direct push to GitHub 2) Ability to manage pull requests directly in the GUI. That includes using the merge button and close buttons and such. No funky “this closes ” commits needed. Dan > 2017-09-12 18:04 GMT+02:00 Achim Nierbeck <bcanh...@googlemail.com>: > >> fine with me, what are the benefits of it again? >> couldn't find what it is really good for compared to what we already got >> ... >> >> regards, Achim >> >> 2017-09-11 9:48 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: >> >>> +1 >>> >>> I think I already sent an e-mail about this while ago (when gitbox has >>> been proposed by infra). >>> >>> Regards >>> JB >>> >>> >>> On 09/11/2017 09:39 AM, Guillaume Nodet wrote: >>> >>>> Infra now offers read/write access to github via a service called >>>> 'gitbox'[1]. PMCs have the option to join the service and then make >>>> use of whichever github features they want (like PRs). >>>> >>>> Thoughts ? >>>> >>>> [1]: https://gitbox.apache.org/ >>>> >>>> >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >> Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >> > > > > -- > > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Removal of JaxBUtil ?
ge would be that the whole jaxb infrastructure could be >>>> avoided, >>>> > including the contexts. >>>> > >>>> > I know manual parsing is a pain, but anyway, just wanted to >>>> throw >>>> this out, >>>> > maybe somebody has a good suggestion. >>>> > >>>> > Fabian >>>> > -- >>>> > Fabian Lange | Performance Expert >>>> > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393> >>>> > >>>> > codecentric AG | Merscheider Straße 1 | 42699 Solingen | >>>> Deutschland >>>> > >>>> > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht >>>> Wuppertal >>>> > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns >>>> > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . >>>> Jürgen >>>> Schütz >>>> > >>>> >>>> >>>> >>>> -- >>>> >>>> Guillaume Nodet >>>> >>>> Red Hat, Open Source Integration >>>> >>>> Email: gno...@redhat.com <mailto:gno...@redhat.com> >>>> Web: http://fusesource.com >>>> Blog: http://gnodet.blogspot.com/ >>>> >>>> >>>> >>>> >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problems due to the endorsed java.lang.Exception
Since Karaf is now Java7+ and jaxb-api is also endorsed, you could likely just
add @javax.xml.bind.annotation.XmlTransient to the getter.
That said, the idea of adding public methods onto JDK level classes screams
“bad idea” to me.
Dan
> On Mar 18, 2016, at 1:11 PM, Guillaume Nodet <gno...@apache.org> wrote:
>
> The getClassContext() method is used in pax-logging to render the exception
> in a nicer way.
> I don't have any problem moving the qualifier to protected or whatever, but
> we'd need to change the code in pax-logging
>
>
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-log4j2/src/main/java/org/apache/logging/log4j/core/impl/ThrowableProxy.java#L136-L144
>
>
> https://github.com/ops4j/org.ops4j.pax.logging/blob/master/pax-logging-service/src/main/java/org/apache/log4j/OsgiThrowableRenderer.java#L62-L67
>
> It should not be a big deal, but the current code expect the method to be
> public unfortunately.
>
> Guillaume
>
>
> 2016-03-18 17:29 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net>:
>
>> Hi Cristiano,
>>
>> I think you are right, it's probably something existing for a while. I'm
>> just surprised that you encountered now.
>>
>> Let me check your detailed use case that you sent previously.
>>
>> Regards
>> JB
>>
>>
>> On 03/18/2016 05:14 PM, Cristiano Costantini wrote:
>>
>>> Hello all,
>>>
>>> it is some days I was having troubles using CXF services on ServiceMix
>>> (and
>>> it is some days I spam on the mailing list of ServiceMix, Camel and CXF
>>> :-D
>>> ) and I've finally come to the source of my issues which are due to the
>>> "endorsed" java.lang.Exception which is used by Karaf:
>>>
>>>
>>> https://github.com/apache/karaf/blob/master/exception/src/main/java/java/lang/Exception.java
>>>
>>> My problem is due to the fact that this class has a public property,
>>> public Class[] getClassContext() {
>>> return classContext;
>>> }
>>> which is seen by JaxB at runtime inside Karaf which cause it to marshall
>>> the Exception in SOAP services with a wrong XML, an XML which include
>>> tags.
>>>
>>> The class in Karaf has not changed since committed by Guillaume Nodet in
>>> 2010, so this issue with CXF has probably always been there.
>>>
>>> In my opinion, this getter should be private or protected as I guess it is
>>> only used on the nested class method's getThrowableContext (it is a
>>> replacement for the JRE's class, I don't think there are external project
>>> using this modification of the Exception class).
>>>
>>>
>>> To confirm my thesis, I've hacked the org.apache.karaf.exception-2.4.0.jar
>>> inside the lib/endorsed folder with a class compiled by myself where I've
>>> changed the method to
>>> private Class[] getClassContext() {
>>> return classContext;
>>> }
>>> and with this hack, Karaf has continued to work (and my CXF service now
>>> works properly).
>>>
>>> Do you think there are potential side effects in this fix?
>>> Do you need me to open an issue on Jira to handle the problem?
>>> If it is confirmed that the fix of making this method private, do you
>>> think
>>> it could be included soon on the next Karaf Release?
>>>
>>> Thank you very much to all,
>>> Cristiano
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
>
> Guillaume Nodet
>
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Karaf 4.0 switch to Java8?
I’m “ok” with building with Java8, but definitely think we need to stick with Java7 for runtime. That said, I’d strongly prefer allowing building with Java7 as well to make sure we don’t miss issues. I don’t see many of our customers moving to Java8 this year at all so maintaining Java7 compatibility is important to me. Is it just a few tests that fail with Java8? Could we create a “Java7” profile that would disable the “known to fail with Java7 and we’ve investigated why and nothing we can do about it” tests? A separate Jenkins job could be setup to run the Java7 tests compared with the Java8 to make sure we don’t miss things. Dan On Jan 26, 2015, at 10:22 AM, Achim Nierbeck bcanh...@googlemail.com wrote: Hi, How is everybody feeling about to switch to JDK8 for building the master branch? (Karaf 4) According to [1], Java 7 is pretty much at EOL. I think this needs to be addressed right now since for Pax Web 4.1. which is now used by Karaf 4 it is needed to use JDK8. Not because of using any new features of Java 8 but because of the memory issues while running the integration tests. There seems to be a reproducible issue since switching to Jetty 9.2 and running the integration tests with Java 7. Those are gone when Java 8 is used. Therefore Pax Web 4.1. uses JDK8 for building right now, though the switches are set to be compatible with Java 7, for source and target. Another benefit might be to use JDK8 features already. For me I would like to see at least JDK8 with source and target set to 7 regards, Achim [1] - http://www.oracle.com/technetwork/java/eol-135779.html -- Apache Member Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead blog http://notizblog.nierbeck.de/ Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS Software Architect / Project Manager / Scrum Master -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Karaf runs slower in Intel Socx 1000 board.
Two things:
1) Cache the JAXBContext. Creating a JAXBContext is very expensive and slow
as it involves scanning packages, annotations, etc…. Create that once.
2) unmarshalling from an InputStream is also very expensive as it needs to
create a SAX Parser which involves the SPI lookup mechanism as well as several
System.getProperties calls which can kill scalability. Also note that this
opens up the door to various attacks as that SAX parser is not configured to
block various things.
If you can, do something like:
XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(XMLInputFactory.IS_NAMESPACE_AWARE, Boolean.TRUE);
factory.setProperty(XMLInputFactory.SUPPORT_DTD, Boolean.FALSE);
factory.setProperty(XMLInputFactory.IS_REPLACING_ENTITY_REFERENCES,
Boolean.FALSE);
factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES,
Boolean.FALSE);
factory.setXMLResolver(new XMLResolver() {
public Object resolveEntity(String publicID, String systemID,
String baseURI, String namespace)
throws XMLStreamException {
throw new XMLStreamException(Reading external entities is
disabled);
}
});
then cache that factory along with your JAXBContext. Then do:
unmarshaller.unmarshall(factory.createXMLStreamReader(inputStream));
That will perform a ton better and be significantly more secure.If the
factory is the woodstox factory (which you REALLY should use as it’s much
faster than the one built into the JDK), then also add:
factory.setProperty(com.ctc.wstx.maxAttributesPerElement, maxAttributeCount)
factory.setProperty(com.ctc.wstx.maxAttributeSize, maxAttributeSize)
factory.setProperty(com.ctc.wstx.maxChildrenPerElement,
innerElementCountThreshold)
factory.setProperty(com.ctc.wstx.maxElementCount, maxElementCount)
factory.setProperty(com.ctc.wstx.maxElementDepth, innerElementLevelThreshold)
factory.setProperty(com.ctc.wstx.maxCharacters, maxXMLCharacters)
factory.setProperty(com.ctc.wstx.maxTextLength, maxTextLength))
with reasonable values for those settings. That would prevent a slew of
various DOS attacks as well as can help reduce some of the memory usage.
Dan
On Dec 18, 2014, at 9:28 AM, R V Ramakrishna ramakrishna...@gmail.com wrote:
JB,
The way we do unmarshalling is
JAXBContext jc;
jc = JAXBContext.newInstance(Class.forName(resObject
.getClass().getName()));
Unmarshaller unmarshaller;
unmarshaller = jc.createUnmarshaller();
unmarshaller.setSchema(schema);
resObject = (Resource) unmarshaller.unmarshal(inputStream);
We use Java JAXB..not servicemix implementation. Actually the code is not
written by me, done by some other team and its a huge code. Looking at
higher level of source i can say this Jaxb unmarshaller has been called in
many bundles explicitly. Any way that we can get rid of this through some
configurations. I have sent one more set of test results that I did today
morning to you, around an hour back.
Thanks,
RK
--
View this message in context:
http://karaf.922171.n3.nabble.com/Karaf-runs-slower-in-Intel-Socx-1000-board-tp4037286p4037303.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Experiment to make karaf 4 smaller
On May 12, 2014, at 5:18 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, as reminder, xercesImpl jar is in lib/endorsed only for IBM JDK (issue at startup with Blueprint). As it may introduces some issue with Oracle JDK, I would like to double check if xercesImpl is still required (I don't think so). There is another reason it’s there: performance/scalability The parser factories in the JDK do a System.getProperty for every parser created. That’s a synchronized call which, under load, can result in a bunch of threads blocking. The Xerces factory does not do that and can scale much better, particularly for lots of small XML messages. The DocumentFactory’s for creating new DOM Documents also suffer the same problem. Dan We talked about Karaf profiles in the past to solve custom distribution issue at both build and runtime. The karaf maven plugin already provide ways to create custom distro. Regards JB On 05/12/2014 10:44 AM, Guillaume Nodet wrote: I agree that the minimal distro should be smaller. Though I think before removing anything, we need to have an easy way for users to add them back. I'm mostly thinking about equinox and xerces : * i don't think we have a simple way to switch an assembly to using equinox using the maven plugin * cxf needs it afaik, and we add it to org.osgi.framework.system.packages.extra in etc/config.properties If we improve the maven plugin to support those things, we can remove those from minimal I think. For wrapper and additional features, the plugin already gives a simple way to add them back, so we can already remove them I think. 2014-05-11 17:50 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net: Hi Christian, I have: - net distro very small (less than 1MB) - minimal distro I guess similar to that you have (but including equinox). It's something that I planned for Karaf 4.0.0. Regards JB On 05/07/2014 04:06 PM, Christian Schneider wrote: Hi all, just wanted to share my experiences in trying to make karaf 4 minimal even smaller. Currently karaf 4 minimal tar.gz is about 10MB. With some small tweaks I was able to get it down to about 6MB. I removed equinox (1.3 MB), XercesImpl (1.3MB in lib/endorsed) and some features like the wrapper. I would not really suggest to do all this for karaf minimal but perhaps this helps some people who aim to build a really small custom distro. What we might look into is to remove equinox and xerces from the framework kar and add them later in the two distros. This would allow people to build their own distros without tweaking the framework kar. Christian -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: On Karaf 2.3.x, stay with Spring 3.2.5.RELEASE
On Mar 25, 2014, at 5:59 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi all, FYI, on Karaf 2.3.x branch, we upgraded to Spring 3.2.8.RELEASE using the ServiceMix bundles. This change breaks CXF as CXF uses Require-Bundle with Spring bundle symbolic name. Would that be considered a bug in the ServiceMix spring bundles that they don’t use the same symbolic names as the original making them incompatible? I would suggest updating the symbolic names in the spring bundles there. Dan In order to be backward compatible on a minor release, I will revert the usage of ServiceMix bundles for Spring 3.2.x. It means that Karaf will stay with Spring 3.2.6.RELEASE (latest one available on Spring EBR). No objection ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Migration to SCR
I would do #2 first, even in the next patch releases. Having the feature defined doesn’t cause any problems at all and that way external projects can start relying on it, even if it is installed by default. Dan On Feb 3, 2014, at 9:52 AM, Ioannis Canellos ioca...@gmail.com wrote: A while back we discussed about migration from Blueprint to SCR and we all agreed that it was a nice thing to do. The question is how to do it, without making maintenance hard and also without taking ages to deliver this new feature. I think that this should be done in 3 steps: i) Migrate from Blueprint to SCR. ii) Define features for Aries Blueprint iii) Make Blueprint Optional. The first step could be done as part of a Karaf 3.1.0 release. Since all changes are internal and the only thing that would be required is to install SCR by default, it doesn't have to be a major release (in fact it could even be a micro release). The benefit of this approach is that we will not have to maintain an other branch that would require extra maintenance, until we are ready for step (ii). Once we have SCR in our Karaf 3 branch, we can define features for aries blueprint and wait for the rest of the projects of the eco system to pickup those features, were necessary. When camel, cxf, activemq have picked up the changes in our features and have performed a release or two, we can proceed to the final step and have Blueprint not installed by default Thoughts? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [PROPOSAL] Release Karaf 2.3.4 end of this week, 2.4.0 next week ?
+1 But please make sure the releases pick up the latest blueprint release that fixes all kinds of regressions. :-) 2.4 likely should get the latest transaction stuff as well. Dan On Jan 6, 2014, at 4:34 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, I started to work on Jira for 2.3.4 and 2.4.0. As we released 2.3.3 in September, I think it's the good time to release a 2.3.4 maintenance release. WDYT ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: A Blueprint Free Karaf
On 04.12.2013 21:41, Ioannis Canellos wrote: For anyone curious on how Karaf without Blueprint would look like, here is a karaf branch that is free of blueprint: https://github.com/iocanel/karaf/tree/karaf-light (it's a fork of the karat-2.3.x branch). It is actually a refactored karaf 2.3.x that removes blueprint from all modules (yet still provides blueprint as feaures). Karaf specific blueprint namespace handlers have moved to optional bundles so that they can still be used if needed. Blueprint has been replaced with Felix SCR (including the shell commands). Moreover, misc refactorings on features and startup bundles have been performed in order to reduce the size and the amount of bundles in the minimal distro. The result is a minimal distribution that starts 12 bundles [1] (out of 37 which were part of karaf 2.3.3 minimal distro). 10 of those bundle were blueprint bundles and the rest are extra noise. My motivation behind this refactoring was: i) I like declarative services more than blueprint. ii) I've been working on projects that are packaged inside the karaf minimal distro which would benefit from a smaller size (e.g. jclouds-cli). iii) I wanted to make a karaf distro as flexible as possible. Please note that my main focus was the minimal distribution and also this is not 100% polished. Enjoy! [1]: The bundle list of the minimal distro: ID State Level Name [ 0] [Active ] [0] System Bundle (4.0.3) [ 1] [Active ] [5] OPS4J Pax Url - mvn: (1.3.6) [ 2] [Active ] [5] OPS4J Pax Url - wrap: (1.3.6) [ 3] [Active ] [8] OPS4J Pax Logging - API (1.7.1) [ 4] [Active ] [8] OPS4J Pax Logging - Service (1.7.1) [ 5] [Active ] [ 10] Apache Felix Configuration Admin Service (1.6.0) [ 6] [Active ] [ 11] Apache Felix File Install (3.2.6) [ 7] [Active ] [ 13] Apache Felix Declarative Services (1.6.2) [ 8] [Active ] [ 25] Apache Karaf :: Shell :: Console (2.3.4.SNAPSHOT) [ 9] [Active ] [ 30] Apache Karaf :: Features :: Core (2.3.4.SNAPSHOT) [ 10] [Active ] [ 30] Apache Karaf :: Features :: Command (2.3.4.SNAPSHOT) [ 11] [Active ] [ 30] Apache Karaf :: Shell :: Log Commands (2.3.4.SNAPSHOT) [ 12] [Active ] [ 30] Apache Karaf :: Shell :: OSGi Commands (2.3.4.SNAPSHOT) -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: A Blueprint Free Karaf
On Dec 5, 2013, at 10:32 AM, Achim Nierbeck bcanh...@googlemail.com wrote: As far as I understood the idea, it's to use DS for Karaf itself, not to get rid of Blueprint. Just so Karaf itself does have a smaller footprint. @Ioannis did I get this right? Yea, I’m 100% OK with that. I’m just saying if we take it that one step further and remove the blueprint (that would no longer be needed) from the minimal distributions, that will have an impact on users. So basically, I think I’m OK with the code changes and such to flip to DS, just not quite so OK with the removal of BP by default (even if it’s not used by karaf). Dan regards, Achim 2013/12/5 Jean-Baptiste Onofré j...@nanthrax.net Good point Dan. I think you should not hurry about this. Ioannis did a good PoC, but I quickly discussed with him and his goal is not to force the inclusion on Karaf 3.x. I think it makes more sense (and it's wise ;)), to act for a plan for Karaf 4.x. Regards JB On 12/05/2013 04:26 PM, Daniel Kulp wrote: On Dec 5, 2013, at 7:31 AM, Guillaume Nodet gno...@apache.org wrote: I think that can be argued : it's a big internal change, but not really a user-facing one. If the work is done in a compatible way (which I think is doable and should be the goal), it can be done in a minor release, as it would be almost transparent for the user: i.e. a user should still be able to deploy his own application without any changes. So I don't think it requires a major version change. Well, there COULD be an impact…. Right now, some of the features.xml files out there just assume blueprint is available. For example, CXF’s just assumes blueprint is there. They don’t depend on any “blueprint” feature.Thus, an application (or CXF) that would deploy fine on the minimal container out of the box right now would not with 3.1 (or whatever) where blueprint isn’t there. We COULD adjust for this by adding a “blueprint” feature right now (before 3.0 ships) that is relatively redundant with the “framework” feature (or have framework depend on the new blueprint) that the other features.xml could start depending on. That could also be added for a 2.3.x patch as well. Dan 2013/12/5 Jamie G. jamie.goody...@gmail.com Just wanted to contribute my 2 cents -- I'd look at a SCR Karaf for 4.0 - removing Blueprint dependencies from the core is too major a change to try to introduce it to 2.3.x or 3.0 at this stage. --Jamie On Thu, Dec 5, 2013 at 8:10 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: I think we have to distinguish different things: - the learn curve and usage outside of Karaf for developers. CDI is like EJB, and other framework. - the usage of CDI inside an OSGi application or Karaf itself (or for native OSGi applications). The fact that Karaf now supports CDI (via pax-cdi) is as good as supporting OpenEJB (in KarafEE), or Spring (in Karaf natively). I would not use OpenEJB in Karaf itself, nor Spring, nor CDI. If a developer wants to create a generic application (that can work in both OSGi or non-OSGi containers), CDI is good. If a developer want to create a native OSGi application, I would use natively OSGi specific framework (like blueprint). My 0.02€ Regards JB On 12/05/2013 12:06 PM, Christian Schneider wrote: Probably you are right. The reason why I came up with CDI is that it has the potential to be the core of user applications. It is fully featured regarding web and persistence if you include other JavaEE stuff and also defines a standardized extension mechanism. CDI is also well known to JavaEE developers. So my point is/was that CDI may be the only thing a developer needs to learn regarding dependency injection. On the other hand a programmer of user applications running on karaf is quite decoupled from the karaf services and commands. So it is probably not necessary that he uses and understands the karaf internals. So from this perspective minimum footprint counts more than having only one framework. So from this point of view DS really is better than CDI. Another argument supporting this is that while I see most potential in CDI to take over dependency injection in user space it is far from the only solution. So there will always be people who use something else. As karaf needs to support a wide range of frameworks this also speaks for minimum footprint for karaf's internals. Christian On 05.12.2013 11:49, Guillaume Nodet wrote: 2013/12/5 Christian Schneider ch...@die-schneider.net Good idea to look into alternatives to blueprint. The big advantage I see for DS is that it is very light weight. I am not so sure about its long term future though. I personally think the future of OSGi dependency injection is CDI like pax-cdi + weld or openwebbeans. Of course this is not really near term and far from being a sure bet. Still
Re: A Blueprint Free Karaf
On Dec 5, 2013, at 11:03 AM, Achim Nierbeck bcanh...@googlemail.com wrote: Hi Johan, I'm fully with you for the client side I wouldn't walk that path for a Karaf without Blueprint. I just have the feeling that especially for the minimal bundle it could be really helpful to start without blueprint. @Dan regarding minimal and blueprint, yes though I think since we'd still provide the blueprint feature it would be viable way of doing minimal without blueprint but the user who still needs it needs to depend on that blueprint feature. The issues is what to do about frameworks that need blueprint, but the user may not. The user may not even know that Blueprint is needed. Their app may be completely spring-dm based or something. However, if they depend on CXF, they would also need blueprint or CXF won’t work (CXF uses Blueprint in many places). (Yes, changing CXF to use DS or something is certainly a possible enhancement, anyone want to tackle that?) Right now, there isn’t a “blueprint” feature that CXF can depend on. We can add one for 3.1 or 4.0, but if CXF then depends on it, then it would no longer load into any 2.3.x Karaf without also doing a 2.3.x release. That’s mostly my point, removing something that is there by default in 2.3 or 3.0 WILL have user impact. It’s not a major one, but it is something that needs to be considered on how to manage it, particularly for frameworks that tend to try and keep a range of compatible Karaf versions supported. It could also be something like having a very small bundle listener or bundle install hook or something in the core that when a bundle is loaded (pre-resolve), if there is a Bundle-Blueprint” manifest, it would automatically start the blueprint feature. Might have some timing quirks that would need to be worked out, but possibly doable. Dan regards, Achim 2013/12/5 Johan Edstrom seij...@gmail.com Looking out there, I've seen one customer using DS in the last 3 years or so. TX, JPA, Spring migrations, Spring only, BP only - sure. Not to mention NS Handlers and so on. It would make a tiny karaf viable, less deps and faster startup. I doubt any developing user would (want to) be able to give up DI. /je On Dec 5, 2013, at 8:36 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: You are right, but we should be careful about the side effects, overlap, etc ;) On 12/05/2013 04:32 PM, Achim Nierbeck wrote: As far as I understood the idea, it's to use DS for Karaf itself, not to get rid of Blueprint. Just so Karaf itself does have a smaller footprint. @Ioannis did I get this right? regards, Achim 2013/12/5 Jean-Baptiste Onofré j...@nanthrax.net Good point Dan. I think you should not hurry about this. Ioannis did a good PoC, but I quickly discussed with him and his goal is not to force the inclusion on Karaf 3.x. I think it makes more sense (and it's wise ;)), to act for a plan for Karaf 4.x. Regards JB On 12/05/2013 04:26 PM, Daniel Kulp wrote: On Dec 5, 2013, at 7:31 AM, Guillaume Nodet gno...@apache.org wrote: I think that can be argued : it's a big internal change, but not really a user-facing one. If the work is done in a compatible way (which I think is doable and should be the goal), it can be done in a minor release, as it would be almost transparent for the user: i.e. a user should still be able to deploy his own application without any changes. So I don't think it requires a major version change. Well, there COULD be an impact…. Right now, some of the features.xml files out there just assume blueprint is available. For example, CXF’s just assumes blueprint is there. They don’t depend on any “blueprint” feature.Thus, an application (or CXF) that would deploy fine on the minimal container out of the box right now would not with 3.1 (or whatever) where blueprint isn’t there. We COULD adjust for this by adding a “blueprint” feature right now (before 3.0 ships) that is relatively redundant with the “framework” feature (or have framework depend on the new blueprint) that the other features.xml could start depending on. That could also be added for a 2.3.x patch as well. Dan 2013/12/5 Jamie G. jamie.goody...@gmail.com Just wanted to contribute my 2 cents -- I'd look at a SCR Karaf for 4.0 - removing Blueprint dependencies from the core is too major a change to try to introduce it to 2.3.x or 3.0 at this stage. --Jamie On Thu, Dec 5, 2013 at 8:10 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: I think we have to distinguish different things: - the learn curve and usage outside of Karaf for developers. CDI is like EJB, and other framework. - the usage of CDI inside an OSGi application or Karaf itself (or for native OSGi applications). The fact that Karaf now supports CDI (via pax-cdi) is as good as supporting OpenEJB (in KarafEE), or Spring
Re: StandardFeaturesTest.installSSHFeature() problem (trunk)
:649)[:1.6.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker. runTask(ThreadPoolExecutor.java:895)[:1.6.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker.run( ThreadPoolExecutor.java:918)[:1.6.0_65] at java.lang.Thread.run(Thread.java:695)[:1.6.0_65] Caused by: java.lang.NoClassDefFoundError: org/apache/mina/core/service/IoHandler at java.lang.ClassLoader.defineClass1(Native Method)[:1.6.0_65] at java.lang.ClassLoader.defineClassCond(ClassLoader. java:637)[:1.6.0_65] at java.lang.ClassLoader.defineClass(ClassLoader.java:621)[:1.6.0_65] at org.apache.felix.framework.BundleWiringImpl$ BundleClassLoader.findClass(BundleWiringImpl.java:2279) at org.apache.felix.framework.BundleWiringImpl. findClassOrResourceByDelegation(BundleWiringImpl.java:1501) at org.apache.felix.framework.BundleWiringImpl.access$400( BundleWiringImpl.java:75) at org.apache.felix.framework.BundleWiringImpl$ BundleClassLoader.loadClass(BundleWiringImpl.java:1955) at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_65] at org.apache.sshd.common.io.mina.MinaServiceFactory.createAcceptor( MinaServiceFactory.java:36) at org.apache.sshd.common.io.DefaultIoServiceFactory.createAcceptor( DefaultIoServiceFactory.java:39) at org.apache.sshd.SshServer.createAcceptor(SshServer.java:375) at org.apache.sshd.SshServer.start(SshServer.java:301) at org.apache.karaf.shell.ssh.SshServerFactory.start( SshServerFactory.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.6.0_65] at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39)[:1.6.0_65] at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25)[:1.6.0_65] at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_65] at org.apache.aries.blueprint.utils.ReflectionUtils.invoke( ReflectionUtils.java:297) at org.apache.aries.blueprint.container.BeanRecipe.invoke( BeanRecipe.java:958) at org.apache.aries.blueprint.container.BeanRecipe. runBeanProcInit(BeanRecipe.java:712) ... 79 more Caused by: java.lang.ClassNotFoundException: org.apache.mina.core.service.IoHandler not found by org.apache.sshd.core [16] at org.apache.felix.framework.BundleWiringImpl. findClassOrResourceByDelegation(BundleWiringImpl.java:1532) at org.apache.felix.framework.BundleWiringImpl.access$400( BundleWiringImpl.java:75) at org.apache.felix.framework.BundleWiringImpl$ BundleClassLoader.loadClass(BundleWiringImpl.java:1955) at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_65] ... 99 more Uninstalling ssh 15:50:50,377 | INFO | apache.aries.blueprint.container.BlueprintExtender | Destroying BlueprintContainer for bundle org.apache.karaf.shell.ssh [org.ops4j.pax.exam.spi.reactors.ReactorManager] : suite finished Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.134 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead OPS4J Pax for Vaadin http://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Build failure on Karaf trunk...
David, I was able to reproduce this. Filed a patch: https://issues.apache.org/jira/browse/KARAF-2530 Dan On Oct 25, 2013, at 1:48 PM, David Bosschaert david.bosscha...@gmail.com wrote: JB Wrote: Anyway, I'm not sure the problem is in Karaf, as the error comes from plexus. Possibly - although I do see a the Karaf Kar Mojo in the stacktrace. It only started appearing today on the Karaf trunk. I had my checkout previously up-to-date to Oct 24 and all was fine then (on OSX with JDK 1.6 and Maven 3.0.3)... ja...@carmanconsulting.com wrote: Stack trace? Caused by: java.lang.NoSuchMethodError: org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLineAsCallable(Lorg/codehaus/plexus/util/cli/Commandline;Ljava/io/InputStream;Lorg/codehaus/plexus/util/cli/StreamConsumer;Lorg/codehaus/plexus/util/cli/StreamConsumer;I)Lorg/codehaus/plexus/util/cli/CommandLineCallable; at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributesByPath(PlexusIoResourceAttributeUtils.java:247) at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.getFileAttributes(PlexusIoResourceAttributeUtils.java:172) at org.codehaus.plexus.archiver.ArchiveEntry.createFileEntry(ArchiveEntry.java:159) at org.codehaus.plexus.archiver.AbstractArchiver.addFile(AbstractArchiver.java:404) at org.codehaus.plexus.archiver.AbstractArchiver.addFile(AbstractArchiver.java:316) at org.apache.karaf.tooling.features.CreateKarMojo.createArchive(CreateKarMojo.java:224) at org.apache.karaf.tooling.features.CreateKarMojo.execute(CreateKarMojo.java:139) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 20 more -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problems with new maven version
On Aug 21, 2013, at 8:36 AM, Andreas Pieber anpie...@gmail.com wrote: Hey guys, I've kind of a problem with KARAF-2395 [1]. While I've a patch making everything compatible to maven 3.1.x it's incompatible then to maven 3.0.x. Thanks to the way we're using aether the only real option I see is to either set the minimum maven version to 3.1 or provide two commands; one for 3.0 and one for 3.1. Both solutions don't feel ideal for me. Any ideas/proposals how to progress? I guess my suggestion would be to look at the source for the maven-dependency-plugin to see how it's handling some of this. I don't think there is much that Karaf does that the dependency plugin doesn't do something very similar to (copying artifacts, resolving tree's, etc..).Since the latest dependency plugin works with both versions of Maven, there should be a way. Dan Kind regards, Andreas [1]https://issues.apache.org/jira/browse/KARAF-2395 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Spring ... not longer OSGIfied
One thing that projects like CXF and Camel and such SHOULD be aware of is that since the jars they are building against are no longer bundles, the bundle plugin will not create version ranges for the imports. They likely should re-audit any jars they have that use spring to check to make sure the proper version ranges are in place. Dan On May 31, 2013, at 4:44 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: It's on the Spring EBR: http://ebr.springsource.com/repository/app/faq FYI, Karaf 2.x and 3.x now uses Spring 3.2.x as OSGi bundle, and etc/org.ops4j.pax.url.mvn.cfg contains the Spring EBR repository. Regards JB On 05/31/2013 07:18 PM, Charles Moulliard wrote: Hi, As last bundles of Spring ( 3.2) are not longer OSGIfied, what do we plan to do : karaf@root install mvn:org.springframework/spring-orm/3.2.2.RELEASE Bundle ID: 638 karaf@root headers 638 Bundle 638 -- Manifest-Version = 1.0 Implementation-Version = 3.2.2.RELEASE Implementation-Title = spring-orm Created-By = 1.7.0_10 (Oracle Corporation) 1) Create ServiceMix Spring OSGI Bundle 2) Switch from Spring to Blueprint, Aries JTA, Aries JPA, ... Regards, -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Board Report - June 2013
Lately, the board has been asking for two additional things: 1) Actual dates for the releases. 2) If no PMC additions or committer additions, when was the last addition. The report should be updated to reflect those. Dan On Jun 2, 2013, at 3:26 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, I prepared the board report for June 2013: https://cwiki.apache.org/confluence/display/KARAF/Board+Reports I would like to send it very quickly. So please review it and update it if I forgot something. Thanks ! Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: fuse source repos are down
On Mar 12, 2013, at 8:19 PM, Jamie G. jamie.goody...@gmail.com wrote: Was there a specific resource that made the snapshot build fail, or just not being able to access the repo enough to stop the build. In the later case it shouldn't have stopped building, in the former I wonder if said artifacts can be replicated on central as Jansi has been. jansi is at central. I would remove the repo from the root pom (or comment it out). It would only be needed if you need a snapshot version of jansi. However, with it there, it would be consulted for all snapshot deps. If it goes down and you have a snapshot dep, you're screwed. (or use -o for offline, but you would need to hope you already have some version of the snapshot) Dan Cheers, Jamie On Tue, Mar 12, 2013 at 9:45 PM, Guillaume Nodet gno...@gmail.com wrote: Jansi is on central : http://repo1.maven.org/maven2/org/fusesource/jansi/jansi/ On Wed, Mar 13, 2013 at 1:12 AM, Jamie G. jamie.goody...@gmail.com wrote: I've been able to build karaf 2.2.x, 2.3.x, and 3.0.x - perhaps I'm just picking up dependencies from my m2. I'll wipe out my m2 repo and try again. IIRC the only resource that we're picking up from a fuse repo is jansi. Cheers, Jamie On Tue, Mar 12, 2013 at 9:35 PM, Łukasz Dywicki l...@code-house.org wrote: Andrei, Please do not cross post across user/developer mailing lists with same problem. Can you point which branch you are trying to build and what fails? \o/, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Andrei Pozolotin andrei.pozolo...@gmail.com w dniu 12 mar 2013, o godz. 22:53: Hello there. FYI fuse source repos are down http://fuse.fusesource.org/fabric/download.html impossible to build karaf snapshot. Thank you, Andrei -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: release by subsystem
On Mar 12, 2013, at 8:36 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: Jamie: :-) how about automatic YES for RC release provided there is not a single NO ? As long as there are at least three YES votes to go along with the no NO votes. :-) Seriously, this falls into the lines of standard Apache release process guidelines. Not something that is really changeable except under extreme circumstances. (example would be shortening the 72 hour window for an emergency security release) Dan Andrei Original Message Subject: Re: release by subsystem From: Jamie G. jamie.goody...@gmail.com To: Andrei Pozolotin andrei.pozolo...@gmail.com Cc: dev@karaf.apache.org, Guillaume Nodet gno...@gmail.com Date: Tue 12 Mar 2013 07:32:11 PM CDT RC's are a tagged and signed entity that are released from Apache - that requires a vote. The nightly snapshot builds are available for integration purposes in the mean time. Cheers, Jamie On Tue, Mar 12, 2013 at 9:58 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: Jamie: cant you make a case that RC is not really a release? Andrei Original Message Subject: Re: release by subsystem From: Jamie G. jamie.goody...@gmail.com To: dev@karaf.apache.org Cc: Guillaume Nodet gno...@gmail.com Date: Tue 12 Mar 2013 07:24:53 PM CDT Sorry for jumping in here, Apache builds require approval before release: http://www.apache.org/dev/release.html#approving-a-release As to release schedule, that's purely at the discretion of the community to my best understanding. Cheers, Jamie On Tue, Mar 12, 2013 at 9:49 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: Guillaume: how about automatic, once a month, karaf RC-XXX release, w/o vote? Andrei. Original Message Subject: Re: release by subsystem From: Guillaume Nodet gno...@gmail.com To: dev@karaf.apache.org dev@karaf.apache.org Date: Tue 12 Mar 2013 06:24:24 PM CDT On Tue, Mar 12, 2013 at 11:03 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: *Jean-Baptiste, Łukasz** * FYI: 1) I released a jenkins plugin which allows incremental cascaded releases from any level of dependency tree: https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin Thx for the heads up. 2) I hope you can switch away from monolithic releases and release karaf modules/subsystems on demand and often. Releasing karaf is fairly easy, and we rarely are waiting for third party dependencies. When that happens, it's mostly because we have bugs waiting to be fixed. 3) IIRC, the first time 3.0.0.RC1 will come out in 2 weeks was promised on this mailing list about 2 years back :-) And this has nothing to do with the release process. Technically speaking, trunk or branches are mostly always in a releasable state. Thank you, Andrei Original Message Subject: Re: release by subsystem From: Jean-Baptiste Onofré j...@nanthrax.net To: dev@karaf.apache.org Date: Thu 07 Feb 2013 02:26:10 PM CST Hi Andrei, I understand your point. Some parts are really tight together. However, that's the purpose of the minimal distribution and framework: - framework should provide the most minimal Karaf container (however, it embeds Aries Blueprint for instance, as Karaf bundles use it) - minimal is a very lightweight Karaf container, the purpose is to let the user create a custom distribution on top of that. I'm listening all proposals to improve these distributions ! Regards JB On 02/07/2013 05:30 PM, Andrei Pozolotin wrote: *Jean-Baptiste* I am curious if you envision to change karaf layout so release by subsystem is possible. For example, if I use minimal sub set of karaf, which does not need Aries, why should I wait for it? this is similar to how ops4j was partitioned way back, so there are no monolithic Godzilla releases any more. Thank you, Andrei -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: release by subsystem
. Releasing karaf is fairly easy, and we rarely are waiting for third party dependencies. When that happens, it's mostly because we have bugs waiting to be fixed. 3) IIRC, the first time 3.0.0.RC1 will come out in 2 weeks was promised on this mailing list about 2 years back :-) And this has nothing to do with the release process. Technically speaking, trunk or branches are mostly always in a releasable state. Thank you, Andrei Original Message Subject: Re: release by subsystem From: Jean-Baptiste Onofré j...@nanthrax.net To: dev@karaf.apache.org Date: Thu 07 Feb 2013 02:26:10 PM CST Hi Andrei, I understand your point. Some parts are really tight together. However, that's the purpose of the minimal distribution and framework: - framework should provide the most minimal Karaf container (however, it embeds Aries Blueprint for instance, as Karaf bundles use it) - minimal is a very lightweight Karaf container, the purpose is to let the user create a custom distribution on top of that. I'm listening all proposals to improve these distributions ! Regards JB On 02/07/2013 05:30 PM, Andrei Pozolotin wrote: *Jean-Baptiste* I am curious if you envision to change karaf layout so release by subsystem is possible. For example, if I use minimal sub set of karaf, which does not need Aries, why should I wait for it? this is similar to how ops4j was partitioned way back, so there are no monolithic Godzilla releases any more. Thank you, Andrei -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Karaf version 2.3.1
On Feb 28, 2013, at 9:25 AM, Dan Tran dant...@gmail.com wrote: now that the Vote has been canceled, I have a second thought on those 2 bugs i found. Can Aries team address this quickly? Since those are regression bugs. Sorry, cant help to ask. Nothing in Aries goes quickly…. why do you think 2.3.1 has taken so long. :-( I'd personally suggest getting 2.3.1 out now and when Aries does get around to getting things fixed, get a 2.3.2. Might be a couple weeks, maybe a month, whatever. I'd like to see more releases more often rather than keep waiting for Aries. That's my $0.02 worth. Dan Thanks -D On Thu, Feb 28, 2013 at 3:32 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Agree, The distro should start out of the box. I revert my vote to -1. Regards JB On 02/28/2013 11:42 AM, Jamie G. wrote: I tend to agree with that reasoning - our distros need to at least startup out of the box. I'm going to post a -1 on this release due to the minimal distro not starting. Once this issue is resolved another RC will be posted for review and vote. Cheers, Jamie On Thu, Feb 28, 2013 at 6:42 AM, Ioannis Canellos ioca...@gmail.com wrote: The minimal distribution fails to start because its missing the org.apache.karaf.jaas.authz-2.3.1.jar from the system repo. Having one of two flavor not being able to start, seems like a show stopper, but I am not sure. What do you thing? -- *Ioannis Canellos* * ** Blog: http://iocanel.blogspot.com ** Twitter: iocanel * -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Idea: Allow users to patch feature files
://team.ops4j.org/wiki/display/PAXVAADIN/Home Commiter Project Lead blog http://notizblog.nierbeck.de/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Idea: Allow users to patch feature files
Could this be even more generic and apply to everything loaded via a URL? Swap the version of xerces with this new version. Or use specs 2.2 instead of 2.1 or similar. Dan On Feb 26, 2013, at 3:46 AM, Christian Schneider ch...@die-schneider.net wrote: Hi all, sometimes we have the issue that a feature file of an already released project is incorrect. Another similar case is if a small issue appears that can be fixed by just patching a single bundle. In both cases it is necessary to change an existing feature file to make this work without a new release and without making user apps bump up the dependency to the feature file to the next bugfix release number. So I thought about a way to patch feature files at runtime. The idea is to have a config with: mvn url of feature:path to patch This config would make the feature command apply the patches to the named feature files after loading them. So a user could patch their feature files to quickly fix simple issues. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Idea: Allow users to patch feature files
On Feb 26, 2013, at 11:34 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Catcha. I think that if we update the feature XML (including the URL of bundles), it works with a simple URL refresh on the features repositories. My point is: if the user override the features XML in the system repo, it already works. So we can apply diff + patch -p0 directly on the features XMLs. The problem with this is that if the user then does: features:chooseurl foosnarf 2.5 and foosnarf also uses an older version, they still get the older version. This requires the user to to patch a BUNCH of features.xml files.I'd definitely prefer something that would allow overriding of information in the system directory (or pulled in), not require changes to stuff in the system directory. Dan Regards JB On 02/26/2013 05:30 PM, Daniel Kulp wrote: On Feb 26, 2013, at 11:14 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: What is the value comparing to just a URL refresh and bundle refresh ? Not sure to see the point. Basically, to allow productizations of Karaf to more easily unify versions of various libraries.For example, lets suppose the CXF features.xml pulls in a particular version of something, lets say WSS4J.Camel, because they may run a little behind CXF, may have an older version in their features.xml. (forget ranges and forget the obr for second) If we could map URL's, we could leave the camel features file alone. There are a bunch of bundles that CXF and Camel (and others) have at different patch levels. Yes, we can work in the communities to unify some of that, but that still leaves the people that are trying to mix and match various versions to have some extra headaches. The other scenario would be that Camel imports the CXF features file. Thus, to get Camel to use a new version of CXF requires a patched version of the Camel features.xml or you end up with both versions of CXF in the features:list.If we could map the URL for the imported features.xml, then we could, more simply, prevent these issues. Dan Regards JB On 02/26/2013 05:12 PM, Daniel Kulp wrote: Could this be even more generic and apply to everything loaded via a URL? Swap the version of xerces with this new version. Or use specs 2.2 instead of 2.1 or similar. Dan On Feb 26, 2013, at 3:46 AM, Christian Schneider ch...@die-schneider.net wrote: Hi all, sometimes we have the issue that a feature file of an already released project is incorrect. Another similar case is if a small issue appears that can be fixed by just patching a single bundle. In both cases it is necessary to change an existing feature file to make this work without a new release and without making user apps bump up the dependency to the feature file to the next bugfix release number. So I thought about a way to patch feature files at runtime. The idea is to have a config with: mvn url of feature:path to patch This config would make the feature command apply the patches to the named feature files after loading them. So a user could patch their feature files to quickly fix simple issues. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Idea: Allow users to patch feature files
On Feb 26, 2013, at 12:09 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: OK, after discussing with Dan, I got a better understanding. The purpose is not to have a patch. The purpose is to have a mapping of URL (ALL URL, feature, bundle, config, or whatever). Basically, it means that we can have a cfg file in etc, let say etc/org.ops4j.pax.url.map.cfg containing: # feature XML mvn:foo/bar/1.0/xml/features=mvn:myfoo/mybar/1.1/xml/features # bundle mvn:group/bundleA/1.0=mvn:group/bundleA/1.1 # config ... At URL resolution, Pax Url can check the content of the map cfg and use the mapped URL. Like this, it allows users to override any kind of resources. I used Pax Url because the URL handling is performed there, and so I think the feature should go there. WDYT ? Yea. Exactly that. Thanks for distilling my random thoughts down into something workable. I'd SUGGEST also making the source URL's a regex of some sort: mvn:foo/bar/1.*/xml/features=mvn:myfoo/mybar/1.1/xml/features or similar. People could use exact versions/url's, but a regex just makes it a bit more flexible. Probably could even do the group expansions: mvn:org.apache.cxf/(.*)/2.6.5=mvn:org.apache.cxf/\1/2.6.6 :-) Dan Regards JB On 02/26/2013 05:57 PM, Daniel Kulp wrote: On Feb 26, 2013, at 11:34 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Catcha. I think that if we update the feature XML (including the URL of bundles), it works with a simple URL refresh on the features repositories. My point is: if the user override the features XML in the system repo, it already works. So we can apply diff + patch -p0 directly on the features XMLs. The problem with this is that if the user then does: features:chooseurl foosnarf 2.5 and foosnarf also uses an older version, they still get the older version. This requires the user to to patch a BUNCH of features.xml files.I'd definitely prefer something that would allow overriding of information in the system directory (or pulled in), not require changes to stuff in the system directory. Dan Regards JB On 02/26/2013 05:30 PM, Daniel Kulp wrote: On Feb 26, 2013, at 11:14 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: What is the value comparing to just a URL refresh and bundle refresh ? Not sure to see the point. Basically, to allow productizations of Karaf to more easily unify versions of various libraries.For example, lets suppose the CXF features.xml pulls in a particular version of something, lets say WSS4J.Camel, because they may run a little behind CXF, may have an older version in their features.xml. (forget ranges and forget the obr for second) If we could map URL's, we could leave the camel features file alone. There are a bunch of bundles that CXF and Camel (and others) have at different patch levels. Yes, we can work in the communities to unify some of that, but that still leaves the people that are trying to mix and match various versions to have some extra headaches. The other scenario would be that Camel imports the CXF features file. Thus, to get Camel to use a new version of CXF requires a patched version of the Camel features.xml or you end up with both versions of CXF in the features:list.If we could map the URL for the imported features.xml, then we could, more simply, prevent these issues. Dan Regards JB On 02/26/2013 05:12 PM, Daniel Kulp wrote: Could this be even more generic and apply to everything loaded via a URL? Swap the version of xerces with this new version. Or use specs 2.2 instead of 2.1 or similar. Dan On Feb 26, 2013, at 3:46 AM, Christian Schneider ch...@die-schneider.net wrote: Hi all, sometimes we have the issue that a feature file of an already released project is incorrect. Another similar case is if a small issue appears that can be fixed by just patching a single bundle. In both cases it is necessary to change an existing feature file to make this work without a new release and without making user apps bump up the dependency to the feature file to the next bugfix release number. So I thought about a way to patch feature files at runtime. The idea is to have a config with: mvn url of feature:path to patch This config would make the feature command apply the patches to the named feature files after loading them. So a user could patch their feature files to quickly fix simple issues. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http
Re: Idea: Allow users to patch feature files
On Feb 26, 2013, at 11:16 AM, Łukasz Dywicki l...@code-house.org wrote: Guys, I don't think going in 'mapping direction' is good. The scenario you have is really case with version race between CXF and Camel releases. I want mark here, that we have an project to solve problem without complicating Karaf - it's called ServiceMix. ;-) OBR resolver should avoid some of problems you pointed. I think in your case you may publish just updated feature file for things you want to have. How do you propose to create a ServiceMix release that uses Camel 2.10.4 (latest release) and CXF 2.7.3 (latest release) without some sort of mapping of features file patching or similar? It's the exact same problem for ServiceMix. We're trying to find a solution that is a bit more generic. Dan Cheers, Łukasz Dywicki -- l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org Wiadomość napisana przez Chris Geer ch...@cxtsoftware.com w dniu 26 lut 2013, o godz. 12:29: On Tue, Feb 26, 2013 at 10:09 AM, Jean-Baptiste Onofré j...@nanthrax.netwrote: OK, after discussing with Dan, I got a better understanding. The purpose is not to have a patch. The purpose is to have a mapping of URL (ALL URL, feature, bundle, config, or whatever). Basically, it means that we can have a cfg file in etc, let say etc/org.ops4j.pax.url.map.cfg containing: # feature XML mvn:foo/bar/1.0/xml/features=**mvn:myfoo/mybar/1.1/xml/**features # bundle mvn:group/bundleA/1.0=mvn:**group/bundleA/1.1 # config ... At URL resolution, Pax Url can check the content of the map cfg and use the mapped URL. Like this, it allows users to override any kind of resources. I used Pax Url because the URL handling is performed there, and so I think the feature should go there. WDYT ? Overall I think this will work but I have one concern around the features commands. I'm concerned that if it's purely a URL mapping that it might be confusing to people who run things like feature:info camel and the dependency list shows camel-core 2.10.3 even when 2.10.4 being installed due to a mapping. It would be better (IMHO) that if there is a mapping, the feature commands could use that data as well and display what the new dependencies are. I realize this complicates things a bit but it will reduce confusion long term. Best case for feature:info camel would be showing something like this. Description of camel 2.10.3 feature Feature has no configuration Feature has no configuration files Feature depends on: camel-core 2.10.3 (mapped to camel-core 2.10.4) camel-spring 2.10.3 camel-blueprint 2.10.3 (mapped to camel-blueprint 2.10.5-SNAPHOT) Feature has no bundles. Bottom line: URL mapping sounds good but I think more than Pax-URL needs to be aware of it to reduce confusion. Chris Regards JB On 02/26/2013 05:57 PM, Daniel Kulp wrote: On Feb 26, 2013, at 11:34 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Catcha. I think that if we update the feature XML (including the URL of bundles), it works with a simple URL refresh on the features repositories. My point is: if the user override the features XML in the system repo, it already works. So we can apply diff + patch -p0 directly on the features XMLs. The problem with this is that if the user then does: features:chooseurl foosnarf 2.5 and foosnarf also uses an older version, they still get the older version. This requires the user to to patch a BUNCH of features.xml files.I'd definitely prefer something that would allow overriding of information in the system directory (or pulled in), not require changes to stuff in the system directory. Dan Regards JB On 02/26/2013 05:30 PM, Daniel Kulp wrote: On Feb 26, 2013, at 11:14 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: What is the value comparing to just a URL refresh and bundle refresh ? Not sure to see the point. Basically, to allow productizations of Karaf to more easily unify versions of various libraries.For example, lets suppose the CXF features.xml pulls in a particular version of something, lets say WSS4J. Camel, because they may run a little behind CXF, may have an older version in their features.xml. (forget ranges and forget the obr for second) If we could map URL's, we could leave the camel features file alone. There are a bunch of bundles that CXF and Camel (and others) have at different patch levels. Yes, we can work in the communities to unify some of that, but that still leaves the people that are trying to mix and match various versions to have some extra headaches. The other scenario would be that Camel imports the CXF features file. Thus, to get Camel to use a new version of CXF requires a patched version of the Camel features.xml or you end up
Re: [Discuss] Apache Karaf 2.3.1 RC in two weeks time?
On Jan 31, 2013, at 11:27 AM, Dan Tran dant...@gmail.com wrote: To improve for next time, we may want to build with aries snaphot or staging release to detect integration issue early +1 - particularly if we're specifically waiting for fixes from Aries. Dan -D On Thu, Jan 31, 2013 at 7:58 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Thu, Jan 31, 2013 at 4:49 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: I would prefer to propose a clean 2.3.1 fixing one of the major issue in 2.3.0. I don't want to hurry to release 2.3.1 without the Aries fix. I'm sure that Dan will be able to cut off a new Aries release quickly. If it's take too much time, I will see how to move forward. It's just a question of days, no more. Thanks for the status update. Regards JB On 01/31/2013 04:38 PM, Claus Ibsen wrote: On Thu, Jan 31, 2013 at 4:32 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: I updated Aries JMX, Blueprint, ... in Karaf 2.3.1-SNAPSHOT, but unfortunately, this Aries release introduced two new issues. I created the Jira and provide fixes, I'm afraid that it will require a new Aries release. Anyway, I'm investigating some workaround, but I would prefer a clean Aries release. What about releasing 2.3.1 with the *same* Aries release as 2.3.0. At least end users of Karaf 2.3.0 gets the fixes. And when the new Aries release is out and has been tested and works etc. Then Karaf 2.3.2 can be released. Regards JB On 01/31/2013 03:18 PM, Claus Ibsen wrote: Hi Any update on a Karaf 2.3.1 release? -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Claus Ibsen - Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: https://issues.apache.org/jira/browse/KARAF-1334
On Oct 24, 2012, at 2:37 PM, Andrei Pozolotin andrei.pozolo...@gmail.com wrote: Hello; I think this should be re-opened https://issues.apache.org/jira/browse/KARAF-1334 watchers: Andrei Pozolotin https://issues.apache.org/jira/secure/ViewProfile.jspa?name=andrei.pozolotin (andrei.pozolotin) Ben Doerr https://issues.apache.org/jira/secure/ViewProfile.jspa?name=craftsman (craftsman) Christian Schneider https://issues.apache.org/jira/secure/ViewProfile.jspa?name=chris%40die-schneider.net (ch...@die-schneider.net) Jean-Baptiste Onofré https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jbonofre (jbonofre) can some one else please take a look? Just fixed the xpath factory name, new snapshot deploying. If that was the only issue with the 2.0 (or 2.1) versions of the specs, that would be considered minor. :-( I spent quite a bit of time fixing other issues with them last week. I would suggest giving the latest 2.2-SNAPSHOT versions a try and see if they help you. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Apache Karaf 2.3.0 very close
On Oct 9, 2012, at 8:06 AM, Charles Moulliard ch0...@gmail.com wrote: Is it required to deliver Karaf 2.3.0 now or could we postpone it a few days till we provide Spring 3.1 ? I don't think Spring 3.1 upgrade is a few days thing. And if you go down that route, why don't we update to Jetty 8.1 which would bring in Servlet 3 support (which CXF could leverage). Jetty 8 has been out for a long time as well.And if we do that, we could update……… It's a never ending thing. At this point, we have been testing all the various projects with Karaf 2.3 running with Spring 3.0.7, Jetty 7.6.x, etc…. We know things are fairly stable with that. If we keep trying to push things forward, we'll never get it out, or if we do, we won't have the same level of testing and confidence. I know CXF has not been extensively (or at all) tested with Spring 3.1. CXF uses spring a LOT more heavily than Camel and we HAVE run into issues with the various Spring upgrades in the past. I don't have a lot of confidence with it, and since CXF was just released (artifacts promoted this morning), it would be several weeks at least before we would normally get any fixes that may be needed for CXF to work with Spring 3.1. From a CXF standpoint, I'm actually MORE confident in a Jetty 8.1 upgrade than I am a Spring 3.1 upgrade as CXF does test with Jetty 8.1 now. I would suggest: 1) Get 2.3 out ASAP using what we have been testing it with. It's WAY WAY WAY overdue at this point. 2) Start a process of timed releases like CXF (and to a lesser extent Camel). Timed releases avoid a lot of the feature creep. If it's there in time, great. If not, there is always next release. 2.4 could just be 3 months away with Sping 3.1 (or 3.2), Jetty 8.1, etc…Of course, get a wiki page up that shows this roadmap so the other projects that use Karaf heavily can plan accordingly and start testing. Dan On Tue, Oct 9, 2012 at 12:48 PM, Jamie G. jamie.goody...@gmail.com wrote: My understanding that the spring31 feature would be an optional part of Karaf 2.3. As to Karaf 2.4 - other than spring 3.1 i think we need to start a separate thread to discuss that particular branch's major changes. Please note, we've added a 2.4.0 version to Jira so that issues for that future release can be recorded. Cheers, Jamie On Tue, Oct 9, 2012 at 8:12 AM, Christian Müller christian.muel...@gmail.com wrote: I share most/all of the opinions. My additional 0,02$: - If we have to release Karaf 2.3.0 today or in the next days, may be it's safer to postpone the spring31 feature for Karaf 2.4.0/3.0.0. In this case, Karaf 2.4.0 should be released in the next 2 - 5 weeks. - If we can postpone Karaf 2.3.0 for 4 - 14 days, it would be great to provide the spring31 feature in Karaf 2.3.0. Best, Christian On Tue, Oct 9, 2012 at 11:19 AM, Jamie G. jamie.goody...@gmail.com wrote: The dependencies table Achim was mentioning: http://karaf.apache.org/index/documentation/karaf-dependencies/karaf-deps-2.2.x.html On Tue, Oct 9, 2012 at 5:12 AM, Guillaume Nodet gno...@gmail.com wrote: Fwiw, mina 2.0.7 is now available, so i'll update 2.3.x branch to it, unless someone has already done it. On Tue, Oct 9, 2012 at 9:23 AM, Achim Nierbeck bcanh...@googlemail.com wrote: I think a valid workaround would be to offer a spring31 feature, I'm quite sure we're able to extract that kind of feature from trunk ;) regarding the road-map proposal, yes this would be really helpful. I know we have a Matrix showing which version does contain which dependencies (@Jamie where is it located?) but somehow it's again a pain to find it. I think we need to redo our webpage desperately since not all information can be found easily and the menu doesn't necessarily relate to the content (e.g. the manual) regards, Achim 2012/10/9 Charles Moulliard ch0...@gmail.com: Even if I understand the karaf position I completely agree about Claus's remark to also have Spring 3.1 for Camel and others projects. What I would like to propose is that we create for Karaf/ServiceMix projects a page containing a table of the different software used and have a roadmap about them. This question is important not only for Spring framework but also Pax, Aries, Felix, ... which are (re)packaged into Karaf/ServiceMix This will avoid that we discover a few days before the publication of a release that we have miss something Just my 5€ cents. On Tue, Oct 9, 2012 at 8:19 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Mon, Oct 8, 2012 at 7:30 PM, Daniel Kulp dk...@apache.org wrote: On Oct 8, 2012, at 1:08 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Agree Claus, but Camel is not the only application running on Karaf. So, we have to think about others projects as well. I have no problem to upgrade to Spring 3.1.x but later (why not imagine a Karaf 2.4.x
Re: Apache Karaf 2.3.0 very close
On Oct 9, 2012, at 11:34 AM, Achim Nierbeck bcanh...@googlemail.com wrote: I second Dan on this only one point I'm not with you :) 2) don't do a 2.4 with jetty 8 but get Karaf 3.0 out of the door instead, we have Jetty 8 Support available there. I would certainly support that direction as well. :-) Dan regards, Achim 2012/10/9 Daniel Kulp dk...@apache.org: On Oct 9, 2012, at 8:06 AM, Charles Moulliard ch0...@gmail.com wrote: Is it required to deliver Karaf 2.3.0 now or could we postpone it a few days till we provide Spring 3.1 ? I don't think Spring 3.1 upgrade is a few days thing. And if you go down that route, why don't we update to Jetty 8.1 which would bring in Servlet 3 support (which CXF could leverage). Jetty 8 has been out for a long time as well.And if we do that, we could update……… It's a never ending thing. At this point, we have been testing all the various projects with Karaf 2.3 running with Spring 3.0.7, Jetty 7.6.x, etc…. We know things are fairly stable with that. If we keep trying to push things forward, we'll never get it out, or if we do, we won't have the same level of testing and confidence. I know CXF has not been extensively (or at all) tested with Spring 3.1. CXF uses spring a LOT more heavily than Camel and we HAVE run into issues with the various Spring upgrades in the past. I don't have a lot of confidence with it, and since CXF was just released (artifacts promoted this morning), it would be several weeks at least before we would normally get any fixes that may be needed for CXF to work with Spring 3.1. From a CXF standpoint, I'm actually MORE confident in a Jetty 8.1 upgrade than I am a Spring 3.1 upgrade as CXF does test with Jetty 8.1 now. I would suggest: 1) Get 2.3 out ASAP using what we have been testing it with. It's WAY WAY WAY overdue at this point. 2) Start a process of timed releases like CXF (and to a lesser extent Camel). Timed releases avoid a lot of the feature creep. If it's there in time, great. If not, there is always next release. 2.4 could just be 3 months away with Sping 3.1 (or 3.2), Jetty 8.1, etc…Of course, get a wiki page up that shows this roadmap so the other projects that use Karaf heavily can plan accordingly and start testing. Dan On Tue, Oct 9, 2012 at 12:48 PM, Jamie G. jamie.goody...@gmail.com wrote: My understanding that the spring31 feature would be an optional part of Karaf 2.3. As to Karaf 2.4 - other than spring 3.1 i think we need to start a separate thread to discuss that particular branch's major changes. Please note, we've added a 2.4.0 version to Jira so that issues for that future release can be recorded. Cheers, Jamie On Tue, Oct 9, 2012 at 8:12 AM, Christian Müller christian.muel...@gmail.com wrote: I share most/all of the opinions. My additional 0,02$: - If we have to release Karaf 2.3.0 today or in the next days, may be it's safer to postpone the spring31 feature for Karaf 2.4.0/3.0.0. In this case, Karaf 2.4.0 should be released in the next 2 - 5 weeks. - If we can postpone Karaf 2.3.0 for 4 - 14 days, it would be great to provide the spring31 feature in Karaf 2.3.0. Best, Christian On Tue, Oct 9, 2012 at 11:19 AM, Jamie G. jamie.goody...@gmail.com wrote: The dependencies table Achim was mentioning: http://karaf.apache.org/index/documentation/karaf-dependencies/karaf-deps-2.2.x.html On Tue, Oct 9, 2012 at 5:12 AM, Guillaume Nodet gno...@gmail.com wrote: Fwiw, mina 2.0.7 is now available, so i'll update 2.3.x branch to it, unless someone has already done it. On Tue, Oct 9, 2012 at 9:23 AM, Achim Nierbeck bcanh...@googlemail.com wrote: I think a valid workaround would be to offer a spring31 feature, I'm quite sure we're able to extract that kind of feature from trunk ;) regarding the road-map proposal, yes this would be really helpful. I know we have a Matrix showing which version does contain which dependencies (@Jamie where is it located?) but somehow it's again a pain to find it. I think we need to redo our webpage desperately since not all information can be found easily and the menu doesn't necessarily relate to the content (e.g. the manual) regards, Achim 2012/10/9 Charles Moulliard ch0...@gmail.com: Even if I understand the karaf position I completely agree about Claus's remark to also have Spring 3.1 for Camel and others projects. What I would like to propose is that we create for Karaf/ServiceMix projects a page containing a table of the different software used and have a roadmap about them. This question is important not only for Spring framework but also Pax, Aries, Felix, ... which are (re)packaged into Karaf/ServiceMix This will avoid that we discover a few days before the publication of a release that we have miss something Just my 5€ cents. On Tue, Oct 9, 2012 at 8:19 AM, Claus
Re: Apache Karaf 2.3.0 very close
On Oct 8, 2012, at 1:08 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Agree Claus, but Camel is not the only application running on Karaf. So, we have to think about others projects as well. I have no problem to upgrade to Spring 3.1.x but later (why not imagine a Karaf 2.4.x for that, it could be a good indicator), and propose both Spring 3.0 and 3.1 in Karaf 2.3.0 (depending of the impact, that I gonna test tonight). I agree with that.I know CXF has had very little testing with Spring 3.1.x. I would definitely prefer keeping on 3.0.7 for Karaf 2.3 and think about that for 2.4. I also agree that this is way to close to release to flip out a major component like spring. Maybe a month ago, but not now. Dan Regards JB On 10/08/2012 06:48 PM, Claus Ibsen wrote: On Mon, Oct 8, 2012 at 6:44 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Camel 2.10.x uses Spring 3.0.7 for now, for we are aligned with Camel 2.10. Does it make sense to update to Spring 3.1.x (for future Camel version maybe) ? Well Camel 2.10 supports both Spring 3.0.x and 3.1.x. And we are frankly only holding back because of Karaf. As when people deploy Camel in Karaf they inherit the spring from Karaf. People in the community would like to use Spring 3.1.x as its been out since December 2011. And its the stable release path where they cut new releases. Regards JB On 10/08/2012 05:55 PM, Claus Ibsen wrote: On Mon, Oct 8, 2012 at 5:45 PM, Jamie G. jamie.goody...@gmail.com wrote: Hi Claus, From the Karaf 2.3.0 pom file: spring.osgi.version1.2.1/spring.osgi.version spring2.version2.5.6.SEC03/spring2.version spring.version3.0.7.RELEASE/spring.version Crap I think you guys shoulder consider switching to the 3.1.2 release of Spring. As well Jetty 7.6.7, so people have the latest stable release of these 2 important pieces. Cheers, Jamie On Mon, Oct 8, 2012 at 1:09 PM, Claus Ibsen claus.ib...@gmail.com wrote: Hi What Spring version does Karaf 2.3.0 come with out of the box? 3.0.x or the newer 3.1.x ? On Mon, Oct 8, 2012 at 10:53 AM, Jamie G. jamie.goody...@gmail.com wrote: I'm always ready! Cheers, Jamie On Mon, Oct 8, 2012 at 5:08 AM, j...@nanthrax.net j...@nanthrax.net wrote: Great, thanks a lot ! -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://wwx.talend.com - Reply message - From: Andreas Pieber anpie...@gmail.com To: dev@karaf.apache.org Subject: Apache Karaf 2.3.0 very close Date: Mon, Oct 8, 2012 9:17 am Hey, On Mon, Oct 8, 2012 at 7:46 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: @Andreas, could you take a look on KARAF-1878 and KARAF-1752 (assigned to you) ? If you are busy today, I think we can postpone to 2.3.1. I wanted to keep KARAF-1878 opened for review till tonight; I'll apply afterwards. I'll also apply KARAF-1752 then. Kind regards, Andreas Thanks all guys, Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Claus Ibsen - Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: ASM version....
On Sep 29, 2012, at 12:06 AM, Freeman Fang freeman.f...@gmail.com wrote: Hi Dan, I think we should be OK to upgrade the asm version, karaf kit include the asm bundle in startup.properties, AFAIK it's only used for the aries.proxy bundle, so if aries.proxy need a higher version of asm, just upgrade asm in karaf should be safe. If other downstream projects which get deployed into karaf need use older asm version, than they can use older asm bundle in their features.xml. Well, downstream projects certainly COULD, but the question is, have they? For example, CXF uses ASM, but doesn't have it listed in the features.xml. Karaf has just always provided a version it could use. CXF is likely different than a lot of apps though in that it has a VERY broad range for ASM (can use 2.x - 4.x) and can thus use whatever version is there whereas most apps are likely locked to either 3.x or 4.x. Basically, 2.3 might not load a project whereas 2.2.x will if that project has a dependency on ASM 3.x but never declared it. Yes, technically a bug in that projects features.xml. I agree with that. But it is something we should likely note in the release notes. Dan @Team, please correct me if I'm wrong Freeman － Freeman Fang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://fusesource.com | http://www.redhat.com/ Twitter: freemanfang Blog: http://freemanfang.blogspot.com http://blog.sina.com.cn/u/1473905042 weibo: http://weibo.com/u/1473905042 On 2012-9-29, at 上午5:37, Daniel Kulp wrote: On Sep 28, 2012, at 5:06 PM, Andreas Pieber anpie...@gmail.com wrote: The question is rather. Does asm 4.x break anything? Or is it only its internal handling? If I remember correctly, it pretty much breaks a lot of things. It's mostly SOURCE compatible, but not binary compatible at all. Code compiled against 3.x won't work with 4.x and vice versa. CXF switched to using some reflection magic to allow use of either version of ASM. Kind of crappy, but…….. Dan Kind regards Andreas On Sep 28, 2012 10:11 PM, Daniel Kulp dk...@apache.org wrote: I was doing some testing with the latest Karaf 2.3.0 snapshot and discovered that it only includes the 3.3.1 version of ASM. However, the Aries proxy stuff now requires 4.x.Is that dependency going to be updated? Should we have both to not break existing things? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
ASM version....
I was doing some testing with the latest Karaf 2.3.0 snapshot and discovered that it only includes the 3.3.1 version of ASM. However, the Aries proxy stuff now requires 4.x.Is that dependency going to be updated? Should we have both to not break existing things? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: ASM version....
On Sep 28, 2012, at 5:06 PM, Andreas Pieber anpie...@gmail.com wrote: The question is rather. Does asm 4.x break anything? Or is it only its internal handling? If I remember correctly, it pretty much breaks a lot of things. It's mostly SOURCE compatible, but not binary compatible at all. Code compiled against 3.x won't work with 4.x and vice versa. CXF switched to using some reflection magic to allow use of either version of ASM. Kind of crappy, but…….. Dan Kind regards Andreas On Sep 28, 2012 10:11 PM, Daniel Kulp dk...@apache.org wrote: I was doing some testing with the latest Karaf 2.3.0 snapshot and discovered that it only includes the 3.3.1 version of ASM. However, the Aries proxy stuff now requires 4.x.Is that dependency going to be updated? Should we have both to not break existing things? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [UPDATE] Jira attachment e-mail
On Sep 19, 2012, at 8:23 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, I just updated the crontab that send the Jira attachment e-mail to support the latest Apache Jira update. jbonofre@minotaur:~/bin$ crontab -l 14 8 * * 1 /home/jbonofre/bin/runreport http://svn.apache.org/repos/asf/cxf/trunk/bin/jira-report.tmpl 12311140 KARAF dev@karaf.apache.org I just copy/pasted that exact command into my terminal and it resulted in an email sent. Thus, not sure what the problem is/was. If you run from the command line does it work? Maybe something strange in the crontab? Dan jbonofre@minotaur:~/bin$ ls -l total 3718 -rwxr-xr-x 1 jbonofre jbonofre 487 Sep 13 06:52 runreport -rw-r--r-- 1 jbonofre jbonofre 1194606 Aug 21 03:16 swizzle-jirareport-1.2.2-dep.jar -rw-r--r-- 1 jbonofre jbonofre 2470591 Sep 13 06:53 swizzle-jirareport-1.6.1-dep.jar However, it doesn't work. I gonna check the Karaf ID in Jira (if it's still 12311140) and ping Dan to help on that. I will keep you posted. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problems running itests on windows in eclipse
If a test passes, shouldn't it also completely clean up after itself?I personally hate things that leave leftover crap all over the place when things have gone well. For failed tests, sure, leave things around to help debug, but for passing tests, clean up. Dan On Sep 19, 2012, at 7:33 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: I always do mvn clean install or mvn clean test. For the target/karaf dir, karaf-pax-exam completly bootstrap a Karaf instance for each test. IMHO, it's a good approach because each test is atomic. If the user want to create only one Karaf instance bootstrap, it can gather all asserts in one method. Regards JB On 09/19/2012 01:22 PM, Christian Schneider wrote: I now got the itests running. The key is to delete the target dir before the test. After I ran one test class the target dir had 80 MB. I think the reason why it now worked is that windows can cope with this size. Still I think it does not make sense that we create a complete karaf dir for each test method and then even keep the data after the test. Can´t we optimize this in some way? Christian Am 19.09.2012 13:07, schrieb Christian Schneider: I saw some failures in the itests on trunk when running from maven. So I tried to import the project into eclipse and run the tests from there to debug into them. The problem is that the tests do not even seem to fully start on eclipse. They seem to hang inside: org.ops4j.pax.exam.spi.intern.TestProbeBuilderImpl.selectCollector(File) I then found that the itests/target dir is about 2GB big. As far as I could debug it seems that the tests do not fully hang and instead seem to go through each of those many files and so never seem to start. So the questions are: Does anyone alse see this behaviour? Can we change this so the tests take less file space? On windows it takes even several minutes to just delete the target dir after the tests. Christian -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [UPDATE] Jira attachment e-mail
On Sep 19, 2012, at 10:14 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi, I have no error on the command line, but no e-mail received. Strange. Can you edit the script to remove the | /usr/sbin/sendmail -it at the end and run it? That SHOULD print the full email that would be generated out on the console. If that works, then we know the swizzle stuff is OK and it's a sendmail issue. If that results in an error or invalid email, can you let me know what is spit out? Dan Regards JB On 09/19/2012 03:46 PM, Daniel Kulp wrote: On Sep 19, 2012, at 8:23 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, I just updated the crontab that send the Jira attachment e-mail to support the latest Apache Jira update. jbonofre@minotaur:~/bin$ crontab -l 14 8 * * 1 /home/jbonofre/bin/runreport http://svn.apache.org/repos/asf/cxf/trunk/bin/jira-report.tmpl 12311140 KARAF dev@karaf.apache.org I just copy/pasted that exact command into my terminal and it resulted in an email sent. Thus, not sure what the problem is/was. If you run from the command line does it work? Maybe something strange in the crontab? Dan jbonofre@minotaur:~/bin$ ls -l total 3718 -rwxr-xr-x 1 jbonofre jbonofre 487 Sep 13 06:52 runreport -rw-r--r-- 1 jbonofre jbonofre 1194606 Aug 21 03:16 swizzle-jirareport-1.2.2-dep.jar -rw-r--r-- 1 jbonofre jbonofre 2470591 Sep 13 06:53 swizzle-jirareport-1.6.1-dep.jar However, it doesn't work. I gonna check the Karaf ID in Jira (if it's still 12311140) and ping Dan to help on that. I will keep you posted. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: a command for listing classes in a bundle
On Aug 22, 2012, at 1:09 PM, Christian Schneider ch...@die-schneider.net wrote: The feature sounds interesting. I would propose bundle:classes or bundle:resources. It could be interesting to have two flavours. Like: bundle:classes bundleid to list all classes in a bundle or bundle:classes fq classname This could list all bundles that have this class. Not sure if bundle:classes would be good command name in this case. Probably something like: bundle:find-class classname or similar. Dan Christian Am 22.08.2012 18:46, schrieb Heath Kesler: I was thinking about adding a command or adding options to an existing command that would allow the user to display a list of classes in a bundle. This will allow users to see what classes are actually in a bundle, not what they think should be in the bundle. Assuming can be a bad thing ;-) I am looking for feedback on the idea, and if this should be a new command or a option on an existing command. I was thinking it should be a new command but looking to the dev group for suggestions. Cheers Heath -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
JIRA's w/ Attachments list
Couple folks asked me this morning about how CXF is doing it's weekly Issues with Attachments email. I just sent a Karaf version to dev@karaf. If you think it's important to have done weekly so things don't get lost, it's not hard. From people.apache.org, you can do: /home/dkulp/bin/runreport \ http://svn.apache.org/repos/asf/cxf/trunk/bin/jira-report.tmpl \ 12311140 KARAF dev@karaf.apache.org although that will send the mail as me. You can copy the runreport script someplace and edit the from line there and the location of the swizzle-jirareport jar. I have in my crontab on p.a.o: 14 8 * * 1 /home/dkulp/bin/runreport . to run it once a week. One of the karaf folks should likely set that up if the community would like it regularly. Note: the cxf/trunk/bin/jira-report.tmpl can also be copied into karaf someplace and edited if you want the report to look different or go back more than 4 weeks or similar. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [REPORT] Apache Karaf
On Friday, June 08, 2012 02:37:10 PM Andreas Pieber wrote: seeing progress is always a fine thing :-) BTW are there any new blog entries, events karaf is presented on (and so on). Following the general list it seams (to me at least) that community building what had been done for community building is also an important part of the report; so such entries might be interesting for the board (besides the obvious activity on the various mailinglists). Just an idea. @commits: maybe writing Commit mailing list instead of commits; while we done tons of commits this list also contains the hudson failure reports (we also received tons of in the last months) creating quite a false impression of the activitiy :-) Actually, the commit count looks about right: http://svnsearch.org/svnsearch/repos/ASF/search?from=20120301to=20120601path=%2Fkaraf 761 total commits. Dan Besides of that smaller issues +1. Those where some great 3 months again with tons of activities and quite great procedure toward 3.0.0! Thx to all of you guys! Kind regards, Andreas On Fri, Jun 8, 2012 at 2:11 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Apache Karaf provides higher level features and services specifically designed for creating OSGi-based servers. Community = Indicators during the last 3 months: - Download: around 12,000 distribution downloads - User mailing list: 424 messages - Dev mailing list: 495 messages - Commits: 758 commits Development === The following new releases have been voted: * Apache Karaf 2.2.6 * Apache Karaf 2.2.7 * Apache Karaf Cellar 2.2.4 We made progresses on the stabilization of the Karaf 3.0 next release. A stabilization branch is going to be create including a 3.0-beta pre-release. Web Site === A new website has been deployed including minor updates and bug fixes. Branding * project website basics: ok * website nav links: ok * trademarks: ok * logo: ok * metadata: ok Issues for board consideration == None so far. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problems building karaf trunk
On Wednesday, May 23, 2012 10:47:46 AM Guillaume Nodet wrote: I think we need at least a working two step build. It can be done using profiles in the root pom and it has to work from a clean repo. The problem is that that will likely make the release process much harder. Not sure if the maven release plugin would be able to deal with multistep build like that. I'm thinking not. Dan So the first step is to build the maven plugin and the required dependencies, the second one is to build everything (easier than just building the rest). The second step should be the default so that dev is not too much impacted, with a README / BUILDING file explaining the steps to build from a clean state. We can start again the discussion, but IIRC it was deliberate and we knew the problems coming ahead when we accepted djencks changes. On Wed, May 23, 2012 at 9:30 AM, Christian Schneider ch...@die-schneider.net wrote: We already talked about the build on irc but to sum it up here also on the list: I tested a build of trunk with a clean maven repo. I did not work out of the box as the karaf-maven-plugin is required when building the feature files. As maven checks that very early the karaf maven plugin is not yet there. So there are three options to really solve that: - The best solution would be to solve the problem in maven as it should not need the plugin so early. There is a very old issue open about it: https://jira.codehaus.org/browse/MNG-1911 So it does not seem this is solved soon - Create a profile in our build that builds up to the karaf-maven-plugin as a first step. Then the full build can be run - Change the feature generation so it does not need a build extension. This would require some more maven config than today but may be worth it I took a simple workaround by commenting out the assemblies module in the root pom. So the build was failing at the itests but the karaf-maven-plugin was built. Then I commented it in again and did a full build which worked. Btw. I had a test failure in the kittests which I currently investigate. Christian Am 22.05.2012 17:50, schrieb Christian Schneider: Am 22.05.2012 17:05, schrieb Guillaume Nodet: Btw, I've tried to build karaf trunk yesterday and couldn't find a way to build it fully. I was starting from a clean repo, but even the root pom was trying to download some other karaf snapshots, so not sure what happens. Thoughts ? Quite probably these are dependencies that were removed by JBs and my refactorings but left in the pom accidently. I will take care of it. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problems building karaf trunk
On Wednesday, May 23, 2012 03:42:17 PM Andreas Pieber wrote: Well... one option might be to release the required components and the karaf-maven-plugin seperatly. Maybe we're able to split those components away far enough to release them separately... I think we might be able to reduce this to a hand of components... Just an idea we would definitely need to dig in deeper to find out the explicit components and which it exactly means to release them separately... To me, it's easier to just reconfigure the three assembly things that use packagingfeature/packaging to be pom and configure in the features plugin explicitly in the right phases. But that's me. :-)The idea of complicating the build system for everyone just to save a little config in the poms seems off balance. Dan Kind regards, Andreas On Wed, May 23, 2012 at 3:36 PM, Guillaume Nodet gno...@gmail.com wrote: No it doesn't. We've lived with that in ServiceMix for a few years, so I'm well aware of the pain btw. On Wed, May 23, 2012 at 3:26 PM, Daniel Kulp dk...@apache.org wrote: On Wednesday, May 23, 2012 10:47:46 AM Guillaume Nodet wrote: I think we need at least a working two step build. It can be done using profiles in the root pom and it has to work from a clean repo. The problem is that that will likely make the release process much harder. Not sure if the maven release plugin would be able to deal with multistep build like that. I'm thinking not. Dan So the first step is to build the maven plugin and the required dependencies, the second one is to build everything (easier than just building the rest). The second step should be the default so that dev is not too much impacted, with a README / BUILDING file explaining the steps to build from a clean state. We can start again the discussion, but IIRC it was deliberate and we knew the problems coming ahead when we accepted djencks changes. On Wed, May 23, 2012 at 9:30 AM, Christian Schneider ch...@die-schneider.net wrote: We already talked about the build on irc but to sum it up here also on the list: I tested a build of trunk with a clean maven repo. I did not work out of the box as the karaf-maven-plugin is required when building the feature files. As maven checks that very early the karaf maven plugin is not yet there. So there are three options to really solve that: - The best solution would be to solve the problem in maven as it should not need the plugin so early. There is a very old issue open about it: https://jira.codehaus.org/browse/MNG-1911 So it does not seem this is solved soon - Create a profile in our build that builds up to the karaf-maven-plugin as a first step. Then the full build can be run - Change the feature generation so it does not need a build extension. This would require some more maven config than today but may be worth it I took a simple workaround by commenting out the assemblies module in the root pom. So the build was failing at the itests but the karaf-maven-plugin was built. Then I commented it in again and did a full build which worked. Btw. I had a test failure in the kittests which I currently investigate. Christian Am 22.05.2012 17:50, schrieb Christian Schneider: Am 22.05.2012 17:05, schrieb Guillaume Nodet: Btw, I've tried to build karaf trunk yesterday and couldn't find a way to build it fully. I was starting from a clean repo, but even the root pom was trying to download some other karaf snapshots, so not sure what happens. Thoughts ? Quite probably these are dependencies that were removed by JBs and my refactorings but left in the pom accidently. I will take care of it. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problems building karaf trunk
On Wednesday, May 23, 2012 04:04:05 PM Christian Schneider wrote: I agree. We should redcommend the packaging feature for our end users but not use it in our own build. With the caveat that it would good to have an it test or similar that uses the plugin like that to make sure it works properly. That would be via the maven invoker stuff and thus not subject to the problematic constraints. :-) Dan So we have a simple build and people have the convenience of the plugin. Christian Am 23.05.2012 15:54, schrieb Guillaume Nodet: Right, I agree, we could just change the way the assembly is build and not use our own plugin to simplify the build. What I meant was I don't think we really want to rework the plugin to get rid of the new packaging. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Plans for release of aries blueprint 0.4.1?
on the feasibility of releasing 0.4.1 rather than just going right to 1.0? Thanks for any updates you can provide! Thanks, Jon -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ FuseSource, Integration everywhere http://fusesource.com -- Daniel Kulp d...@kulp.com http://dankulp.com/blog
Re: Loading of feature within 2.2.7
You need to use the etc/jre.properties.cxf instead of the default. Dan On Thursday, April 26, 2012 12:35:44 AM Brian Topping wrote: I was mentioning this to Jamie last night. The particular feature.xml I have baked causes this error to show up the first time an attempt to load this particular feature is made, but not the second: Error executing command: Could not start bundle mvn:org.apache.cxf/cxf-bundle/2.5.2 in feature(s) cxf-2.5.2: Unable to resolve module org.apache.cxf.bundle [892.0] because it is exposed to package 'javax.xml.bind.attachment' from org.apache.felix.framework [0] and org.apache.servicemix.specs.jaxb-api-2.2 [818.0] via two dependency chains. Chain 1: org.apache.cxf.bundle [892.0] import: ((package=javax.xml.bind.attachment)(version=0.0.0)(!(version=3. 0.0))) export: package=javax.xml.bind.attachment org.apache.felix.framework [0] Chain 2: org.apache.cxf.bundle [892.0] import: (package=com.sun.tools.xjc.reader.xmlschema.parser) export: package=com.sun.tools.xjc.reader.xmlschema.parser; uses:=javax.xml.bind org.apache.servicemix.bundles.jaxb-xjc [850.0] import: ((package=javax.xml.bind)(version=2.2.0)(!(version=3.0.0))) export: package=javax.xml.bind; uses:=javax.xml.bind.attachment export: package=javax.xml.bind.attachment org.apache.servicemix.specs.jaxb-api-2.2 [818.0] I have not tested this behavior in 2.2.6 or dug very deep and don't feel it's a major deal, but can investigate it more if anyone is interested. Cheers, Brian -- Daniel Kulp d...@kulp.com http://dankulp.com/blog
Re: [Discussion] Apache Karaf projects for Google Summer of Code 2012
On Tuesday, February 28, 2012 9:29:08 AM Jamie G. wrote: Hi All, Open source projects and organisations have until Friday, 9 March at 23:00 GMT to apply to mentor students as part of this year's Google Summer of Code (GSoC) event. Projects interested in applying can register (sign in required) for the eighth annual event now; application requirements can be found on the FAQ page and a Mentor Manual is provided. In the past, none of this needed to be done by anyone here. Apache has always applied as an organization and all the Apache projects fell under that. There will likely be discussions starting soon on code-awa...@apache.org about it. (actually, a *bit* surprised there hasn't been more action there.) Dan If we're going to submit a project idea, then we'll have to gain a consensus shortly and register our proposal and mentor nominee to look after the submitted project. Google Summer of Code: http://code.google.com/soc/ Project Registration Page: http://www.google-melange.com/gsoc/profile/org_admin/google/gsoc2012 FAQ Page: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faq s#mentoring_apply Mentoring Manual: http://www.booki.cc/gsoc-mentoring/ Cheers, Jamie -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [Proposal] Start 3.0.x stabilizing branch and feature freeze
On Saturday, January 14, 2012 9:19:53 AM David Jencks wrote: We've been feature complete since last august, except everyone keeps deciding we need more features. I think Andreas's point is that unless we decide that we're going to do a release we'll never run out of essential features that absolutely need to be in 3.0 before we can release it. What specific features do you need in 3.0 that aren't there right now? Is Guillaume's activator stuff ready/in there? That would be the main thing I'd like to see included at this point. Dan anyway +1 from me. thanks david jencks On Jan 14, 2012, at 9:04 AM, Christian Schneider wrote: Basically this is a good idea. I am just unsure if we are already at the point where we should do the branch. Do we have all features necessary for 3.0 finished? I think we should do the branch as soon as we are feature complete. So the branch really can focus on stabilizing things. Christian Am 14.01.2012 16:40, schrieb Andreas Pieber: Hey guys, As all of you know we really want to get Karaf 3.0 out now for some time. But as long we add new groundbreaking features to the master we'll always destabilize it at some point. To give us a chance to finally stabilize the entire thing and getting out a 3.0 release I would like to propose a feature freeze for 3.0 starting (for example) today in a week. Pack everything into trunk you already have and really want to be part of Karaf 3. Then we'll cut off a new branch (karaf-3.0.x) where we do not allow any new features. The version on the master/trunk will be increased to 3.1.0-SNAPSHOT. This should be the place then for all new features. This step should free us from new regressions and give us the time to finalize 3.0.0. WDYT? Kind regards, Andreas -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [PROPOSAL] Change the default jre.properties
:04, schrieb Jean-Baptiste Onofré: Hi all, We have currently an issue in Camel and CXF with the default jre.properties and some exported packages (like JAXB, etc). Currently, by default, the jre.properties exports all packages from the JRE. I would like to propose a new approach: 1/ remove packages with problem by default from the jre.properties 2/ add a set of Karaf features (in bootFeatures by default) to install bundles providing the packages (JAXB, etc) It's a quick workaround for next Karaf 2.2.6 and Karaf 3.0. We can find a more elegant solution. I have some solutions in mind: - new properties in the jre.properties to define an override flag - add a KARAF-INF/* files to define some behaviors (like overriding system packages) Feel free to propose your ideas for this problem. Please: [ ] +1 to remove the packages from the jre.properties and provide a set of Spec/API features in Karaf [ ] 0 [ ] -1 for that (please provide arguments) Ideas (if you have ;)): Thanks Regards JB -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [PROPOSAL] Change the default jre.properties
On Monday, December 26, 2011 8:13:39 PM Guillaume Nodet wrote: Once again, a lot of karaf users just want OSGi. People who want to deploy cxf or camel should be targetted to ServiceMix instead. This is where I STRONGLY disagree with you. If people want to deploy CXF or Camel into OSGi, we should be working on making that easier and work better if at all possible, not point them off to another project.Installing CXF should just be a features:addurl and a features:install.People may already have OSGi based applications that they want to add CXF or Camel services into. They definitely shouldn't be required to switch to ServiceMix for that. I'm hoping your activator idea can really get us there. If that works well, then I'm hoping the above can really become a reality. Dan On Monday, December 26, 2011, Jean-Baptiste Onofré j...@nanthrax.net wrote: Agree Ioannis, I think that 95% of the users don't know the issue, the jre.properties, etc :) They just want to use Camel or CXF directly in Karaf. Regards JB On 12/26/2011 04:13 PM, Ioannis Canellos wrote: Is there any chance that there are users that prefer the jre packages ? From what I understand most Karaf users will not use them at all, but I am not sure about it. If most of our users, will disable them anyway, I see no reason not doing it ourselves ( +1 ). -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [Proposition] - Apache KarafEE
I'm kind of +1 to the idea, but more -0.5 to the idea *here*. I'm struggling to really see how it fits here as compared to being done as part of OpenEJB community.We're getting a lot of stuff going on in Karaf right now that is already beginning to splinter things up a bit and this just seems to me to be further cause issues. Also, if OpenEJB is already considering a Karaf based assembly, what would the difference be between that and this? Anyway, I really think Karaf should stick with the stuff we're working on and more or less leave the EJB stuff and the EE server thing with OpenEJB to them. They are the experts in that. Basically, create an awesome Karaf assembly with all the stuff we provide, then they can build on that to create an OpenEJB EE or something by adding in their stuff. Also, another thing I hate seeing is circular dependencies between projects: Karaf - OpenEJB - KarafEE but that's more of a personal opinion. To put it in another context, we could also create an Karaf JBI which is Karaf + the JBI stuff from SMX. But that doesn't really make a lot of sense to me as that's really up to the SMX folks to do. That's $0.02 worth. Dan On Wednesday, December 14, 2011 1:40:17 PM Charles Moulliard wrote: Hi, As you probably knows, I work with OpenEJB community since a couple of weeks to be able to deploy OpenEJB 4.0.0-SNAPSHOT on Apache Karaf. The OpenEJB container can already been deployed and EJBs jars registered. Work should be done around OpenEJB to be able to easily scan (like we do for deploy directory in Karaf) new or updated EJB jars file and add karaf command. When this new brick will be ready, everything will be in place to propose/provide an Apache KarafEE (EE = Enterprise Edition) release packaging OpenEJB, OpenJPA, Aries JPA, Aries JNDI, Pax Web, Aries Transaction Manager. The first question/remark that I will receive from the communauty will be : Great/Brillant idea but Apache Geronimo is already there and use Apache Karaf. So why developing a new server : There a lot of good reasons why we should do that and study my suggestion carefully but some arguments could be : (1) concurrence in this area is always good comparing to what we have in J2EE world, JBoss, TomEE, Glassfish. J2EE are de facto servers used in major and many Java projects. OSGI is not yet recognized as a robust and simple solution to be used due to lack of tooling, complexity to package and create bundles. So having a new OSGI true J2EE server could help to spread the world, (2) The packaging and deployment approach of Apache Geronimo is a bit different from Karaf and some of the Karaf features are not enable (e.g : features, ...). (3) The Geronimo web console cannot be reused for Apache Karaf and now with our new WebConsole we are independent of Apache WebConsole Felix (4) EJB is back since spec EJB3 like also JPA and more and more project does not longer use de facto Spring ! (5) With Cellar/Fabric we have a strong foundation to deploy/manage/use Karaf in the cloud and design multi-servers architecture. KarafEE could be like Cellar, new WebConsole a subproject having its own assembly release process. It will contain assembly process, featurs, karaf commands, branding and web consoles stuffs. Remark : I have proposed also for OpenEJB that they have a karaf-assembly but our sub-project could be designed for that purpose - http://openejb.979440.n4.nabble.com/Proposition-New-maven-module-OpenEJB-Ka raf-tt4194577.html What do you think about this proposition ? Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Fwd: [jira] [Created] (KARAF-1060) use bash file extenstions: karaf - karaf.sh
I'm more -1 to it. It really is against normal unix conventions to do it. A user shouldn't need to know if an executable is a shell script, a perl script, python, executable, etc... That's all that the .sh really does. I just checked my /usr/bin directory and 560 of the 2758 executables in there are really shell scripts. Only 16 of them have a .sh extension. Dan On Wednesday, November 30, 2011 8:20:00 AM Guillaume Nodet wrote: Originally, the distribution did not contain both unix and windows files (there are 2 different distributions in 2.x), but given we now have a single distribution containing both files, it seems to me a bit more homogeneous to have .bat for windows batches and .sh for unix scripts. So I'm *slightly* inclined to rename those, but that's not really a big problem to me. If it can help some users, why not Jean-Baptiste, do you see any problem with renaming those files apart from the fact that it's not really necessary on unix (so I do agree that it's not a requirement). On Wed, Nov 30, 2011 at 05:25, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Andres, My comments: 1/ the windows script as .bat extension because it's a requirement on Windows 2/ the important thing is the header (#!/bin/sh) in the unix script more than the extension. 3/ it's really important, for portability, to use /bin/sh (which allow us to use with bash, zsh on Linux, csh and ksh on Solaris/AIX) more than /bin/bash I don't see a good reason to rename to karaf.sh, karaf looks very good for me. Regards JB On 11/30/2011 05:21 AM, Andreas Pieber wrote: Hey guys, I want to start a discussion about this JIRA here on the dev list: TBH I'm personally quite indifferent but if we want to change this we should do it now for 3.0 or otherwise it wont happen for quite a long time (till 4.0). So, WDYT? Kind regards, Andreas -- Forwarded message -- From: Andrei Pozolotin (Created) (JIRA)j...@apache.org Date: Tue, Nov 29, 2011 at 23:45 Subject: [jira] [Created] (KARAF-1060) use bash file extenstions: karaf - karaf.sh To: iss...@karaf.apache.org use bash file extenstions: karaf - karaf.sh Key: KARAF-1060 URL: https://issues.apache.org/jira/browse/KARAF-1060 Project: Karaf Issue Type: Bug Reporter: Andrei Pozolotin currently, windows /bin files have extensions, such as karaf.bat but unix, do not: karaf I suggest to use, instead: karaf.sh so that I can associate *.sh with bash editors like this http://sourceforge.net/projects/shelled/ :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.js pa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Fwd: [jira] [Created] (KARAF-1060) use bash file extenstions: karaf - karaf.sh
On Wednesday, November 30, 2011 4:17:46 PM Guillaume Nodet wrote: Well, I'd object tomcat does the same, and afaik, I've never heard it was a problem. I think not having the suffix .sh is fine when you only have unix binaries. If you mix both in the same distribution, having different extensions makes things more intuitive / homogeneous imho As a counter example, we all type mvn, not mvn.sh yet there is a mvn.bat in there as well.:-) Dan On Wed, Nov 30, 2011 at 16:07, Daniel Kulp dk...@apache.org wrote: I'm more -1 to it. It really is against normal unix conventions to do it. A user shouldn't need to know if an executable is a shell script, a perl script, python, executable, etc... That's all that the .sh really does. I just checked my /usr/bin directory and 560 of the 2758 executables in there are really shell scripts. Only 16 of them have a .sh extension. Dan On Wednesday, November 30, 2011 8:20:00 AM Guillaume Nodet wrote: Originally, the distribution did not contain both unix and windows files (there are 2 different distributions in 2.x), but given we now have a single distribution containing both files, it seems to me a bit more homogeneous to have .bat for windows batches and .sh for unix scripts. So I'm *slightly* inclined to rename those, but that's not really a big problem to me. If it can help some users, why not Jean-Baptiste, do you see any problem with renaming those files apart from the fact that it's not really necessary on unix (so I do agree that it's not a requirement). On Wed, Nov 30, 2011 at 05:25, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Andres, My comments: 1/ the windows script as .bat extension because it's a requirement on Windows 2/ the important thing is the header (#!/bin/sh) in the unix script more than the extension. 3/ it's really important, for portability, to use /bin/sh (which allow us to use with bash, zsh on Linux, csh and ksh on Solaris/AIX) more than /bin/bash I don't see a good reason to rename to karaf.sh, karaf looks very good for me. Regards JB On 11/30/2011 05:21 AM, Andreas Pieber wrote: Hey guys, I want to start a discussion about this JIRA here on the dev list: TBH I'm personally quite indifferent but if we want to change this we should do it now for 3.0 or otherwise it wont happen for quite a long time (till 4.0). So, WDYT? Kind regards, Andreas -- Forwarded message -- From: Andrei Pozolotin (Created) (JIRA)j...@apache.org Date: Tue, Nov 29, 2011 at 23:45 Subject: [jira] [Created] (KARAF-1060) use bash file extenstions: karaf - karaf.sh To: iss...@karaf.apache.org use bash file extenstions: karaf - karaf.sh Key: KARAF-1060 URL: https://issues.apache.org/jira/browse/KARAF-1060 Project: Karaf Issue Type: Bug Reporter: Andrei Pozolotin currently, windows /bin files have extensions, such as karaf.bat but unix, do not: karaf I suggest to use, instead: karaf.sh so that I can associate *.sh with bash editors like this http://sourceforge.net/projects/shelled/ :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!defa ult.js pa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Code formatting
On Thursday, November 10, 2011 3:46:17 AM Guillaume Nodet wrote: I do agree, but 120 sounds more reasonable to me. I agree that 120 seems reasonable. CXF has always used 110 which I *personally* like, but 120 is reasonable. On my machine, I don't run Eclipse full screen, it only covers about 2/3's of the screen. Of the eclipse window, the workspace/package pane covers about 1/5 of the width leaving the editor showing 112 characters. Thus, I think anything in the 110-125 range would be reasonable. 160 would be way too much IMO. Dan On Thu, Nov 10, 2011 at 03:44, Jamie G. jamie.goody...@gmail.com wrote: Where would we put the limit too if we extend it? There is something to be said about cleanly structured code, it would be nice not to have 500 char lines ;) Cheers, Jamie On Thu, Nov 10, 2011 at 8:11 AM, Guillaume Nodet gno...@gmail.com wrote: Can we get rid of the 80 chars per line max in code ? We're not in the 90s whith 640x480 screens anymore. I don't see the value of losing 2/3 of my screen to follow this silly limitation. Thoughts? -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Features
On Monday, October 24, 2011 11:10:34 PM Gert Vanthienen wrote: LS, Reading back on this thread, I see a few suggestions that we might want to consider translating into JIRA issues that we can fix in a next version of Karaf. 1. Improve the features Maven plugin to be aware of feature versions while filling the features repository (a suggested by Dan Kulp) 2. Improve the features descriptor to allow specifying a requirement (other descriptor) with a version range and only install an additional features url if the requirement is not met (to avoid installing more than one version of the same descriptor) +1. Honestly, I'd like to see that on bundles as well: bundlemvn:org.apache.ws.security/wss4j/[1.6,1.7)/bundle Useful when not using the OBR. 3. Allow the features service to resolve all boot features with a single obr in-memory repository to ensure picking up the latest and greatest from the available bundles #3, while interesting, leads to a bunch of other issues that would require a lot more testing and likely a lot of changes to the other project features.xml files. I was chatting with gnodet about this the other day as well. The OBR stuff really only considers imports and dependencies that are not marked optional. Thus, with something like CXF that has a bunch of things that are optional, if you use the OBR, a lot of things that used to work would no longer work. It might be good if the OBR resolver was able to look at the locally available bundles to resolve the imports as well. Doesn't need to go out to the internet and such, but at least check what has been pre-installed into the system dir. Dan #1 looks very reasonable to me, so I'll raise that his in the morning. How about the other two? Any other suggestions to fix some of the problems mentioned in this thread? Regards, Gert On Oct 19, 2011 6:11 PM, Johan Edstrom seij...@gmail.com wrote: -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Features
On Tuesday, October 25, 2011 12:11:57 AM Gert Vanthienen wrote: Reply versus reply all seems to become a difficult thing for my mind at this time of the day ;) LOL inline 2. Improve the features descriptor to allow specifying a requirement (other descriptor) with a version range and only install an additional features url if the requirement is not met (to avoid installing more than one version of the same descriptor) +1. Honestly, I'd like to see that on bundles as well: bundlemvn:org.apache.ws.security/wss4j/[1.6,1.7)/bundle Useful when not using the OBR. Absolutely - we do want to make sure it can do that without requiring full Maven resolution with metadata and things like that, as that information is currently not available in the system folder. Perhaps an implementation that looks in the system folder for a bundle matching this requirement and then falls back to e.g. the 1.6 version when there's no bundle there? At that point, if there is a mvn URL, could it resolve it via the mvn mechanisms? AKA, get the mavenmetadata.xml and look for the latest? Another option may be something like: bundle range=[1.6,1.7)mvn:org.apache.ws.security/wss4j/1.6.2/bundle Where we specify an exact version, but provide an optional range that we would find acceptable.This may be slightly more backwords compatible too if the current versions ignore unknown attributes. (I'm really not sure) 3. Allow the features service to resolve all boot features with a single obr in-memory repository to ensure picking up the latest and greatest from the available bundles #3, while interesting, leads to a bunch of other issues that would require a lot more testing and likely a lot of changes to the other project features.xml files. I was chatting with gnodet about this the other day as well. The OBR stuff really only considers imports and dependencies that are not marked optional. Thus, with something like CXF that has a bunch of things that are optional, if you use the OBR, a lot of things that used to work would no longer work. There's an option available for the org.apache.karaf.features.obr PID that allows the OBR resolver to take optional imports into account as well and try to resolve as many of those as possible, this has been implemented to allow using the OBR resolver in e.g. ServiceMix where we were bumping into similar issues with optional imports as the ones you're looking at with CXF probably. Well, I think there needs to be something in between. If you resolve ALL the optionals, it will definitely take a lot longer and likely grab a LOT more bundles. Especially if you have a full OBR there.CXF would pull in all kinds of stuff like eclipse stuff and sdo and jibx and all kinds of stuff that wouldn't be there if not using an OBR.It's basically resolve the optionals for which we have the jars already there. If not already there, don't bother. Dan It might be good if the OBR resolver was able to look at the locally available bundles to resolve the imports as well. Doesn't need to go out to the internet and such, but at least check what has been pre-installed into the system dir. Yeah, that's why I suggested to do it for the boot features as a whole - a lot of those bundles, in a typical scenario, will already be sitting in the local system folder anyway and if they're not there, the boot features installation would be downloading them anyway so there's not much overhead there in just doing the OBR resolution on those bundles as a whole instead of by feature (as it is implemented now). Dan #1 looks very reasonable to me, so I'll raise that his in the morning. How about the other two? Any other suggestions to fix some of the problems mentioned in this thread? Regards, Gert On Oct 19, 2011 6:11 PM, Johan Edstrom seij...@gmail.com wrote: -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com Regards, Gert -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Features
On Friday, October 14, 2011 11:58:26 PM Johan Edstrom wrote: Hey, Just poking around in the features, and yes I cross post this - I know there has been work going on with regards to creating a sane default set of features but currently the CXF features in 2.4.2 (I think it was) uses spring 3.0.6, the karaf features 3.0.5 and the camel features actually copy in cxf with a similar version but the older neethi. If we want these features in a consistent state, should we have a master reference? I know this will impact development and agility, but it sure as heck would improve stability if we had a solid inheritance chain? I know we also have a bunch of different features in the SMX area, would a new features project help? Just asking… This is pretty much exactly where JB and I have been going with the recent changes in the features. Basically, the projects all STOP redefining features like spring and cxf and such. Instead, they grab those from the appropriate place (and using a version range to accommodate updates). For example: Karaf 2.2.4 defines all the Spring things. Thus, neither Camel or CXF define that anymore. They just grab spring from there (using [3,4) or similar). Camel 2.8.2 will use the CXF 2.4.3 features directly. (no redefines) If you don't use an obr, we still have issues with different bundle versions of various things. I did sync CXF and Camel as much as possible a little while ago, but they will likely drift a bit. Anyway, Karaf 2.2.4, CXF 2.4.3, and Camel 2.8.2 will go a long way to make it a lot easier and more consistent. Dan Cheers! -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Switch jira to wiki field syntax?
There doesn't seem to be any objections and certianly a lot of people wanted
it so I went ahead and flipped it.
Dan
On Wednesday, October 12, 2011 4:05:21 PM Daniel Kulp wrote:
What are peoples thoughts about switching the jira project from the default
field configuration to Wiki Enabled?
I tend to like to be able to do:
{code}
//snippet here
{code}
to get some formatting in there. Would anyone object?
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: [PROPOSAL] Features autostart attribute
Would it make more sense to have something a bit more extensible than an
attribute? For example, I had some bundles I wanted installed on an IBM JDK,
but not on a Sun JDK.Also, JDK 7 vs 6 differences and such can also come
into play. I'm kind of thinking something similar to the Maven profile
activation element things, but make it actually work. :-) We could add
and and or elements and such in there.
Either that or define a simple DSL for the attribute
install=${Java.Version}=7 etc
Dan
On Wednesday, October 12, 2011 12:13:23 PM Jean-Baptiste Onofré wrote:
I also prefer a feature attribute.
Guillaume just mentioned that it means it's built-in the feature, and
don't let the user choose its behavior.
Regarding the attribute name, install=auto or install=manual looks
good to me.
Regards
JB
On 10/12/2011 12:10 PM, Ioannis Canellos wrote:
I would prefer an attribute in the feature descriptor, as it would
provide more granularity for custom features.
We may need to rethink the name of the attribute to avoid confusing our
users.
maybe call it manual=true/false or deploy=auto/manual
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Switch jira to wiki field syntax?
What are peoples thoughts about switching the jira project from the default
field configuration to Wiki Enabled?
I tend to like to be able to do:
{code}
//snippet here
{code}
to get some formatting in there. Would anyone object?
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Another issue with 2.2.4....
While doing some testing with 2.2.4-SNAPSHOT, I ran into another issue. The war feature no longer supports Java 5. You cannot install the feature due to pax-web-jsp pulling in classes only available in Java6. Since 2.2.x is supposed to support Java5, this is an issue for me. https://issues.apache.org/jira/browse/KARAF-933 JB is going to look a bit at pax-web tomorrow morning to see if there is anything that can be done. If not, we may need to do something like: 1) release note that war is Java6 only.(btw: this issue exists in 2.2.3 as well) 2) Remove jsp from the war feature and maybe add a war-jsp feature that would include it. (or something similar) 3) Rollback to pax-web-jsp 1.0.1 (last version that doesn't have the problem) 4) others? Anyway, at this point, I'd like to wait and see what JB finds out. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Another issue with 2.2.4....
On Wednesday, October 12, 2011 10:37:25 PM Achim Nierbeck wrote: Hi I rather would like to see this dependency solved then going back to 1.0.1 cause lot's of improvements where achieved still after that :) I completely agree. I'm just listing options. :-) I really hope we have a better solution available. Dan regards, Achim 2011/10/12 Daniel Kulp dk...@apache.org While doing some testing with 2.2.4-SNAPSHOT, I ran into another issue. The war feature no longer supports Java 5. You cannot install the feature due to pax-web-jsp pulling in classes only available in Java6. Since 2.2.x is supposed to support Java5, this is an issue for me. https://issues.apache.org/jira/browse/KARAF-933 JB is going to look a bit at pax-web tomorrow morning to see if there is anything that can be done. If not, we may need to do something like: 1) release note that war is Java6 only.(btw: this issue exists in 2.2.3 as well) 2) Remove jsp from the war feature and maybe add a war-jsp feature that would include it. (or something similar) 3) Rollback to pax-web-jsp 1.0.1 (last version that doesn't have the problem) 4) others? Anyway, at this point, I'd like to wait and see what JB finds out. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: feature names are potentially ambiguous?
On Thursday, October 13, 2011 1:57:59 AM Ioannis Canellos wrote:
Though I liked the idea of symbolic-name like features a lot, I somehow do
not like the result.
I agree. I really don't like it either.I'd much prefer something
shorter, but still unique:
karaf-config
karaf-war
karaf-http
etc
Still points at karaf, but is relatively small and doesn't clutter things up
terribly. The whole org.apache. part is terribly redundant. But that's
my opinion. :-)
Dan
What I do not like is that a lot of things have become unreadable and the
new feature names require way more effort to use.
Some examples:
*a) org.apache.karaf.features.cfg*
featuresBoot=org.apache.karaf.features.standard.config,org.apache.karaf.feat
ures.standard.ssh,org.apache.karaf.features.standard.management,org.apache.k
araf.features.standard.config,org.apache.karaf.features.standard.ssh,org.apa
che.karaf.features.standard.management,org.apache.karaf.features.standard.
This has become somehow unreadable. There are a lot of dots and commas and
you can easily spot where a feature name starts and where it ends. This is a
bit painfull to read.
*b) The package like format doesn't suit well to our code completion*
If I want to install the war feature, I have to press TAB for code
completion* 4* times:
o (choices are obr and org)
org. (choice are ops4j and apache)
org.apache.karaf.features (choices are standard and enterprise)
org.apache.karaf.features.standard (lot of choices)
Moreover the hints on each code completion are too long that I need to put
extra effort to understand my possible choices.
*b) The output of the features:list is somehow unreadable*
Really long lines which actually all repeat the same information.
I actually have to maximize my terminal to be able to read it.
*
*
*d) A feature descriptor*
feature name=org.apache.karaf.features.standard.spring.dm.web
description=Spring DM Web support version=${spring.osgi.version}
resolver=(obr)
feature version=${spring.osgi.version}
org.apache.karaf.features.standard.spring.dm/feature
feature
version=[2.5.6,4)org.apache.karaf.features.standard.spring.web/feature
feature
version=${project.version}org.apache.karaf.features.standard.http/featur
e bundle
start-level=30mvn:org.springframework.osgi/spring-osgi-web/${spring.osgi.
version}/bundle /feature
*e) The new naming increases entropy.*
I am not sure If I expressed that right, so I will use an example. In the
karaf context when someone used to see the following string *camel-jms *he
could directly correlate the string to a feature (or an artifactId).
With the new naming the string *org.apache.camel.jms *can be anything: a) a
package name, b) a symbolic name, c) a groupId/artifactId d) a repository id
(standard repository ids are now using the same naming).
Feature elements look a lot like bundle elements and its not that friendly
to read.
The main goal of this email is point to share my concern about the
user-friendliness of the symbolic-name like features.
I would like to hear your views first, before start thinking of
alternatives.
Thanks for having the patience to go through all of it :)
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
Re: [PROPOSAL] Promote Cave and WebConsole as Karaf sub-projects
I'm +1 (non-binding) I did have some concerns about moving out of the sandbox if there were some non-Karaf committers contributing there, but I asked on IRC and everyone said the folks working there are already committers. Dan On Monday, September 05, 2011 7:45:47 AM Jean-Baptiste Onofré wrote: Hi all, I think that we made good progress in WebConsole and Cave. What do you think about promoting as Karaf sub-projects ? If we are OK, I will: - move the svn directly under karaf root (as others sub-projects like Cellar) - request git repo for both Cave and WebConsole - create the corresponding Jira components and versions - prepare the Karaf website update (including documentation) Thought ? Regards JB -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [PROPOSAL] Karaf 2.2x, 2.3.x and Spring version
On Monday, September 05, 2011 8:51:07 AM Jean-Baptiste Onofré wrote: I'm agree Andreas. It's exactly the purpose of Cave: to be able to decouple some features (like Spring*) from the core and the distribution. However, Cave is not fully ready, so we have to find a way waiting Cave. I can see two: 1/ stay with Spring 3.0.6.RELEASE in 2.2.x branch, and provide the Spring* features (I'm working on it). As Freeman said, it might work even if it's not the target version for Camel 2.8.1. It also means that previous Camel versions (like 2.7.x or 2.8.0) don't work with Karaf 2.2.3. 2/ rollback to Spring 3.0.5.RELEASE, and release Karaf 2.2.4 (and following) with this Spring version. To be honest, I would prefer 2 as it means that Camel 2.7.x, 2.8.x and CXF 2.4.x won't work starting from Karaf 2.2.3. As an FYI: CXF 2.4.3 will be going to Spring 3.0.6. It's a PATCH release, not even a minor point update. Thus, it should be nearly a no-brainer for projects to updat to it. Thus, I'm all for keeping karaf 2.2.x on 3.0.6. Dan So +1 for 2. Regards JB On 09/05/2011 08:23 AM, Andreas Pieber wrote: TBH I'm not happy that we can't upgrade a micro version of a referenced library in a micro release of karaf. TBH I would rather prefer staying with 3.0.5 for the entire 2.x branch than keeping 2.3 for a micro dep upgrade. In addition we should learn from this and completely remove all features from karaf. Even http, spring wrapper... Those should be maintained by the karaf team but not distributed in karaf core. They could be loaded from a cave repo or from any other method we've discussed in the last time. Because of this situation I think it is very important that we get rid of the problem in 3.0 for once and all. Knd regards Andreas On Sep 5, 2011 7:09 AM, Jean-Baptiste Onofréj...@nanthrax.net wrote: Hi all, as you have certainly seen, we have an issue with Karaf 2.2.3 and Camel. In Karaf 2.2.3, we upgraded to Spring 3.0.6.RELEASE, whereas Camel still uses Spring 3.0.5.RELEASE. As Spring is major component for CXF, Camel, etc. So, we should address a Spring update with a lot of attention. I propose: - to rollback Spring to 3.0.5.RELEASE in Karaf 2.2.x. - to create a Karaf 2.3.x branch, exactly a copy of 2.2.x, but with update to Spring 3.0.6.RELEASE - in both branches, we add all Spring features to cover all Spring bundles. We have few issues to fix in both branches and I propose to release 2.2.4 and 2.3.0 soon. - update Karaf 3.0.x (trunk) to Spring 3.0.6.RELEASE WDYT ? Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Links to the manual on the website....
Everytime Karaf releases a new version, I seem to have to update my bookmarks and other locations to point at the new version of the manual on the website. Would people object to having a sym-link of: latest-2.2.x - 2.2.2 in the manual directory that could be used for such links. Eventually we could have latest-3.x along side the 2.2.x and such. Thoughts? -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [INFO] Karaf Cave moved into sandbox/jbonofre
On Wednesday, August 10, 2011 8:29:27 PM Jean-Baptiste Onofré wrote: Thanks for the update Dan. However, I'm not sure that the Karaf sandbox is setup in that way. Just checked. It's not. :-( It's not hard to do as PMC chair, I'll catch you on IRC to help you if you want it that way. Dan Regards JB On 08/10/2011 08:28 PM, Daniel Kulp wrote: On Wednesday, August 10, 2011 8:05:12 PM Jean-Baptiste Onofré wrote: Hi Andreas, yeah, I think it's better: it allows *all* Karaf committers to contribute. Once we consider that it's usable and clean, we can create the sub-project. It's actually a little more than that. Many projects (like CXF, Maven,etc..) have their sandbox open to all Apache committers. Thus, any Apache committer can participate. I've used the CXF sandbox to collaborate with some Wink and Axis developers on things before. I'm not sure if the Karaf sandbox is setup that way. If not, it's easy to do. In any case, the sandbox commits go to the same commits list and such so the whole community can see what is happening there.That's always a good thing. :-) Dan I can do it for you if you want. Regards JB On 08/10/2011 06:19 PM, Andreas Pieber wrote: Should we/I also important karaf-webconsole into the sandbox? Kind regards Andreas On Aug 10, 2011 6:12 PM, Jean-Baptiste Onofréj...@nanthrax.net wrote: Hi all, In order to give your more visibility on Karaf Cave development and progress, I moved Cave from my github to my Karaf sandbox repository. You can access to Cave here: http://svn.apache.org/repos/asf/karaf/sandbox/jbonofre/cave/trunk/ I keep on working on it. I will keep you posted with documentation/blog when I have something ready to test/use. Thanks Dan for his bright advice ;) Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [CANCEL][VOTE] Release Apache Karaf Cellar 2.2.1 version
On Wednesday, June 29, 2011 1:41:26 PM Jean-Baptiste Onofré wrote: Hi all, This release is cancelled due to the following issues: 1/ the legal files are presents in the source repo but it's not the one included in the artifacts (coming from the maven plugin) That's OK as long as the stuff in the artifacts/jar is actually correct. The only one that looks wrong or incomplete is the webconsole one as it's lacking any information about the included json jar. 2/ even if the files are presents in the jar META-INF, we should upload these files on the repository Actually, they don't need to be uploaded separately. In the jar is fine. 3/ the Cellar webconsole groupId is not correct, it should be org.apache.karaf.cellar.webconsole 4) There needs to be a full source distribution that is basically a zip of the svn checkout. This is an Apache requirement since we release open source software. Basically, we need stuff that would go into www.apache.org/dist/karaf/cellar that is buildable and such. Dan I'm going to fix these issues and resubmit a release to your vote. Regards JB On 06/28/2011 04:56 PM, Jean-Baptiste Onofré wrote: Hi all, Apache Karaf Cellar 2.2.1 is the first Cellar release. The version number is aligned to the Apache Karaf one, it means that this Cellar version is expected to run on Karaf 2.2.1. This release includes the documentation/manual describing the features, installation procedure, and architecture of Cellar. Staging repository: https://repository.apache.org/content/repositories/orgapachekaraf-001/ I updated a script to check the release: http://svn.apache.org/repos/asf/karaf/scripts/check_staged_cellar_releas e.sh 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 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
