felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Barthel (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FELIX-4436) DirectoryWatcher should not "refresh" Blueprint XML deployments on every start-up
Date Tue, 04 Mar 2014 17:15:22 GMT

    [ 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)

Mime
View raw message