[ https://issues.apache.org/jira/browse/FELIX-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103494#comment-13103494 ]
Laszlo Hordos commented on FELIX-3095: -------------------------------------- There are two sides to every coin. One side as you are suggesting the user MUST program around every relative path to make them absolute before they are uses by the framework. What are the consequences of this in a real project. Whoever use the Felix framework in embedded mode in a project very likely have the same problem because I guess most of the application serves do set user.dir for each application or for some other reason the problem may present. We can assume there is a development instance and the developers have their own environment with custom paths. There are test and QA environment somewhere and the production too. If the application is running and a clustered environment then it makes more instance paths. It's undesired to keep the absolute path in the shared config files so the developers MUST develop something to get those updated at run or build time. OK, Let's assume they did the update and then there is the default relative conf folder. The framework does not finds it because of the same reason so the developers has to explicitly define it. But what if they hit a problem where it's not solvable by any workaround. They will open an issue on the same problem. There may be other default relative paths that the framework won't be able to find. It's depends on the users' desperation to use the solution further. The other side of the coin is how important for the Felix team to support the embedded felix setups and make it easy to use and popular. It's your decision to say it's not a bug because we don't care much about the embedded installations so if there is an issue then the users have to solve their problem by unique technics or you can say there was not many requests so far but obviously we want to make it as easy to use as a standalone installation and change it to something "nice to have" further improvement. So far I was the only one who reported this issue and I try to make my workaround but I'd like to keep this issue open for further update if there will be more demand on it. Of course if it fine with you. I can comment on this issue after I solved the relative path problem by programatically set the absolute paths and I run into a problem where I couldn't do that so if you ever take an action on to fix this issue you can use these as test cases. > FELIX running in embedded mode the File().exits() is false and the > File().getAbsoluteFile().exists() is true > ------------------------------------------------------------------------------------------------------------ > > Key: FELIX-3095 > URL: https://issues.apache.org/jira/browse/FELIX-3095 > Project: Felix > Issue Type: Bug > Components: Framework > Affects Versions: framework-3.2.2 > Environment: Windows 7 32bit and 64bit: JVM 1.6.0_21 > OSX : JVM 1.6.0_26 > Running embedded Felix with Jetty 6.x 7.x and JBoss 4.2, 5.X > Reporter: Laszlo Hordos > Attachments: Screen shot 2011-08-31.png > > > I have the following code in the config.properties > felix.auto.start.1 = \ > reference:file:bundle/init/openidm-system.jar \ > When the framework tries to find the bundle the > org.apache.felix.framework.cache.createRevisionFromLocation(..) line:840 > calls the org.apache.felix.framework.util.fileExists(..) and I double checked > the file is there but the code did not find it. > I noticed if I create a watch in the debugger the file.exists() it returns > false. If I change the watch to file.getAbsoluteFile().exists() it returns > true. > I change the code everywhere to get the getAbsoluteFile always to be safe but > this "bug" is in the Felix. I have an issue to deploy and run the OpenIDM > within an embedded deployment. The code is published > svn co https://svn.forgerock.org/openidm/trunk/openidm-webapp/ openidm-webapp > cd openidm-webapp > mvn jetty:run-war -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira