ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bram de Kruijff (JIRA)" <>
Subject [jira] [Commented] (ACE-168) Check version validity before publishing to targets
Date Thu, 25 Aug 2011 13:24:29 GMT


Bram de Kruijff commented on ACE-168:

I can see that the model is generic so from a design standpoint I agree. However the "provisioning
server cannot access the url (yet)" use cases feel a little exotic to me and 9 out of 10 times
I would like to be able to implement strategies that (try to) catch this type of issues. 

I can even image the provisioning server actually retrieving and privately caching the artifacts
to guard them from tampering, network failures and any other mistakes. It could then simply
pass the relay (that may also not have access to arbitrary urls cause its outside a dmz) the
urls to the cached artifact on the "trusted" parent server.

Obviously you cannot catch everything or prevent network failure between server and target
(so you'll still need retries). However due to the rather crucial role op provisioning and
configuration management in a large and complex deployment I feel you should be able to go
a long way. In most cases I think it is not unreasonable to have the provisioning being in
control of the resources it has in its model?

Disclaimer: Cause I struggled with failure that turned out to be a url typo mistake after
a lot of debugging... I may feel more strongly about this right now then I will in a couple
of days :)

> Check version validity before publishing to targets
> ---------------------------------------------------
>                 Key: ACE-168
>                 URL:
>             Project: Ace
>          Issue Type: Improvement
>    Affects Versions: 1.0.0
>            Reporter: Bram de Kruijff
> There is no sanity checking on artifacts (at least url) before publishing versions to
targets. Simple case is an artifact with an url that is not accessible. This will result in
any target it is associated to recieving a new version, polling for the deploymentpackage
and getting an error (DeploymentServlet catches the IOException) for ever and ever and ever.
> I think URL attributes should at least be validated at creation and some way to prevent
this endless fail cycle on every thread that handles deployment package requests affecting
all targets would be nice. 
> typical auditlog sample:
> ama-1,1314117989738,421,1314119324121,3001,version,9.0.0?current=8.0.0,name,http://localhost:8080/deployment/ama-1/versions/9.0.0?current=8.0.0
> ama-1,1314117989738,422,1314119326080,3001,version,9.0.0?current=8.0.0,name,http://localhost:8080/deployment/ama-1/versions/9.0.0?current=8.0.0
> ama-1,1314117989738,423,1314119328103,3001,version,9.0.0?current=8.0.0,name,http://localhost:8080/deployment/ama-1/versions/9.0.0?current=8.0.0
> typical client log sample:
> [2011-08-23 19:16:20] ERROR: Error installing update [org.apache.felix.framework]
> org.osgi.service.deploymentadmin.DeploymentException: null
> org.apache.felix.log.LogException: org.osgi.service.deploymentadmin.DeploymentException:
>         at org.apache.felix.deploymentadmin.DeploymentPackageManifest.<init>(
>         at org.apache.felix.deploymentadmin.AbstractDeploymentPackage.<init>(
>         at org.apache.felix.deploymentadmin.StreamDeploymentPackage.<init>(
>         at org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(
>         at org.apache.ace.deployment.deploymentadmin.DeploymentAdminDeployer.install(
>         at org.apache.ace.deployment.task.DeploymentTaskBase.installVersion(
>         at
>         at
>         at java.util.TimerThread.mainLoop(
>         at

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message