karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Idea: Allow users to patch feature files
Date Wed, 27 Feb 2013 22:01:56 GMT

After sitting through a series of security related talks this morning and then some chats
with folks at lunch, there is another important use case for the mapping:

Lets pretend a very major security bug or performance issue or similar is found (and made
public) in a particular version of a library.   There is a newer patch version of that bundle
available that fixes that particular issue.   We need to make sure that the old version is
NEVER loaded into the container.  Whenever encountered, we need to make sure all references
to that old version are automatically mapped to the new version.   Without some sort of URL
mapping, how could that be accomplished?  (No OBR here)

As a concrete example of this:  Woodstox 4.1.3 has a severe performance issue in it.  However,
a bunch of features files did reference it as it was the latest for a while.  I'd like some
way to say "don't ever load 4.1.3, always replace it with 4.1.4".  I don't consider editing
anything in system a valid solution.   

Thoughts?

Dan


On Feb 27, 2013, at 12:56 PM, Achim Nierbeck <bcanhome@googlemail.com> wrote:

> I second Andreas and Guillaume here,
> this is going to open the gates to Hell and I'm sure I don't want to go
> that road :)
> 
> The idea of creating a small set of tools to improve this sounds much more
> reasonable.
> And as Filippo already said, how do you want to make sure you have a
> valid artifact deployed in operations if someone mis-uses this, who has
> been in
> charge of breaking the operational system?
> 
> regards, Achim
> 
> 
> 2013/2/27 Andreas Pieber <anpieber@gmail.com>
> 
>> I have to admit one thing: all of those ideas (as summed up nicely by
>> Ioannis) sound VERY tempting. They would solve some of the problems we're
>> facing in production and would definitely help many people.
>> 
>> BUT I'm definitely with Guillaume. This feels like we're opening the gates
>> to Hell introducing a LOT of possible problems which are anything than
>> intuitive!
>> 
>> Wouldn't it be easier providing the tooling providing the correct
>> features.xml files manually? For example I could think of something like
>> the mapping features but only for "compile time use" instead of runtime
>> use. E.g. extending our Karaf Plugin to supporting the url mapping. This
>> could produce the patched feature files with their own versions in 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
>> thinking (or lacking the knowledge) while creating the feature files.
>> 
>> Does this sound completely off the road? Would this make sense?
>> 
>> Kind regards,
>> Andreas
>> 
>> 
>> On Tue, Feb 26, 2013 at 10:24 PM, Guillaume Nodet <gnodet@gmail.com>
>> wrote:
>> 
>>> While I don't have any problem at introducing a kind of mapping, I do
>> fear
>>> the abuses it can lead to.
>>> I don't really want to add a feature to be able to fix broken things.
>>> Valid use cases, sure, broken features descriptors, no.
>>> So what I mean is that if we allow any kind of global mapping, we can
>>> easily end up screwing the features even more, i.e. if I override the
>>> spring stuff as mentionned below, i won't be able to deploy any feature
>>> that does need the 2.x release of spring (because of version ranges on
>> the
>>> packages such as [2.5,3) for example).
>>> 
>>> 
>>> On Tue, Feb 26, 2013 at 10:05 PM, Ioannis Canellos <iocanel@gmail.com
>>>> wrote:
>>> 
>>>> Some of the views expressed so far:
>>>> 
>>>> i) Allow defining an alternate location for a feature repository.
>>>> ii) Allow overriding a feature repository or bundle url using a
>> mapping.
>>>> iii) Using version feature version ranges to resolve the right version
>> to
>>>> use.
>>>> 
>>>> Some thoughts about each idea.
>>>> 
>>>> i) I'd love to be able to do that, even though in most cases modifying
>>> the
>>>> feature repo in the system directory does work for me.
>>>> We could take this one step further an be able to modify the feature
>> repo
>>>> itself, using the editor we have in trunk (mostly as a dev tool).
>>>> 
>>>> ii) I like this idea too. This would solve the recent problem we had
>> with
>>>> spring versions. We could just let the user define a mapping like
>>>> mvn:org.springframework/*/[3,4] =
>> mvn:org.springframework/*/3.1.2.RELEASE
>>>> and it would be awesome.
>>>> 
>>>> iii) This would definetely solve a lot of problems, without direct user
>>>> interaction. I think that we should maybe start with this point but
>> maybe
>>>> also grant the user the power to do things like i) and ii).
>>>> 
>>>> I hope I didn't miss anything.
>>>> 
>>>> --
>>>> *Ioannis Canellos*
>>>> *
>>>> 
>>>> **
>>>> Blog: http://iocanel.blogspot.com
>>>> **
>>>> Twitter: iocanel
>>>> *
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Red Hat, Open Source Integration
>>> 
>>> Email: gnodet@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message