[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 12/10/14 6:59 PM:
----------------------------------------------------------------
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{code}}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
{{code}}
was (Author: dlmiles):
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles edited comment on JBIDE-18862 at 12/10/14 6:59 PM:
----------------------------------------------------------------
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
}}
was (Author: dlmiles):
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
{{code}}
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
{{code}}
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugi... ]
Darryl Miles commented on JBIDE-18862:
--------------------------------------
To go back to Rob's race concern:
> 3) eclipse has another incremental publish of the module before the server has managed to pick up the full publish
Eclipse can check *.isdeploying does not exist, before performing any kind of publish action that causes file/dir modification in the deployment area.
This (*.isdeploying) is managed by the AS and will be removed and replaced with a *.failed or *.deployed file once a terminal cause has been reached of the currently in-progress deployment operation at the AS.
Think of *.isdeploying as the AS's way of instructing Eclipse not to modify files just now, because the AS maybe opening/reading them.
BASENAME="blah.blah.ear"
FILENAME="${BASENAME}.isdeploying"
while test -f $FILENAME
do
Update Eclipse monitor description "Waiting for AS to remove $FILENAME marker file"
while test -f $FILENAME && $loop < 10
do
sleep 0.25 seconds
$loop++
done
Present dialog to user asking to continue waiting or abort operation
done
# at this point *.isdeploying does not exist
if rm "${BASENAME}.dodeploy"
then
# re-test *.isdeploying again, using same logic as above (you can skip this re-test if you know the "rm -f" did not remove any file, this maybe possible as the unlink() system call has an error code when the file being deleted did not exist.
fi
# Update eclipse progress monitor description to relate to publish action
# there can technically still be a race but the chances of it happening are a small as possible, when you are not getting a positive acknowledgement back from the AS, that would act like a synchronization point
## do publish stuff
if eclipse_module_is_set_to_start
then
touch $FILENAME
fi
> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-18862
> URL: https://issues.jboss.org/browse/JBIDE-18862
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Environment: Windiws7 64bit, JDK 8u25
> Reporter: Darryl Miles
> Priority: Minor
> Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18923) remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18923?page=com.atlassian.jira.plugi... ]
Fred Bricon commented on JBIDE-18923:
-------------------------------------
I'm +1 on principal, since these urls are confusing, require extra maintenance and are no lomger necessary given we use ide-congi.properties now.
But earlyaccess and integration stack should also be affected
> remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
> -----------------------------------------------------------------------------
>
> Key: JBIDE-18923
> URL: https://issues.jboss.org/browse/JBIDE-18923
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: buid, central, discovery
> Affects Versions: 4.3.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> These fallbacks are no longer required, so let's remove them.
> {code}
> - siteUrl="${jboss.discovery.site.url:https://devstudio.redhat.com/updates/9.0-development/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
> and
> {code}
> - siteUrl="${jboss.discovery.site.url:http://download.jboss.org/jbosstools/updates/development/luna/central/core/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18923) remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18923?page=com.atlassian.jira.plugi... ]
Fred Bricon edited comment on JBIDE-18923 at 12/10/14 6:36 PM:
---------------------------------------------------------------
I'm +1 on principal, since these urls are confusing, require extra maintenance and are no longer necessary given we use ide-config.properties now.
But earlyaccess and integration stack should also be affected
was (Author: fbricon):
I'm +1 on principal, since these urls are confusing, require extra maintenance and are no lomger necessary given we use ide-congi.properties now.
But earlyaccess and integration stack should also be affected
> remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
> -----------------------------------------------------------------------------
>
> Key: JBIDE-18923
> URL: https://issues.jboss.org/browse/JBIDE-18923
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: buid, central, discovery
> Affects Versions: 4.3.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> These fallbacks are no longer required, so let's remove them.
> {code}
> - siteUrl="${jboss.discovery.site.url:https://devstudio.redhat.com/updates/9.0-development/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
> and
> {code}
> - siteUrl="${jboss.discovery.site.url:http://download.jboss.org/jbosstools/updates/development/luna/central/core/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18923) remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18923?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-18923:
----------------------------------
Assignee: Nick Boldt
> remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
> -----------------------------------------------------------------------------
>
> Key: JBIDE-18923
> URL: https://issues.jboss.org/browse/JBIDE-18923
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: buid, central, discovery
> Affects Versions: 4.3.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> These fallbacks are no longer required, so let's remove them.
> {code}
> - siteUrl="${jboss.discovery.site.url:https://devstudio.redhat.com/updates/9.0-development/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
> and
> {code}
> - siteUrl="${jboss.discovery.site.url:http://download.jboss.org/jbosstools/updates/development/luna/central/core/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18923) remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18923?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-18923:
-------------------------------
Fix Version/s: 4.3.0.Alpha1
> remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
> -----------------------------------------------------------------------------
>
> Key: JBIDE-18923
> URL: https://issues.jboss.org/browse/JBIDE-18923
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: buid, central, discovery
> Affects Versions: 4.3.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.0.Alpha1
>
>
> These fallbacks are no longer required, so let's remove them.
> {code}
> - siteUrl="${jboss.discovery.site.url:https://devstudio.redhat.com/updates/9.0-development/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
> and
> {code}
> - siteUrl="${jboss.discovery.site.url:http://download.jboss.org/jbosstools/updates/development/luna/central/core/}">
> + siteUrl="${jboss.discovery.site.url}">
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months
[JBoss JIRA] (JBIDE-18923) remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-18923:
----------------------------------
Summary: remove fallback URLs for jboss.discovery.site.url in central plugin.xml files
Key: JBIDE-18923
URL: https://issues.jboss.org/browse/JBIDE-18923
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: buid, central, discovery
Affects Versions: 4.3.0.Alpha1
Reporter: Nick Boldt
These fallbacks are no longer required, so let's remove them.
{code}
- siteUrl="${jboss.discovery.site.url:https://devstudio.redhat.com/updates/9.0-development/}">
+ siteUrl="${jboss.discovery.site.url}">
{code}
and
{code}
- siteUrl="${jboss.discovery.site.url:http://download.jboss.org/jbosstools/updates/development/luna/central/core/}">
+ siteUrl="${jboss.discovery.site.url}">
{code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 5 months