"dimitris@jboss.org" wrote:
The client only cares about deploying a URL. He doesn't care how this should be done or what is VFS and especially not what VFS options would be needed to workaround a particular problem.
I agree on VFS and impl details,
but I disagree on what the client cares about.
e.g. we can easily say we don't support super quick re-deploys.
In this case the cause is reaper, who's performance benefits out-weigh
user's simplicity to do quick re-deploy.
The only cost is to know what option to set.
Before we didn't have such options, now we do.
Is this a good this? More options is always good. ;-)
Perhaps we could make them more human nameable.
e.g noReaper --> quickRedeploy
"dimitris@jboss.org" wrote:
If we need to workaround the problem for this particular testcase, that's easy, just introduce a small delay and a note pointing to a JIRA with future work on this.
I don't see this impl change as workaround.
Looking at it better it was expected.
We had similar issue on PS's handling of deployments.
We eventually introduced VFS:delete, which knows how to halt current reaper,
hence enabling file for deletion.
This test case just shows what user can do if it has a deployment
which is gonna be redeployed in less than reaper's work time unit.
"dimitris@jboss.org" wrote:
Extending the MainDeployer api with implentation details doesn't offer any real value, it just complicates things.
The way it's currently done yes, if we put generic Map, then no.
It's not the nicest api, but it dos the job.
e.g. programmatic deployment
But see Scott's next post for better suggestion.
"dimitris@jboss.org" wrote:
And BTW, I think all VFS options should be visible in bootstrap/vfs.xml with the user able to override them in the command line, or by modifying the file.
Yes. I'll add a JIRA for you to do this. ;-)
