Exactly. I think the mapping is ideal for hotfix scenarios where you
find a problem late and need to solve it in production.
In this case you do not have time for long release processes.
Especially when a bug is in a low level library it can easily lead to
the following release deps:
- release aries module
- update and release cxf
- update and release camel
This process will take at least about two weeks. In practice I would
expect at least a month.
With the mapping you can either wait for the aries release and then do
the mapping or do the patch release in house and do the mapping.
This will make the time to production go down from a month to a few
hours to days.
As the mapping is separate from the artifacts it is easy to document and
revert. We only have to deliver some debugging tools that show where the
mapping
affects artifacts. Then I think this is absolutely manageable and of
course no admin has to use the mapping. It is just an additional tool
that can help in some cases.
Christian
On 27.02.2013 23:01, Daniel Kulp wrote:
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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
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 <[email protected]
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: [email protected]
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/>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
