You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by John Ellinwood <jo...@gmail.com> on 2014/10/08 00:32:58 UTC
Re: Problems With Factory Configurations In Karaf 3.0.1
So did the original error end up getting fixed? I couldn't tell from the
commits, jira, or this thread whether you reverted back to the original
behavior or not.
Gareth was correct in the original post for this thread, 3.0.1 is broken.
We just upgraded from Karaf 3.0.0 to Karaf 3.0.1 and all of feature file
based configs are broken now. Let me stress, everybody's feature based
config deployments just broke between 3.0.0 and 3.0.1.
For all of karaf history, including Karaf 3.0.0, the config name's value was
parsed as <factoryPid>-<configName>.
If you had a feature file like:
<features name="features">
<feature name="feature>
<config name="my.factory-config1">
prop1=value1
</config>
</feature>
</features>
I'd end up with a ConfigAdmin config like:
service.pid: my.factory-123412341234342
service.factoryPid: my.factory
prop1: value1
Now, with Karaf 3.0.1 that same feature file results in:
service.pid: config1-12312312312312123
service.factoryPid: config1
prop1: value1
FileInstall always followed the original convention as well, where a
filename would be factoryPid-configName.cfg.
I see commit
https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422dda8ffec474
modified
features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java:
- return configurationAdmin.createFactoryConfiguration(pid, null);
+ return configurationAdmin.createFactoryConfiguration(factoryPid, null);
and it doesn't appear to be fixed in
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
Why would you make such a drastic change to the way that a core part of
karaf works??
--
View this message in context: http://karaf.922171.n3.nabble.com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-tp4033921p4035676.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Problems With Factory Configurations In Karaf 3.0.1
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Gareth,
I think Achim missed this part in his patch.
I'm fixing it.
Regarding you <rant>, I agree for the delays between versions. It's
something that we are improving. After the 3.0.2 and 4.0.0.M1 out, we
will force ourself to release on a regular cycle (I propose one release
every 6/8 weeks).
I deeply sorry about your feeling about Karaf, and be sure that it's
something that concern me and again, we're working to improve that.
Regards
JB
On 10/08/2014 05:35 AM, Gareth wrote:
> Hello John,
>
> It looks like it is fixed on the 3.0.x branch:
>
> https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/main/java/org/apache/karaf/features/internal/FeatureConfigInstaller.java
>
> Guillaume reverted the offending change on July 11:
>
> https://github.com/apache/karaf/commit/c31edca04692d8127989acbcdadc8157d1390f2a
>
> The same revert was done on master but Achim appears to have remade the
> change here:
>
> https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422dda8ffec474
>
> Achim - was that intentional?
>
> I am not sure if David was referring to me in some way when he said "there
> is a bunch of misinformation in some of the comments on this thread". I
> don't really care about the philosophical reasons for one particular factory
> pid format or the other. I just know with this change my
> ManagedServiceFactories and Declarative Service components could not find
> their factory configurations anymore...which thus made it impossible for me
> at least to upgrade to Karaf 3.
>
> <rant>
> Karaf is a great project but the surprise regressions and the long variable
> delays between versions (which include fixes for these regressions) is very
> frustrating. What makes it worse for me is that in the version I was using
> (Karaf 2.3.2) editing factory configurations (not stored in etc) from the
> Karaf command line console is broken causing me hours upon hours of misery
> as the workaround for it (copy the factory configuration to a file in the
> etc directory, edit the file, delete the old factory configuration, restart
> karaf) is very error prone (I can't ask people to use the web console
> because I need to use Pax Web 3 with Karaf 2.3.2). I keep being told how
> karaf is "too hard to use". Oh well...
> </rant>
>
> thanks,
> Gareth
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-tp4033921p4035683.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems With Factory Configurations In Karaf 3.0.1
Posted by David Jencks <da...@yahoo.com>.
I agree with nearly everything you (Gareth) have said on this thread. I see you also suggested returning 3 strings from the parse method for the same reason I did :-)
I was objecting to:
- calling the generated karat-specific id <foo>-<bar> , where one of foo and bar is the factoryPid and the other is a user supplied id, a pid (or a factory pid). For a factory configuration the only pid is generated by config admin and the format is implementation specific.
- confusing pid and factoryPid. It's a little hard to talk about…. however a factoryPid is never a pid, and the pid from calling configAdmin.createFactoryConfiguration(factoryPid, null) is not a factoryPid.
I think the original code had the correct effect but is hopelessly confusing because of not making these distinctions properly.
thanks
david jencks
On Oct 7, 2014, at 8:35 PM, Gareth <ga...@gmail.com> wrote:
> Hello John,
>
> It looks like it is fixed on the 3.0.x branch:
>
> https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/main/java/org/apache/karaf/features/internal/FeatureConfigInstaller.java
>
> Guillaume reverted the offending change on July 11:
>
> https://github.com/apache/karaf/commit/c31edca04692d8127989acbcdadc8157d1390f2a
>
> The same revert was done on master but Achim appears to have remade the
> change here:
>
> https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422dda8ffec474
>
> Achim - was that intentional?
>
> I am not sure if David was referring to me in some way when he said "there
> is a bunch of misinformation in some of the comments on this thread". I
> don't really care about the philosophical reasons for one particular factory
> pid format or the other. I just know with this change my
> ManagedServiceFactories and Declarative Service components could not find
> their factory configurations anymore...which thus made it impossible for me
> at least to upgrade to Karaf 3.
>
> <rant>
> Karaf is a great project but the surprise regressions and the long variable
> delays between versions (which include fixes for these regressions) is very
> frustrating. What makes it worse for me is that in the version I was using
> (Karaf 2.3.2) editing factory configurations (not stored in etc) from the
> Karaf command line console is broken causing me hours upon hours of misery
> as the workaround for it (copy the factory configuration to a file in the
> etc directory, edit the file, delete the old factory configuration, restart
> karaf) is very error prone (I can't ask people to use the web console
> because I need to use Pax Web 3 with Karaf 2.3.2). I keep being told how
> karaf is "too hard to use". Oh well...
> </rant>
>
> thanks,
> Gareth
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-tp4033921p4035683.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Problems With Factory Configurations In Karaf 3.0.1
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Guys,
yes, that failure of me, has been unintentional and thanks for spotting. :)
I'm very frustrated by the release cycle we have right now too so I fully
understand Gareth on this.
So I'm in a big favor of having a hard release date of every 6 weeks, this
way we get more momentum on the road, and still are not hurt by regressions
to much.
regards, Achim
2014-10-08 7:47 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Done and checked on all branches.
>
> Regards
> JB
>
> On 10/08/2014 05:35 AM, Gareth wrote:
>
>> Hello John,
>>
>> It looks like it is fixed on the 3.0.x branch:
>>
>> https://github.com/apache/karaf/blob/karaf-3.0.x/
>> features/core/src/main/java/org/apache/karaf/features/internal/
>> FeatureConfigInstaller.java
>>
>> Guillaume reverted the offending change on July 11:
>>
>> https://github.com/apache/karaf/commit/c31edca04692d8127989acbcdadc81
>> 57d1390f2a
>>
>> The same revert was done on master but Achim appears to have remade the
>> change here:
>>
>> https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422d
>> da8ffec474
>>
>> Achim - was that intentional?
>>
>> I am not sure if David was referring to me in some way when he said "there
>> is a bunch of misinformation in some of the comments on this thread". I
>> don't really care about the philosophical reasons for one particular
>> factory
>> pid format or the other. I just know with this change my
>> ManagedServiceFactories and Declarative Service components could not find
>> their factory configurations anymore...which thus made it impossible for
>> me
>> at least to upgrade to Karaf 3.
>>
>> <rant>
>> Karaf is a great project but the surprise regressions and the long
>> variable
>> delays between versions (which include fixes for these regressions) is
>> very
>> frustrating. What makes it worse for me is that in the version I was using
>> (Karaf 2.3.2) editing factory configurations (not stored in etc) from the
>> Karaf command line console is broken causing me hours upon hours of misery
>> as the workaround for it (copy the factory configuration to a file in the
>> etc directory, edit the file, delete the old factory configuration,
>> restart
>> karaf) is very error prone (I can't ask people to use the web console
>> because I need to use Pax Web 3 with Karaf 2.3.2). I keep being told how
>> karaf is "too hard to use". Oh well...
>> </rant>
>>
>> thanks,
>> Gareth
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.
>> com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-
>> tp4033921p4035683.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@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/>
Software Architect / Project Manager / Scrum Master
Re: Problems With Factory Configurations In Karaf 3.0.1
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Done and checked on all branches.
Regards
JB
On 10/08/2014 05:35 AM, Gareth wrote:
> Hello John,
>
> It looks like it is fixed on the 3.0.x branch:
>
> https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/main/java/org/apache/karaf/features/internal/FeatureConfigInstaller.java
>
> Guillaume reverted the offending change on July 11:
>
> https://github.com/apache/karaf/commit/c31edca04692d8127989acbcdadc8157d1390f2a
>
> The same revert was done on master but Achim appears to have remade the
> change here:
>
> https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422dda8ffec474
>
> Achim - was that intentional?
>
> I am not sure if David was referring to me in some way when he said "there
> is a bunch of misinformation in some of the comments on this thread". I
> don't really care about the philosophical reasons for one particular factory
> pid format or the other. I just know with this change my
> ManagedServiceFactories and Declarative Service components could not find
> their factory configurations anymore...which thus made it impossible for me
> at least to upgrade to Karaf 3.
>
> <rant>
> Karaf is a great project but the surprise regressions and the long variable
> delays between versions (which include fixes for these regressions) is very
> frustrating. What makes it worse for me is that in the version I was using
> (Karaf 2.3.2) editing factory configurations (not stored in etc) from the
> Karaf command line console is broken causing me hours upon hours of misery
> as the workaround for it (copy the factory configuration to a file in the
> etc directory, edit the file, delete the old factory configuration, restart
> karaf) is very error prone (I can't ask people to use the web console
> because I need to use Pax Web 3 with Karaf 2.3.2). I keep being told how
> karaf is "too hard to use". Oh well...
> </rant>
>
> thanks,
> Gareth
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-tp4033921p4035683.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems With Factory Configurations In Karaf 3.0.1
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
By the way, the revert on master has been reverted as well (same patch
as on karaf-3.0.x). I'm fixing there as well.
Regards
JB
On 10/08/2014 05:35 AM, Gareth wrote:
> Hello John,
>
> It looks like it is fixed on the 3.0.x branch:
>
> https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/main/java/org/apache/karaf/features/internal/FeatureConfigInstaller.java
>
> Guillaume reverted the offending change on July 11:
>
> https://github.com/apache/karaf/commit/c31edca04692d8127989acbcdadc8157d1390f2a
>
> The same revert was done on master but Achim appears to have remade the
> change here:
>
> https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422dda8ffec474
>
> Achim - was that intentional?
>
> I am not sure if David was referring to me in some way when he said "there
> is a bunch of misinformation in some of the comments on this thread". I
> don't really care about the philosophical reasons for one particular factory
> pid format or the other. I just know with this change my
> ManagedServiceFactories and Declarative Service components could not find
> their factory configurations anymore...which thus made it impossible for me
> at least to upgrade to Karaf 3.
>
> <rant>
> Karaf is a great project but the surprise regressions and the long variable
> delays between versions (which include fixes for these regressions) is very
> frustrating. What makes it worse for me is that in the version I was using
> (Karaf 2.3.2) editing factory configurations (not stored in etc) from the
> Karaf command line console is broken causing me hours upon hours of misery
> as the workaround for it (copy the factory configuration to a file in the
> etc directory, edit the file, delete the old factory configuration, restart
> karaf) is very error prone (I can't ask people to use the web console
> because I need to use Pax Web 3 with Karaf 2.3.2). I keep being told how
> karaf is "too hard to use". Oh well...
> </rant>
>
> thanks,
> Gareth
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-tp4033921p4035683.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Problems With Factory Configurations In Karaf 3.0.1
Posted by Gareth <ga...@gmail.com>.
Hello John,
It looks like it is fixed on the 3.0.x branch:
https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/main/java/org/apache/karaf/features/internal/FeatureConfigInstaller.java
Guillaume reverted the offending change on July 11:
https://github.com/apache/karaf/commit/c31edca04692d8127989acbcdadc8157d1390f2a
The same revert was done on master but Achim appears to have remade the
change here:
https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422dda8ffec474
Achim - was that intentional?
I am not sure if David was referring to me in some way when he said "there
is a bunch of misinformation in some of the comments on this thread". I
don't really care about the philosophical reasons for one particular factory
pid format or the other. I just know with this change my
ManagedServiceFactories and Declarative Service components could not find
their factory configurations anymore...which thus made it impossible for me
at least to upgrade to Karaf 3.
<rant>
Karaf is a great project but the surprise regressions and the long variable
delays between versions (which include fixes for these regressions) is very
frustrating. What makes it worse for me is that in the version I was using
(Karaf 2.3.2) editing factory configurations (not stored in etc) from the
Karaf command line console is broken causing me hours upon hours of misery
as the workaround for it (copy the factory configuration to a file in the
etc directory, edit the file, delete the old factory configuration, restart
karaf) is very error prone (I can't ask people to use the web console
because I need to use Pax Web 3 with Karaf 2.3.2). I keep being told how
karaf is "too hard to use". Oh well...
</rant>
thanks,
Gareth
--
View this message in context: http://karaf.922171.n3.nabble.com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-tp4033921p4035683.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Problems With Factory Configurations In Karaf 3.0.1
Posted by David Jencks <da...@yahoo.com>.
From my point of view there is a bunch of misinformation in some of the comments on this thread. Here's what I think:
0) The config admin spec has a meaning for factory pid and pid. If you create a factory configuration, you use a factory pid, but you cannot control the pid for the configuration, that is implementation defined. Most CA implementations seem to try to help you out by using <factoryPid>-<number> but it could just as well be a UID or other generated unique meaningless string.
1) master now at least looks self-consistent: for factory pids, the input xml has an identifier of the form <id>-<factoryPid> and this is replicated in the identifier used by karaf put into the configuration under the key CONFIG_KEY = "org.apache.karaf.features.configKey". I didn't examine the code thoroughly before the change, but from the diff it looks like it was not consistent in that an incoming xml id <a>-<b> got turned into a config key of <b>-<a> which is weird.
2) The current code seriously abuses "pid" for when there is a factory pid. In this case, the "pid" is just some random string the user picked for their own convenience and has nothing whatsoever to do with a CA pid which is used internally to uniquely identify configurations.
3) This code from the "pre" in the diff is just a bad idea if there's something called "factoryPid" lying around
> return configurationAdmin.createFactoryConfiguration(pid, null);
Anything that fixes that is an improvement.
4) To make the code clearer, I would change parsePid(String unparsed) to return an object like
class PidInfo {
String pid;
String factoryPid;
String userId;
}
where the parser fills in either pid, or factoryPid and userId.
5) I think it's weird to have <userId>-<factoryPid>, and apparently this differs from fileInstall and the old karaf behavior. I'd change it to <factoryPid>-<userId> and change the config key values. This is a backwards incompatible change, but I doubt configurations can actually be usefully persisted across karaf upgrades.
thanks
david jencks
On Oct 7, 2014, at 3:32 PM, John Ellinwood <jo...@gmail.com> wrote:
> So did the original error end up getting fixed? I couldn't tell from the
> commits, jira, or this thread whether you reverted back to the original
> behavior or not.
>
> Gareth was correct in the original post for this thread, 3.0.1 is broken.
> We just upgraded from Karaf 3.0.0 to Karaf 3.0.1 and all of feature file
> based configs are broken now. Let me stress, everybody's feature based
> config deployments just broke between 3.0.0 and 3.0.1.
>
> For all of karaf history, including Karaf 3.0.0, the config name's value was
> parsed as <factoryPid>-<configName>.
>
> If you had a feature file like:
>
> <features name="features">
> <feature name="feature>
> <config name="my.factory-config1">
> prop1=value1
> </config>
> </feature>
> </features>
>
> I'd end up with a ConfigAdmin config like:
> service.pid: my.factory-123412341234342
> service.factoryPid: my.factory
> prop1: value1
>
> Now, with Karaf 3.0.1 that same feature file results in:
> service.pid: config1-12312312312312123
> service.factoryPid: config1
> prop1: value1
>
> FileInstall always followed the original convention as well, where a
> filename would be factoryPid-configName.cfg.
>
> I see commit
> https://github.com/apache/karaf/commit/21089127c89ddae275d495607c422dda8ffec474
> modified
> features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java:
> - return configurationAdmin.createFactoryConfiguration(pid, null);
> + return configurationAdmin.createFactoryConfiguration(factoryPid, null);
>
> and it doesn't appear to be fixed in
> https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
>
> Why would you make such a drastic change to the way that a core part of
> karaf works??
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Problems-With-Factory-Configurations-In-Karaf-3-0-1-tp4033921p4035676.html
> Sent from the Karaf - User mailing list archive at Nabble.com.