August 18, 2011  
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31

[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> :(

top