[00:00:21] <sbryzak> oranheim: how do you mean? [00:00:39] <oranheim> think of it. You'll end up with multiple cdi extensions trying to solve the same things.. that's going to turn into a mess in the end of day. Solder is good progressing the CDI evolution [00:00:56] <jose_freitas> I think that what sbryzak is saying is that it's nice if they use solder, but we can force it as a requirement. [00:01:12] <sbryzak> jose_freitas: agreed [00:01:12] <jose_freitas> as it's not a specification [00:01:13] <kenfinnigan> Off to catch plane home. See u all later [00:01:19] <sbryzak> cya ken! [00:01:20] <jose_freitas> cya kenfinnigan [00:01:33] *** kenfinnigan has quit IRC [00:01:35] <oranheim> sbryzak: Others take will only depend on Weld, will possibly make overlapping functionality.. Hence if you shop an extension here and there, it'll end up as a mud [00:01:35] <sbryzak> i would love to see them use solder, but we're not going to force it on them [00:01:52] <sbryzak> oranheim: which particular feature of solder do you think they need? [00:01:59] <jose_freitas> we can promote it, though [00:02:08] <jose_freitas> as part of our partnership [00:02:27] <oranheim> I'm not referring to any particular feature. It's making an eco-system of web frameworks that hopefully can interact with each other over time [00:02:32] <oranheim> CDI is in its early days [00:03:09] <sbryzak> i don't see not using solder as a bad thing [00:03:18] <sbryzak> i mean, it's got some useful features if you need them [00:03:37] <lightguard_jp> That's up to them, really. Solder has some nice to haves. If they want to recreate all that work, good for them. [00:03:57] <sbryzak> at this point i don't actually see what they'd need it for [00:04:03] <lightguard_jp> It's like commons or all the other logging frameworks, if you want to use what's there go for it, if not then recreate it all yourself. [00:04:04] <sbryzak> the wicket module is incredibly simple [00:04:29] <oranheim> agree to that [00:05:04] <sbryzak> so, i think we should be encouraging this initiative [00:05:44] <sbryzak> it furthers the goal of cdi, it furthers our own goals, and in practical terms it reduces the amount of maintenance work we do [00:06:03] <oranheim> ok [00:06:05] <sbryzak> we should promote it in terms of documentation [00:06:17] <sbryzak> i'd like to see us keep a wicket chapter in the reference guide [00:06:56] <sbryzak> when i see clint online next i'll have a chat with him and see how we can help [00:07:38] <lightguard_jp> Anyone have anything else they'd like to bring up? [00:07:39] <sbryzak> i think that's all of our topics covered? [00:07:47] <sbryzak> good timing actually [00:07:55] <oranheim> :) [00:08:03] <lightguard_jp> Thanks for coming everyone! [00:08:13] <sbryzak> thanks guys, it was a very passionate meeting ;) [00:08:20] <lightguard_jp> #endmeeting [00:08:21] <oranheim> Thanks all :-) [00:08:26] <jose_freitas> sbryzak: what was resolution on dependency thing, again? [00:08:31] *** jbott changes topic to "Seam 3.0.0.Final has been released! Development discussions for Seam (seamframework.org). Join #seam for user discussions. See http://seamframework.org/Seam3/Chat for logs and more info. TeamSpeak 3 server is available for Seam devs at 216.6.228.98:10024, password: seam-dev" [00:08:31] <jbott> Meeting ended Wed Aug 17 22:01:54 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [00:08:31] <jbott> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-08-17-21.00.html [00:08:31] <jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-08-17-21.00.txt [00:08:31] <jbott> Log: http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-08-17-21.00.log.html [00:08:47] <jose_freitas> thanks jbott [00:08:58] <sbryzak> jose_freitas: that we have an api and impl, and the user imports both [00:09:24] <jose_freitas> hm, that wasn't clear on the minutes. [00:09:48] <sbryzak> it's in the transcript :) [00:09:58] <jose_freitas> hehehe [00:10:00] <jose_freitas> ok [00:10:19] <sbryzak> now we have a lot of work to do... [00:11:30] <johnament> runtime scope, right? [00:11:41] <jose_freitas> mojavelinux: are you working with graddle? I'm curious to know if it works the way you said maven should work. but I don't know even if it uses those same concepts. [00:11:49] <sbryzak> for implementations, yes [00:12:05] <oranheim> Regarding the blocking issue for Seam Mail and AS7 now have a solution: https://issues.jboss.org/browse/AS7-1375 [00:12:06] <jbossbot> jira [AS7-1375] UnsupportedDataTypeException sending email [Open (Unresolved) Bug, Major, Tomaz Cerar] https://issues.jboss.org/browse/AS7-1375 [00:12:09] <jose_freitas> and solder was kept with api and impl separated? [00:12:09] <sbryzak> jose_freitas: gradle won't solve our problem, because we still deploy our artifacts to a maven repo [00:12:14] <sbryzak> and most of our users will still use maven [00:12:24] <jose_freitas> sbryzak: I'm just curious [00:12:34] <sbryzak> yes, solder is staying separated [00:12:43] <lightguard_jp> Gradle will make the build eaiser and less maintenance for us [00:12:50] <sbryzak> although we need to move some classes around [00:13:00] <jose_freitas> sbryzak: nice [00:13:01] <sbryzak> because many of the modules are importing solder impl classes [00:13:02] <oranheim> Is Gradle Nexus repo compliant? [00:13:24] <sbryzak> oranheim: good question, i'm not sure about that [00:13:28] <lightguard_jp> oranheim: It reads poms, can create poms, and retrieves artifacts the same way maven does [00:13:44] <sbryzak> there's probably quite a few maven plugins that haven't been replicated in gradle yet i'm guessing [00:13:46] <lightguard_jp> oranheim: What exactly do you mean by "Nexus repo compliant"? [00:13:59] <sbryzak> i think he means the release plugin [00:14:00] <oranheim> I mean M2 repo compliant [00:14:07] <oranheim> yes, pluss release [00:14:17] <lightguard_jp> oranheim: explain what you mean by compliant? [00:14:33] <oranheim> Is it capable to fetching artifacts from the repo server [00:14:42] <lightguard_jp> yes [00:14:53] <oranheim> Does it support maven release plugin? [00:15:08] <mojavelinux> aha!!! [00:15:20] <mojavelinux> I figured out the dependency scoping thing [00:15:28] <oranheim> If so, it's worth evaluating a change if it sorts all the deps mess you're experiencing [00:15:37] <mojavelinux> the bom must set the *-api explicitly to "compile" [00:15:47] <mojavelinux> right now, we aren't setting a scope (assuming it will default to compile) [00:16:03] <mojavelinux> but that's not "strong" enough to override the scope defined by the module itself [00:16:09] <sbryzak> mojavelinux: did you test this? [00:16:14] <mojavelinux> so, if I set seam-faces-api to "compile" in the seam-bom [00:16:16] <mojavelinux> and import the bom [00:16:30] <mojavelinux> then add seam-faces as a dep (no scope set in the user's project), I get this: [00:16:40] <mojavelinux> [INFO] +- org.jboss.seam.faces:seam-faces:jar:3.1.0.Beta1:runtime [00:16:41] <mojavelinux> [INFO] | +- org.jboss.seam.faces:seam-faces-api:jar:3.1.0.Beta1:compile (scope managed from runtime) [00:16:47] <mojavelinux> so it's just a problem with the seam-bom [00:17:03] *** lazarotti has quit IRC [00:17:04] <mojavelinux> any dependency that doesn't have a <scope> tag, just add one that says <scope>compile</scope> [00:17:07] <mojavelinux> and this all will work [00:17:08] <sbryzak> that's great if it works [00:17:10] <sbryzak> brb, testing ;) [00:17:17] <mojavelinux> of course, you get that lame "scope managed from runtime" message [00:17:22] <mojavelinux> but, at least it does the right thing [00:17:52] <jose_freitas> mojavelinux: but then the user must import our bom, right? [00:18:08] <mojavelinux> yes, the user must import the bom for that to work [00:18:10] <mojavelinux> but that is reasonable [00:18:13] <sbryzak> that's fine though jose [00:18:22] <sbryzak> it's our bom that sets the impl to runtime in the first place [00:18:25] <oranheim> what about Gradle and maven integration? Automatic dep resolver? [00:18:26] <mojavelinux> well, they don't have to [00:18:29] <sbryzak> so if they don't use our bom, they don't have the issue anyway [00:18:35] <mojavelinux> if they don't, they need to explicitly import two dependencies [00:18:41] <mojavelinux> one as compile, one as runtime [00:18:41] <jose_freitas> sbryzak: oic [00:19:24] <mojavelinux> jose, in gradle dependencies are declared how you want them to be declared...it's really an open book [00:19:35] <jose_freitas> well, that's great then. [00:19:59] <mojavelinux> you could, for instance, have a clause that runs through and sets all dependencies than end in -api to compile scope [00:20:07] <mojavelinux> you at least have the flexibility [00:20:12] <mojavelinux> intent [00:20:15] <mojavelinux> guys, gotta run [00:20:32] <oranheim> bye dan [00:20:36] <jose_freitas> bye mojavelinux [00:20:57] <sbryzak> by jove he's done it [00:21:09] <sbryzak> good work mojavelinux [00:21:20] <mojavelinux> woot! :) [00:21:34] <mojavelinux> good note to end on before I run...bbl [00:21:36] <sbryzak> so we can leave the impl naming alone [00:21:38] *** mojavelinux has left #seam-dev [00:21:45] <jose_freitas> gotta go too [00:21:47] <jose_freitas> bye guys [00:21:50] *** jose_freitas has quit IRC [00:22:11] *** johnament has quit IRC [00:22:20] *** edburns is now known as edburns_away [00:23:05] *** cbrock has quit IRC [00:23:05] <oranheim> sbryzak: what's the downside with gradle compared to maven? [00:23:26] <sbryzak> i wouldn't say there's a downside, just that it's less mature [00:23:53] <oranheim> well, maven may be mature, but the amount of wasted time spent on it has its cost [00:24:06] <sbryzak> you don't need to tell me that [00:24:12] <sbryzak> my wall has a head shaped indent in it [00:24:16] <oranheim> :) [00:25:01] <oranheim> well gotta go too [00:30:47] <clerum> Is there @Create equivialent in CDI? [00:31:36] <clerum> or just handled that inside the no-arg constructor or via a Producer method? [00:34:40] <lightguard_jp> clerum: Annotate a method with @Inject [00:34:49] <lightguard_jp> It acts as a post construct [00:34:55] *** lightguard_jp sets mode: -o jbott [00:35:13] <clerum> ah makes sense [00:39:25] <lightguard_jp> clerum: You can also add params and they become injection points [00:39:59] <clerum> yep. totally makes sense...just wasn't thinking about it like that [00:46:05] <lightguard_jp> stuartdouglas: Any ideas here ? http://seamframework.org/Community/InjectingSessionScopedBeanIntoFilterDoesntMatchJsf#comment164510 [00:46:08] <lightguard_jp> Is that a weld issue? [00:47:06] <stuartdouglas> lightguard_jp: probably [00:47:20] <lightguard_jp> sbryzak: I think using teambox for us with this work please do. [00:47:29] <lightguard_jp> Or you could use JIRA and assign things out [01:09:44] *** ssachtleben has quit IRC [01:20:35] *** hannelita has quit IRC [01:24:01] <sbryzak> lightguard_jp: ping [01:26:56] *** sannegrinovero has joined #seam-dev [01:27:24] *** bleathem has quit IRC [01:30:28] <lightguard_jp> sbryzak: Yes [01:30:52] <sbryzak> i had a question, but i can't remember exactly what it was... [01:31:00] <sbryzak> i'm going through seam-parent now [01:31:10] <sbryzak> there's a whole heap of things there i'm unsure of, and would like to document [01:31:23] <sbryzak> so at the moment i'm just writing it all up in a text file [01:31:38] <sbryzak> when i'm done i'll post to seam-dev [01:31:51] <lightguard_jp> Okay [01:32:05] <sbryzak> ah, i remember.. do you know if we use jboss-logging-tools? [01:32:27] <lightguard_jp> Does that one have the annotation processor? [01:32:43] <sbryzak> hmm, i'm not sure [01:32:55] <sbryzak> solder doesn't seem to use it [01:33:16] <lightguard_jp> If it doesn't have the annotation processor then I would say no [01:33:46] <sbryzak> ok i'm hoping ken can answer that [01:34:21] <lightguard_jp> jamezp: Any ideas on that jar? [01:34:26] <lightguard_jp> jamezp: jboss-logging-tools [01:35:05] *** rruss has quit IRC [01:39:44] <lightguard_jp> sbryzak: I'm going to sign off for a bit [01:39:51] <sbryzak> lightguard_jp: no probs [01:43:28] <jamezp> sbryzak: I think solder just used the jboss-logging-tools-generator. It has it's own processor. [01:44:00] *** lightguard_jp has quit IRC [01:44:03] <sbryzak> solder doesn't seem to have a dependency on jboss-logging-tools [01:44:10] <sbryzak> are you saying that solder has its own now? [01:45:08] <jamezp> I think it has it's own implementation of jboss-logging-tools-processor, which is I think 3 classes. [01:45:38] <sbryzak> ah, so i should be able to remove it from seam-parent now? [01:46:32] <jamezp> I think so, https://github.com/seam/solder/blob/develop/tooling/pom.xml#L37 [01:46:58] <jamezp> In fact it's probably pulling in old stuff :-) [01:47:29] <sbryzak> i'll remove it from the parent, it's not really common concern for all modules anyway [01:47:42] <jamezp> Makes sense to me. [01:47:45] <sbryzak> thanks :) [01:48:17] <jamezp> No problem. [01:59:29] *** mbg is now known as mbg|away [02:02:22] *** hannelita has joined #seam-dev [02:08:45] *** rruss has joined #seam-dev [02:24:24] *** johnament has joined #seam-dev [02:27:31] *** tkimura has joined #seam-dev [02:30:54] *** jose_freitas has joined #seam-dev [02:32:28] *** tkimura has quit IRC [02:34:14] <jose_freitas> lincolnthree stopped entering the channel? [02:34:42] <johnament> jose_freitas, where is he? [02:35:36] <jose_freitas> dunno [02:35:41] <jose_freitas> I was wondering about that [02:35:42] <jose_freitas> hehehe [02:36:04] <jose_freitas> I've been trying to catch him the last couple of days [02:43:19] *** oranheim has quit IRC [02:43:41] *** oranheim has joined #seam-dev [02:44:07] *** mbg|away is now known as mbg [02:45:19] *** tkimura has joined #seam-dev [02:50:34] <jbossbot> git [parent] push master cd2de7b.. Shane Bryzak remove weld-parent, total overhaul of seam-parent - remove unnecessary stuff, update plugins to latest versions, improve comments [02:50:34] <jbossbot> git [parent] push master URL: http://github.com/seam/parent/compare/ce12c43...cd2de7b [02:51:04] <jbossbot> git [parent] push master 2c8b2d2.. Shane Bryzak remove jboss-logging-tools [02:51:04] <jbossbot> git [parent] push master URL: http://github.com/seam/parent/compare/cd2de7b...2c8b2d2 [03:01:01] <stuartdouglas> sbryzak: Is org.jboss.seam:seam-bom:pom:3.1.0.Beta1 supposed to be in nexus? [03:01:10] <sbryzak> only in staging [03:01:14] <stuartdouglas> ah [03:01:39] <stuartdouglas> I have a SOLDER-112 [03:01:40] <jbossbot> jira [SOLDER-112] Default producer with a disposal method doesn't work [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-112 [03:01:40] <stuartdouglas> fix [03:01:50] <sbryzak> ah cool [03:01:54] <stuartdouglas> but after rebasing on develop I can't build [03:02:03] <sbryzak> you could build the bom locally [03:02:10] <sbryzak> or add the staging repo to your settings.xml [03:02:12] <stuartdouglas> I'll just add staging [03:02:38] <johnament> sbryzak, is there anyway to build all this locally? [03:02:57] <sbryzak> johnament: the bom? [03:03:26] <stuartdouglas> Now I get: Could not find artifact org.jboss.seam:seam-bom:pom:3.1.0.Beta1 [03:03:27] <johnament> sbryzak, bom, deps, etc [03:03:56] <stuartdouglas> I'm just going to push it, it worked before the rebase :-) [03:03:56] <sbryzak> johnament: yes, clone from github, run git checkout 3.1.0.Beta1, then mvn clean install [03:04:07] <sbryzak> stuartdouglas: weird, it should be there [03:04:12] <sbryzak> https://repository.jboss.org/nexus/index.html#nexus-search;quick~seam-bom [03:04:13] <jbossbot> git [solder] push develop 594327b.. Stuart Douglas SOLDER-112 Fix disposal methods on default beans [03:04:14] <jbossbot> jira [SOLDER-112] Default producer with a disposal method doesn't work [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-112 [03:04:14] <jbossbot> git [solder] push develop URL: http://github.com/seam/solder/compare/d5720a7...594327b [03:04:20] <johnament> sbryzak, clone what exactly? [03:04:31] <sbryzak> johnament: the bom, if that's what you mean [03:04:37] <sbryzak> git clone git at github dot com:seam/dist.git dist [03:04:48] <johnament> got you [03:06:52] <clerum> jose_freitas: i think lincolnthree is on vacation per his twitter [03:14:00] <sbryzak> it's so cold here today [03:14:08] *** rruss has quit IRC [03:27:27] *** cbrock has joined #seam-dev [03:32:09] *** kenfinnigan has joined #seam-dev [03:32:13] *** akazakov has quit IRC [03:35:39] *** jamezp is now known as jamezp_afk [03:37:34] *** hannelita has quit IRC [03:38:05] *** cbrock has quit IRC [03:44:11] *** johnament has quit IRC [03:44:43] *** sannegrinovero has quit IRC [03:58:37] <jose_freitas> thanks clerum [04:06:33] *** kenfinnigan has quit IRC [04:57:28] *** sbryzak has quit IRC [05:00:40] *** DiabloD3 has quit IRC [05:02:40] *** hannelita has joined #seam-dev [05:06:04] *** sbryzak has joined #seam-dev [05:06:04] *** sbryzak has joined #seam-dev [05:07:15] *** hannelita has quit IRC [05:35:20] *** daniel_hinojosa has quit IRC [05:45:38] *** jose_freitas has quit IRC [06:15:55] *** gastaldi has joined #seam-dev [06:16:02] *** gegastaldi has joined #seam-dev [06:16:30] <gastaldi> hey [06:16:46] *** daniel_hinojosa has joined #seam-dev [06:17:10] <sbryzak> gastaldi: heya [06:17:39] <gastaldi> wow ! Jboss 7.0.1 is ready ! :) [06:17:51] <gastaldi> these guys are fast [06:21:02] *** clerum has quit IRC [06:23:09] <gastaldi> hey sbryzak [06:23:16] <gastaldi> Still struggling with Maven ? [06:24:56] [06:25:55] *** hannelita has joined #seam-dev [06:32:59] *** rruss has joined #seam-dev [06:33:02] *** rruss has quit IRC [06:56:29] <sbryzak> gastaldi: not struggling with maven at the moment [06:56:33] <sbryzak> the pain has passed for now [06:56:37] <sbryzak> np about the meeting [06:57:14] <gastaldi> cool [06:57:42] <gastaldi> gotta go now, see ya tomorrow [06:58:09] *** gastaldi has quit IRC [07:44:47] *** daniel_hinojosa has quit IRC [07:45:10] *** mbg is now known as mbg|away [08:04:12] *** mbg|away is now known as mbg [08:05:12] *** tkimura has quit IRC [08:05:32] *** daniel_hinojosa has joined #seam-dev [08:05:40] *** tkimura has joined #seam-dev [08:16:52] *** mbg has quit IRC [08:21:06] *** chkal has joined #seam-dev [08:25:02] *** daniel_hinojosa has quit IRC [08:32:41] *** marekn has joined #seam-dev [08:35:38] *** hannelita has quit IRC [08:38:06] *** mgoldmann has joined #seam-dev [08:42:05] *** maschmid has joined #seam-dev [08:42:20] *** shervin_a has joined #seam-dev [08:42:59] *** epbernard has joined #seam-dev [08:42:59] *** epbernard is now known as emmanuel [09:05:29] *** koentsje has joined #seam-dev [09:22:41] *** dabloem has joined #seam-dev [09:41:54] *** koentsje has quit IRC [09:44:39] *** koentsje has joined #seam-dev [09:56:36] *** fiorenzino has joined #seam-dev [10:13:36] *** dabloem has joined #seam-dev [10:28:10] *** alesj has joined #seam-dev [10:35:37] *** sannegrinovero has joined #seam-dev [10:43:23] *** alesj has quit IRC [11:26:48] *** tkimura has quit IRC [11:57:53] *** tkimura has joined #seam-dev [12:02:24] *** emmanuel has quit IRC [12:08:20] *** epbernard has joined #seam-dev [12:08:20] *** epbernard is now known as emmanuel [13:12:59] *** rmartinelli has joined #seam-dev [13:15:51] *** aslak has joined #seam-dev [13:15:51] *** aslak has quit IRC [13:15:51] *** aslak has joined #seam-dev [13:24:10] *** DiabloD3 has joined #seam-dev [13:33:02] *** jose_freitas has joined #seam-dev [13:39:41] *** mbg has joined #seam-dev [13:47:32] *** mbg has quit IRC [13:49:28] *** koentsje has quit IRC [13:50:31] *** mbg has joined #seam-dev [13:54:12] *** mbg has quit IRC [13:58:14] *** DiabloD3 has quit IRC [14:02:50] *** koentsje has joined #seam-dev [14:19:56] *** sannegrinovero has quit IRC [14:27:20] *** Diablo-D3 has joined #seam-dev [14:35:38] *** Diablo-D3 has quit IRC [14:35:47] *** Diablo-D3 has joined #seam-dev [14:41:04] *** Diablo-D3 has quit IRC [14:44:37] *** koentsje_ has joined #seam-dev [14:46:51] *** koentsje has quit IRC [14:46:51] *** koentsje_ is now known as koentsje [14:52:21] *** kevinpollet has joined #seam-dev [14:53:49] *** alesj has joined #seam-dev [15:01:40] *** jganoff has joined #seam-dev [15:02:54] *** tsurdilo has joined #seam-dev [15:03:53] *** alesj has quit IRC [15:05:11] *** Diablo-D3 has joined #seam-dev [15:05:37] *** sannegrinovero has joined #seam-dev [15:05:40] *** hannelita_ has joined #seam-dev [15:11:45] *** jganoff has quit IRC [15:15:04] *** Diablo-D3 has quit IRC [15:15:14] *** daniel_hinojosa has joined #seam-dev [15:16:57] *** kevinpollet has quit IRC [15:17:33] *** Diablo-D3 has joined #seam-dev [15:18:21] *** lazarotti has joined #seam-dev [15:41:04] *** edburns_away is now known as edburns [15:43:51] *** hannelita_ has quit IRC [15:48:28] *** sannegrinovero has quit IRC [16:12:46] *** daniel_hinojosa has quit IRC [16:18:53] *** hannelita has joined #seam-dev [16:24:36] *** epbernard has joined #seam-dev [16:25:03] *** clerum has joined #seam-dev [16:25:15] *** emmanuel has quit IRC [16:44:32] *** bdlink has joined #seam-dev [16:50:29] *** chkal has quit IRC [16:56:06] *** mbg has joined #seam-dev [16:59:21] *** daniel_hinojosa has joined #seam-dev [17:11:54] *** shervin_a has quit IRC [17:12:39] *** daniel_hinojosa has quit IRC [17:13:00] *** Diablo-D3 has quit IRC [17:13:22] *** Diablo-D3 has joined #seam-dev [17:23:33] *** marekn has left #seam-dev [17:23:47] *** gastaldi has joined #seam-dev [17:25:02] *** daniel_hinojosa has joined #seam-dev [17:36:40] *** jamezp_afk is now known as jamezp [17:37:41] *** tkimura has quit IRC [17:51:13] *** maschmid has quit IRC [17:58:10] *** koentsje has quit IRC [18:03:08] *** cbrock has joined #seam-dev [18:05:22] *** balunasj has joined #seam-dev [18:12:07] <clerum> shuchks, I was hoping jsf would have been upgrade to 2.0.6 in AS 6.1 [18:20:46] *** dabloem has quit IRC [18:35:55] *** sannegrinovero has joined #seam-dev [18:40:43] <gastaldi> clerum: I hoped that on 7.0.1 also [18:40:51] <gastaldi> but it is still 2.0.4 :( [18:43:29] *** daniel_hinojosa has quit IRC [18:44:07] *** bleathem has joined #seam-dev [18:48:40] *** akazakov has joined #seam-dev [18:52:50] *** fiorenzino has left #seam-dev [19:05:41] <jose_freitas> gastaldi: you can upgrade yourself [19:05:47] *** tsurdilo has quit IRC [19:05:55] <gastaldi> how ? [19:06:20] *** tsurdilo has joined #seam-dev [19:06:33] <jose_freitas> server/deployers/jsf.deployer [19:06:37] <gastaldi> the as7 team says that the other versions have a TCCL issue [19:06:44] <jose_freitas> just drop the new jars [19:06:53] <jose_freitas> on the mojarra 2 folder [19:07:08] <jose_freitas> and remove the old ones [19:07:13] <gastaldi> hum,, AS7 ? [19:07:28] <jose_freitas> I've been using 2.1.1 for sometime now [19:07:31] <jose_freitas> no, jboss6 [19:07:43] <gastaldi> ah, I was talking about AS7 :) [19:07:48] <jose_freitas> ahn [19:07:54] <gastaldi> Yeah, cool knowing that for 6 [19:10:15] <jose_freitas> for jbossas7 its /modules/com/sun/jsf-impl/ and ../jsf-api [19:10:36] <jose_freitas> ops, there's no jsf-api [19:12:04] <jose_freitas> api on modules/javax/faces/api [19:12:18] <jose_freitas> I'm sure it's just a matter of switching jars [19:12:25] <jose_freitas> like it's in jboss [19:12:28] <jose_freitas> 6 [19:12:49] <jose_freitas> didn't try it though [19:13:43] <jose_freitas> hm [19:13:51] <jose_freitas> there's <resources> [19:13:51] <jose_freitas> <resource-root path="jboss-jsf-api_2.0_spec-1.0.0.Final.jar"/> [19:13:51] <jose_freitas> <!-- Insert resources here --> [19:13:51] <jose_freitas> </resources> [19:13:58] <jose_freitas> on modules.xml [19:14:04] <jose_freitas> module.xml* [19:14:29] <jose_freitas> someone must give a try [19:14:39] <jose_freitas> jsf 2.1.* has a lot of bugfixes [19:17:59] <gastaldi> yeah [19:21:25] *** jamezp has quit IRC [19:24:51] *** koentsje has joined #seam-dev [19:27:19] *** jamezp has joined #seam-dev [19:31:45] *** aslak has quit IRC [19:33:27] *** balunasj has quit IRC [19:34:55] *** aslak has joined #seam-dev [19:35:45] *** daniel_hinojosa has joined #seam-dev [19:35:48] *** jganoff has joined #seam-dev [19:36:11] *** alesj has joined #seam-dev [19:37:54] *** alesj has quit IRC [19:59:16] <bleathem> anyone know how to use a maven archetype file that I downloaded manually? [19:59:28] <bleathem> do I have to install it into my local maven repo to use it? [19:59:39] <bleathem> or can I just point to it with command line arguments? [20:01:21] <hannelita> bleathem: you should be able to use it with command line args [20:01:41] <bleathem> these maven docs suck almost as much as maven :P [20:03:03] <hannelita> bleathem: Do you use eclipse? i think there's a wizard there for local archetypes :) [20:03:12] <bleathem> great, thanks! [20:03:14] <bleathem> I'll try that [20:06:11] *** tsurdilo has quit IRC [20:07:31] <bleathem> hannelita: do you see that under "New Maven Project" ? [20:07:51] <hannelita> bleathem: I do think so... let me check it [20:07:53] <bleathem> I don't see where I can point to a specific archetype file :( [20:08:52] <bleathem> or is it that I point to the file under "Repository URL" when adding an archetype [20:09:26] <jose_freitas> bleathem: window>preferences>maven>archetypes>add local catalog [20:09:43] <bleathem> and a local catalog is the archetype file I downloaded? [20:10:35] <jose_freitas> catalog is normally a set of archetypes [20:10:44] <jose_freitas> but try adding your archetype alone [20:11:32] <gastaldi> bleathem: http://maven.apache.org/archetype/maven-archetype-plugin/generate-mojo.html [20:11:43] <gastaldi> archetypeCatalog can be a file:// [20:11:45] <jose_freitas> if not, try adding a new maven project, where you choose the archetype, you can add a new archetype there [20:11:57] <gastaldi> ah wait [20:12:09] <bleathem> gastaldi: that's where I'm looking, but.. [20:12:15] [20:12:19] <bleathem> I don't have that file [20:12:21] <gastaldi> yeah [20:12:27] <gastaldi> what if you install it to your repo ? [20:12:51] <gastaldi> http://maven.apache.org/plugins/maven-install-plugin/examples/installing-secondary-artifacts.html [20:13:13] <gastaldi> http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html [20:13:35] <bleathem> yeah, I guess I shouldn't have tried to avoid that... :P [20:13:52] <gastaldi> :) [20:14:22] [20:14:45] <bleathem> ahh man, turns out it was in the JBoss repo [20:14:50] * bleathem facepalm [20:14:50] <gastaldi> hahaha [20:14:56] <gastaldi> doh [20:15:18] <bleathem> thanks for all your help! [20:15:51] <jose_freitas> :) [20:26:27] <gastaldi> I am thinking of buying REAL WORLD JAVA EE NIGHT HACKS [20:26:50] <gastaldi> Is it better than the previous one ? Rethinking best practices ? [20:27:09] <gastaldi> Have anyone read it ? [20:27:46] <jose_freitas> I read Rethinking best practices, it's very good [20:27:56] <jose_freitas> too focused on jee5 thoug [20:28:03] <gastaldi> hum [20:28:15] <jose_freitas> but it's still useful on jee6 [20:28:34] <jose_freitas> night hacks might discuss some new problems after the addition of CDI [20:28:47] <bleathem> I found the first few chapters of "Rethinking" to be good, but quickly got dry as he got into the patterns [20:29:04] <bleathem> is night hacks still written in the same patterns style? [20:29:34] <clerum> So in seam 2 I have a activeUser bean [20:29:37] <jose_freitas> I think that he discuss some aspects of jee applications based on an app that he made [20:29:50] <clerum> which I inject into this for doing audit logging and such [20:29:50] <bleathem> jose_freitas: sounds more hands-on then [20:29:57] <clerum> into things [20:30:16] <jose_freitas> I think so, but didn't have the oportunity to read it yet. [20:30:27] <clerum> There is session scoped one for each logged in user and also an application scoped bean if the system is making changes on its own [20:30:54] <clerum> will CDI search all scoped for existing beans before cycling back through looking for producers? [20:31:10] <bleathem> clerum: how can you have both a session and application scoped bean of the same type? [20:31:18] <clerum> you can in seamn 2 [20:31:26] <clerum> there is an order to the search [20:31:32] <clerum> application checked last [20:31:34] <bleathem> I don't *think* you can in CDI [20:31:42] <bleathem> not sure though [20:32:03] <bleathem> I think you gat an ambiguous excpetion exception of some kind [20:32:16] <jose_freitas> I think that that would be resolved as ambiguous [20:32:23] <jose_freitas> bleathem: agree [20:32:34] *** lightguard_jp has joined #seam-dev [20:32:54] <jose_freitas> clerum: I think that the seam2 aproach is kinda dangerous [20:33:51] *** bdlink has quit IRC [20:34:41] <clerum> yes but it also does have it's places where it is handy [20:35:31] <jose_freitas> yeah. what's your situation? [20:35:49] <clerum> I have AuditLog events which @Inject a bean called SessionUser [20:36:08] <clerum> which is produced by a @SessionScoped Bean created when the user logs in [20:36:19] <jose_freitas> hm [20:36:37] <clerum> but....what if the event is triggered by someing started by Seam Cron or something [20:36:42] <clerum> no session context [20:36:59] <jose_freitas> hm [20:38:07] <clerum> maybe the producer is dependent scoped and checks to see if there is an active session? [20:38:27] <clerum> and if not produces a different bean? [20:39:12] <jose_freitas> I was thinking about that [20:40:05] <clerum> any idea how to check if a session context exists? [20:40:11] <gastaldi> clerum: How would you have a SessionUser it is started by Seam Cron ? [20:40:20] <gastaldi> IF it is ... [20:40:45] <gastaldi> You may @Inject a Instance<SessionUser> [20:41:28] <gastaldi> and test the isUnsatisfied() [20:42:04] <jose_freitas> hm, isUnsatisfied does check when there's no context? [20:43:00] *** epbernard has quit IRC [20:43:41] *** daniel_hinojosa has quit IRC [20:43:52] <jose_freitas> well, in theory what gastaldi proposed makes sense clerum. I'm not sure though about isUnsatisfied [20:43:56] <gastaldi> jose_freitas: Nice question :) [20:45:06] <clerum> yeah since it would be satisified [20:45:19] <clerum> but potentially not if there is no sessionContext [20:45:20] <gastaldi> I think you need to inject BeanManager and check whether the scope is active or not [20:45:27] <gastaldi> Worth a shot :) [20:45:50] <jose_freitas> clerum: if does not work, you could check for iterator size. [20:45:57] <gastaldi> BeanManager.getContext [20:46:15] <gastaldi> BeanManager.getContext(SessionScoped.class).isActive() [20:46:32] <jose_freitas> instance.iterator().hasNext() [20:46:43] <gastaldi> But you need to place in under an Instance, for sure [20:46:48] <jose_freitas> gastaldi: thats better ! [20:46:49] <jose_freitas> :) [20:47:03] <clerum> checking [20:47:05] <gastaldi> :) [20:49:14] <gastaldi> let us know if it works [20:58:09] *** epbernard has joined #seam-dev [20:58:09] *** epbernard is now known as emmanuel [20:58:58] *** emmanuel has quit IRC [21:02:56] *** mgoldmann has quit IRC [21:08:31] <clerum> jose_freitas: gastaldi: it ended up being two issues [21:08:42] <clerum> one the injection of the SessionScoped Session user [21:09:00] <clerum> and then also the injection of the ConversationScoped EntityManager from seam persistence [21:10:25] <jose_freitas> hm [21:10:46] <jose_freitas> did you solve? can we see a pastebin? [21:10:52] <clerum> so the AuditLog class ended https://gist.github.com/04cbd3c9bb76ebb214e1 [21:10:56] <jose_freitas> or gist :) [21:11:21] <clerum> I ended up just catching the context not active exceptions [21:11:21] *** gastaldi has quit IRC [21:11:42] <jose_freitas> interesting way out [21:11:53] <clerum> and running my injections via Instance.get() [21:12:08] <clerum> seems to work :-) [21:12:08] <jose_freitas> just starred your gist :) [21:12:53] <clerum> have to learn a whole new set of tricks [21:13:18] <jose_freitas> yeah, me too. and that's awesome =x [21:13:28] *** jganoff has quit IRC [21:17:46] *** nilian has joined #seam-dev [21:19:09] *** rmartinelli has quit IRC [21:20:45] *** rmartinelli has joined #seam-dev [21:22:25] *** jamezp is now known as jamezp_afk [21:30:12] *** gastaldi has joined #seam-dev [21:38:54] *** tsurdilo has joined #seam-dev [21:53:43] *** daniel_hinojosa has joined #seam-dev [22:10:20] *** jamezp_afk is now known as jamezp [22:28:44] <gastaldi> jose_freitas: You there ? [22:28:52] <jose_freitas> yeap [22:28:58] <gastaldi> Have you read that article on Java Magazine about Seam 3 ? [22:29:05] <jose_freitas> nope [22:29:09] <jose_freitas> why? [22:29:17] [22:29:20] <jose_freitas> (who wrote it?) [22:29:24] <jose_freitas> hehehe [22:29:35] <jose_freitas> now you made me curious [22:30:04] <gastaldi> http://www.devmedia.com.br/post-21935-Seam-3--Weld-a-base-do-novo-framework.html [22:30:18] <gastaldi> It basically describes CDI [22:30:22] <gastaldi> No Seam 3 at all :P [22:30:30] [22:30:47] <gastaldi> This is the only paragraph about Seam 3 [22:31:11] <gastaldi> Although the title says another thing [22:31:23] <gastaldi> Adam Victor Nazareth Brandizzi [22:31:27] <gastaldi> This is the author [22:31:43] <jose_freitas> LOL [22:31:53] <jose_freitas> just took a peek [22:31:59] <gastaldi> hehehe [22:32:32] <jose_freitas> and it's the main article [22:33:06] <gastaldi> Yeah [22:33:08] <gastaldi> lol [22:33:23] <gastaldi> false advertising [22:34:48] *** mateus has joined #seam-dev [22:40:07] <clerum> is there a way to chain f:ajax or a:ajax calls? [22:40:42] <hannelita> gastaldi: Crap article [22:41:21] <gastaldi> hannelita: :) [22:41:25] <gastaldi> hannelita: Have you read it ? [22:41:35] <hannelita> gastaldi: I stopped reading this magazine [22:42:06] <gastaldi> hannelita: Yeah me too [22:47:42] <gastaldi> They could at least remove the "Seam 3" from the front cover :P [22:56:01] <hannelita> Idk that author [22:56:35] <gastaldi> neither do I [22:56:50] *** balunasj has joined #seam-dev [22:57:16] <hannelita> but this is not the entire post gastaldi [22:57:26] <gastaldi> no [22:57:39] <gastaldi> You must buy the magazine for that [22:58:23] <gastaldi> Have anyone played with metawidget + primefaces ? [22:58:37] <lightguard_jp> not for primefaces [22:58:41] <gastaldi> or Richfaces ? [22:59:03] <gastaldi> lightguard_jp: Have you had any issue ? [22:59:29] <gastaldi> lightguard_jp: the jquery,js is not added to my <head> page [22:59:53] <gastaldi> I am banging my head on the wall trying to figure it out [23:00:36] <gastaldi> It does not work for either frameworks [23:00:39] <lightguard_jp> Things seemed to work fine with Richfaces, I was using vision 1.15 [23:00:53] <gastaldi> hum, I am using 1.25, could be that ? [23:00:57] <gastaldi> On JSF 2.0 [23:01:07] <gastaldi> well, a Forge ap [23:01:08] <gastaldi> app [23:01:48] <lightguard_jp> I would imagine it works okay [23:04:00] <clerum> this primefaces autocomplete is going to drive me to drink [23:04:22] <gastaldi> clerum: Is that a good thing ? [23:04:27] <gastaldi> :) [23:04:48] <clerum> not in celebration unfortuantly [23:04:54] <gastaldi> lol [23:05:18] <gastaldi> clerum: Try Richfaces [23:05:26] <gastaldi> Richfaces kicks ass [23:06:31] <clerum> dead end at the momemnt [23:07:35] <clerum> http://community.jboss.org/thread/170992?tstart=30 [23:07:59] <clerum> the primefaces autocomplete is the only one it appears with object support [23:08:31] *** koentsje has quit IRC [23:09:45] *** jose_freitas has quit IRC [23:11:12] *** balunasj has quit IRC [23:12:57] <gastaldi> clerum: Whoa ! Your post seems to have made people flee :) [23:13:59] <clerum> or they didn't see it and now it's slipping down the list [23:14:24] <gastaldi> :) [23:14:38] <clerum> bleathem has it on his todo list to take a look at the post [23:15:40] <bleathem> clerum: looking at it now, I'm half way through a reply [23:15:44] <gastaldi> cool [23:16:02] <gastaldi> the reply will be: "Pull request accepted !" :D [23:16:18] <clerum> I'm sure [23:16:53] *** rmartinelli has quit IRC [23:17:22] <bleathem> clerum: so, to summarize my understanding, you want the dynamic search capability of "autocomplete" [23:17:39] <bleathem> but the "locking" capability of "inplaceSelect" [23:17:49] <bleathem> or rather, let me ask: [23:18:06] <bleathem> clerum: what is richFaces autocomplete missing that you need? [23:18:37] <clerum> well the main part of it is that the value is an object like an entity [23:19:09] <clerum> the input box is simply a field to input the search paramater and display the label of the object (entity in this case) [23:19:34] <gastaldi> clerum: Does Primefaces behaves like that ? [23:19:37] <clerum> eys [23:19:38] <clerum> yes [23:19:47] <gastaldi> bleathem: ouch [23:19:49] <gastaldi> ;) [23:20:00] <clerum> http://www.primefaces.org/showcase-labs/ui/autoCompletePojo.jsf [23:20:21] *** oranheim has left #seam-dev [23:20:23] <gastaldi> cool [23:20:36] <clerum> but I do understand that the rich:autocomplete as it was in 3 and now and 4 is designed for suggesting Strings [23:21:20] <clerum> which has me wondering if a autocompletePojo is something that should be created or just modify the existing autocomplete to support it [23:21:32] <gastaldi> really cool [23:22:00] <bleathem> ok, I'm going to constrain myself to talking about the RichFaces autocomplete [23:22:14] <bleathem> lest an IRC chat be perceived as "marketing" [23:22:20] <clerum> sure sure [23:22:52] <clerum> right now thats the only component that is keeping primefaces in my pom [23:22:52] <bleathem> so you are saying the RichFaces autocomplete only works with strings, but now tih objects/entities? [23:23:07] <clerum> but not with [23:23:08] <gastaldi> not with [23:23:08] <clerum> right [23:23:40] <bleathem> FYI, our goal for RichFaces as a project it to integrate well with PrimeFaces [23:24:20] <clerum> the showcase currently doesn't even bind to a value http://richfaces-showcase.appspot.com/richfaces/component-sample.jsf?demo=autocomplete&skin=blueSky [23:24:33] <bleathem> but back to the RichFaces autocomplete - I'm taking a closer look at it now, but I'm suprised it doesn't work with SelectItems [23:24:44] <clerum> well not select items [23:24:50] <clerum> an autocomplete method [23:24:51] <bleathem> as that is how the rest of the RichFaces 4 select components work [23:26:42] <bleathem> clerum: I'm looking at the autocomplete example from the dev-examples [23:27:15] <clerum> the autocompletemethod passes a string and returns a List [23:27:22] <bleathem> https://github.com/richfaces/dev-examples/blob/develop/input-demo/src/main/webapp/examples/autocomplete.xhtml [23:27:31] <clerum> but on any object that somes back it seems to be invoking a toString [23:27:34] <clerum> and using that as the value [23:27:50] <bleathem> https://github.com/richfaces/dev-examples/blob/develop/input-demo/src/main/java/org/richfaces/demo/autocomplete/AutoCompleteBean.java#L93 [23:28:04] <bleathem> the above autocomplete method returns a collection [23:28:26] <bleathem> looks like a collection of CountryBean [23:28:33] *** mateus has quit IRC [23:29:03] <bleathem> clerum: I appreciate your patience, the autocomplete component from RichFaces isn't one I've spent much time with [23:29:20] <clerum> but is the value an instance of Country or is it a string [23:29:35] <Diablo-D3> heh [23:29:44] <clerum> np this is one that has been in the back of my mind for about 2 years [23:29:58] <clerum> I held off on trying to get in fixed in 3 once development of 4 startd [23:30:17] <bleathem> this is definitely the kind of functionality we want to be able to provide [23:30:57] <gastaldi> bleathem: Too late for 4.1.0 ? [23:31:32] <bleathem> gastaldi: I'm still trying to figure out what exactly needs to be different [23:31:47] <gastaldi> clerum: Maybe you should file an issue for posterity [23:31:51] <bleathem> clerum: so it's a list of Country objects [23:32:08] <bleathem> gastaldi: I'm not convinced yet that we can't do this with what we already have [23:32:08] <gastaldi> hum [23:32:12] <gastaldi> ok [23:32:21] <bleathem> clerum: https://github.com/richfaces/dev-examples/blob/develop/input-demo/src/main/java/org/richfaces/demo/CountriesBean.java#L74 [23:33:11] <bleathem> clerum: look at this facelet, where it's dereferncing pojo properties inside the autocomplete: [23:33:12] <bleathem> https://github.com/richfaces/dev-examples/blob/develop/input-demo/src/main/webapp/examples/autocomplete.xhtml#L49 [23:33:55] <gastaldi> seems that already does that [23:33:56] [23:34:45] <bleathem> that's a pretty complex facelet though! holy crow there are a lot of listeners in there [23:35:01] <gastaldi> lol [23:35:28] <bleathem> clerum: is any of this a help? Is it what you are looking for? [23:36:08] <clerum> not really [23:36:23] <clerum> I had a basic example like this setup [23:36:45] <clerum> but the problem is that the value it sends is a toString representation of the value [23:37:09] <clerum> the value that the component submits to the form [23:38:18] <clerum> hmm possible that the converter isn't being used on the values coming back from the autocompleteMethod [23:41:38] <bleathem> so, if the converter was invoked (as one would expect it to be) would that work? [23:43:02] *** sannegrinovero has quit IRC [23:43:19] <clerum> it should [23:43:34] <clerum> it's an entity as a value I'm using the id [23:43:49] <clerum> https://gist.github.com/0090b6e45157cdb40d6e [23:44:06] *** edburns is now known as edburns_away [23:44:48] <clerum> it appears to have passed a toString Represenation to my converter [23:45:33] <clerum> just testing that though [23:45:34] <bleathem> clerum: ok, so if we file a jira, pointing out that the autocomplete does not invoke the converter on the submitted value? [23:45:39] <bleathem> ok [23:45:49] <clerum> is that what is happening? [23:45:54] <bleathem> I don't know [23:45:57] <clerum> it was just a theory on my side [23:46:00] <bleathem> I haven't written any code [23:46:05] *** daniel_hinojosa has quit IRC [23:46:30] <bleathem> I'd just like to nail down the issue as much as possible, then dig into it later when I work in the jira issue [23:46:39] <bleathem> ^work on [23:47:29] <bleathem> clerum: if you could confirm that is what is going on, that would put us miles ahead in terms of finding the solution [23:47:54] *** daniel_hinojosa has joined #seam-dev [23:49:09] <clerum> ok acutally it seems to be sending the string value of that is in the inputbox [23:49:23] <clerum> not even the toString of the value [23:50:07] <clerum> so assuming this https://gist.github.com/e31883f812c97d9a9a14 [23:50:52] <clerum> what gets sent to the converter is _a.name [23:51:16] <clerum> not converted _a [23:52:59] <bleathem> ok, and you believe that to be incorrect behaviour? [23:53:09] *** ssachtleben has joined #seam-dev [23:53:11] <clerum> everything revolves around getting a string value to put in the input field and that is the value that is submitted [23:53:31] <clerum> it may be correct it may just not be desigined to do what I want [23:53:47] *** cbrock has quit IRC [23:53:48] <clerum> might just only be for text [23:54:06] <bleathem> I don't think it would be terribly useful that way [23:54:21] <bleathem> text-only i mean [23:54:42] <clerum> right it has some uses but does ignore using it for making entity associations [23:55:07] <bleathem> is that output text what get's submitted? [23:55:16] <clerum> the fetchValue [23:55:27] <clerum> I think lemmie just double check [23:56:04] <clerum> yeah it's the fetch value that ends up in the inputtext [23:56:22] <bleathem> what if fetchValue is just "_a" ? [23:56:26] <bleathem> does that work? [23:56:31] <clerum> then it is the toString ot _a [23:56:35] <clerum> of _a [23:56:47] <bleathem> and what get's submitted? [23:56:52] <bleathem> the toString value? [23:56:56] <clerum> and the toString of a goes into the inputtext [23:57:14] <clerum> whatever is in the input box gets submitted [23:57:18] <clerum> to the converter [23:57:22] <bleathem> what input text? [23:57:30] <bleathem> one provided by the component? [23:57:36] <bleathem> (I think I'm getting this...) [23:57:40] <clerum> http://richfaces-showcase.appspot.com/richfaces/component-sample.jsf?demo=autocomplete&skin=blueSky [23:57:41] <clerum> yes [23:57:45] <bleathem> so what *does* the converter do then? [23:57:48] <clerum> the one that the component creates on the screen [23:57:51] <ssachtleben> hey question [23:57:56] <bleathem> if you leave the converter out, does it have an effect? [23:58:04] <ssachtleben> do I need to bundle mojarra on as 7 with my webapp? [23:58:08] <clerum> well my converter is expecting an intger id of the _a [23:58:12] <clerum> so it blows up on the string name of it [23:58:15] <bleathem> ssachtleben: mojarra ia included in AS7 [23:58:47] <bleathem> so can we say the converter isn't doing anything? [23:58:54] <clerum> it's being called [23:58:59] <ssachtleben> k thanks [23:59:03] <clerum> the issue is the value of the component [23:59:13] <bleathem> ssachtleben: 2.0.x is the mojarra version [23:59:22] <bleathem> ok [23:59:26] <bleathem> That's fixable [23:59:32] <bleathem> do you mind filing the jira? [23:59:38] <clerum> the value of the component should not be equal to the label if in pojo mode [23:59:42] <gastaldi> bleathem: Have you worked with metawidget before? [23:59:49] <bleathem> gastaldi: not at all [23:59:54] <gastaldi> :(