[
https://issues.apache.org/jira/browse/ACE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090995#comment-13090995
]
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: https://issues.apache.org/jira/browse/ACE-168
> 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: null
> at
> org.apache.felix.deploymentadmin.DeploymentPackageManifest.<init>(DeploymentPackageManifest.java:53)
> at
> org.apache.felix.deploymentadmin.AbstractDeploymentPackage.<init>(AbstractDeploymentPackage.java:96)
> at
> org.apache.felix.deploymentadmin.StreamDeploymentPackage.<init>(StreamDeploymentPackage.java:48)
> at
> org.apache.felix.deploymentadmin.DeploymentAdminImpl.installDeploymentPackage(DeploymentAdminImpl.java:194)
> at
> org.apache.ace.deployment.deploymentadmin.DeploymentAdminDeployer.install(DeploymentAdminDeployer.java:51)
> at
> org.apache.ace.deployment.task.DeploymentTaskBase.installVersion(DeploymentTaskBase.java:75)
> at
> org.apache.ace.deployment.task.DeploymentUpdateTask.run(DeploymentUpdateTask.java:57)
> at org.apache.ace.scheduler.Executer.run(Executer.java:92)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
