2014-03-05 12:12 GMT+01:00 Christian Schneider :
> On 05.03.2014 11:51, Guillaume Nodet wrote:
>
>> 2014-03-05 11:07 GMT+01:00 Christian Schneider :
>>
>> The only problem I see is the incompatibility for old modules.
>>> I propose a slightly different layo
ew api? I guess not.
>
The ActiveMQ commands do implement CommandWithAction, so they should be
fully supported.
ActiveMQ could migrate to the new model but that's a different question.
>
> Christian
>
>
>
>
> On 05.03.2014 10:48, Guillaume Nodet wrote:
>
>> I'd l
2014-03-05 8:51 GMT+01:00 Christian Schneider :
> On 04.03.2014 17:59, Guillaume Nodet wrote:
>
>> Btw, i pushed some commits to my branch. Karaf seems fully functional and
>> a compatibility layer has been extracted as a fragment to the console, so
>> that the shell.cons
I'd like to start a discussion on how and where (in terms of branch /
version) we can integrate the new console I worked on those past days.
https://github.com/gnodet/karaf/tree/console-api/
It provides two apis, one for the console and one for the action model.
Both apis have no dependencies
https://github.com/gnodet/karaf/blob/console-api/shell/compatibility/src/main/java/org/apache/karaf/shell/compat/CommandTracker.java
So, supporting plain gogo commands is just a matter of writing a Command
implementation as above which supports "--help" and a completer, that's
all.
gt; it sounds good. Thanks for the update.
>
> Regards
> JB
>
>
> On 02/27/2014 12:54 PM, Guillaume Nodet wrote:
>
>> I'm experimenting with the API i proposed earlier, but what I'm playing
>> with right now is, in addition to a cleaner Action model API, an
I'm experimenting with the API i proposed earlier, but what I'm playing
with right now is, in addition to a cleaner Action model API, an
abstraction of the console, so that the command model only depends on the
console api.
This way, we should be able to have an action model that works on a
pluggab
2014-02-26 9:13 GMT+01:00 Christian Schneider :
> On 25.02.2014 17:34, Guillaume Nodet wrote:
>
>> 2014-02-25 14:29 GMT+01:00 Christian Schneider :
>>
>> As Achim stated in the roadmap thread Guillaume and me had a lot of
>>> discussions on the irc channel recent
2014-02-25 14:29 GMT+01:00 Christian Schneider :
> As Achim stated in the roadmap thread Guillaume and me had a lot of
> discussions on the irc channel recently. I fully agree that we need to
> recapitulate the discussions here on the list to give the other community
> members a chance to take par
2014-02-25 13:49 GMT+01:00 Christian Schneider :
> Hi Guillaume,
>
> some questions and comments inline.
>
>
> On 25.02.2014 11:14, Guillaume Nodet wrote:
>
>> demos modules with samples modules. The purpose is to illustrate the
>> developer guide (that I refac
2014-02-25 11:28 GMT+01:00 Achim Nierbeck :
> Hi JB,
>
> thanks again for doing a great job to put us all in the right picture again
> :)
>
> Now please see my comments inline:
>
>
> 2014-02-25 10:57 GMT+01:00 Jean-Baptiste Onofré :
>
> > Hi all,
> >
> > In the latest weeks, we discussed about dif
In addition, I'll soon start 2 discussion threads about 2 new features i'd
like to introduce:
- a new resolver on way to install features / bundles using the osgi
resolver the goal would be to have on a more "global" resolution when
installing features, i.e. compute the needed bundles to resolve
Just a few comments to explain what I've (am) working on...
2014-02-25 10:57 GMT+01:00 Jean-Baptiste Onofré :
> Hi all,
>
> In the latest weeks, we discussed about different topics and changes for
> Karaf. We had very interesting different proposals, discussions, etc.
> However, some discussions
I agree, I think the feature is broken, as the bundle should not be flagged
as dependency = true if it's supposed to be installed.
Currently, the resolvers we have always resolve bundles feature by feature,
i.e. the resolver is only used to compute the bundles needed for a given
feature, and not a
kaging of command-exporter is a bundle, I put a NOTICE file.
>
> Regards
> JB
>
>
> On 02/22/2014 02:46 PM, Guillaume Nodet wrote:
>
>> I don't think the command exporter is supposed to be released.
>> My understanding is that cschneider was going to rem
I don't think the command exporter is supposed to be released.
My understanding is that cschneider was going to remote it from master, but
it should not be in 3.0.1.
2014-02-22 10:55 GMT+01:00 :
> Repository: karaf
> Updated Branches:
> refs/heads/master ed167f00d -> ab704c6bc
>
>
> Fix legal
ings like this IMHO are trivial
> respect good work and feature added
>
> If I have created misunderstanding was not my goal.
> and I apologize
>
> Regards
>
> --Filippo
>
>
> 2014-02-19 12:32 GMT+01:00 Guillaume Nodet :
>
> > I had tested the build, but not
I had tested the build, but not on a clean repo.
As a workaround, go to scr/support and build it, you should be able to
compile master after that.
It seems maven can not handle modules being dependencies of plugins, not
sure why.
I'll have a look and see how to refactor it into a goal in the karaf
done with this work right now but opened to any comments on how to
improve this.
2014-02-17 18:29 GMT+01:00 Guillaume Nodet :
> Fwiw, I've implemented the annotation support for blueprint.
> See https://github.com/gnodet/karaf/commits/inject
> An example for the jms command is at
Fwiw, I've implemented the annotation support for blueprint.
See https://github.com/gnodet/karaf/commits/inject
An example for the jms command is at
https://github.com/gnodet/karaf/commit/9f2854da465fb55e57ec01952629e732273786a8
So you're right, that if we want that level of integration for each
sal, and I think those will be the same that can't be
covered by the blueprint xml handler now (i.e. exit and help commands).
>
>
> Christian
>
>
> On 17.02.2014 15:48, Guillaume Nodet wrote:
>
>> I think we could build upon those annotations and have them leveraged by
>> the n
eport soon.
2014-02-17 14:35 GMT+01:00 Guillaume Nodet :
> I have experimented this morning with a possible implementation of what I
> outlined last week.
> We have a very simple set of 4 annotations:
> @Service @Reference @Init @Destroy
>
> @Service can be added on an action
So I really have 2 concerns with your approach:
* we expose in the OSGi registry some services which are not supposed to
use
* we use introspection on exported services
It seems to me that we are kinda breaking multiple aspects of the OSGi
registry contract.
I'll continue the discussion on the
omplicated would mean rewriting a layer such as blueprint,
DS, etc... and I don't think we should go this way.
Here's an example on how it could be used:
https://github.com/gnodet/karaf/commit/9649a3bf8d5967d58c048b07619f1218284d040b
2014-02-14 20:31 GMT+01:00 Guillaume Nodet :
>
>
-1
I think it's a really bad idea to have the user expose services in OSGI
which are not supposed to be used and not thread safe by design.
Please revert and let's continue the discussion on the dev mailing list.
2014-02-17 13:54 GMT+01:00 :
> Repository: karaf
> Updated Branches:
> refs/heads
-0 : The copyright years in the various notice files are wrong (either 2012
or 2013 when they should be 2014).
The distribution otherwise looks good to me.
2014-02-15 3:09 GMT+01:00 Jamie G. :
> Hi,
>
> We resolved 116 issues in this release (web page will be published post RC
> promotion):
>
>
If we were to introduce a new model, we could just reuse what gogo has, I
don't think we have to re-invent a different one:
https://github.com/apache/felix/blob/trunk/gogo/command/src/main/java/org/apache/felix/gogo/command/Basic.java
Guillaume
2014-02-14 20:31 GMT+01:00 Guillaume
rows Exception {
}
}
So with 2 new annotations, it should remove most of the blueprint stuff
needed I think.
I really don't think changing the model action/command model is a good
idea. I'd much rather write a new one if we want to not instantiate new
commands each
See https://issues.apache.org/jira/browse/KARAF-2761
The idea is to simplify writing commands as much as possible.
With the recent @Completer annotation, things are already much easier to
deal with, but writing commands without blueprint is a real pain.
I've committed a simple java DSL to help ar
ile. I just
don't get it, but I'll stop arguing and loosing time on a log statement,
it's not worth it.
>
> Having a switch that may invoke a signed bundle installation only Karaf
> could be interesting.
>
> --jamie
>
>
> On Wed, Feb 12, 2014 at 4:08 P
if we think there's a problem.
Guillaume
>
> As to a global on/off switch for the mechanism that would be a nice
> addition.
>
Yeah, I can add that, though it's not as if this feature was triggered
automatically, as you have to create this known file, so there's always a
consci
as being what was originally
> intended by the feature provider. I'm up for different wordings however.
> What would you suggest?
>
>
> On Wed, Feb 12, 2014 at 12:07 PM, Guillaume Nodet
> wrote:
>
> > Yes, I was going to add that I had no problems saying a bundle ha
gt; Though as far as I can see the change only introduced some logging
> > to let the user know something changed due to adding another feature,
> > I think this is a viable solution, especially when looking for failures
> > or unintended changes.
> > No?
> >
>
especially when looking for failures
> or unintended changes.
> No?
>
>
> 2014-02-12 16:15 GMT+01:00 Guillaume Nodet :
>
> > I'm tempted to -1 this change.
> >
> > What kind of problems are you trying to solve here ?
> > Imho, such code is unnecessary b
I'm tempted to -1 this change.
What kind of problems are you trying to solve here ?
Imho, such code is unnecessary because there are many other ways to
introduce so called "malicious" code.
If one wants to be safe, there is already an existing way to solve the
problem which is signed bundles.
Now
When writing a command, completers have to be wired in blueprint in a not
very easy to use way.
For example:
In addition, complete
Regards
> JB
>
>
> On 12/20/2013 08:58 AM, Guillaume Nodet wrote:
>
>> 2013/12/20 Jean-Baptiste Onofré
>>
>> Hi Matt,
>>>
>>> We don't use wiki at Karaf. If you want to contribute on documentation,
>>> just submit patches or git r
2013/12/20 Jean-Baptiste Onofré
> Hi Matt,
>
> We don't use wiki at Karaf. If you want to contribute on documentation,
> just submit patches or git request.
>
> For the Jira, I gonna give the karma to you.
>
> Regarding committership, I look forward to see patches from you. I would
> be pleased t
I'm not sure it's needed to move the subversion repo.
Afaik, other projects let it where it is.
2013/12/17 Jean-Baptiste Onofré
> Hi all,
>
> The Apache Karaf source repositories have moved to git.
>
> Read-only:
>
> https://git.apache.org/repos/asf/karaf.git
> https://github.com/apache/kar
Does that mean that the svn repo is in read-only or that we should not
commit to it as the commits not be mirrored to git ?
2013/12/17 Jean-Baptiste Onofré
> Yes,
>
> but I didn't send an e-mail yet because I would like to check if it's OK.
> I planned to send an e-mail after the mirrors.
>
> R
we'll need to register ManagedService instance anyway and handle updaes on
> our own.
>
>
Fwiw, DS manages configuration too (not to the level of blueprint, it's
mostly a bulk update), so you have no need to implement a ManagedService
directly.
> Cheers,
> Łukasz Dywick
I don't count the number of weeks I've spent during the last months fixing
pure OSGi code for concurrency and thread safety issues. And that includes
Karaf, Pax-Web, Blueprint, Fabric and even SCR. Service trackers are nice
tools, but not sufficient at all when it comes to handle multiple servic
t this right?
> >>>>
> >>>> regards, Achim
> >>>>
> >>>>
> >>>> 2013/12/5 Jean-Baptiste Onofré
> >>>>
> >>>>> Good point Dan.
> >>>>>
> >>>>> I think you should not hurry
2013/12/5 Łukasz Dywicki
> <...> If we would step off blueprint then I do not consider DS or SCR as
> an alternative to blueprint since it's just another dependency and XML to
> maintain. <...>
>
Could you rephrase please, I'm not sure to understand your thoughts ?
>
> Cheers,
> Lukasz
>
> W
ounts 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
2013/12/5 Christian Schneider
> 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
for 4.0. IMHO we dont have to wait all that long for a a
> major as we do/did for 3.x
>
> Kind regards,
> Andreas
>
>
> On Thu, Dec 5, 2013 at 10:14 AM, Achim Nierbeck >wrote:
>
> > Guillaume,
> >
> > that's why I would go for 4.0 :)
> >
> &
The migration seems to have been done already and I've just spotted that
the support for blueprint commands seems still present, though in a
different bundle.
2013/12/5 Achim Nierbeck
> I think this is definitely something for a 4.x line, it's just to major
> switch.
> How will it fit in with
Forking a git repo is really the easiest way to experiment imho. If
there's a consensus, we can port all the changes to the karaf repo and
maintain it in Karaf, else it will certainly be dropped.
+1 too on both ideas (trim down minimal and switch to scr)
The question I wonder about is which ver
One possibility is that mina-core has not been deployed and you're running
on JDK 6.
That's due to the upgrade to sshd 0.9.0 I suppose.
2013/12/3 David Bosschaert
> Hi all,
>
> When I'm running the following test on trunk (which is part of the
> itests) StandardFeaturesTest.
> installSSHFeature
+1
2013/6/25 Jean-Baptiste Onofré
> Hi all,
>
> to follow the discussion that we had some weeks ago, I start here a formal
> vote to migrate our scm from svn to git.
>
> Please vote to approve this switch:
>
> [ ] +1 Approve the switch (from svn to git)
> [ ] -1 Do not approve the switch (pleas
For karaf 2.x branches, we're still using pax-web 1.1.x which did not
provide a features repository.
Btw, I think we may want to consider upgrading karaf 2.4 to pax-web 3.0 if
we plan to do a release on that branch.
2013/7/3 Charles Moulliard
> Hi,
>
> As Apache Karaf uses by default OSGI HTTP
You could use a profiler which is able to trace where objects were
allocated from ...
Not sure if that's what you had in mind.
2013/7/3 Charles Moulliard
> Hi,
>
> With classes or packages, we are able on Karaf 2.3.x to know packages
> imported and classes loaded by each bundle classloader.
>
>
The first rule when using start levels is "don't use them". When they are
*necessary*, it means the bundles misbehave, so if there's something to
explain to the users, that's really this rule (which does not prevent users
to actually use them, but this decision need to be taken wisely).
In the CX
Fwiw, having a more fine grained start level helps reducing the log
verbosity at start time and may slightly help with performance too. The
reason is that a correct start order will result in service dependencies
being satisfied correctly for most bundles, thus not having to wait until
those are s
jars placed under lib directory where the startup/boostrap script will use
> to construct the extract classpath.
>
> Now, base on Guillaume Nodet comments, I have to think hard about my
> approach, since karaf indirectly load all the jars under lib directory to
> its class loader
AFAIK, all jar files in the lib folder are added to the classpath, so if
anyone want to add jars globally without using bundles, that's the way to
go.
See
https://github.com/apache/karaf/blob/trunk/main/src/main/java/org/apache/karaf/main/Main.java#L266
The lib/ext lib/endorsed and lib/karaf-*.jar
>>
> > >>>>> Staging repository:
> > >>>>>
> > https://repository.apache.org/content/repositories/orgapachekaraf-019/
> > >>>>>
> > >>>>> Release tags:
> > >>>>> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> > >>>>>
> > >>>>> 3.0.x Dependencies table:
> > >>>>>
> > >>>
> > >>>
> >
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> > >>>>>
> > >>>>>
> > >>>>> 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.
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > 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/>
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
; Abhinav
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Remote-Debugging-of-Karaf-tp4028192.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>
--
Guillaume Nodet
Red Ha
araf-3.0.0.RC1/
> > >>
> > >> 3.0.x Dependencies table:
> > >>
> >
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> > >>
> > >> Please vote to approv
referring to the current situtation which is only a set
of utility classes, no real services or apis.
>
> Regards
> JB
>
>
> On 03/13/2013 04:35 PM, Guillaume Nodet wrote:
>
>> Actually, I think I was not really clear.
>> What I mean is that the larger util is, the less i
should
be (which is what an api package is), which is the exact opposite of a
utility library which tends to grow over time.
On Wed, Mar 13, 2013 at 4:28 PM, Guillaume Nodet wrote:
>
>
>
> On Wed, Mar 13, 2013 at 4:25 PM, Jean-Baptiste Onofré
> wrote:
>
>> I think it
ke sense for Karaf
>>>>> utils (we are not in a developer bullshit approach where we turn all
>>>>> in OSGi just for "fun" or "elegance", we have to keep things simple,
>>>>> maintainable, and coherent).
>>>>>
>>>> I hope you do not really mean to say my opinion is a "developer bullshit
>>>> aproach". My main focus is exactly to keep things simple, maintainable
>>>> and coherent. Just more from a developer point of view than an admin
>>>> point of view.
>>>>
>>>> Christian
>>>>
>>>>
>>>
>>
>>
> --
> 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/
where we turn all in OSGi just for
> "fun" or "elegance", we have to keep things simple, maintainable, and
> coherent).
>
> My 0.02€
>
> Regards
> JB
>
>
> On 03/13/2013 11:21 AM, Guillaume Nodet wrote:
>
>> Starting a new thread for discu
uring deployment because a refresh is needed to solve those new
constraints. So when possible, they should be avoided and optional stuff
be deployed as a separate bundle.
On Wed, Mar 13, 2013 at 11:21 AM, Guillaume Nodet wrote:
> Starting a new thread for discussing those points.
>
>
ur customers need are certainly the same to
some degree.
>
> From a community perspective, I think we have to maintain max 2 branches.
>
I'd rather keep trunk and 2.3.x. It should be easier to merge from 2.3.x
to 2.x than the opposite.
>
> Regards
> JB
>
>
> On
ving good modularity is much more important than any pain
at dev time.
I've seen the problems you mention during dev time too, but really, I'm
willing to suffer that pain.
>
>
> Christian
>
>
>
> On 13.03.2013 11:46, Guillaume Nodet wrote:
>
>> On Wed, Ma
community release cycles.
> The problem is that as soon as a branch is there it is kind of an
> obligation for all developers to backport at least fixes.
>
> Christian
>
>
> On 13.03.2013 11:32, Guillaume Nodet wrote:
>
>> I think we already discussed to not add new fea
al for the implementation, there's no way it can happen (unless
there's a bug somewhere).
> So while in an ideal world OSGi dependency resolution based on pure
> packages should work with bundles embedding libs I thnk it is not such a
> good idea.
>
> Christian
>
>
> On
2.3.x like we did in 2.2.x. I general I think we should
> keep feature changes in 2.3.x to the minimum and rather concentrate on 3.x.
>
> Christian
>
>
>
> On 13.03.2013 02:50, Guillaume Nodet wrote:
>
>> Sorry to jump on late, but is there any need to change the branch naming
ding I propose to check if we could just merge some of these libs.
>
> Christian
>
>
> On 13.03.2013 07:41, Guillaume Nodet wrote:
>
>> +1
>>
>> A few comments though
>>
>> When I started the first time, karaf failed to install the additional
>&g
ould cost to switch back to a stable 2.x branch and weight that with the
cost of helping stabilising it.
>
>
> Andrei
>
> Original Message
> Subject: Re: release by subsystem
> From: Guillaume Nodet
> To: Andrei Pozolotin
> Cc: "Jamie
gt;
> 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.
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
araf 2.4 in 6 weeks after 2.3.1.
>> - I propose a Karaf 2.2.11 with latest bug fixes before the switch to
>> EOL mode.
>>
>> WDYT ?
>>
>> Thanks,
>> Regards
>> JB
>>
>>
> --
> 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/
2.x ? One possibility may be to backport those to
2.4.x branch ...
>
> cheers,
>
> Andrei.
>
>
> Original Message
> Subject: Re: release by subsystem
> From: Guillaume Nodet
> To: Jamie G.
> Cc: Andrei Pozolotin ,
> "dev@karaf.apache.or
ow about automatic "YES" for RC release provided there is not a single
> "NO" ?
>
> Andrei
>
> Original Message
> Subject: Re: release by subsystem
> From: Jamie G.
> To: Andrei Pozolotin
> Cc: dev@karaf.apache.org, Guillaume Nodet
&
i
> >
> > Original Message
> > Subject: Re: release by subsystem
> > From: Jamie G.
> > To: dev@karaf.apache.org
> > Cc: Guillaume Nodet
> > Date: Tue 12 Mar 2013 07:24:53 PM CDT
> >
> > Sorry for jumping in here,
> >
>
.org
> >
> > Wiadomość napisana przez Andrei Pozolotin
> w dniu 12 mar 2013, o godz. 22:53:
> >
> >> Hello there.
> >>
> >> FYI
> >> fuse source repos are down
> >>
> >> http://fuse.fusesource.org/fabric/download.html
>
t;> 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/
-
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
n need to contact ldap
> to get the roles. So we would still have to turn off validation in the ldap
> part.
>
> Christian
>
>
> On 07.03.2013 11:25, Guillaume Nodet wrote:
>
>> Is that a limitation of wss4j ?
>> I see spring-ws can do it (or i suppose, see
>> h
the chance to
> tap into it using jaas.
>
> Christian
>
>
> On 07.03.2013 10:33, Guillaume Nodet wrote:
>
>> I think there are two different things, verifying the crendentials
>> validity
>> and authenticating the user.
>> The first one can be done by ws-securi
t;> Best regards,
>> Łukasz
>>
>> W dniu poniedziałek, 4 marca 2013 użytkownik Christian Schneider napisał:
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.t
browse/KARAF-2219<
> https://issues.apache.org/jira/browse/KARAF-2219>
> >
> > Christian
> >
> > On 04.03.2013 13:19, Guillaume Nodet wrote:
> >
> >> The authentication part is already switchable, you can have a custom
> login
> >> module which
which is
not usedby the container itself for security.
On Mon, Mar 4, 2013 at 12:25 PM, Christian Schneider <
ch...@die-schneider.net> wrote:
> On 04.03.2013 12:11, Guillaume Nodet wrote:
>
>> Shouldn't STS delegate certificate authentication to the underlying JAAS
>>
--
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
ndex/documentation/karaf-dependencies/karaf-deps-2.3.x.page
>
> 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.
>
--
Guillaum
> quite a
> >> minimalistic style. Maybe we could even pack this into a simple command
> >> line tool also allowing end users to do this step before starting Karaf.
> >> Finally it's all about fixing problems devs introduce because they
> weren't
> >&
gt;
> --
> *Ioannis Canellos*
> *
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
oth 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.
> >>>>>>>
> >>>>
t;>>>>
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>> On 02/26/2013 05:12 PM, Daniel Kulp wrote:
> >>>>>>>
> >>>>>>>>
> >>
?
>
> Thank you,
>
> Andrei
>
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
self. So you're questioning my integrity, and I can't really let that go
without answering.
> --
> Pozdrawiam,
> Lukasz
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
7;t
regret a single word of it, which does not always succeed btw). So please,
have a break during the weekend, stop attacking people and if you have
technical arguments, raise them so that we can get the discussion going
with sane arguments.
--
> Cheers from cold Poland,
> Lukasz
>
>
gt;> So if we succeed in creating an accepted generic foundation for
>> management consoles then each of the technology plugins could be
>> developed in the respective projects.
>>
>> What do you think about this?
>>
>> Christian
>>
>> On 25.01.2
ed Hat
Email: jstra...@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
useSource 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: @Freeman小屋
>
> On 2013-1-21, at 下午11:54, Guillaume Nodet wrote:
>
> >
g());
> > }
> >
> > + protected static String getPath(URL url) {
> > +if (url.getProtocol().equals("mvn")) {
> > +String[] parts =
> url.toExternalForm().substring(4).split("/");
> > +String groupId;
> > +String artifactId;
> > +String version;
> > +String type;
> > +String qualifier;
> > +if (parts.length < 3 || parts.length > 5) {
> > +return url.getPath();
> > +}
> > +groupId = parts[0];
> > +artifactId = parts[1];
> > +version = parts[2];
> > +type = (parts.length >= 4) ? "." + parts[3] : ".jar";
> > +qualifier = (parts.length >= 5) ? "-" + parts[4] : "";
> > +return groupId.replace('.', '/') + "/" + artifactId + "/"
> > ++ version + "/" + artifactId + "-" + version +
> qualifier + type;
> > +}
> > +return url.getPath();
> > +}
> > +
> > protected static void copyInputStream(InputStream in, OutputStream
> out) throws Exception {
> > byte[] buffer = new byte[4096];
> > int len = in.read(buffer);
> >
> >
>
--
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere
http://fusesource.com
;> [ 83] [Active ] [] [ ] [ 30]
> >> spring-osgi-extender (1.2.1)
> >> [ 84] [Active ] [] [ ] [ 30]
> >> spring-osgi-annotation (1.2.1)
> >>
> >>
> >>
> >> So I
I've raised and fixed KARAF-2134 for this issue.
On Mon, Jan 21, 2013 at 12:13 PM, Charles Moulliard wrote:
> You better know than me this part of the code. So you can go.
>
>
> On Mon, Jan 21, 2013 at 12:10 PM, Guillaume Nodet
> wrote:
>
> > Right, so it's
301 - 400 of 1087 matches
Mail list logo
