August 11, 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:06] <sbryzak> cool, are those other two issues showstoppers in any way?
[00:00:07] <bleathem> it would be good to get 194 in
[00:00:20] <bleathem> 194 is a showstopper for AS 7 use
[00:00:32] <bleathem> and stuartdouglas provided details of a fix in the jira
[00:00:37] <sbryzak> hmm, any chance of getting it in today?
[00:00:37] <bleathem> so I'd like to see that get in
[00:00:53] <bleathem> sure
[00:01:04] <sbryzak> great, i'll make a note that it's a blocker
[00:01:12] <sbryzak> so after that's done we can push out the release
[00:01:19] <sbryzak> please keep me posted ;)
[00:01:23] <bleathem> you bet
[00:01:37] <sbryzak> thanks
[00:01:39] <sbryzak> ok next
[00:01:53] <sbryzak> international.. ken's not here, but i think we can release a beta
[00:01:59] *** msmigielski has joined #seam-dev
[00:02:05] <sbryzak> i'll confirm with him via e-mail
[00:02:07] <lightguard_jp> Yep
[00:02:38] <sbryzak> next is JCR
[00:02:48] <sbryzak> johnament: i'm pretty sure you asked me for a beta release, right?
[00:03:15] <johnament> sbryzak: yes
[00:03:26] <gastaldi> johnament: I got a question
[00:03:29] <sbryzak> cool, i'll make sure it gets done
[00:03:32] <sbryzak> and how about jms?
[00:04:13] <gastaldi> Why do you use JcrConfiguration on @JcrDao ?
[00:04:49] *** kevinpollet has quit IRC
[00:04:55] <johnament> gastaldi: so that you can choose a session
[00:05:03] <johnament> sbryzak: jms the same, cr1 is out
[00:05:24] <sbryzak> ah that's right, we made it 3.0.0.CR1
[00:05:43] <sbryzak> johnament: did we remove the combined jar in that release?
[00:06:01] <lightguard_jp> I don't think so
[00:06:06] <johnament> sbryzak: yessir
[00:06:12] <lightguard_jp> Oh, cool.
[00:06:17] <sbryzak> great
[00:06:37] <sbryzak> next up is mail
[00:07:00] <sbryzak> clerum: you around?
[00:07:01] <clerum> I need someone to help on that
[00:07:07] <sbryzak> sure, what do you need?
[00:07:27] <clerum> someone to help with writing the docs if not just setting up the base structure so I can add to it
[00:07:40] <clerum> and getting the tests up to the standardized way of doing it
[00:07:45] <gastaldi> shoot, gotta run
[00:07:49] <gastaldi> See ya later
[00:07:54] <lightguard_jp> gastaldi: latre
[00:07:55] <sbryzak> gastaldi: cya
[00:08:05] *** gastaldi has quit IRC
[00:08:09] <sbryzak> clerum: no problem with the tests, that will be done as part of the testing infrastructure overhaul
[00:08:22] <clerum> I can do tasks, but if you leave it up to me at this point it's just not going to get done
[00:08:29] <clerum> I maybe have 2 hours a week I can put it
[00:08:45] <sbryzak> docs should be no problem.. what do you need exactly, someone to write them?
[00:08:52] <sbryzak> or just to set up the empty chapters?
[00:08:57] <clerum> yeah
[00:09:04] <clerum> empty chapters
[00:09:09] <sbryzak> ok that's easy
[00:09:09] <clerum> I've just never used that before
[00:09:17] <clerum> and don't have time to learn the boilerplate
[00:09:17] <sbryzak> tell you what
[00:09:29] <sbryzak> if you can write the docs in plain text
[00:09:35] <sbryzak> or as a google docs document
[00:09:44] <sbryzak> or whatever format you prefer, then i'll convert them to docbook
[00:09:49] <sbryzak> how's that sound?
[00:09:57] <clerum> that works
[00:10:07] <sbryzak> cool.. what would be easiest for you.. google docs?
[00:10:12] *** maschmid has quit IRC
[00:10:19] <mojavelinux> to be honest, the simplest would be markdown
[00:10:20] <mojavelinux> just a text file
[00:10:26] <mojavelinux> just a suggestion
[00:10:31] <mojavelinux> that's how I start all my docs
[00:10:33] <clerum> yeah I can just do a text file
[00:10:35] <sbryzak> google docs makes it easy to drop in images
[00:10:43] <sbryzak> but pick whatever you like cody
[00:10:44] <mojavelinux> well, when I actually have time to write them (hmmm, feeling a bit like a stranger to writing these days)
[00:11:05] <sbryzak> text file is fine
[00:11:20] <sbryzak> and don't be too fussy with grammar/wording
[00:11:25] <clerum> k
[00:11:29] <sbryzak> i'm happy to do some editing if you don't have time
[00:11:36] <clerum> the java docs aren't too bad
[00:11:38] <sbryzak> as long as the content is there
[00:11:43] <sbryzak> cool
[00:11:44] *** johnament has quit IRC
[00:11:45] <clerum> just reference is what is needed
[00:11:58] <sbryzak> sounds good.. how long do you think they would take?
[00:12:20] <sbryzak> i can do the boilerplate stuff like maven dependencies,e tc
[00:12:43] <clerum> week
[00:12:50] <clerum> I'll set myself a deadline of a week
[00:12:55] <sbryzak> no problem
[00:13:06] <sbryzak> code wise, is the mail module ok for a beta release?
[00:13:50] <clerum> I'll review it as I do the doc
[00:13:58] <clerum> but basically
[00:14:03] <clerum> there aren't any outstanding features
[00:14:08] <clerum> that I was holding off putting it
[00:14:09] <clerum> in
[00:14:11] <sbryzak> the beta is this weekend though ;)
[00:14:16] <sbryzak> it can go out without docs
[00:14:21] <sbryzak> as long as the code is ok
[00:14:34] <sbryzak> but this weekend is the last chance to get it into 3.1.0 Seam release
[00:15:05] <sbryzak> let's release it as a beta as is
[00:15:07] <lightguard_jp> We can get docs for the CR1 release.
[00:15:11] <clerum> k
[00:15:13] <sbryzak> and let our users do some testing
[00:15:17] <clerum> sounds good
[00:15:51] <sbryzak> did we say we'd release it as 3.0.0? or 3.1.0?
[00:16:10] <lightguard_jp> 3.0.0
[00:16:26] <sbryzak> what do you guys think about the versioning mismatch
[00:16:35] <sbryzak> do you think we should reconcile them?
[00:16:45] <clerum> I think they are going to drift going forward
[00:16:48] <clerum> no matter want
[00:16:49] <sbryzak> i.e. just make it 3.1.0 even for the new modules?
[00:16:52] <clerum> what
[00:17:08] <clerum> it is possible that a module would have no changes between 3.1 and 3.2
[00:17:19] <sbryzak> true
[00:17:22] <clerum> so we would have to do a new release to just have the version numbers change
[00:17:27] <sbryzak> but for this release, every module has been updated
[00:17:31] <clerum> true
[00:17:53] <sbryzak> and honestly, i find it hard to accept that a module would have no updates made to it in a 6 month period
[00:17:56] <clerum> I think its fine to align, but shouldn't be a requirement
[00:17:59] <clerum> true
[00:18:09] <sbryzak> lightguard_jp mojavelinux: opinions?
[00:18:52] <mojavelinux> if it comes down to it, i'll add the one api that I really want to see, and we'll call that enough of a change :)
[00:19:09] <mojavelinux> having some docs also warrants a version number change...we can at the very least copy the setup from any other module
[00:19:14] <sbryzak> or fix a typo in the javadoc ;)
[00:19:28] <lightguard_jp> That sounds fine.
[00:19:37] <mojavelinux> i told jason I'm very interested in reviewing it anyway...I will try to make that a priority before the week's end
[00:19:48] <sbryzak> ok, then we'll update all the versions to 3.1.0
[00:19:51] <lightguard_jp> For new modules though it seems odd they'd just come up out of the blue at 3.1 or 3.2
[00:20:03] <sbryzak> lightguard_jp: i agree
[00:20:09] <clerum> well 3.0 is just as odd :-)
[00:20:12] <sbryzak> but if you think about it, it's also strange coming out of the blue at 3.0
[00:20:23] <sbryzak> clerum: you beat me ;)
[00:20:30] <mojavelinux> hahaha
[00:20:58] <sbryzak> ok, aligned versions it is then
[00:21:10] <clerum> I went more concise and got it out first
[00:21:11] <sbryzak> someone tell the meeting bott about this decision
[00:21:21] <jose_freitas> I have to go guys
[00:21:33] <jose_freitas> Hope to see you all tomorrow
[00:21:38] <sbryzak> jose_freitas: np, sorry for the extended meeting
[00:21:45] *** jose_freitas has quit IRC
[00:21:53] <sbryzak> ok moving on quickly
[00:22:03] <sbryzak> remoting is ok for a release
[00:22:17] <sbryzak> and i'll do a security release after the hack  night
[00:22:30] <sbryzak> which leaves... reports
[00:22:39] <sbryzak> gastaldi is gone, so i'll ping him later about reports
[00:23:02] <sbryzak> rest and servlet i think will be fine
[00:23:15] <sbryzak> they'll have the combined jars removed at least
[00:23:25] <mojavelinux> cody had a concern about a serialization issue in servlet
[00:23:33] <sbryzak> oh?
[00:23:35] <mojavelinux> has that been resolved (sorry if that is way past)
[00:23:41] <lightguard_jp> #agreed new modules will be aligned with the bundled release to which they belong
[00:23:59] <clerum> thinking of what that was...
[00:24:01] <sbryzak> clerum: is this something that's in jira?
[00:24:17] <clerum> oh
[00:24:26] <lightguard_jp> sbryzak: Reports is still a question ongoing on the mailing list
[00:24:27] <clerum> so the issue was
[00:24:42] <sbryzak> lightguard_jp: wasn't that in regards to seam render?
[00:24:55] <clerum> injecting a RequestParam
[00:24:58] <clerum> http://docs.jboss.org/seam/3/servlet/latest/reference/en-US/html_single/#injectablerefs.request_param
[00:25:18] <lightguard_jp> sbryzak: Yes
[00:25:27] <clerum> causes an issue in a @ConversationScoped bean
[00:25:37] <clerum> because it isn't serializable
[00:25:50] <sbryzak> lightguard_jp: np.. i know i answered that in irc, but i'll respond on seam-dev
[00:26:00] <clerum> but the docs do say that it's only safe cor requestscoped beans
[00:26:02] <sbryzak> clerum: no problem
[00:26:08] <clerum> so it may be ok...just something I ran into
[00:26:31] <sbryzak> ah yes, you have to use Instance
[00:26:33] <mojavelinux> RequestParamProducer needs to be serializable
[00:26:39] <mojavelinux> oh, wait
[00:26:43] <mojavelinux> no, yes, you need to use Instance
[00:26:54] <mojavelinux> otherwise, you would have a problem with scoping
[00:27:32] <clerum> right
[00:27:34] <mojavelinux> k
[00:27:34] <sbryzak> anyone know the current status of the social module?
[00:27:36] <clerum> thats the conclusion I came to
[00:27:47] <clerum> I may create a pull request on thd docs
[00:28:07] <lightguard_jp> I saw some commits earlier
[00:28:10] <clerum> the docs to just make it clearer for newbies and @NormalScoped beans
[00:28:19] <sbryzak> i'll email antoine and check with him
[00:28:40] <lightguard_jp> Yeah, about two hours ago he made some commits
[00:28:51] *** edburns_away is now known as edburns
[00:29:03] <sbryzak> validation and wicket i think should be ok for a release
[00:29:17] <sbryzak> i don't think they've had any substantial changes, just the combined jar removed
[00:29:34] <sbryzak> we need an action item, for all module leads
[00:29:46] <sbryzak> the following versions need to be created in JIRA
[00:29:54] <sbryzak> 3.1.0.Beta1, 3.1.0.CR1 and 3.1.0.Final
[00:30:15] <mojavelinux> actually, I have a major change pending for the wicket module (well, not major, but cool)
[00:30:15] <sbryzak> i'll send that out on seam-dev though as everyone isn't here
[00:30:29] <mojavelinux> I actually coded it in the cdi extensions showcase project, just need to port it over
[00:30:29] <lightguard_jp> #action all modules need to have versions 3.1.0.Beta1, 3.1.0.CR1 and 3.1.0.Final created
[00:30:31] <sbryzak> mojavelinux: will it be done today? :)
[00:30:33] <mojavelinux> but not a showstopper
[00:30:47] <mojavelinux> I could do a pull request tonight
[00:30:51] <mojavelinux> in a few hours
[00:30:55] <mojavelinux> it's pretty straightforward
[00:31:01] <sbryzak> no problem, we'll hold off the release then
[00:31:05] <mojavelinux> just makes initial configuration super simple
[00:31:22] <sbryzak> can you ping me when it's done?
[00:31:35] <mojavelinux> yep
[00:31:38] <sbryzak> cool, thanks
[00:31:47] <sbryzak> i think that covers all the modules, did i miss any?
[00:32:26] <lightguard_jp> nope
[00:32:45] <sbryzak> great
[00:32:57] <sbryzak> mojavelinux: just reading your email - so who is drools management exactly?
[00:33:01] <lightguard_jp> I think that pretty much covers it for the meeting
[00:33:09] <lightguard_jp> Anyone have anything else they'd like to cover?
[00:33:10] <sbryzak> i thought we'd just have to communicate with markp?
[00:33:30] <sbryzak> lightguard_jp: i'm all done for the meeting i think
[00:33:50] <sbryzak> now we have a lot of work to do
[00:33:57] <sbryzak> the security hack night is tomorrow, right?
[00:34:13] <lightguard_jp> #endmeeting
[00:34:16] <lightguard_jp> Thanks for being here everyone.
[00:34:23] *** 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:34:23] <jbott> Meeting ended Wed Aug 10 22:29:33 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[00:34:23] <jbott> Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-08-10-21.00.html
[00:34:23] <jbott> Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-08-10-21.00.txt
[00:34:23] <jbott> Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/seam-dev/2011/seam-dev.2011-08-10-21.00.log.html
[00:36:58] *** msmigielski has quit IRC
[00:37:47] *** msmigielski has joined #seam-dev
[00:44:14] *** edburns is now known as edburns_away
[00:50:39] *** sannegrinovero has quit IRC
[01:04:18] *** msmigielski has quit IRC
[01:09:41] *** lightguard_jp is now known as lightguard_jp_aw
[01:13:16] *** oskutka has quit IRC
[01:30:39] *** rmartinelli has quit IRC
[01:31:26] *** rruss has quit IRC
[01:34:40] *** lazarotti has quit IRC
[01:40:16] *** alesj has quit IRC
[01:43:39] *** hannelita has quit IRC
[01:44:22] *** aslak has quit IRC
[01:57:16] *** bleathem has quit IRC
[02:13:50] *** johnament has joined #seam-dev
[02:16:03] *** bleathem has joined #seam-dev
[02:16:18] <bleathem> ping sbryzak
[02:17:41] <bleathem> sbryzak: doing some jira cleanup for Faces - did anyone ever create issues for the removal of the removal of the combined maven module?
[02:18:25] <johnament> double removal?
[02:18:55] <johnament> bleathem, at least in my modules there was no issue created
[02:18:56] <bleathem> johnament: not double removal, just removal without a having a jira for it
[02:19:22] <bleathem> johnament: I'm going to create an issue then - otherwise it will get left out of the release notes
[02:20:33] *** jamezp is now known as jamezp_afk
[02:22:07] <bleathem> i can't find gastaldi in the list of jira users
[02:24:07] <johnament> hold on
[02:24:09] <johnament> he's there
[02:24:46] <johnament> "George Gastaldi"
[02:27:41] <bleathem> not seeing him
[02:27:55] <bleathem> I wonder if he has to be a developer of my project
[02:28:56] <johnament> am i listed?
[02:29:12] *** tkimura has joined #seam-dev
[02:31:10] <bleathem> johnament: you are perhaps listed in the FBI's 10 most wanted men, but not in the list of people I can assign a Seam Faces jira to.
[02:32:35] <johnament> bleathem, i can assign jcr or jms to pretty much anyone
[02:33:25] <johnament> actually, i think you're right
[02:33:33] <johnament> for redhat employees, its anyone
[02:33:49] <johnament> for outsiders, have to be a programmer.
[02:36:27] <johnament> personally i think all modules leads should be on each others list
[02:36:56] <johnament> anyways gotta run
[02:36:59] *** johnament has quit IRC
[02:42:38] *** mojavelinux has quit IRC
[02:50:26] <jbossbot> git [faces] push develop c6151e6.. Brian Leathem SEAMFACES-194: Removed the Faces ServletContainerInitializer
[02:50:29] <jbossbot> jira [SEAMFACES-194] Both Seam Faces and Mojarra have competing ServetContextInitalizers for adding the faces servlet [Open (Unresolved) Bug, Major, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-194
[02:50:29] <jbossbot> git [faces] push develop URL: http://github.com/seam/faces/compare/678db3a...c6151e6
[02:52:27] *** cbrock has joined #seam-dev
[02:52:27] *** cbrock has quit IRC
[02:52:27] *** cbrock has joined #seam-dev
[02:54:34] <bleathem> ping sbryzak
[02:55:24] <bleathem> sbryzak: Seam Faces is ready for a 3.1.0.Beta1 release.  There are no remaining issues in the jira assigned to that version.
[02:55:40] *** bleathem has quit IRC
[03:51:45] *** hannelita has joined #seam-dev
[03:55:48] *** hannelita has quit IRC
[03:59:52] *** akazakov has quit IRC
[04:28:03] *** jamezp_afk has quit IRC
[04:37:15] *** tsurdilo has quit IRC
[05:02:22] *** mojavelinux has joined #seam-dev
[05:04:26] <sbryzak> lightguard_jp_aw: great work on the module release guide
[05:40:16] *** lincolnthree has joined #seam-dev
[05:41:49] *** lincolnthree has quit IRC
[05:43:58] *** edburns_away is now known as edburns
[06:14:52] *** hannelita has joined #seam-dev
[06:17:44] *** edburns is now known as edburns_away
[06:19:36] *** hannelita has quit IRC
[06:31:00] *** bleathem has joined #seam-dev
[06:59:01] *** lightguard_jp_aw is now known as lightguard_jp
[06:59:04] <lightguard_jp> sbryzak: Thanks
[07:02:38] *** oskutka has joined #seam-dev
[07:03:51] *** jamezp has joined #seam-dev
[07:43:33] *** mojavelinux has quit IRC
[07:54:38] *** gastaldi has joined #seam-dev
[07:54:45] <gastaldi> Hey
[07:55:37] <gastaldi> That exception idea was Nice
[07:56:13] <gastaldi> And make it i18n is a must
[07:58:00] <lightguard_jp> brb, rebbot
[07:58:00] *** gastaldi has quit IRC
[07:59:27] *** shervin_a has joined #seam-dev
[08:00:50] *** tremes has joined #seam-dev
[08:02:48] *** daniel_hinojosa has quit IRC
[08:02:50] *** lightguard_jp has quit IRC
[08:11:48] *** chkal has joined #seam-dev
[08:12:35] *** lightguard_jp has joined #seam-dev
[08:15:23] *** oskutka has quit IRC
[08:26:16] *** jamezp is now known as jamezp_afk
[08:39:41] *** msmigielski has joined #seam-dev
[08:49:42] *** msmigielski has quit IRC
[08:54:01] *** marekn has joined #seam-dev
[08:59:01] *** kpiwko has joined #seam-dev
[09:01:15] *** cbrock has quit IRC
[09:10:15] <lightguard_jp> sbryzak: Doing the Catch release now
[09:10:39] <sbryzak> lightguard_jp: do we need to release the parent/bom first?
[09:10:46] <sbryzak> i also need to do a solder release
[09:10:50] *** marekn has quit IRC
[09:10:58] <lightguard_jp> Snap
[09:11:01] <lightguard_jp> You're right
[09:11:33] <sbryzak> i'd like to have those two solder issues addressed first though
[09:11:41] <sbryzak> let me try to find them
[09:11:45] *** marekn has joined #seam-dev
[09:11:58] <sbryzak> SOLDER-112 and SOLDER-113
[09:12:00] <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
[09:12:00] <jbossbot> jira [SOLDER-113] Generic beans producer annotated with @DefaultBean doesn't work [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-113
[09:13:27] <sbryzak> and i just noticed a typo in a classname, that's bad
[09:13:41] <lightguard_jp> Little late now.
[09:13:41] <sbryzak> org.jboss.seam.solder.bean.generic.AbstactGenericBean
[09:13:47] <sbryzak> we can fix that up
[09:13:56] <sbryzak> not like pete to make a spelling mistake though ;)
[09:13:57] *** oskutka has joined #seam-dev
[09:14:15] <lightguard_jp> That's probably only used in Solder
[09:14:29] <lightguard_jp> I'd be sure to make it a ticket though so it's in release notes.
[09:15:25] <sbryzak> yeah, i'll fix it now
[09:15:38] <sbryzak> i'm not quite sure what the 112 issue is about
[09:16:27] <lightguard_jp> That seems like something would be wrong with Weld if that were the case
[09:18:38] <jbossbot> git [solder] push develop 1c8406c.. Shane Bryzak SOLDER-117
[09:18:39] <jbossbot> jira [SOLDER-117] Typo in class name org.jboss.seam.solder.bean.generic.AbstactGenericBean [Open (Unresolved) Task, Trivial, Shane Bryzak] https://issues.jboss.org/browse/SOLDER-117
[09:18:39] <jbossbot> git [solder] push develop URL: http://github.com/seam/solder/compare/bf2be94...1c8406c
[09:20:23] <sbryzak> ok i think i found the general area
[09:20:29] <sbryzak> org.jboss.seam.solder.bean.defaultbean
[09:20:37] <sbryzak> i suspect the problem is in DefaultBeanExtension
[09:20:47] <sbryzak> one thing we need to do is move the DefaultBean annotation into the api
[09:27:32] *** koentsje has joined #seam-dev
[09:31:13] <sbryzak> stuartdouglas: ping
[09:31:18] <stuartdouglas> sbryzak: pong
[09:31:27] <sbryzak> hey stuart, do you think you could take a look at SOLDER-112?
[09:31:28] <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
[09:32:17] <stuartdouglas> ok
[09:32:40] <sbryzak> pretty sure the issue is in DefaultBeanExtension
[09:32:58] <sbryzak> just trying to get my head around your code ;)
[09:33:15] <sbryzak> looks like the producer methods are scanned around line 200
[09:36:21] <sbryzak> stuartdouglas: and do you agree that the DefaultBean annotation should go into the solder api?
[09:36:28] <stuartdouglas> yes
[09:36:37] <sbryzak> k, i'll move it over
[09:38:42] *** jharting has joined #seam-dev
[09:38:48] <sbryzak> stuartdouglas: so i'm just trying to understand how it works.. does it disable the bean by removing all of its qualifiers?
[09:39:04] <stuartdouglas> no, it disables it by adding a new qualifier
[09:39:21] <sbryzak> ah, Synthetic?
[09:39:34] *** maschmid has joined #seam-dev
[09:39:39] <stuartdouglas> yes
[09:39:53] <sbryzak> got it.. so i'm guessing the same thing needs to happen to the disposer method?
[09:40:56] <stuartdouglas> yes
[09:41:11] <stuartdouglas> the trick is identifying the ones that it needs to happen to
[09:41:40] <stuartdouglas> would it be ok to also require @DefaultBean on the disposer method do you think?
[09:42:13] <sbryzak> hmm, won't the disposer be in the same class?
[09:42:33] <stuartdouglas> yes
[09:42:46] <stuartdouglas> but we also support @DefaultBean on producer methods
[09:43:02] <stuartdouglas> hmm, actually this is not that hard to do
[09:44:45] <sbryzak> yeah, i'm just reading section 3.3.7 of the spec
[09:45:25] <sbryzak> it should be pretty simple to match the correct disposer
[09:46:00] <stuartdouglas> kinda
[09:46:16] <stuartdouglas> you have to basically implement type safe resolution in the extension
[09:46:58] <sbryzak> hmm, a disposer can match multiple producer methods though
[09:47:12] <stuartdouglas> hmm
[09:47:27] <stuartdouglas> that makes things much more complicated
[09:47:43] <sbryzak> ok, let's say that the disposer method requires a @DefaultBean annotation also
[09:48:30] <stuartdouglas> actually we need to do type safe resolution anyway
[09:48:42] <stuartdouglas> to figure out the correct synthetic to use
[09:51:31] <stuartdouglas> actually I don't know if we can support that properly
[09:52:02] <stuartdouglas> I could stop the deployment error
[09:52:14] <stuartdouglas> but then I don't think I can make the disposer method work
[09:52:34] <stuartdouglas> because it may be private, and there is no way to invoke private methods on a proxied instance
[09:52:54] <sbryzak> i'm not sure if i understand the issue correctly
[09:53:00] <sbryzak> does it only manifest if there's another producer?
[09:53:15] <stuartdouglas> no
[09:53:17] <sbryzak> or does it happen whenever there's any disposer method?
[09:53:23] *** aslak has joined #seam-dev
[09:53:29] <stuartdouglas> the issue is that there is not way to actually register a new disposer
[09:53:59] <stuartdouglas> actually never mind, I was wrong
[09:54:13] <stuartdouglas> all the logic needs to go into DefaultProducerMethod.destroy
[09:54:34] <stuartdouglas> hmm, it looks like it actually has the disposer method logic there already
[09:55:59] <sbryzak> i think the issue is the following paragraph from 3.3.7: "If there is no producer method declared by the bean class that is assignable to the disposed parameter of a disposer method,
[09:55:59] <sbryzak> the container automatically detects the problem and treats it as a definition error."
[09:57:13] <sbryzak> so we need to detect whether a disposal method has a matching, enabled producer method/s and if not, disable it
[10:01:11] <stuartdouglas> I am probably not going to get this done till tomorrow
[10:01:43] <sbryzak> we can postpone it for CR1 if you like
[10:01:51] <sbryzak> i wouldn't call it a blocker
[10:16:23] *** tremes has left #seam-dev
[10:17:29] <jbossbot> git [solder] push develop c21fe2c.. Shane Bryzak move DefaultBean annotation to api, fix class name typo
[10:17:29] <jbossbot> git [solder] push develop URL: http://github.com/seam/solder/compare/1c8406c...c21fe2c
[10:17:36] *** aslak has quit IRC
[10:26:57] <jbossbot> git [parent] push master e874e42.. Shane Bryzak [maven-release-plugin] prepare release 12
[10:26:57] <jbossbot> git [parent] push master URL: http://github.com/seam/parent/compare/99b38ce...e874e42
[10:27:02] <jbossbot> git [parent] push 12 URL: http://github.com/seam/parent/compare/0000000...03409a8
[10:27:07] <jbossbot> git [parent] push master ce12c43.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[10:27:07] <jbossbot> git [parent] push master URL: http://github.com/seam/parent/compare/e874e42...ce12c43
[10:33:14] *** alesj has joined #seam-dev
[10:43:57] <sbryzak> is in.relation.to slow for anyone else?
[10:44:10] <sbryzak> or is it just my internet connection...
[10:44:48] <lightguard_jp> It's slow
[10:44:53] <lightguard_jp> kick it
[10:47:54] <sbryzak> will do
[10:50:50] <lightguard_jp> sbryzak: Are we going to do the conf call this week?
[10:51:07] <sbryzak> do we have any items for the agenda?
[10:51:16] *** alesj has quit IRC
[10:52:30] <lightguard_jp> This release and the f2f?
[10:52:33] <sbryzak> the weekly community meetings seem to be covering all of the issues pretty well
[10:52:49] <sbryzak> true, i would like to confirm the f2f details with rodney
[10:52:59] <sbryzak> apparently we have a place booked, according to mike
[10:53:40] <sbryzak> lightguard_jp: have you booked flights already?
[10:53:55] <lightguard_jp> No, not yet.
[10:54:07] <sbryzak> i have.. arriving around 6pm on the sunday
[10:54:13] <lightguard_jp> Was debating to use the new site (assuming I can find it, and I'm in the system) or just book direct.
[10:54:42] <lightguard_jp> We're doing 12 - 16?
[10:55:01] <sbryzak> yes
[10:56:01] <sbryzak> ir2 restarted
[10:56:07] <lightguard_jp> Okay so the in on the 11 and out on the 17 is probably best.
[10:56:12] <sbryzak> it didn't want to cooperate though.. the shutdown didn't work
[10:56:17] <sbryzak> so i had to kill the process
[10:56:25] *** tkimura has quit IRC
[10:56:28] <sbryzak> yep, those dates are best
[10:57:11] <lightguard_jp> Which airport are we going into, or is there only one up there?
[10:57:46] <sbryzak> pretty sure there's just the one
[10:57:46] <jbossbot> git [dist] push master 4736303.. Shane Bryzak update module version numbers, add missing modules, remove/update combined jar artifacts, add hibernate validator, update hhibernate versions
[10:57:46] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/4bed61c...4736303
[11:00:49] <jbossbot> git [compatibility] push develop f01d1b5.. Jozef Hartinger Workaround for ARQ-543
[11:00:50] <jbossbot> jira [ARQ-543] CDI injection into testcase does not work on GlassFish [Resolved (Done) Bug, Blocker, Aslak Knutsen] https://issues.jboss.org/browse/ARQ-543
[11:00:50] <jbossbot> git [compatibility] push develop URL: http://github.com/seam/compatibility/compare/9f3d79b...f01d1b5
[11:11:47] *** aslak has joined #seam-dev
[11:38:01] <lightguard_jp> sbryzak: Do you remember which airport you're flying into?
[11:38:06] <lightguard_jp> It's showing me multiple
[11:38:21] <sbryzak> checking
[11:38:34] <sbryzak> Pearson Intl
[11:38:50] <lightguard_jp> YYZ ?
[11:39:07] <sbryzak> not sure
[11:39:12] <sbryzak> can't see the airport code
[11:39:18] <lightguard_jp> Okay
[11:40:28] <lightguard_jp> Which carrier is getting you there?
[11:40:42] <sbryzak> AA
[11:40:46] <sbryzak> from LAX
[11:41:09] <sbryzak> i hate that airport
[11:48:41] <lightguard_jp> Hm, do I really want to be flying on the 10th anniversary of 9/11?
[12:01:02] <lightguard_jp> sbryzak: Okay, all setup
[12:18:56] *** lightguard_jp has quit IRC
[12:45:16] *** alesj has joined #seam-dev
[13:01:22] *** sannegrinovero has joined #seam-dev
[13:09:24] *** koentsje has quit IRC
[13:23:40] *** msmigielski has joined #seam-dev
[13:28:21] *** jose_freitas has joined #seam-dev
[13:28:40] <jose_freitas> good morning
[13:35:35] *** bleathem has quit IRC
[13:42:34] <maschmid> morning!
[13:54:28] *** alesj has quit IRC
[13:54:30] *** alesj1 has joined #seam-dev
[13:54:46] *** alesj1 is now known as alesj
[14:16:12] *** tsurdilo has joined #seam-dev
[14:23:53] <nickarls> any bean validation wizards around?
[14:36:53] *** rmartinelli has joined #seam-dev
[14:37:50] *** balunasj has joined #seam-dev
[14:37:56] *** alesj has quit IRC
[14:38:13] *** alesj has joined #seam-dev
[14:40:19] *** rruss has joined #seam-dev
[14:44:08] *** bleathem has joined #seam-dev
[14:50:56] *** koentsje has joined #seam-dev
[15:07:16] *** mbg has quit IRC
[15:11:08] *** tsurdilo has quit IRC
[15:13:30] *** lazarotti has joined #seam-dev
[15:17:02] *** chkal has quit IRC
[15:21:11] *** gastaldi has joined #seam-dev
[15:21:34] <gastaldi> morning all !
[15:24:12] *** msmigielski has quit IRC
[15:24:19] *** tsurdilo has joined #seam-dev
[15:27:10] <jose_freitas> hey gastaldi]
[15:27:15] <gastaldi> hey jose_freitas
[15:27:20] <jose_freitas> I'd like to talk to you for a minute
[15:27:23] <jose_freitas> do you have time?
[15:27:25] 
[15:27:26] <gastaldi> ?
[15:27:41] <jose_freitas> do you remember we're talking about then SAF project?
[15:27:47] <gastaldi> yeah
[15:27:59] <jose_freitas> is that an idea of yours? or something that's kinda reality?
[15:28:16] <gastaldi> the SAF exists in Seam 2
[15:28:40] <gastaldi> There are eclipse plugins in JBoss tools to create components like that
[15:29:13] <gastaldi> http://seamframework.org/Community/SeamApplicationFrameworkEntityHomeQueryHome
[15:34:10] <gastaldi> why ? You need something like that "pronto" ?
[15:49:22] *** msmigielski has joined #seam-dev
[15:49:36] *** pmuir has joined #seam-dev
[15:57:03] <jose_freitas> hehehe
[15:57:22] <jose_freitas> no, just would like to get the wire of the idea for seam3
[15:57:27] <jose_freitas> if there's one
[15:58:05] <jose_freitas> I still believe it's unnecessary and kinda retrocess
[15:58:23] <jose_freitas> but it might a reality for seam 3
[15:58:31] <jose_freitas> that's why I ask
[15:59:20] *** mbg has joined #seam-dev
[15:59:25] *** hannelita has joined #seam-dev
[16:01:32] <jose_freitas> might be*
[16:04:34] *** msmigielski has quit IRC
[16:19:39] <gastaldi> no doubt about it
[16:22:12] *** msmigielski has joined #seam-dev
[16:24:34] *** rruss has quit IRC
[16:26:32] *** Diablo-D3 has quit IRC
[16:28:10] *** rruss has joined #seam-dev
[16:34:17] *** alesj has quit IRC
[16:34:28] *** alesj has joined #seam-dev
[16:35:18] *** mgoldmann has quit IRC
[16:37:30] *** oranheim_ has joined #seam-dev
[16:40:23] *** oranheim has quit IRC
[16:40:24] *** oranheim_ is now known as oranheim
[16:47:35] *** jharting has quit IRC
[16:50:31] *** shervin_a has quit IRC
[17:05:19] *** marekn has left #seam-dev
[17:06:15] *** oskutka has quit IRC
[17:12:49] <jbossbot> git [faces] push develop 08cff03.. Brian Leathem Merge branch 'seam-faces' of https://github.com/tremes/seam-faces into tremes-seam-faces
[17:12:49] <jbossbot> git [faces] push develop URL: http://github.com/seam/faces/compare/c6151e6...08cff03
[17:15:05] *** bdlink has joined #seam-dev
[17:15:40] *** edburns_away is now known as edburns
[17:24:25] *** alesj has quit IRC
[17:33:24] *** jamezp_afk is now known as jamezp
[17:44:26] <clerum> is there a proper way to redirect to a new view with a viewparam programatically?
[17:45:12] <clerum> trying to do something like this https://gist.github.com/42f18da14ab469f0b1b0
[17:45:41] <clerum> but on line 38 I navigate to the result but the oid value is dropped
[17:59:35] <gastaldi> There should be a FacesManager somewhere
[18:07:13] *** maschmid has quit IRC
[18:07:33] *** hannelita has quit IRC
[18:15:34] *** lincolnthree has joined #seam-dev
[18:16:12] *** msmigielski has quit IRC
[18:17:46] *** msmigielski has joined #seam-dev
[18:17:52] *** balunasj has quit IRC
[18:18:48] *** lincolnthree has left #seam-dev
[18:19:17] <clerum> FacesManager in jsf2?
[18:21:12] *** lincolnthree has joined #seam-dev
[18:22:52] <gastaldi> Yup, I guess this feature is missing in Seam Facevs
[18:23:25] <lincolnthree> gastaldi: which featuer?
[18:23:31] <gastaldi> FacesManager
[18:23:36] <lincolnthree> which does?
[18:23:41] <gastaldi> redirectToView
[18:23:54] <lincolnthree> as a static?
[18:23:57] <gastaldi> no
[18:24:08] <gastaldi> In Seam 2 you do a @In FacesManager
[18:24:35] <gastaldi> and then you could redirect to another view, with the conversation ID and parameters etc
[18:24:39] <lincolnthree> ah ok
[18:24:46] <lincolnthree> yeah we could use that
[18:24:53] <lincolnthree> it's annoying not to have something like that
[18:25:01] <gastaldi> indeed
[18:27:42] <gastaldi> SEAMFACES-196
[18:27:44] <jbossbot> jira [SEAMFACES-196] Support for FacesManager [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-196
[18:28:24] <gastaldi> Actually in Seam 2 we had a Manager class
[18:28:29] <gastaldi> FacesManager extended it
[18:28:55] <gastaldi> I miss three classes: Manager, Contexts and Component
[18:29:16] <gastaldi> Everything could be done with these classes
[18:30:33] 
[18:30:55] <gastaldi> I really miss these features from Seam 2
[18:44:23] <gastaldi> bleathem: you there ?
[18:44:39] *** akazakov has joined #seam-dev
[18:44:42] <bleathem> yes
[18:44:45] <bleathem> kind of
[18:45:00] <gastaldi> :)
[18:45:13] <bleathem> sounds like I can expect a pull request from you shortly :)
[18:45:24] <gastaldi> :)
[18:45:38] <gastaldi> just want to know your thoughts about it
[18:45:42] *** kpiwko has quit IRC
[18:46:41] <bleathem> sounds like a good idea.
[18:46:54] <bleathem> But the Seam Faces jira is full of good ideas!
[18:47:36] <bleathem> lately progress in Faces has been made by community members contributing features that are important to them
[18:48:25] <gastaldi> Glad you assigned RF-10882 to yourself :)
[18:48:27] <jbossbot> jira [RF-10882] Upgrade jQuery to latest version [Open (Unresolved) Task, Critical, Brian Leathem] https://issues.jboss.org/browse/RF-10882
[18:48:52] <bleathem> like chkal recently added a bunch of fixes for MyFaces, and is working on a @ProductionStage CDI extension
[18:49:43] <bleathem> so if this particular feature would help you out, I'd really recommend you write it - it's the only way it will get done at this point
[18:50:04] <bleathem> yeah, jQuery upgrade *has* to happen this release, or we risk falling behind
[18:50:21] <gastaldi> cool
[18:54:58] *** hannelita has joined #seam-dev
[18:55:23] *** lightguard_jp has joined #seam-dev
[18:55:55] <gastaldi> hey lightguard_jp
[18:56:07] <lightguard_jp> Hey George
[18:57:00] <bleathem> ooh, early start for you today lightguard_jp!
[18:57:15] <lightguard_jp> Too early for a very late date
[18:57:17] <lightguard_jp> day
[18:57:21] <lightguard_jp> bleh
[18:57:26] <gastaldi> What do you guys think of having an @Inject @Faces Manager manager; ?
[18:57:35] <gastaldi> Or @Inject FacesManager manager ?
[18:57:40] <lightguard_jp> Went to bed seven hours ago, woke up two hours ago.
[18:57:50] <gastaldi> wow
[18:57:52] <lightguard_jp> What is a Manager
[18:57:54] <lightguard_jp> ?
[18:58:04] <gastaldi>  SEAMFACES-196
[18:58:04] <bleathem> lightguard_jp: the guy who signs your paycheck
[18:58:05] <jbossbot> jira [SEAMFACES-196] Support for FacesManager [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-196
[18:58:14] <gastaldi> lol
[18:59:02] <lightguard_jp> bleathem: rruss doesn't sign my paycheck :)
[18:59:21] <lightguard_jp> He may approve it though :)
[19:00:00] *** msmigielski has quit IRC
[19:00:21] * rruss takes notes for later
[19:00:38] <gastaldi> lol, busted !
[19:01:13] <bleathem> lol
[19:02:51] <gastaldi> hummm we should really have the Contexts class in Seam 3 :)
[19:03:02] <gastaldi> Dunno how to make it work under CDI
[19:06:07] <lightguard_jp> Oh, rruss was here??
[19:06:09] <lightguard_jp> Crap
[19:06:13] <gastaldi> hehe
[19:06:28] <gastaldi> doh
[19:08:40] <gastaldi> Is it a good idea to upgrade org.jboss.seam.framework in a new module ?
[19:09:15] <gastaldi> Like, the Controller, EntityHome, EntityQuery classes
[19:09:34] <lightguard_jp> They probably belong in persistence.
[19:09:39] <gastaldi> humm
[19:09:45] <gastaldi> yeah, guess so
[19:09:45] <lightguard_jp> But they could possibly be used in JCR as well
[19:10:02] 
[19:10:06] <gastaldi> There are subclasses of it as well
[19:10:41] <lightguard_jp> I don't know if there's a whole lot of value in massively deep hierarchy we had in Seam 2
[19:10:50] <lightguard_jp> I'd prefer composition
[19:11:04] <gastaldi> Yeah, me too
[19:11:13] <jbossbot> git [core] push master 366378e.. Lincoln Baxter, III Added forge icons
[19:11:14] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/bbd377a...366378e
[19:11:33] <gastaldi> But at least the concept is there
[19:12:00] <gastaldi> I mean, there are some directions to take on a Seam 3 app
[19:13:17] 
[19:16:19] *** flashboss1 has quit IRC
[19:17:37] <lightguard_jp> perhaps. Probably get more input on the mailing list from people who have used both
[19:17:55] <lightguard_jp> I think there's also a thread on the forums
[19:18:07] *** sannegrinovero has quit IRC
[19:18:16] <jbossbot> git [core] push master 5558504.. Lincoln Baxter, III Updated module names
[19:18:16] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/366378e...5558504
[19:21:47] <lightguard_jp> lincolnthree: I'm guessing the forge plugin isn't pulling in transactions? http://seamframework.org/Community/SeamForge
[19:22:41] <lincolnthree> does persistence not pull in transactions?
[19:24:35] <lightguard_jp> thought it did, but not sure
[19:26:12] *** igels_ has joined #seam-dev
[19:27:05] *** bobmcw_ has joined #seam-dev
[19:28:33] <lincolnthree> lightguard_jp: i just went through this guide yesterday
[19:29:00] <lincolnthree> https://docs.jboss.org/author/display/SEAMFORGE/Home
[19:30:09] *** tsurdilo1 has joined #seam-dev
[19:32:17] <lightguard_jp> lincolnthree: No, it does not pull in transaction, that'll need to be fixed
[19:32:19] *** jbossbot has quit IRC
[19:32:19] *** akazakov has quit IRC
[19:32:21] *** tsurdilo has quit IRC
[19:32:35] <lincolnthree> fixed where?
[19:34:01] <lightguard_jp> in the persistence pom
[19:34:35] <gastaldi> Is there a Expressions class in Seam 3 ?
[19:35:30] <clerum> gastaldi: do you know if it is possible to do what I want to do currently?
[19:35:49] <clerum> redirect to a view and with a ?oid=blah
[19:35:59] <jose_freitas> gastaldi, you mean for eL or regular expressions?
[19:36:07] <gastaldi> jose_freitas: EL
[19:36:17] <gastaldi> clerum: Have you tried a response.sendRedirect ? :)
[19:36:18] <jose_freitas> nope,
[19:36:36] <jose_freitas> I believe it's use default EL
[19:36:40] <jose_freitas> but I'm not sure
[19:38:42] <lightguard_jp> gastaldi: Currently yes, just use the default EL
[19:39:01] <lightguard_jp> If you want an easy way to get it, just create a request scoped producer
[19:40:14] <gastaldi> I thought of adding org.jboss.seam.core.Interpolator to org.jboss.seam.solder.messages
[19:40:34] <gastaldi> in order to interpolate EL expressions in Strings
[19:40:48] <lightguard_jp> Wasn't that a ticket, or discussed on the mailing list?
[19:41:31] *** koentsje has quit IRC
[19:41:32] <gastaldi> dunno :P
[19:41:55] <gastaldi> SEAMINTL-16
[19:42:16] *** daniel_hinojosa has joined #seam-dev
[19:42:28] <gastaldi> hum
[19:42:32] <gastaldi> Where is the bot ? :P
[19:45:43] <bleathem> jbott: ping
[19:45:44] <jbott> pong
[19:45:48] <clerum> gastaldi: so very close expect it is missing the root of the url  localhost:8080/admin/blah.xhtml?oid=3 vs localhost:8080/woo/admin/blah.xhtml
[19:47:29] <gastaldi> clerum: Add the Context path
[19:47:29] <clerum> ah request.getContextPath
[19:47:33] <gastaldi> yeah
[19:47:46] <gastaldi> jbott: ping
[19:47:46] <jbott> pong
[19:47:51] <clerum> yeah that would be handy to have in a FacesManager or something
[19:47:53] <gastaldi> SEAMINTL-16
[19:48:00] <gastaldi> :P
[19:48:03] <clerum> starting to apperciate all the little things from seam 2 more
[19:48:18] <gastaldi> Yeah, It wil surely be missed
[19:48:22] <gastaldi> will
[19:49:20] <clerum> has seam 2 code made it to github yet?
[19:50:50] <lightguard_jp> clerum: No
[19:50:55] <lightguard_jp> It'll probably stay in svn
[19:51:34] <clerum> k just thinkiing a mirror would be nice on github...handy for source browsing but no biggie
[19:53:22] *** mojavelinux has joined #seam-dev
[19:53:31] <lightguard_jp> mojavelinux: Afternoon
[19:53:50] <lightguard_jp> mojavelinux: You were up almost as late as I was. Reading late?
[19:56:03] <lincolnthree> http://vimeo.com/27534958
[19:57:22] <bleathem> that's wesley hales in the bunny outfit
[19:57:25] <clerum> was thinking about SEAMFACES-6
[19:57:33] *** rruss has quit IRC
[19:57:41] <clerum> https://issues.jboss.org/browse/SEAMFACES-6
[19:57:49] *** ChanServ sets mode: +o lightguard_jp
[19:57:51] *** lightguard_jp sets mode: -o jbott
[19:58:19] <clerum> if you had a list of all the @Named beans could you determine if there is an instance in a particular scope without triggering the production of a bean
[19:58:46] <lightguard_jp> clerum: Types would be better
[20:00:01] <clerum> well...since you are inspecting from  the EL perspecitve wouldn you want name
[20:00:12] <clerum> since you could have multple names for the same type
[20:00:35] <lightguard_jp> But you can't query the BeanManager based on qualifers (I don't think)
[20:00:42] <jose_freitas> where's jbbott?
[20:00:49] *** lightguard_jp sets mode: -o lightguard_jp
[20:01:01] <jose_freitas> doh
[20:01:16] <lightguard_jp> Seems to be a bit broken today
[20:02:07] <clerum> I guess the mail thing I'm wondering is it possible to inspect a scope for a given name or type to see if a bean already exists
[20:02:35] <clerum> and get that bean, but not trigger the production of a new bean to satisify if it doesn't exist
[20:02:36] *** jbossbot has joined #seam-dev
[20:03:16] <lightguard_jp> Hm
[20:03:25] <jose_freitas> :)
[20:03:59] <jamezp> gastaldi: I think jbossbot is back SEAMINTL-16
[20:04:00] <jbossbot> jira [SEAMINTL-16] Implement an interpolator for strings containing expressions [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/SEAMINTL-16
[20:04:11] <lightguard_jp> Oh, guess I was wrong
[20:04:12] <clerum> like in seam 2 we are able to see what beans are in the conversation scope for a particular conversation
[20:04:27] <clerum> but I don't see how to do that with beanmanager
[20:04:54] <lightguard_jp> BeanManager.getBeans(String)
[20:05:08] <lightguard_jp> Gives you a Set<Bean<?>>
[20:06:12] <clerum> but are those active or ones that could be produced
[20:06:40] <clerum> for debugging we only want ones that have already been created
[20:09:06] <lightguard_jp> They're enabled
[20:09:13] <jose_freitas> clerum: last time we talked about seamfaces-6, we mention something like reading the annotations from the class
[20:09:29] <jose_freitas> on that ocasion we'd read annotations looking for @Named
[20:09:30] <lightguard_jp> A bean is said to be enabled if:
[20:09:32] <lightguard_jp> it is deployed in a bean archive, and
[20:09:34] <lightguard_jp> it is not a producer method or field of a disabled bean, and
[20:09:36] <lightguard_jp> it is not specialized by any other enabled bean, and either
[20:09:40] <jose_freitas> but we could look for the @...scoped too
[20:09:40] <lightguard_jp> it is not an alternative, or it is a selected alternative of at least one bean archive.
[20:09:42] <lightguard_jp> clerum: ^^
[20:10:11] <clerum>  jose_freitas: right so that we could have a list of all the @Named beans
[20:10:25] <jose_freitas> yes, at least that's what I remember
[20:10:40] <clerum> but at the point where you want to inspect and see what active beans are in the conversation scope for this conversation
[20:11:01] <jose_freitas> bleathem: do you remember what class use this research on class for its annotations?
[20:11:13] <jose_freitas> clerum: ahn
[20:11:16] <clerum> not beans valid to be produced
[20:11:16] <jose_freitas> true
[20:11:23] <clerum> but ones that have acutally been produced
[20:11:35] <jose_freitas> yeah
[20:11:38] <clerum> because you are going to want to inspect the values on the existing bean...just like in seam 2
[20:11:55] <bleathem> jose_freitas: it would be a CDI extension
[20:13:16] <bleathem> We would write a CDI extension that would store all @Named beans, to be displayed later in a debug "popup"
[20:13:26] <bleathem> filtering out those that are not active
[20:13:34] <bleathem> does that sound like what we talked about before?
[20:13:40] <jose_freitas> eyah
[20:13:53] <clerum> yes..but how do we query if a bean is active in a particual scope?
[20:14:04] <bleathem> ask the bean manager that
[20:14:15] <bleathem> SEAMFACES-6
[20:14:16] <jbossbot> jira [SEAMFACES-6] s:debug [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-6
[20:14:41] <bleathem> hmmm, would have been nice if I updated the jira with our last conversation on this
[20:14:43] <clerum> isn't that going to produced a new instance of the bean if it isn't active?
[20:14:54] <bleathem> we have to make sure we don't do that
[20:15:53] <bleathem> reviewing the log:
[20:15:53] <bleathem> http://echelog.matzon.dk/logs/browse/seam-dev/1308002400
[20:17:38] <bleathem> [17:51:28] <jose_freitas> beanManager has public List<Bean<?>> getBeans()
[20:17:38] <bleathem> [17:51:34] <jose_freitas> that returns all resolvable beans
[20:17:38] <bleathem> [17:51:54] <jose_freitas> we might filter that list on our class
[20:17:38] <bleathem> [17:52:36] <jose_freitas> ir returns all those beans registered with the Web Bean manager which are resolvable and does not include interceptor and decorator beans
[20:17:38] <bleathem> [17:53:44] <jose_freitas> and Bean class have a public String getName() that Obtains the {@linkplain javax.enterprise.inject EL name} of a bean, if it has one.
[20:19:02] <bleathem> So, for SEAMFACEs-6 we need to write a CDI extension that collects all @Named classes
[20:20:12] <jose_freitas> I think that method is just for weld implementation
[20:20:31] <bleathem> that's ok, we don't need it I think
[20:20:52] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/1a7ed20...f206077
[20:20:59] <jose_freitas> :)
[20:21:08] <clerum> OK so that gets our list
[20:21:08] <bleathem> It's just a matter of looping thorugh the @Named classes stored in the Extension, and qurying the BeanManager to see if they are active
[20:21:26] * bleathem looking at the BeanManager and Solder APIs
[20:21:30] <clerum> OK thats what I'm missing. What method on the bean manager allows us to query for active beans without producing
[20:21:48] <clerum> aussming we have a list of all the possible beans we are looking for
[20:22:31] <clerum> I'm worried we might need a spec change before we can do this...but I'm probably missing something
[20:23:05] <bleathem> lightguard_jp: ping
[20:23:28] *** sannegrinovero has joined #seam-dev
[20:23:38] <bleathem> lightguard_jp: how can we ask the BenManager is a particular class has a currently active contextual instance?
[20:23:52] <bleathem> or maybe gastaldi would know ^^
[20:24:48] <jbossbot> git [core] push 1.0.0.Beta1 URL: http://github.com/forge/core/compare/0000000...f9569d9
[20:24:49] <jbossbot> git [core] push master bbe5fb7.. Lincoln Baxter, III [maven-release-plugin] prepare release 1.0.0.Beta1
[20:24:49] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/f206077...bbe5fb7
[20:24:53] <jbossbot> git [core] push master 9d4d361.. Lincoln Baxter, III [maven-release-plugin] prepare for next development iteration
[20:24:54] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/bbe5fb7...9d4d361
[20:25:47] <bleathem> or maybe mojavelinux can tell us how to ask the BenManager is a particular class has a currently active contextual instance?
[20:26:30] <mojavelinux> thinking...
[20:27:10] <mojavelinux> three step process
[20:27:29] <mojavelinux> first, get a reference to the Bean (the Contextual) <- the thing you are inquiring about
[20:27:41] <mojavelinux> then get it's scope...and get the context for that scope
[20:27:58] <mojavelinux> then ask the context if it has an instance of that contextual (Context#get(Contextual))
[20:28:05] <mojavelinux> sounds like a most excellent utility method for Solder
[20:28:56] <mojavelinux> the api calls you need are
[20:28:57] <bleathem> might that first request to get a reference to the bean end up creating an instance?
[20:29:21] <bleathem> so that when we ask is it has an instance, it always will since it was created in the first step?
[20:29:35] <mojavelinux> Object o = beanManager.getContext(bean.getScope()).get(bean);
[20:29:39] <mojavelinux> null if there is no instance
[20:29:54] <mojavelinux> no, Context#get() will not create
[20:30:07] <mojavelinux> get(Contextual<T> contextual)
[20:30:07] <mojavelinux>           Return an existing instance of a certain contextual type or a null value.
[20:30:21] <mojavelinux> the docs sort of suck there...it should say "a null value if there is no instance"
[20:30:32] <bleathem> cool
[20:30:47] <clerum> cool. as long as it returns a null there we should be golden
[20:30:51] *** flashboss has joined #seam-dev
[20:30:56] <mojavelinux> the utility method for that should perhaps be getIfInstanceExists(Contextual)
[20:31:08] <bleathem> we'll just have to loop through the known scope types
[20:31:14] <mojavelinux> though, clearly this would be insanely useful if it were on Instance
[20:31:25] <mojavelinux> at one point we discussed subclassing Instance in Solder, not sure if that happened
[20:31:30] <bleathem> would be nice to provide an extension point, so one could add custom scopt type to the debug display
[20:31:35] <clerum> and each conversation id for conversation right?
[20:31:43] <mojavelinux> why loop through the known scope types?
[20:31:47] <mojavelinux> the bean knows it's scope
[20:31:53] <mojavelinux> s/it's/its/
[20:31:54] <bleathem> right
[20:32:02] <bleathem> and we are looping through all the @Named beans
[20:32:15] <bleathem> ok, I'll summarize in jira
[20:32:27] <mojavelinux> super
[20:32:27] <clerum> so we won't be able to see @RequestScoped
[20:32:45] <jose_freitas> :)
[20:32:47] <bleathem> clerum: why not?
[20:32:54] <mojavelinux> not sure I understand clerum, could you expand?
[20:33:36] <clerum> well if this is something we trigger as an ajax call on an already rendered page won't they have already been destroyed
[20:34:17] <bleathem> we'll just have to make sure we do this looping last minute at render time, to catch all beans activated throughout the lifecycle
[20:34:20] <clerum> anything below @RenderScoped
[20:34:28] <bleathem> and update the debug output on every ajax call
[20:34:52] <clerum> ok so if the debug component is rendered=true on the page
[20:35:05] <bleathem> right
[20:35:06] <clerum> then you generate it's output  and it's just in a hidden dive
[20:35:11] <clerum> div
[20:35:24] <clerum> that works
[20:35:25] <bleathem> maybe use a c:if insead
[20:35:33] <bleathem> so it's not added to the component tree
[20:35:38] <bleathem> if not requested
[20:35:44] <clerum> sure
[20:36:06] <bleathem> also, all this should be disabled if the project stage is not development
[20:36:34] <bleathem> this is a 2nd CDI extension in the same week with a requirement to determine the production stage (before JSF has started)
[20:36:35] <clerum> is it something that you could enable on a production project?
[20:36:42] <clerum> at runtime
[20:36:52] <bleathem> hmmm
[20:36:55] <clerum> the only cost is going to be grabbing the list of @Named beans at boot
[20:37:18] <bleathem> I don't really like the idea of having an unecessary memory footprint with all @Named classes hanging around at production time
[20:37:54] <bleathem> maybe default to "off" in production mode, with a capability to override that behaviour in Seam Config
[20:37:59] <bleathem> or something like that
[20:38:06] <clerum> Would be nice if it was optional. but diabled by default
[20:38:09] <clerum> right.
[20:39:07] <clerum> a few hundered named beans references should be tiny and the ability to throw a switch on a production system to inspect is something a of people would probably like
[20:40:51] <clerum> link added to jira for irc log
[20:41:43] *** msmigielski has joined #seam-dev
[20:43:37] <bleathem> still missing something here
[20:43:59] <bleathem> how do we get from the Class (stored in the extension) to the Context?
[20:44:20] <lightguard_jp> You store the bean, not the class.
[20:44:29] <bleathem> but the bean is an instance
[20:44:44] <bleathem> at the time the Extension runs, there are no instances
[20:44:46] <lightguard_jp> No it isn't
[20:44:51] <bleathem> it's not?
[20:44:55] <lightguard_jp> Bean?
[20:44:59] <bleathem> yeah
[20:45:04] <bleathem> what is the Bean then?
[20:45:04] <lightguard_jp> It's the container for the meta data.
[20:45:12] <bleathem> what class is it?
[20:45:16] <lightguard_jp> Bean
[20:45:26] <bleathem> this is new to me :P
[20:45:37] <lightguard_jp> javax.enterprise.inject.spi.Bean
[20:45:51] <bleathem> looking now
[20:45:55] <bleathem> http://download.oracle.com/javaee/6/api/javax/enterprise/inject/spi/Bean.html
[20:45:59] <bleathem> for those following along
[20:46:27] <bleathem> so you can get Extension would store the Bean, rather than the class
[20:46:49] <bleathem> and then we can invoke getScope on the Bean
[20:46:55] <bleathem> which we use to get the Context
[20:47:07] <bleathem> and ask the Context if there is are any instances
[20:47:11] <bleathem> or "an instance"
[20:47:27] <lightguard_jp> Yep
[20:48:46] *** koentsje has joined #seam-dev
[20:49:43] *** msmigielski has quit IRC
[20:49:54] <lincolnthree> Please retweet! http://twitter.com/#!/lincolnthree/status/101725675945336832
[20:50:06] *** gastaldi has quit IRC
[20:50:52] *** tremes has joined #seam-dev
[20:51:11] *** tremes has left #seam-dev
[20:52:10] <clerum> so something like this for FacesManager?
[20:52:10] <clerum> https://gist.github.com/7b3db37172cf2ff1173b
[20:52:16] *** msmigielski has joined #seam-dev
[20:53:16] <bleathem> Ok, I updated SEAMFACES-6 with a summary of the conversation
[20:53:17] <jbossbot> jira [SEAMFACES-6] s:debug [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-6
[20:53:48] <bleathem> clerum: that looks good for the FacesManager, although I am not familiar with what was available in Seam 2.
[20:54:19] <clerum> http://docs.jboss.org/seam/2.2.2.Final/api/org/jboss/seam/faces/FacesManager.html
[20:54:54] *** bleathem is now known as bleathem_away
[20:55:49] <clerum> you could extend it with some options to end the conversation and what not
[20:56:02] <clerum> or to include the current cid I guess
[20:57:55] *** msmigielski has quit IRC
[21:00:15] <edburns> I am happy to report that I have successfully published jsf api 2.2-SNAPSHOT to the java.net maven repo by sonatype: https://maven.java.net/content/repositories/snapshots/javax/faces/javax.faces-api/2.2-SNAPSHOT/
[21:01:08] <bleathem_away> edburns: cool!
[21:01:29] <jose_freitas> great edburns! with sources and javadoc!
[21:01:37] <jose_freitas> thanks!
[21:01:44] <edburns> it's just a snapshot, mind you.
[21:01:57] <jose_freitas> :)
[21:02:03] <edburns> bleathem_away: Also, I have good news to report: 758 is making good progress.
[21:02:15] <edburns> Once I get this maven nonsense done, I'll be sending a mail to the EG about it.
[21:02:20] <bleathem_away> edburns: this is great
[21:02:31] <bleathem_away> edburns: I look forward to reading that
[21:02:38] *** bleathem_away is now known as bleathem
[21:03:00] <edburns> bleathem: I've made it simpler than it is in seam faces because I can make spec requirements to the nav handler.
[21:03:33] <bleathem> edburns: I can imagine - there is much room for simplification there, with apprporiate spec changes
[21:04:00] *** jamezp is now known as jamezp_afk
[21:04:07] <bleathem> edburns: which reminds me, I have to follow-up to determine if I am actually representing RedHat on the JSF EG now
[21:04:27] <edburns> bleathem: I'll need your help to ensure I've simplified it as much as possible!
[21:04:44] <bleathem> edburns: looking forward to it
[21:05:13] <clerum> edburns: does this mean that this is in the 2.2 snapshot? http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-479
[21:06:17] <edburns> clerum: That's not done yet, it's not in there yet.
[21:06:32] <clerum> gottcha. wasn't sure what the snapshot comment meant
[21:06:33] <clerum> thanks
[21:08:07] *** daniel_hinojosa has quit IRC
[21:08:09] *** sannegrinovero has quit IRC
[21:10:13] *** msmigielski has joined #seam-dev
[21:10:38] *** daniel_hinojosa has joined #seam-dev
[21:13:05] *** sannegrinovero has joined #seam-dev
[21:37:04] <clerum> bleathem: thinking this may work better
[21:37:10] <clerum> https://gist.github.com/7ee371983f30981fc960
[21:37:48] <clerum> So you can call like this
[21:37:48] <clerum> facesManager.viewId("/admin/user.xhtml").addParam("oid", 1).endConversation().redirect();
[21:38:30] <clerum> thoughts?
[21:38:38] <bleathem> and what's the use case for this?
[21:39:25] <clerum> https://gist.github.com/6ec91f795e272a8ab6c3
[21:39:33] <clerum> so for me I have a global search bar in my app
[21:39:56] <clerum> and if I only match on exactly one result I want to redirect to the view page for that entity
[21:40:29] <clerum> err refresh that
[21:41:03] <bleathem> looks good to me
[21:41:10] <clerum> so I need to be able to end the current conversation if there is one, and redirect to a specifc viewid and pass a param
[21:41:25] <bleathem> and this behaviour is consistent with what people expect of the FacesManager from Seam 2?
[21:41:48] <clerum> thats what it looks like to me
[21:42:02] <clerum> I think it could be expanded on
[21:42:14] <clerum> maybe to begin the conversation before redirecting
[21:42:22] <clerum> among other things
[21:42:26] <clerum> but I think it's a good start
[21:42:48] <bleathem> If you're happy with it the way it is, can you file a jira and issue a pull request?
[21:43:22] *** rruss has joined #seam-dev
[21:43:25] <clerum> yeah I think I'll bounce it off gastaldi as he was thinking it would be nice too
[21:43:40] <clerum> then I'll get a pull request and we can go from there
[21:43:46] <bleathem> cool
[21:44:00] <bleathem> just make sure there is a jira, so it doesn't get lost in the release notes
[21:44:24] <bleathem> And if you want to add something to the docs about it, you'll be my hero!
[21:44:34] <clerum> https://issues.jboss.org/browse/SEAMFACES-196
[21:44:36] <jbossbot> jira [SEAMFACES-196] Support for FacesManager [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-196
[21:44:43] <bleathem> but that *is* asking a lot :D
[21:44:47] <clerum> gastaldi opened it this am
[21:44:48] <clerum> will do
[21:44:52] <bleathem> cool
[21:45:06] <bleathem> thanks for getting the ball rolling on this
[21:45:17] <clerum> np, it was something that I needed anyway
[21:49:25] <clerum> bleathem: where would you stick that class?
[21:49:35] <bleathem> which one?
[21:49:45] <clerum> https://github.com/seam/faces/tree/develop/impl/src/main/java/org/jboss/seam/faces/util
[21:49:49] <clerum> FacesManager
[21:50:10] <clerum> dunno which package it should go in
[21:50:26] <clerum> https://github.com/seam/faces/tree/develop/impl/src/main/java/org/jboss/seam/faces/navigation ?
[21:57:07] *** igels_ has quit IRC
[21:57:31] *** akazakov has joined #seam-dev
[22:04:31] <bleathem> oh, sorry
[22:04:41] <bleathem> I read "where did" not "where should"
[22:04:45] <bleathem> err would
[22:04:50] <bleathem> 1 sec, let me have a peak
[22:05:02] <clerum> ah
[22:13:37] *** jamezp_afk is now known as jamezp
[22:16:10] *** alesj has joined #seam-dev
[22:19:31] *** bleathem has quit IRC
[22:23:03] *** maschmid has joined #seam-dev
[22:24:37] <lightguard_jp> lincolnthree: Do I need anything in this file in an EE6 app? I wouldn't think so, but I have it in there for some reason. https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/webapp/WEB-INF/web.xml
[22:27:37] <mojavelinux> you probably have it to set the faces development stage
[22:27:47] <mojavelinux> anyway that can be set w/o web.xml ... seam faces feature?
[22:29:17] <lightguard_jp> It can be set in JNDI
[22:29:23] <lightguard_jp> and there may be one other place to set it.
[22:29:37] <lightguard_jp> I didn't think I needed the faces servlet in there.
[22:34:04] <lightguard_jp> Okay, who's bug is this? https://pastee.org/pedbm
[22:34:12] <lightguard_jp> I commented out everything in that web.xml
[22:34:20] <lightguard_jp> And got this when I tried to access the app
[22:34:36] <nickarls> jp: AS7?
[22:34:42] <lightguard_jp> yep
[22:34:46] <nickarls> jp: faces ;-)
[22:34:59] <lightguard_jp> It's either JSF or PrettyFaces
[22:35:45] <nickarls> jp: do you have seam faces in use?
[22:36:04] <lightguard_jp> Yep
[22:36:20] <nickarls> brian only recently removed an extra listener that was causing problems
[22:36:50] <lightguard_jp> Issue number?
[22:37:16] *** tsurdilo1 has quit IRC
[22:37:21] <nickarls> SEAMFACES-194
[22:37:22] <jbossbot> jira [SEAMFACES-194] Both Seam Faces and Mojarra have competing ServetContextInitalizers for adding the faces servlet [Resolved (Done) Bug, Major, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-194
[22:38:16] <lightguard_jp> Use 3.1.0.Beta1-SNAPSHOT then?
[22:38:17] *** tsurdilo has joined #seam-dev
[22:38:40] <nickarls> I would believe so, yes
[22:38:58] <lightguard_jp> Okay, I'll give it a try.
[22:39:14] <nickarls> re-deploying a couple of times also helps sometimes...
[22:40:40] <lightguard_jp> I'll try the new version anyway.
[22:40:52] <lightguard_jp> What I'm writting will be targeted for Seam 3.1 anyway
[22:41:41] <lightguard_jp> We have to get our versioning correct
[22:42:00] <lightguard_jp> IMO it should be 3.x.y.m-SNAPSHOT not 3.x.y-SNAPSHOT
[22:53:29] *** bobmcw_ has quit IRC
[22:53:42] <lightguard_jp> I must be too tired to figure this out, why does the impl of faces depend on the 3.0.0.Final API when I build develop?
[22:57:05] *** clerum_ has joined #seam-dev
[22:58:04] <clerum_> first time working with git flow. if I clone the the persistence repo do I need to run git flow init ?
[22:58:21] <clerum_> for is that only done the very first time to the repo?
[22:58:25] <clerum_> or is that
[22:59:23] <lightguard_jp> No, you'll need to do it.
[22:59:36] <lightguard_jp> It's local to that repo (not remotes)
[22:59:59] <clerum_> so branch name for production release?
[23:00:02] <clerum_> just master?
[23:00:10] <clerum_> or is there a doc outlining this?
[23:01:30] <lightguard_jp> It's in the contrib docs
[23:01:37] <clerum_> k
[23:01:48] *** maschmid has quit IRC
[23:01:53] <clerum_> so if I was going to correct some typos in docs I would go
[23:02:01] <clerum_> git flow feature start docFixes
[23:02:07] <clerum_> something like that?
[23:02:19] <lightguard_jp> Yep
[23:02:27] <clerum_> cool I'll give it a whril
[23:09:05] <hannelita> lightguard_jp: Hi! Is confbuzz app working with 3.1.0.Beta1-SNAPSHOT faces version?
[23:10:19] <hannelita> lightguard_jp: I did tons of workarounds to have it working here with the last version
[23:10:42] <lightguard_jp> No
[23:11:03] <lightguard_jp> I have compilation issues, then when I look at the API version it's 3.0.0.Final
[23:11:11] <lightguard_jp> Still trying to figure out what's going on
[23:13:54] <lincolnthree> lightguard_jp:
[23:13:55] <lincolnthree> https://github.com/seam/seam-example-confbuzz/blob/develop/src/main/webapp/WEB-INF/web.xml
[23:14:02] <lincolnthree> .xhtml is not the default mapping
[23:14:09] <lincolnthree> but it is the recommended one
[23:14:19] <lincolnthree> *.jsf and /faces/* are the defaults
[23:19:09] <lightguard_jp> Okay, fair enough. I'm done messing with the app for now, just going to write the guide
[23:19:13] <lightguard_jp> lincolnthree: thanks
[23:20:06] *** clerum_ has quit IRC
[23:25:11] *** pmuir has quit IRC
[23:25:32] <clerum> so appearetnly if seam security is installed you don't have to define the interceptors in beans.xml for transation?
[23:25:49] <clerum> https://gist.github.com/455fc5cc6490c1d29b3d
[23:26:20] <sbryzak> morning all
[23:26:38] <lightguard_jp> sbryzak: Hi
[23:27:08] <lincolnthree> sbryzak: morning sbryzak!
[23:28:10] *** daniel_hinojosa has quit IRC
[23:30:10] <clerum> that is with security 3.0.0.Final and persistence 3.0.0 Final
[23:30:10] *** alesj has quit IRC
[23:31:12] <clerum> is that something we should document?
[23:31:46] *** daniel_hinojosa has joined #seam-dev
[23:37:22] <clerum> or is that going to cause issues if two modules enable this by default?
[23:38:13] <hannelita> lightguard_jp: Found the problem... If you take off richfaces everything isgoing to work
[23:38:15] <jbossbot> git [spring] push develop 0c068db.. Marius Bogoevici Update versions to 3.1.0-SNAPSHOT
[23:38:16] <jbossbot> git [spring] push develop cbc9915.. Marius Bogoevici Reorganized modules - replaced API/Impl with Core
[23:38:16] <jbossbot> git [spring] push develop 23085e5.. Marius Bogoevici Merge branch 'feature/structure' into develop
[23:38:16] <jbossbot> git [spring] push develop URL: http://github.com/seam/spring/compare/cc21b24...23085e5
[23:38:16] <jbossbot> git [spring] push master 0c068db.. Marius Bogoevici Update versions to 3.1.0-SNAPSHOT
[23:38:17] <jbossbot> git [spring] push master cbc9915.. Marius Bogoevici Reorganized modules - replaced API/Impl with Core
[23:38:18] <jbossbot> git [spring] push master 23085e5.. Marius Bogoevici Merge branch 'feature/structure' into develop
[23:38:19] <jbossbot> git [spring] push master 703df34.. Marius Bogoevici Merge branch 'release/structure-reorganized'
[23:38:19] <jbossbot> git [spring] push master URL: http://github.com/seam/spring/compare/cc21b24...703df34
[23:38:29] <lightguard_jp> :)
[23:38:38] <lightguard_jp> Nice work mbg
[23:38:43] <sbryzak> clerum: the interceptor is only enabled for the bean archive
[23:39:01] <lightguard_jp> hannelita: If I leave out RichFaces?? in the dependency management section or all together?
[23:39:25] <lightguard_jp> clerum: You may be experiencing a bug in AS6
[23:39:30] <mbg> lightguard_jp: I'm brushing up on my git-flow skills :)
[23:39:36] <lightguard_jp> clerum: AS7 is the gold standard for CDI working ;)
[23:39:39] <hannelita> lightguard_jp: Just take off richfaces dependencies from the pom.xml... [ok, just for testing]
[23:39:52] <lightguard_jp> mbg: I can see, looking good.
[23:40:20] <hannelita> lightguard_jp: and sure, make a home test page without rich tags... everything will work
[23:40:29] <lightguard_jp> mbg: When working by yourself it's not as helpful, but when others start working with you it's very nice and leads to less headaches with merging and keeping everything straight
[23:40:51] <hannelita> lightguard_jp: I think some filter into faces modules is messing up with richfaces :(
[23:41:01] <lightguard_jp> hannelita: bah. Okay, I'll have to wait until we get the Beta out.
[23:41:23] <lightguard_jp> sbryzak: Reference guide should probably wait until we have a new BOM so the guide follows the code.
[23:41:32] <hannelita> lightguard_jp: This is the easiest way, I've just hacked a bew way that seems to work
[23:41:41] <hannelita> *new
[23:41:44] <sbryzak> lightguard_jp: i updated the bom last night
[23:41:54] <mbg> lightguard_jp: yeah, I like it even solo, anyways
[23:41:58] <sbryzak> but the bom version for this release will be 3.1.0.Beta1
[23:42:25] <clerum> lightguard_jp: yes and no
[23:42:36] <clerum> currently my faces-config doesn't load with AS7
[23:42:37] <lightguard_jp> hannelita: Okay. I'll have to try it with the new bom and see if things work better.
[23:42:45] <lightguard_jp> hannelita: Or you can if you have the spare cycles.
[23:43:05] <lightguard_jp> clerum: paste it?
[23:43:15] <clerum> the faces-config?
[23:43:58] <clerum> it deploys fine on AS6 - https://gist.github.com/86b4db54d008fd21e18b
[23:44:45] <lightguard_jp> clerum: Seam 3 app?
[23:45:08] <clerum> yep
[23:45:53] <clerum> and I was unable to figure out how to crank the logging up in AS7 to troubleshoot
[23:46:17] <lightguard_jp> clerum: Why are you using navigation rules instead of the ViewConfig?
[23:47:32] <clerum> how do I do from-action?
[23:48:45] <clerum> I do use it...just for basic security though https://gist.github.com/48a2c4e147f6f8d755c8
[23:49:35] *** koentsje has quit IRC
[23:49:35] <clerum> didn't really see how to do from-action and from-outcome with @ViewConfig
[23:49:52] <clerum> http://docs.jboss.org/seam/3/faces/latest/reference/en-US/html/viewconfig.html
[23:50:30] <clerum> am I missing something?
[23:50:45] <sbryzak> clerum: bleathem is the expert in this area
[23:54:06] <lincolnthree> clerum: I don't think you can yet
[23:55:17] <clerum> So thats why I'm using faces-config.xml :-)
[23:55:54] <clerum> sbryzak: so that should only be enabling transaction support within the security archive?
[23:56:03] <sbryzak> clerum: that's right
[23:56:33] <clerum> and since it throws an error when I try and enable it with my beans.xml I wonder if it is being enabled in my archive
[23:56:46] <clerum> any way to test for that?
[23:57:18] <sbryzak> can you pastebin the error?
[23:57:36] <clerum> https://gist.github.com/455fc5cc6490c1d29b3d
[23:57:43] *** edburns is now known as edburns_away
[23:58:49] <sbryzak> that's a bug
[23:59:30] <sbryzak> section 9.4 of the CDI spec: "By default, a bean archive has no enabled interceptors bound via interceptor bindings. An interceptor must be explicitly
[23:59:30] <sbryzak> enabled by listing its class under the <interceptors> element of the beans.xml file of the bean archive."
[23:59:54] <clerum> well I was looking for a reason to try 6.1-SNAPSHOT

top