[00:00:33] <lfryc> Hi aslak
[00:00:42] <lfryc> just looking into it
[00:01:38] <lfryc> nice, thanks for the clean-up!
[00:07:33] <lfryc> merged!
[00:11:02] <lfryc> I plan to release Warp Alpha1 in the middle of next week
[00:11:48] <lfryc> before that, I will test that gear on some real tests in RichFaces ;-)
[00:15:47] <aslak> lfryc, i'm hacking a bit in relation to this: ARQ-935
[00:15:48] <jbossbot> jira [ARQ-935] Should handle de-enrich of final fields [Open (Unresolved) Bug, Major, Aslak Knutsen] https://issues.jboss.org/browse/ARQ-935
[00:16:06] <lfryc> yeah, was looking on that..
[00:16:14] <aslak> so we can transfer rich objects back and forth..
[00:16:15] <lfryc> tests for deenricher would be handy
[00:16:56] <lfryc> yeah, it is possible
[00:17:15] <aslak> verify(new MyServerAssertion(new RichObject())).getServerObject()
[00:17:35] <lfryc> right
[00:17:47] <lfryc> pretty cool :-)
[00:18:09] <lfryc> we could actually automated that...
[00:18:16] <lfryc> @Inject @TranssferToClient
[00:18:35] <lfryc> @Inject @FromServer
[00:19:25] <aslak> currently i'm just looking at transfering to and back objects that are serializable. the rest will be null
[00:19:29] <lfryc> in case the enrichment is serializable
[00:19:57] <lfryc> sure, you need to handle it manually on server atm
[00:20:28] <lfryc> I'm not sure about CDI/EJB/JPA entities, how much they could be serialized
[00:20:58] <aslak> some will be, some won't..
[00:22:19] <aslak> lfryc, i'm not quite following that you do here..
[00:22:52] <aslak> aa right.. now i get what you are doing..
[00:23:11] <lfryc> looking at https://github.com/arquillian/arquillian-extension-warp/blob/master/impl/src/main/java/org/jboss/arquillian/warp/server/test/LifecycleTestDeenricher.java ?
[00:23:46] <lfryc> okay :-)
[00:24:39] <aslak> yea
[00:24:58] <aslak> you store all initial values before Before happen
[00:25:13] <aslak> then all fields After Before (the ones that has changed by enrichment)
[00:25:14] <lfryc> then after that happen I look what have changed
[00:26:08] <aslak> yea, and restore the state to before @Test
[00:26:10] <aslak> ?
[00:26:11] <lfryc> hmm, I'm looking I should catch exceptions appropriately around context.proceed
[00:27:03] <lfryc> restoreFields after all @After methods
[00:28:12] <aslak> aa this has nothing to do with serialization, it's in the case of running the Same Assertion instance multiple times ?
[00:28:56] <lfryc> no, it is avoiding having enriched instances when serializing back to client (which I assume happen in Before)
[00:29:10] <lfryc> I assume all enrichment happen in Before
[00:29:38] <aslak> well that is correct
[00:29:52] <aslak> something i'm missing here i think
[00:29:55] <lfryc> then I saw Arquillian itself do nothing for de-enriching
[00:30:01] <lfryc> right?
[00:30:05] <aslak> we don't..
[00:30:11] <lfryc> yep, it's not necessary
[00:30:23] <lfryc> but for keeping the assertion serializable
[00:30:29] <lfryc> I need to de-enrich
[00:30:40] <aslak> i don't quite understand why you hvae the 'after' enrichment state?
[00:30:44] <aslak> state back
[00:31:24] <aslak> 1. store all field values (Before Before)
[00:31:43] <lfryc> yeah, it could be at before AfterClass, you mean?
[00:32:02] <lfryc> which is on the end of the request
[00:32:07] <aslak> 2. loop trough all previously stored fields, and create a new store for all the values that has changed, but with their original value from the previous store
[00:32:17] <aslak> 3. replay the 2. backup to the object
[00:32:45] <aslak> i don't understand step 2
[00:33:06] <lfryc> I need to identify, what has been enriched
[00:33:24] <lfryc> do delta of state backupAllFields <-> backupUpdatedFields
[00:33:31] <aslak> aa ok.. so if a Enricher sets a field that's should be removed, but I can set a field and that should survive.. right go tit
[00:34:52] <lfryc> right
[00:35:20] <lfryc> btw that doesn't have to be valid assumption in any case
[00:35:51] <lfryc> at some point, high-level Deenrichers could be necessary
[00:35:56] <aslak> just trying to understand. :)
[00:36:34] <aslak> on little annoying this is that ServerAssertion needs t obe Serializable
[00:37:07] <aslak> or that's not the annoying part, but the serialUUID warning in eclipse is
[00:37:22] <aslak> and no tsetting a serialUUID cause some issues with JRebel extension
[00:37:26] <lfryc> yeah, I have used @SuppressWarnings :-)
[00:37:53] <aslak> if you don't set the version id, the jvm will generate one for you, which is based on the method etc in the class
[00:38:01] <lfryc> yep
[00:38:06] <aslak> with JRebel that start to break since the class change constanly
[00:38:08] <aslak> but..
[00:38:28] <lfryc> we could just skip final fields
[00:38:28] <aslak> but i've done s ofar in my experiments.. is to make ServerAssertion a abstract class that implements Externalizable
[00:38:56] <lfryc> they can't be enriched, thus doesn't have to be de-enriched
[00:39:13] <aslak> no more IDE serial version problems
[00:39:35] <lfryc> why abstract class?
[00:40:08] <lfryc> ah, yeah, got it
[00:40:09] <aslak> similar we now have control over how these ServerAssertion objects are serialized, so we can in theory avoid the deenricher, but base it on what we can serialize or not
[00:42:42] <lfryc> hmm, writing the own serializer..
[00:42:53] <lfryc> I don't fully get it right now :-)
[00:42:58] <lfryc> in theory, yes..
[00:43:08] <aslak> similar to what you do
[00:43:08] <lfryc> do you have some prototypes?
[00:43:22] <lfryc> just skip the objects whcih are not serializable?
[00:43:29] <lfryc> (in serialization process)
[00:43:37] <aslak> for each field in this.getClass().getDecalredFields() {  out.writeObject(field.get(this))}
[00:43:44] <aslak> and then the other way around on deserialize
[00:44:24] <aslak> but then for instance before , if field.get().isSerializable() { out.write() }
[00:45:12] <lfryc> yeah, got it..
[00:45:14] <aslak> we're not dealing with evolving objects here.. so the Class we send to the Server wil be the same as the one we get back
[00:46:40] <lfryc> yep, that's the contract of ServerAssertion
[00:47:54] <aslak> lfryc, by evolving i mean, we're not getting back the ServerAssertion objects we wrote a month ago, so we don't have to serialize between different versions, matching changed/missing fields and all that stuff
[00:48:18] <aslak> the problem you might run into in a more traditional client server communication
[00:48:27] <lfryc> oic
[00:50:59] <lfryc> okay, let's try to go that way..
[00:51:24] <lfryc> I can hack on it
[00:51:55] <aslak> lfryc, i'm already deep in it.. give me a little time so i can finish my sphagetti and i'll hvae a pr for you
[00:51:57] <aslak> :)
[00:52:35] <lfryc> sounds great :-)
[00:53:26] <lfryc> I need to leave for now..
[00:53:45] <lfryc> ttyl
[00:55:07] <aslak> l8r
[00:56:37] *** lfryc has quit IRC
[03:22:16] *** qmx|away is now known as qmx
[03:57:30] *** ldimaggi has joined #jbosstesting

top