[
https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919641#comment-13919641
]
Uwe Barthel edited comment on FELIX-4436 at 3/4/14 5:14 PM:
------------------------------------------------------------
I think the provided patch does not solve the real problem.
h4. Explanation of my understanding
The blueprint deployer extending the {{ArtifactUrlTransformer}} and create a
new bundle (JAR) based on passed blueprint XML file. This bundle goes the
normal way and will be installed. The bundle location is a opaque URI like:
{noformat}
blueprint:file:/tmp/fileinstall/deploy/blueprint.xml
{noformat}
The real problem, as I understand it, is located deep in the
{{#initializeCurrentManagedBundles()}} method.
If the {{DirectoryWatcher}} starts to work, the
{{#initializeCurrentManagedBundles()}} will be executed and analysed the
installed artifacts:
# get all installed bundles
# interate over all bundles and get the bundle location
# create normalized {{URI}} based on bundle location
# check {{URI#getPath()}}
## if path is {{null}} or path doesn't starts with the configured watch
directory
*** continue *without* create {{Artifact}} object for the installed bundle/
## otherwise
*** create {{Artifact}} object and add to global {{currentManagedArtifacts}}
via {{#setArtifact(...)}}
After all the {{#process(...)}} method will be execute (this is the method
where the provided patch is located).
This method iterate also over the files and tried to get a {{Artifact}} object
for the passed file.
In the described case no {{Artifact}} object will be found for the blueprint
XML file and the way goes to the {{// File has been added}}-_else_ part of the
big _if-else_ statement.
At this point a new {{Artifact}} object will be created and added to the
{{created}}-List.
The content of the {{created}}-List will be installed or updated via
{{#install(...)}} and the returned {{Bundle}} objects goes directly into the
{{toRefresh}}-Set.
h4. Possible solution
Try to handle opaque {{URI}} at the point _4.1_.
was (Author: barthel):
I think the provided patch does not solve the real problem.
h4. Explanation of my understanding
The blueprint deployer extending the {{ArtifactUrlTransformer}} and create a
new bundle (JAR) based on passed blueprint XML file. This bundle goes the
normal way and will be installed. The bundle location is a opaque URI like:
{noformat}
blueprint:file:/tmp/fileinstall/deploy/blueprint.xml
{noformat}
The real problem, as I understand it, is located deep in the
{{#initializeCurrentManagedBundles()}} method.
If the {{DirectoryWatcher}} starts to work, the
{{#initializeCurrentManagedBundles()}} will be executed and analysed the
installed artifacts:
# get all installed bundles
# interate over all bundles and get the bundle location
# create normalized {{URI}} based on bundle location
# check {{URI#getPath()}}
## if path is {{null}} or path doesn't starts with the configured watch
directory
*** continue *without* create {{Artifact}} object for the installed bundle/
## otherwise
*** create {{Artifact}} object and add to global {{currentManagedArtifacts}}
via {{#setArtifact(...)}}
After all the {{#process(...)}} method will be execute (this is the method
where the provided patch is located).
This method iterate also over the files and tried to get a {{Artifact}} object
for the passed file.
In the described case no {{Artifact}} object will be found for the blueprint
XML file and the way goes to the {{// File has been added}}-_else_ part of the
big _if-else_ statement.
At this point a new {{Artifact}} object will be created and added to the
{{created}}-List.
The content of the {{created}}-List will be installed or updated via
{{#install(...)}} and the returned {{Bundle}} objects goes directly into the
{{toRefresh}}-Set.
h4. Possible solution
Try to handle opaque {{URI}}s at the point _4.1_.
> DirectoryWatcher should not "refresh" Blueprint XML deployments on every
> start-up
> ---------------------------------------------------------------------------------
>
> Key: FELIX-4436
> URL: https://issues.apache.org/jira/browse/FELIX-4436
> Project: Felix
> Issue Type: Bug
> Components: File Install
> Affects Versions: fileinstall-3.2.4
> Environment: ServiceMix 4.5.3
> Reporter: metatech
> Priority: Minor
> Attachments: felix_no_refresh_installed.patch
>
>
> DirectoryWatcher can auto-deploy JAR or XML files placed in a directory.
> Blueprint XML files (containing for instance ActiveMQ factories or JAAS
> realms) are detected as "installed" on every start-up. Prior to FELIX-2066,
> this had no effect. Since FELIX-2066, bundles detected as "installed" are
> now forcibly "refreshed" on every start-up. The impact is that these bundles
> are stopped and restarted during the container start-up. Because there are
> some race conditions (see FELIX-3067), this can prevent those XML files or
> other bundles depending on them from fully starting. Here is a patch which
> avoids restarting those bundles when they were not modified.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
