[
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
