Exception in Karaf when Aries tries to write a default configuration file

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Exception in Karaf when Aries tries to write a default configuration file

Rubén Pérez
Hello,

This is my first time writing to this list and I'm not even sure that this mail should go here. I have found what I think to be a bug and I was not sure how to report it. Apologies if this is not the appropriate place.

I am one of the developers of Opencast [1], which since several months uses Karaf as the OSGI container. We are in the process of releasing a new version and I have detected a small issue: Aries tries to write a default configuration file ("org.apache.aries.transaction.cfg", most often empty) when it does not find one in the configuration directory. That causes an exception when Karaf starts if it does not have permission to write in that directory, which is the case when the system is deployed following the FHS guidelines --namely, the system-wide configuration files should be stored under /etc, and such files should not be modified by the applications (and therefore applications should not have write permission on these files).

The good (and curious) part is that Aries does not even seem to need any configuration file to work properly --the system works well despite the big ugly exception on startup. Therefore I do not see the point to try to create that file at all. The standard approach should be to either completely fail on startup (thus requiring the user to provide a configuration file on their own) or to use the default parameters (and the file would only be present if the user wished to modify such defaults).

In the end, the issue is harmless but scary at the first sight, and affects all our users who install the RPM-packaged version of Opencast. In the meantime, we have got rid of the exception by including an empty configuration file in the /etc directory, but because we consider this a bug, I wanted to report it to the upstream project. Please find attached a sample log file containing the exception.

Apologies if this is not the right list for posting bug reports.


Best regards

--
Rubén Pérez Vázquez

Universität zu Köln
Regionales Rechenzentrum (RRZK)
Weyertal 121, Raum 4.05
D-50931 Köln
✆: +49-221-470-89603

[1] http://www.opencast.org

opencast.log (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Exception in Karaf when Aries tries to write a default configuration file

Brad Johnson
Which version of karaf are you using? Christian or Jean-Baptiste would be better sources of information than I am but I'll take a shot. Personally I'd do what you are and just put the empty .cfg file in the etc directory and be done with it.  I guess it's arguable whether that's a bug or not since the configuration file is apparently necessary even if it is empty.  It takes care of that by writing it's own empty cfg file out but if it is locked out from writing then there's not much to do about it. I'm surprised that it's required.  I'd thin k the properties specification in Blueprint would make that irrelevant.  I've always put default properties in so don't know how it behaves if no defaults are specified. Perhaps it then requires a cfg file as it doesn't have defaults(?) Without cracking open the code and looking at it I'm just guessing.

This has existed for awhile but I think it has been fixed.  That's why I wondered what version you were using.  I think Tomcat actually modifies its log4j to exclude those errors/warnings. Since the error/warnings seem to make no difference in your application's functionality you may want to do that as well.  


Are you using JPA?

If memory serves it has something to do with the features start up order and versions of JPA/Hibernate being installed. That's from memory so I'm suspicious of my recall. Our team ran into during an upgrade but I wasn't directly involved so can't say what the exact resolution was. Here's an older thread that may relate though I'm not sure.



I'm curious. When you put the cfg file in the etc directory it works but when it is in the /etc/opencast/ directory it doesn't work?

Take a look at the following and then check the features/POM dependencies.



On Fri, Nov 18, 2016 at 6:42 AM, Rubén Pérez <[hidden email]> wrote:
Hello,

This is my first time writing to this list and I'm not even sure that this mail should go here. I have found what I think to be a bug and I was not sure how to report it. Apologies if this is not the appropriate place.

I am one of the developers of Opencast [1], which since several months uses Karaf as the OSGI container. We are in the process of releasing a new version and I have detected a small issue: Aries tries to write a default configuration file ("org.apache.aries.transaction.cfg", most often empty) when it does not find one in the configuration directory. That causes an exception when Karaf starts if it does not have permission to write in that directory, which is the case when the system is deployed following the FHS guidelines --namely, the system-wide configuration files should be stored under /etc, and such files should not be modified by the applications (and therefore applications should not have write permission on these files).

The good (and curious) part is that Aries does not even seem to need any configuration file to work properly --the system works well despite the big ugly exception on startup. Therefore I do not see the point to try to create that file at all. The standard approach should be to either completely fail on startup (thus requiring the user to provide a configuration file on their own) or to use the default parameters (and the file would only be present if the user wished to modify such defaults).

In the end, the issue is harmless but scary at the first sight, and affects all our users who install the RPM-packaged version of Opencast. In the meantime, we have got rid of the exception by including an empty configuration file in the /etc directory, but because we consider this a bug, I wanted to report it to the upstream project. Please find attached a sample log file containing the exception.

Apologies if this is not the right list for posting bug reports.


Best regards

--
Rubén Pérez Vázquez

Universität zu Köln
Regionales Rechenzentrum (RRZK)
Weyertal 121, Raum 4.05
D-50931 Köln
✆: <a href="tel:%2B49-221-470-89603" value="+4922147089603" target="_blank">+49-221-470-89603

[1] http://www.opencast.org

Reply | Threaded
Open this post in threaded view
|

Re: Exception in Karaf when Aries tries to write a default configuration file

Rubén Pérez

Hi,

First of all, sorry for the delay to answer and thanks for your complete answer.

We are currently using Karaf 3.0.8, and that is where this issue appears. We will soon migrate to 4.0.7, but that branch is at the moment quite unstable. We are using JPA with the jpa-eclipselink feature.

The system works regardless of whether the config file is in the etc directory or not. The only issue is that, if the file is *not* there, then a exception is raised on startup. Then the system works normally despite the exception. If the file exists on startup, then no exception is raised. It seems to be irrelevant whether the file is empty or not.

IMHO, a bundle should not try to write their own default configuration file when there is none. If the bundle **cannot** work without such a file, then it should simply not activate until the configuration is provided. If it can work without such a file, then it should not try to create it on its own. This is not a big deal, but I consider it to be a minor bug, at least.

Anyway, the bug is not bothering us anymore because we have included an empty configuration file in our RPM packages, but I thought it would be interesting to report the bug upstream, in case you guys consider that it's worth fixing.


Best regards


On 20/11/16 00:24, Brad Johnson wrote:
Which version of karaf are you using? Christian or Jean-Baptiste would be better sources of information than I am but I'll take a shot. Personally I'd do what you are and just put the empty .cfg file in the etc directory and be done with it.  I guess it's arguable whether that's a bug or not since the configuration file is apparently necessary even if it is empty.  It takes care of that by writing it's own empty cfg file out but if it is locked out from writing then there's not much to do about it. I'm surprised that it's required.  I'd thin k the properties specification in Blueprint would make that irrelevant.  I've always put default properties in so don't know how it behaves if no defaults are specified. Perhaps it then requires a cfg file as it doesn't have defaults(?) Without cracking open the code and looking at it I'm just guessing.

This has existed for awhile but I think it has been fixed.  That's why I wondered what version you were using.  I think Tomcat actually modifies its log4j to exclude those errors/warnings. Since the error/warnings seem to make no difference in your application's functionality you may want to do that as well.  


Are you using JPA?

If memory serves it has something to do with the features start up order and versions of JPA/Hibernate being installed. That's from memory so I'm suspicious of my recall. Our team ran into during an upgrade but I wasn't directly involved so can't say what the exact resolution was. Here's an older thread that may relate though I'm not sure.



I'm curious. When you put the cfg file in the etc directory it works but when it is in the /etc/opencast/ directory it doesn't work?

Take a look at the following and then check the features/POM dependencies.



On Fri, Nov 18, 2016 at 6:42 AM, Rubén Pérez <[hidden email]> wrote:
Hello,

This is my first time writing to this list and I'm not even sure that this mail should go here. I have found what I think to be a bug and I was not sure how to report it. Apologies if this is not the appropriate place.

I am one of the developers of Opencast [1], which since several months uses Karaf as the OSGI container. We are in the process of releasing a new version and I have detected a small issue: Aries tries to write a default configuration file ("org.apache.aries.transaction.cfg", most often empty) when it does not find one in the configuration directory. That causes an exception when Karaf starts if it does not have permission to write in that directory, which is the case when the system is deployed following the FHS guidelines --namely, the system-wide configuration files should be stored under /etc, and such files should not be modified by the applications (and therefore applications should not have write permission on these files).

The good (and curious) part is that Aries does not even seem to need any configuration file to work properly --the system works well despite the big ugly exception on startup. Therefore I do not see the point to try to create that file at all. The standard approach should be to either completely fail on startup (thus requiring the user to provide a configuration file on their own) or to use the default parameters (and the file would only be present if the user wished to modify such defaults).

In the end, the issue is harmless but scary at the first sight, and affects all our users who install the RPM-packaged version of Opencast. In the meantime, we have got rid of the exception by including an empty configuration file in the /etc directory, but because we consider this a bug, I wanted to report it to the upstream project. Please find attached a sample log file containing the exception.

Apologies if this is not the right list for posting bug reports.


Best regards

--
Rubén Pérez Vázquez

Universität zu Köln
Regionales Rechenzentrum (RRZK)
Weyertal 121, Raum 4.05
D-50931 Köln
✆: <a moz-do-not-send="true" href="tel:%2B49-221-470-89603" value="+4922147089603" target="_blank">+49-221-470-89603

[1] http://www.opencast.org


--
Rubén Pérez Vázquez

Universität zu Köln
Regionales Rechenzentrum (RRZK)
Weyertal 121, Raum 4.05
D-50931 Köln
✆: +49-221-470-89603