[arquillian-issues] [JBoss JIRA] (ARQ-1166) Check if current deployment is same as from metadata

[Bernard Labno (JIRA)]

    [ https://issues.jboss.org/browse/ARQ-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728291#comment-12728291 ] 

Bernard Labno commented on ARQ-1166:
------------------------------------

[10:41] <aslak> blabno, hmm, wondering of the issue i was seeing was when adding new classes
[10:41] <aslak> (looking at my extension-jrebel git status)
[10:42] <aslak> of/if
[10:42] <blabno> aslak: hm, adding new classes is not supported, since we apply includes to rebel.xml which is not reloadable
[10:43] <aslak> blabno, yea, we spoke about that earlier.
[10:43] <aslak> maybe do a hash of archive.toString(Formatters.VERBOSE) or something. do a complete redeploy if it change
[10:45] <blabno> aslak: we still need timestamp, because you may 1:deploy with extension on; 2:deploy with extension off; 3:deploy with extension on
[10:46] <blabno> and in case of 1 and 3 archive.toString(Formatters.VERBOSE) will be same
[10:47] <blabno> but using both timestamp and archive.toString(Formatters.VERBOSE) (which i suspect prints contents of the archive) will fix both issues
[10:47] <aslak> blabno, but the ping will handle that case ?
[10:48] <blabno> aslak: yes, timestamp will be read both from metadata and ping
[10:48] <aslak> (yes, it prints the the paths in the archive)
[10:48] <aslak> blabno, aa right, to compare them. 
                
> Check if current deployment is same as from metadata
> ----------------------------------------------------
>
>                 Key: ARQ-1166
>                 URL: https://issues.jboss.org/browse/ARQ-1166
>             Project: Arquillian
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Extension - JRebel
>            Reporter: Bernard Labno
>            Assignee: Bernard Labno
>
> [10:09] <aslak> one example from the JavaOne demo: I had ran the example with jrebel earlier and it worked during preparation.
> [10:10] <aslak> but not during the demo, because at demo time i had disabled the extension and ran a few other tests, then enabled it again. strange exceptions started to happen
> [10:10] == mnovak [mnovak at nat/redhat/x-vnphfxzlziqohqfq] has joined #jbosstesting
> [10:10] <aslak> the reason was that i hadn't cleaned up target, so the extension falsely found the old deployment metadata and assumed it was deployed
> [10:11] <blabno> aslak: that's what i suspected
> [10:11] == chm007 [~cmoulliar at ip-83-134-24-63.dsl.scarlet.be] has joined #jbosstesting
> [10:11] <blabno> aslak: devs need to remember to cleanup target
> [10:12] <aslak> just wondering if there is some kind of check we can do to know if we're running within the same 'run' or not
> [10:12] <aslak> basically knowing if what we assume is deployed is actually deployed.
> [10:13] <aslak> pr spi now, we can't check if a deployment is deployed
> [10:13] <aslak> but can we detect this in some other way
> [10:15] <blabno> aslak: we could add servlet that would return deployments checksum
> [10:15] <blabno> same as in metadata
> [10:15] <aslak> hmm.. that's an option
> [10:16] <aslak> we have the ProtocolMetadata stored, so we know the details of where that should be deployed
> [10:16] <aslak> ip/port/context

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira