The deployment-scanner and the CLI are both clients using the management
API. Under the covers, they both do the same thing -- take an archive
somewhere on the filesystem and upload it to the server, which stores it
in data/content and then deploys it.
The deployment-scanner is for people who prefer to use OS gestures (like
the cp command) as their user interface instead of using the CLI.
On 4/4/12 12:47 AM, Bela Ban wrote:
I understand the CLI places applications into a separate directory
('data' ?), so I'm wondering why we have 2 different locations:
'deployments' for manual deployment and 'data' for deploying via the CLI
?
If this is the case, then this would be inconsistent
On 4/3/12 10:41 PM, Brian Stansberry wrote:
> Did this kind of deployment dir sharing work on previous AS releases? I
> suppose it might have for .war files since IIRC wars were copied into
> tmp/. For other deployment types I believe doing this would have led to
> file lock problems on Windows.
>
> Anyway, I've opened
https://issues.jboss.org/browse/AS7-4383 to look
> into not writing marker files or optionally writing them in data/. Part
> of the purpose of those marker files was a request that we provide in
> the dir itself input to users as to what was happening with the
> deployment.
>
> Even if AS7-4383 were done I don't think *exploded* deployments would
> work reliably at all if scanners on multiple servers were scanning the
> same dir. There would likely be file lock problems and deleting the
> .deployed file is the intended trigger for undeploy. Deleting the
> deployment itself also triggers undeploy, but it is very dangerous to do
> it that way for an exploded deployment.
>
> More in-line...
>
> On 3/30/12 7:34 AM, Bela Ban wrote:
>> I have a big problem with the way AS deploys applications: I have a
>> web.war and a cluster of AS 7.1.1 instances.
>>
>> Each instance has separate work, data, log, tmp etc directories
>> (jboss.node.name, jboss.server.data.dir, jboss.server.temp.dir etc).
>>
>> I have a $HOME/jboss/standalone/deployments dir into which I copied
>> web.war, assuming that web.war is an application that can be shared by
>> all cluster nodes.... However, the markers screw things up, as they
>> actually modify things.
>>
>> The first node is started and adds a suffix web.war.dodeply -->
>> .isdploying --> .deployed.
>>
>> The second node is started and does the same. (The weird thing is why
>> does the 2nd node even deploy web.war anymore, as the marker .deployed
>> suggested that the app has already been deployed !)
>>
>
> It knows it's not deployed, because it can check the server-side state.
>
>> However, if I start a few nodes concurrently, then this lifecycle is
>> screwed, and I end up with some nodes having web.war deployed and others
>> not. This apparently gets sorted out, and after some time the marker is
>> .deployed again. But this spits out nasty warnings in-between.
>>
>> Is there a recommended way to share web.war between cluster nodes ?
>>
>
> Recommended is to use the CLI to do the deployments. This can be
> scripted easily enough if you know the addresses/ports the servers are
> listening on. (I realize that may be a problem in some situations.)
>
> You can also configure the AS to use a deployment at a specific location:
>
> <deployments>
> <deployment name="demo.war" runtime-name="demo.war">
> <fs-archive path="demo.war" relative-to="user.home"/>
> </deployment>
> </deployments>
>
> The value for fs-archive "path" can be absolute if the relative-to
> attribute is not used.
>
> I just filed a JIRA to make it easier to set this up via the CLI:
>
>
https://issues.jboss.org/browse/AS7-4385
>
>> IMO, markers should be in the *data* dir for a node, which can easily be
>> separated by using -Djboss.server.data.dir=xxx !
>>
>
> See above; the request was to provide input to the user as to what went
> on. The user is not meant to look in the data/ dir; it's the AS' private
> playground. Also, the recommended trigger for undeploy is deleting the
> .deployed file.
>
>> What's the recommended way to share applications between nodes ? (I
>> tried domain mode, but couldn't get it to work after half a day...)
>>
>> If this is an RTFM, perhaps I didn't google enough, then let me know !
>>
>
>