[00:02:25] <lightguard_jp> stuartdouglas: ping
[00:02:36] <stuartdouglas> lightguard_jp: pong
[00:03:08] <lightguard_jp> stuartdouglas: What's happening with the tests in persistence besides base? Are we no longer using them? Do they need to be updated?
[00:03:20] <stuartdouglas> I'm not sure
[00:03:31] <stuartdouglas> I have not looked at it recently
[00:05:24] <lightguard_jp> Okay, they probably need some tlc then.
[00:10:27] *** lightguard_jp has quit IRC
[00:26:28] *** gabrielrodrigues has joined #seam-dev
[00:41:27] *** sgilda has quit IRC
[01:02:22] *** arbi has quit IRC
[01:07:16] *** sannegrinovero has quit IRC
[01:22:52] *** jharting has quit IRC
[01:28:18] *** hannelita has quit IRC
[01:39:14] *** alesj has quit IRC
[01:53:19] *** alesj has joined #seam-dev
[01:53:45] *** gastaldi has joined #seam-dev
[01:53:46] *** ChanServ sets mode: +v gastaldi
[01:54:06] <gastaldi> Hey all
[01:54:20] <gastaldi> Damn, I dont believe I missed the meeting
[01:55:29] *** jamezp has quit IRC
[01:59:16] <sbryzak> gastaldi: morning
[01:59:21] <sbryzak> don't worry i missed it too
[01:59:31] <sbryzak> but i was awake at 3am giving a presentation, so i have an excuse ;)
[02:00:08] <gastaldi> :)
[02:00:29] <gastaldi> sbryzak: Evening :)
[02:04:05] <gastaldi> Yay! Congrats on this new seam release !
[02:05:06] *** jamezp has joined #seam-dev
[02:05:07] *** ChanServ sets mode: +v jamezp
[02:07:17] *** alesj has quit IRC
[02:09:00] *** gastaldi has quit IRC
[02:15:01] *** jamezp is now known as jamezp_afk
[02:15:19] *** jamezp_afk is now known as jamezp
[02:22:04] *** jamezp is now known as jamezp_afk
[02:23:45] *** jamezp_afk is now known as jamezp
[02:33:07] *** tkimura has joined #seam-dev
[02:33:07] *** tkimura has joined #seam-dev
[02:43:55] *** jamezp is now known as jamezp_afk
[02:56:34] *** gastaldi has joined #seam-dev
[02:56:34] *** ChanServ sets mode: +v gastaldi
[03:08:41] <gastaldi> sbryzak: you there ?
[03:15:13] *** rruss has quit IRC
[03:15:19] <sbryzak> gastaldi: yep i'm here
[03:15:42] <gastaldi> sbryzak: sent you a msg on pvt
[03:35:00] *** akazakov has quit IRC
[03:37:25] *** lincolnthree has left #seam-dev
[03:39:24] <gastaldi> have anyone seen this error when running a Seam test case  in Eclipse ? http://pastie.org/2765290
[03:39:49] <gastaldi> I think it may be an Arquillian issue
[03:41:31] <gastaldi> the tests run fine however outside eclipse
[03:56:13] *** hannelita has joined #seam-dev
[03:56:43] *** tsurdilo has quit IRC
[04:06:59] <gastaldi> yay ! :D
[04:07:02] <jbossbot> git [reports] push develop b597fd6.. George Gastaldi SEAMREPORTS-29: Fixed output bug
[04:07:03] <jbossbot> jira [SEAMREPORTS-29] XDocReport always generates PDF [Coding In Progress (Unresolved) Bug, Major, George Gastaldi] https://issues.jboss.org/browse/SEAMREPORTS-29
[04:07:03] <jbossbot> git [reports] push develop URL: http://github.com/seam/reports/compare/567ca31...b597fd6
[04:12:21] <gastaldi> hey hannelita
[04:12:38] <hannelita> hey gastaldi :)
[04:13:15] *** rruss has joined #seam-dev
[04:15:55] *** rruss has quit IRC
[04:23:13] <jbossbot> git [reports] push develop 83641a7.. George Gastaldi SEAMREPORTS-26: Added HTML/XHTML support
[04:23:14] <jbossbot> jira [SEAMREPORTS-26] Add HTML type for renderers [Coding In Progress (Unresolved) Enhancement, Major, George Gastaldi] https://issues.jboss.org/browse/SEAMREPORTS-26
[04:23:15] <jbossbot> git [reports] push develop 756d153.. George Gastaldi SEAMREPORTS-26: Changed docs
[04:23:15] <jbossbot> git [reports] push develop URL: http://github.com/seam/reports/compare/b597fd6...756d153
[04:26:24] <jbossbot> git [reports] push develop c2e4f4a.. George Gastaldi SEAMREPORTS-25
[04:26:25] <jbossbot> jira [SEAMREPORTS-25] PentahoReportingExtension eating pentaho initialization exceptions [Open (Unresolved) Bug, Major, George Gastaldi] https://issues.jboss.org/browse/SEAMREPORTS-25
[04:26:26] <jbossbot> git [reports] push develop URL: http://github.com/seam/reports/compare/756d153...c2e4f4a
[04:26:29] <gastaldi> Yeah !! Reports is on fire ! :D
[04:27:10] *** jamezp_afk is now known as jamezp
[04:27:24] *** jamezp is now known as jamezp_afk
[04:31:21] *** clerum has quit IRC
[04:34:44] *** alex5771 has quit IRC
[04:39:33] <jbossbot> git [reports] push develop 338ccf9.. George Gastaldi SEAMREPORTS-30
[04:39:34] <jbossbot> jira [SEAMREPORTS-30] Upgrade XDocReports to 0.9.2 [Open (Unresolved) Library Upgrade, Major, George Gastaldi] https://issues.jboss.org/browse/SEAMREPORTS-30
[04:39:34] <jbossbot> git [reports] push develop URL: http://github.com/seam/reports/compare/c2e4f4a...338ccf9
[04:47:26] <gastaldi> ok, enough Seam fun for me today
[04:47:30] <gastaldi> Time to go to bed
[04:47:34] <gastaldi> Night all !
[04:47:59] *** gastaldi has quit IRC
[05:08:41] *** hannelita has quit IRC
[05:13:31] *** rruss has joined #seam-dev
[05:28:31] *** stuartdouglas has quit IRC
[05:29:02] *** clerum has joined #seam-dev
[05:29:03] *** ChanServ sets mode: +v clerum
[05:30:49] *** clerum has quit IRC
[05:32:04] *** stuartdouglas has joined #seam-dev
[05:32:04] *** ChanServ sets mode: +v stuartdouglas
[06:11:11] *** lightguard_jp has joined #seam-dev
[06:11:11] *** ChanServ sets mode: +o lightguard_jp
[06:11:34] *** rruss has quit IRC
[06:31:43] *** lightguard_jp sets mode: -o jbott
[06:35:48] *** rruss has joined #seam-dev
[06:38:56] <jbossbot> git [persistence] push develop b091afd.. LightGuard Updating the pom to reflect the correct versioning
[06:38:56] <jbossbot> git [persistence] push develop URL: http://github.com/seam/persistence/compare/c9272ec...b091afd
[06:40:32] *** tkimura has quit IRC
[06:41:42] <lightguard_jp> sbryzak: ping
[06:48:00] <lightguard_jp> sbryzak: See comments for SEAM-115
[06:48:02] <jbossbot> jira [SEAM-115] Release has dependencies on an older release [Open (Unresolved) Bug, Blocker, Shane Bryzak] https://issues.jboss.org/browse/SEAM-115
[06:48:59] <lightguard_jp> bleathem: ping
[06:50:32] <lightguard_jp> stuartdouglas: Do you see any problems with the proposed solution for SEAMPERSIST-64?
[06:50:34] <jbossbot> jira [SEAMPERSIST-64] Persistence doesn't pull in transaction as a dependency [Open (Unresolved) Library Upgrade, Blocker, Unassigned] https://issues.jboss.org/browse/SEAMPERSIST-64
[06:51:28] <stuartdouglas> I think that is ok
[06:52:23] <lightguard_jp> stuartdouglas: Okay, I'm going to fix it with the proposed solution then.
[07:08:43] *** rruss has quit IRC
[07:15:15] <jbossbot> git [persistence] push develop 4cce33f.. LightGuard Fixing SEAMPERSIST-64
[07:15:16] <jbossbot> jira [SEAMPERSIST-64] Persistence doesn't pull in transaction as a dependency [Open (Unresolved) Library Upgrade, Blocker, Unassigned] https://issues.jboss.org/browse/SEAMPERSIST-64
[07:15:16] <jbossbot> git [persistence] push develop URL: http://github.com/seam/persistence/compare/b091afd...4cce33f
[07:20:21] <sbryzak> lightguard_jp: i'm not sure what to do about the faces dependency in security
[07:20:38] <sbryzak> one option is to move the examples out
[07:20:41] <lightguard_jp> It's only being used in the examples it looks like
[07:20:50] <sbryzak> yep, that's right
[07:21:16] <lightguard_jp> I kind of think they should all be moved out to the examples section, then packaged up with the distribution.
[07:21:25] <sbryzak> i've discussed the jms testsuite with john previously
[07:21:34] <sbryzak> we decided that by default no tests should run
[07:21:39] <lightguard_jp> It's a pretty good way for QE (or anyone really) to help us ferret out bugs by checking those examples and running the tests.
[07:21:41] <sbryzak> as there is no jms available in embedded weld
[07:21:49] <lightguard_jp> Okay
[07:35:43] <lightguard_jp> sbryzak: We're setup with cloudbees FOSS Pro
[07:36:03] <lightguard_jp> We also have the maven release plugin now. So there's some config we'll have to, but we're getting there.
[08:14:35] *** tremes has joined #seam-dev
[08:17:08] <lightguard_jp> No Ove :(
[08:22:27] *** bd727 has quit IRC
[08:23:01] *** jharting has joined #seam-dev
[08:23:02] *** ChanServ sets mode: +v jharting
[08:32:25] <lightguard_jp> bleathem: ping
[08:32:54] <lightguard_jp> sbryzak: Did you help with the ViewConfig stuff?
[08:34:46] *** mgoldmann has joined #seam-dev
[08:44:17] <bleathem> lightguard_jp: pong
[08:44:35] <bleathem> just finished painting the family
[08:44:36] <bleathem> room
[08:44:46] <bleathem> oops, funny spot for a carriage return
[08:45:30] <lightguard_jp> I think Ove found a little corner case for us to look at.
[08:46:19] <lightguard_jp> SEAMSECURITY-111
[08:46:20] <jbossbot> jira [SEAMSECURITY-111] Security rules is broken [Resolved (Done) Bug, Critical, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-111
[08:46:50] <lightguard_jp> As it currently stands his AccessDeniedView also has a restriction on it.
[08:48:32] <bleathem> have you looked at the example project
[08:48:33] <bleathem> ?
[08:48:43] <bleathem> also, I've been thinking about your pull request
[08:49:25] <bleathem> I'd really prefer the check to be that the Faces SecurityPhaseListener is loaded and/or active
[08:49:49] <bleathem> checking that a Seam Security class seems insufficient
[08:49:50] <lightguard_jp> Yeah, I'm looking at the example project now
[08:50:02] <bleathem> it guards against the last error, but not necessarily against the next error
[08:50:11] <lightguard_jp> I'm checking for the existence of the extension
[08:51:00] <lightguard_jp> At least as of right now, there's no way to not enable an extension without mucking with the jar and removing te Service Registry file.
[08:52:12] <bleathem> hmm
[08:52:23] <bleathem> I got tired all of a sudden
[08:52:29] <bleathem> adrenaline is running out
[08:53:02] <bleathem> this was a lot more clear for me when I was thinking about it this afternoon
[08:53:29] <bleathem> right now, I'm thinking some check is better than no check, and we should just move on
[08:53:57] <bleathem> so what's oranheim's app looking like?
[08:54:28] <lightguard_jp> I may have found one of the problems.
[08:54:39] <lightguard_jp> He's not using an interface for the ViewConfig
[08:55:21] <bleathem> just an enum?
[08:55:28] <bleathem> or a class maybe?
[08:55:38] <lightguard_jp> It's a class with an enum in it
[08:55:44] <bleathem> hmm
[08:56:05] <lightguard_jp> So we log a warning and don't even process anything on the enum inside
[08:56:38] <bleathem> huh
[08:56:46] <bleathem> we could allow classes I guess
[08:57:16] <lightguard_jp> I'd say just keep it as interfaces for now
[08:57:25] <lightguard_jp> It's documented that way, that's how all the examples are.
[08:58:21] <lightguard_jp> I think I got it stuck in an infinite loop because of this issue where the AccessDenied view is also restricted
[09:01:13] *** mkouba has joined #seam-dev
[09:06:56] <bleathem> I wish jira supported bookmarking issues
[09:08:49] <lightguard_jp> Hm, not issues, filters yes though
[09:27:53] *** maschmid has joined #seam-dev
[09:35:42] *** bleathem has quit IRC
[09:37:00] *** oskutka has joined #seam-dev
[09:38:55] *** jamezp_afk has quit IRC
[09:39:45] *** jamezp has joined #seam-dev
[09:39:45] *** ChanServ sets mode: +v jamezp
[09:45:50] <lightguard_jp> sbryzak: Still here?
[09:47:29] <sbryzak> lightguard_jp: yep i'm here
[09:48:47] <jbossbot> git [examples] push master 59295e2.. U-MAZITHINKPAD\Matic Added navigation rule for failed login (SEAM-71)
[09:48:48] <jbossbot> jira [SEAM-71] Seam-booking example: Unable to find matching navigation case with from-view-id '/home.xhtml' for action '#{identity.login}' with outcome 'failed' [Pull Request Sent (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAM-71
[09:48:48] <jbossbot> git [examples] push master 625ccbb.. Shane Bryzak Merge pull request #14 from mmazi/feature/login-navigation...
[09:48:49] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/a737567...625ccbb
[09:48:52] <lightguard_jp> I think including Servlet by default may have been a bad thing. I'm wondering if we want to break it out so there's a solder-servlet.
[09:49:11] <sbryzak> is it causing issues?
[09:49:33] <lightguard_jp> It might be, I haven't been able to verify yet. My initial idea for excluding it didn't work.
[09:49:52] <lightguard_jp> I tried just removing the extension registrations but then it died on deploy
[09:49:55] <sbryzak> i thought we had it disabled if we were running in an SE environment
[09:50:29] <lightguard_jp> This isn't for an SE environment.
[09:50:33] <lightguard_jp> It's a web app
[09:50:44] <sbryzak> what's the exact issue?
[09:50:46] <lightguard_jp> SEAMSECURITY-111
[09:50:48] <jbossbot> jira [SEAMSECURITY-111] Security rules is broken [Resolved (Done) Bug, Critical, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-111
[09:52:02] <sbryzak> the fix definitely isn't to remove servlet
[09:52:08] <lightguard_jp> After a series of redirects it dies and it looks like it's dying because of an observer, but I don't know which or where.
[09:52:18] <sbryzak> we can't force people to do that in their applications
[09:52:42] <lightguard_jp> No, but as it stands now, we're forcing servlet on them when we weren't before.
[09:52:48] <sbryzak> i'll try to look at the issue soon
[09:53:11] <lightguard_jp> After making the changes I listed things are working save that last test case.
[09:53:11] <sbryzak> solder provides a lot of features, not just servlet integration
[09:53:54] <sbryzak> ok, i'll spend some time on it when i get a chance
[09:54:07] <lightguard_jp> Right, I know, but including the servlet module into Solder at Beta3 was new, now every app has the Servlet Module where it may not have in the past.
[09:55:08] <lightguard_jp> It may not be the problem, but I haven't been able to verify if is causing a problem in this last test or if it's something else.
[09:56:19] <sbryzak> if it is the cause of this issue, we need to find out why and fix it
[09:56:32] <sbryzak> we can't have features that are incompatible with other features
[09:56:44] <lightguard_jp> True.
[09:56:51] <sbryzak> are you joining the discussion in 10 minutes?
[09:57:14] <lightguard_jp> Pete's conf line?
[09:57:24] <sbryzak> yep
[09:57:26] *** oskutka has quit IRC
[09:57:34] <lightguard_jp> Yeah, I can.
[09:58:33] <lightguard_jp> I doubt I'll be there for the other one, probably still be at the dentist
[09:58:40] <sbryzak> there's another one in 8 hours if that's a better time
[09:58:45] <lightguard_jp> And running on low sleep.
[10:03:11] <lightguard_jp> Hm
[10:03:28] <lightguard_jp> It's not starting up the web start, is that because the meeting hasn't started?
[10:03:45] <sbryzak> no.. it should work
[10:03:57] <sbryzak> is the webstart app launching?
[10:06:52] <lightguard_jp> No
[10:07:01] <sbryzak> can you launch it manually?
[10:07:06] <sbryzak> javaws meeting.jnlp
[10:07:48] <lightguard_jp> I'll try
[10:08:21] <lightguard_jp> There we go
[10:09:50] <lightguard_jp> Hm, can't authenticat.
[10:13:08] <lightguard_jp> Nevermind, I'm good
[10:15:54] *** oskutka has joined #seam-dev
[10:20:21] *** emmanuel has joined #seam-dev
[10:22:05] *** Diablo-D3 has joined #seam-dev
[10:26:43] *** pmuir has joined #seam-dev
[10:26:43] *** pmuir has quit IRC
[10:26:43] *** pmuir has joined #seam-dev
[10:47:54] *** alesj has joined #seam-dev
[10:54:00] *** mkouba has quit IRC
[10:54:53] *** kpiwko has joined #seam-dev
[10:59:13] *** sannegrinovero has joined #seam-dev
[11:17:46] *** mkouba has joined #seam-dev
[11:49:21] *** lightguard_jp has quit IRC
[12:19:00] *** emmanuel has quit IRC
[12:23:08] *** aslak has quit IRC
[12:42:47] *** koentsje has joined #seam-dev
[12:44:40] *** sannegrinovero has quit IRC
[13:19:20] *** oranheim has joined #seam-dev
[13:27:54] *** pmuir has quit IRC
[13:29:48] *** pmuir has joined #seam-dev
[13:39:15] *** epbernard has joined #seam-dev
[13:39:15] *** epbernard is now known as emmanuel
[13:45:29] *** alesj has quit IRC
[13:53:23] *** gonzalad has joined #seam-dev
[13:53:39] *** alesj has joined #seam-dev
[14:09:31] *** pmuir has quit IRC
[14:25:52] *** pmuir has joined #seam-dev
[14:44:31] *** bd727 has joined #seam-dev
[15:10:01] *** oskutka has quit IRC
[15:21:16] *** aslak has joined #seam-dev
[15:28:52] *** sgilda has joined #seam-dev
[15:36:10] *** tsurdilo has joined #seam-dev
[15:39:07] <oranheim> guys, you probably have noticed. But, seam-parent/pom.xml says solder.version 3.1.0.Beta3
[15:39:46] <oranheim> I meant to say seam-bom/pom.xml
[15:41:44] *** oskutka has joined #seam-dev
[15:45:09] <maschmid> oranheim: we know, but thanks!  SEAM-112
[15:45:11] <jbossbot> jira [SEAM-112] seam-bom 3.1.0.Beta4 declares solder 3.1.0.Beta3 [Resolved (Done) Bug, Critical, Shane Bryzak] https://issues.jboss.org/browse/SEAM-112
[15:49:30] *** alex5771 has joined #seam-dev
[15:55:10] *** sgilda has quit IRC
[15:56:13] <alex5771> hi anybody alive?
[16:02:38] *** sannegrinovero has joined #seam-dev
[16:05:58] <jbossbot> git [social] push develop bfaebe7.. Marek Schmidt Convert to the new testsuite structure
[16:05:58] <jbossbot> git [social] push develop 780d54f.. Antoine Sabot-Durand Merge pull request #10 from maschmid/SEAMSOCIAL-23...
[16:05:59] <jbossbot> jira [SEAMSOCIAL-23] testsuite structure update [Pull Request Sent (Unresolved) Feature Request, Major, Marek Schmidt] https://issues.jboss.org/browse/SEAMSOCIAL-23
[16:05:59] <jbossbot> git [social] push develop URL: http://github.com/seam/social/compare/4e22ffc...780d54f
[16:06:53] *** jamezp has quit IRC
[16:07:17] *** mkouba has quit IRC
[16:07:20] *** jamezp has joined #seam-dev
[16:07:21] *** ChanServ sets mode: +v jamezp
[16:08:17] *** clerum has joined #seam-dev
[16:08:17] *** ChanServ sets mode: +v clerum
[16:11:44] *** sgilda has joined #seam-dev
[16:13:51] *** rruss has joined #seam-dev
[16:20:56] *** mkouba has joined #seam-dev
[16:26:28] <alex5771> i have a Seam2 App which uses EntityQuery I am moving to Seam3 any advice on how to migrate it?
[16:28:20] *** tremes has quit IRC
[16:30:05] *** tremes has joined #seam-dev
[16:32:56] *** tremes has quit IRC
[16:34:35] *** tremes has joined #seam-dev
[16:48:34] *** koentsje has quit IRC
[16:53:47] <jbossbot> git [social] push develop b023512.. Antoine Sabot-Durand Added meta annotation @ServiceRelated and Qualifiers for each Social...
[16:53:47] <jbossbot> git [social] push develop e2ddba6.. Antoine Sabot-Durand Building association between name of Services and Qualifier
[16:53:48] <jbossbot> git [social] push develop d95ee3d.. Antoine Sabot-Durand Ended refactoring for a stronger typed Quqlifier system on Services
[16:53:48] <jbossbot> git [social] push develop 4c0c444.. Antoine Sabot-Durand Updating Readme file with the new qualifier system
[16:53:48] <jbossbot> git [social] push develop 5797b21.. Antoine Sabot-Durand Cleaning Import in TwitterTest
[16:53:49] <jbossbot> git [social] push develop URL: http://github.com/seam/social/compare/780d54f...5797b21
[16:59:05] *** tremes has quit IRC
[17:02:47] *** lincolnthree has joined #seam-dev
[17:02:47] *** ChanServ sets mode: +v lincolnthree
[17:03:52] *** tremes has joined #seam-dev
[17:07:14] *** jamezp is now known as jamezp_afk
[17:10:18] *** tremes1 has joined #seam-dev
[17:10:20] *** tremes1 has left #seam-dev
[17:13:05] *** tremes has quit IRC
[17:13:22] *** tremes has joined #seam-dev
[17:15:55] *** edburns_away is now known as edburns
[17:15:57] *** tremes2 has joined #seam-dev
[17:19:24] *** tremes has quit IRC
[17:19:57] *** amitev has quit IRC
[17:21:59] *** hannelita has joined #seam-dev
[17:22:02] *** amitev has joined #seam-dev
[17:24:53] *** jose_freitas has joined #seam-dev
[17:32:22] *** jharting has quit IRC
[17:32:34] *** mkouba has quit IRC
[17:33:35] *** tremes2 has quit IRC
[17:33:48] *** jamezp_afk is now known as jamezp
[17:35:28] *** sannegrinovero has quit IRC
[17:45:19] *** alesj has quit IRC
[17:49:27] *** jamezp has quit IRC
[17:56:14] *** alex5771 has quit IRC
[17:56:51] *** alex5771 has joined #seam-dev
[17:57:25] *** hannelita has quit IRC
[17:59:47] <edburns> lincolnthree: Hello, are you here?  I have a question about an issue you filed.
[17:59:55] <lincolnthree> hey edburns: yep
[18:00:33] <lincolnthree> which one?
[18:00:34] <edburns> lincolnthree: Can you please take a look at your <http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-766>?
[18:00:42] *** akazakov has joined #seam-dev
[18:00:51] *** jamezp has joined #seam-dev
[18:00:52] *** ChanServ sets mode: +v jamezp
[18:00:58] <lincolnthree> ok got it
[18:01:01] <edburns> lincolnthree: The question: what do want for the timing of the publishing of PostConstructFlashEvent and PreDestroyFlashEvent?
[18:01:07] <lincolnthree> ah
[18:01:19] <lincolnthree> immediately before and after?
[18:01:27] <lincolnthree> err
[18:01:33] <lincolnthree> immediately after flash has been created
[18:01:39] <lincolnthree> and immediately before it will be destroyed
[18:01:49] <lincolnthree> or am i miunderstanding you?
[18:02:13] <lincolnthree> it should work just like the other events, i think
[18:02:27] <edburns> ok.  The flash is created lazily upon the first put to it for the current session (or application depending on how you have the flash storage configured).
[18:02:41] <edburns> It would be destroyed at app shutdown.
[18:02:54] <edburns> lincolnthree: Is that acceptable for the timing of the publishing of the events?
[18:03:02] <lincolnthree> i thought the flash only lived between one page transition?
[18:03:11] <edburns> I meant to say, "it *is* destroyed at app shutdown.
[18:03:16] *** sannegrinovero has joined #seam-dev
[18:03:26] <edburns> The data structure that is the flash has the lifetime I just mentioned.
[18:03:37] <edburns> The objects you put *in* the flash, naturally, have the flash lifetime.
[18:03:57] <lincolnthree> ok, so the lifespan of the actual implementation data-structure is irrelivant
[18:04:02] <lincolnthree> nobody needs to know
[18:04:05] <lincolnthree> it's impl specific
[18:04:17] <lincolnthree> (or should be if it's not)
[18:04:19] <edburns> lincolnthree: Well, we do specify it, but I agree that app developers would not be interested in it.
[18:04:33] <edburns> You know, maybe we don't.
[18:04:45] <lincolnthree> hmm
[18:04:46] <lincolnthree> not sure
[18:04:59] <lincolnthree> but I think what matters is when the flash for the current page is "activated" and then when it is cleaned
[18:05:05] <lincolnthree> so post-activation
[18:05:06] <lincolnthree> pre-clean
[18:05:09] <lincolnthree> if that makes sense?
[18:05:27] <edburns> Either way, I understand now that you are not interested in the lifetime of the flash datastructure for the purposes of 766. Rather you seem to be interested in the lifetime of the data in the flash.
[18:05:35] <lincolnthree> right :)
[18:05:54] <edburns> First off, we need different names then the ones you proposed.
[18:06:04] <lincolnthree> Sure
[18:06:13] <lincolnthree> I think that makes some sense
[18:06:16] <edburns> Though because you proposed the names based on your understanding of the system, perhaps others percieve it that way.
[18:06:27] <lincolnthree> But yeah, I think there is a perception in play here
[18:06:49] <lincolnthree> And in a sense, the "effect" of the system is what I think should be reflected
[18:07:05] <lincolnthree> The effect is that a "new context" is created for every page transition
[18:07:10] <lincolnthree> and then that context is destroyed
[18:07:37] <lincolnthree> the fact that the context is stored in an application-lifespan backing is not really relevant imo
[18:08:21] *** tremes has joined #seam-dev
[18:08:43] <edburns> I agree.
[18:09:23] <lincolnthree> Glad to see so much work happening on JSF btw - sorry I have been too busy to do much.
[18:10:58] *** tremes has quit IRC
[18:11:10] *** tremes has joined #seam-dev
[18:11:13] *** tremes has left #seam-dev
[18:12:17] <edburns> lincolnthree: How about "PostValuePutToFlashEvent" and "PreValuePurgedFromFlashEvent" ?
[18:13:30] <lincolnthree> edburns: Would it be good to define when the flash becomes available on a given request?
[18:13:54] <lincolnthree> Or is it ubiquitous?
[18:13:58] <edburns> It becomes available as soon as someone puts something in it.=
[18:14:32] <lincolnthree> Ok. But let's assume that there are a *lot* of values in the flash for some reason
[18:14:42] <lincolnthree> would we then fire an event for each object in these cases?
[18:15:12] <lincolnthree> Also, is that behavior specified?
[18:15:16] <edburns> lincolnthree: That's the thing.  The developer can control when they want stuff to expire by calling flash.keep().
[18:15:49] <lincolnthree> But that's global for that entire instance of the flash
[18:15:49] <edburns> So on one request you can put stuff in, and then, mid-request, say, "hey I want that to stick around a bit longer, let me call keep() on it".
[18:16:01] <edburns> No, it is absolutely per-entry.
[18:16:13] <lincolnthree> flash.keep(myObject) ?
[18:16:19] <edburns> wait!
[18:16:23] <edburns> Let me look at the API again.
[18:16:24] <edburns> Sorry.
[18:16:39] <edburns> Yes, it is flash.keep(key)
[18:16:43] <lincolnthree> you're right
[18:16:45] <lincolnthree> (just looked)
[18:16:46] <lincolnthree> ok
[18:16:53] <lincolnthree> so in that case
[18:16:58] <lincolnthree> I think your proposed events make sense
[18:17:03] <lincolnthree> but
[18:17:13] <lincolnthree> I would maybe take one step back from that
[18:17:47] <lincolnthree> And say, let's only fire an event PostFirstValuePutToFlash
[18:17:55] <lincolnthree> Hmmm
[18:17:58] <lincolnthree> Actually
[18:18:00] *** rruss has quit IRC
[18:18:01] <lincolnthree> I dont think that works
[18:18:05] <lincolnthree> I think we have to do it your way
[18:18:11] <lincolnthree> This is a very strange context :)
[18:18:19] <edburns> Yes, it is.  But that's rails for you.
[18:18:22] <lincolnthree> variable lifespan of individual elements
[18:18:45] <lincolnthree> it's basically not a context at that point. it's more of a temporary data store with garbage collection if you forget something inside
[18:19:19] <lincolnthree> we'd have to do it your way
[18:19:52] <edburns> lincolnthree: yes, it is entirely a temporary data store with garbage collection.  It was never intended to be anything else.
[18:20:01] <edburns> lincolnthree: That said, is there still real utility in your request?
[18:20:22] <edburns> lincolnthree: Because, as you pointed out, there would be significant overhead when you have lots of values.
[18:20:38] <lincolnthree> I think so
[18:20:50] <lincolnthree> in order to integrate CDI lifecycle into the Flash
[18:20:59] <lincolnthree> We need some kind of handle to these events
[18:21:15] <lincolnthree> But
[18:21:25] <lincolnthree> Without experimenting, I'm not sure I
[18:21:31] <lincolnthree> d be able to say if it would be good or not
[18:21:45] *** kpiwko has quit IRC
[18:21:47] *** pmuir has quit IRC
[18:22:06] *** kpiwko has joined #seam-dev
[18:22:22] <edburns> lincolnthree: If I put these in, can I count on you to experiment with them and let me know if I should remove them or not?
[18:22:49] <lincolnthree> edburns: well. I'm away for 5 weeks starting on tuesday :-/
[18:23:05] <edburns> lincolnthree: I'm inclined to simply say no to this request, but I trust your instincts and your experience with your users.
[18:23:16] <lincolnthree> In the end, I don't think we need this
[18:23:17] <lincolnthree> But.
[18:23:28] <edburns> lincolnthree: 5 weeks is fine as long as I can count on you to try it. You see, if I put it in, it'll stay in unless I take it out.
[18:23:41] <lincolnthree> I think the outcome is just that people aren't going to use the flash if they use CDI
[18:23:44] <edburns> and I won't know to take it out unless someone tells me to take it out.
[18:24:01] <lincolnthree> They will use something like our RenderScoped
[18:24:13] <lincolnthree> Which is what I think most people thought the flash was supposed to be
[18:24:24] <edburns> RenderScoped, is that in faces module?
[18:24:27] <lincolnthree> Yes
[18:24:38] <lincolnthree> Basically, anything you put in lives until the next Render_Response phase
[18:24:44] <lincolnthree> it's that simple :)
[18:25:06] *** rruss has joined #seam-dev
[18:25:08] <lincolnthree> That's the one rule of RenderScoped
[18:25:13] <jbossbot> git [social] push develop fd0ad44.. Antoine Sabot-Durand Correcting Arquillian config to have the generated war
[18:25:13] <jbossbot> git [social] push develop URL: http://github.com/seam/social/compare/5797b21...fd0ad44
[18:25:19] <edburns> lincolnthree: So can I copy some text from this chat to the issue and close it as WontFix?
[18:25:24] <edburns> or Works As Designed?
[18:26:30] <lincolnthree> Hmmm
[18:26:50] <lincolnthree> well
[18:27:09] <lincolnthree> the events you suggested (per object) would definitely let us do what we'd need to add CDI support to the Flash (probably increasing its use)
[18:27:11] <lincolnthree> but
[18:27:21] <lincolnthree> I'll leave it up to you as to whether or not it would be a performance hit
[18:27:30] <lincolnthree> an (unacceptable) performance hit
[18:27:33] *** hannelita has joined #seam-dev
[18:27:54] *** hannelita has quit IRC
[18:27:57] <lincolnthree> So with that, I'd say, Yes, I think it's useful, but the design of the flash leaves me with some concerns as to the impact of doing this
[18:27:59] <lincolnthree> That being said
[18:28:06] <lincolnthree> I don't think people use it for all that much
[18:28:12] <lincolnthree> typically you transfer a few objects at a time
[18:28:19] <lincolnthree> so I doubt the hit would be that great
[18:28:31] <lincolnthree> a few messages from page to page
[18:28:36] <lincolnthree> a few entities
[18:28:46] <lincolnthree> My gut feeling is to say, yes, add it
[18:28:52] <lincolnthree> because the scope is lacking integration points
[18:28:54] *** lightguard_jp has joined #seam-dev
[18:28:54] *** ChanServ sets mode: +o lightguard_jp
[18:28:55] <lincolnthree> and that makes it less useful
[18:29:06] <lincolnthree> if that is the point that is most reliable, I'd say we need it
[18:29:25] <lincolnthree> because it's basically useless to CDI without it
[18:29:27] <edburns> After discussing this, we have elicited that the intent of the flash is to provide a place to put stuff and know that it'll be cleared out "soon".
[18:29:43] <edburns> without having to take any action to clear it out.
[18:29:52] <lincolnthree> Which is exactly what CDI scopes give you
[18:29:57] <lincolnthree> for instance
[18:30:22] <lincolnthree> @Inject @FlashScoped WorkObject work;
[18:30:37] <edburns> I see.
[18:30:38] <lincolnthree> Or, if we had that integration point, we could do something like this:
[18:30:56] <lincolnthree> @Inject FlashInstance<WorkObject> work;
[18:30:59] <lincolnthree> then you could call:
[18:31:04] <lincolnthree> Work w = work.get()
[18:31:10] <lincolnthree> work.keep();
[18:31:13] <lincolnthree> work.evict();
[18:31:14] <lincolnthree> etc
[18:31:44] <lincolnthree> and CDI will still know when to call @PreDestroy because it gets the event when the JSF Flash Implementation *actually* is about to destroy the reference to the object
[18:31:49] <edburns> Sorry, what is FlashInstance?
[18:32:02] <lincolnthree> It is the API that I just created in my head.
[18:32:16] <lincolnthree> To provide access to both the Flash controls like .keep(), and also the object itself.
[18:32:33] <lincolnthree> FlashInstance.get() returns the object from the flash
[18:32:44] <edburns> Well, we already have that.  ExternalContext.getFlash().
[18:32:46] <lincolnthree> FlashInstance.keep() instructs the flash to "keep the object a little longer"
[18:32:56] <lincolnthree> No we don't :)
[18:33:08] <lincolnthree> We can literally get a reference to the Flash itself
[18:33:15] <lincolnthree> This is a reference to a *single* object in the flash.
[18:33:21] <lincolnthree> In a typesafe way
[18:33:31] <lincolnthree> Where @Injection is supported
[18:33:56] <lincolnthree> That is what I tried to implement originally, but couldn't because we didn't have hooks to determine when the object would actually be destroyed
[18:34:00] <lincolnthree> which is why I filed the issue
[18:34:19] <lincolnthree> because I assumed that all objects in the flash were destroyed at the same time
[18:34:24] <lincolnthree> which is why i filed it the way i did
[18:34:48] <lincolnthree> Put it in. I'll make this happen.
[18:34:50] <edburns> Right, and, mostly, they *are* destroyed all at the same time, but it's the keep(key) case that is the wrinkle.
[18:34:54] <lincolnthree> Right
[18:35:04] <edburns> Ok, I'm happy to put it in.
[18:35:19] <lincolnthree> The events you proposed, on a per-object level, make all this work :)
[18:35:31] <edburns> So let me restate: How about "PostValuePutToFlashEvent" and "PreValuePurgedFromFlashEvent" ?
[18:35:40] <lincolnthree> Perfect
[18:36:00] <lincolnthree> Sorry it took me a little while to get my thought process from however long ago, back again.
[18:36:11] <edburns> lincolnthree: should I really use the past tense in the latter event?
[18:36:21] <lincolnthree> hm
[18:36:35] <lincolnthree> Yes I think so
[18:36:44] <lincolnthree> The event is fired before the value is purged
[18:37:09] <lincolnthree> it's gramatically correct when stated fully :) so sounds good to me
[18:37:14] <edburns> ok.
[18:37:16] <edburns> Will do.
[18:37:19] <lincolnthree> Awesome!
[18:37:31] <lincolnthree> I'll make sure we put this issue in for JSF2.2 updates
[18:37:35] <lincolnthree> (In Seam)
[18:37:38] <edburns> There is another thing, lincolnthree.
[18:37:40] <lincolnthree> So we can get that integration done
[18:37:41] <lincolnthree> Sure
[18:37:57] <edburns> You appended an "oh by the way" to the issue, what do you want to do about that?
[18:38:20] <lincolnthree> Also, can we consider adding the @javax.faces.bean.FlashScoped annotation like
[18:38:20] <lincolnthree> (Dan) mentioned in the last EG meeting? I'm not concerned about enhancing the
[18:38:20] <lincolnthree> JSF bean container. We just needs a common annotation for CDI or Spring
[18:38:20] <lincolnthree> integration. We need a common touch point, so we avoid introducing
[18:38:20] <lincolnthree> @org.jboss.seam.faces.context.FlashScoped.
[18:38:23] <lincolnthree> that?
[18:38:31] <edburns> yes
[18:38:43] <lincolnthree> Drop it.
[18:38:55] <lincolnthree> Unless...
[18:39:16] <edburns> lincolnthree: I respectfully request that you state the request to drop that portion of the issue as a comment on the issue.
[18:39:22] <lincolnthree> Sure, let's think though
[18:39:34] <edburns> But I'm not against it.  But if you don't need it, then you don't need it.
[18:39:57] <lincolnthree> The reason to include it is to avoid adding new non-standard scope annotations to CDI extensions
[18:40:28] <lincolnthree> I don't think implementing this scope in JSF itself makes much sense
[18:40:39] <lincolnthree> so from that perspective the annotation seems moot
[18:40:40] <lincolnthree> but
[18:40:48] <lincolnthree> when you think about it from an integration perspective
[18:40:53] <lincolnthree> (Spring, CDI, Guice)
[18:41:07] <lincolnthree> If they are going to specify an annotation to put things in the flash
[18:41:16] <lincolnthree> It would be nice to use a standard annotation
[18:41:29] <lincolnthree> can we introduce an annotation that has no defined behavior?
[18:41:34] <lincolnthree> is that totally illogical>
[18:41:35] <lincolnthree> ?
[18:41:58] <lincolnthree> i think it is illogical
[18:42:09] <lincolnthree> lincolnthree1 wins this internal debate
[18:42:15] <lincolnthree> lincolnthree concedes
[18:42:22] <lincolnthree> i'll put in a request to drop that part
[18:43:17] <lincolnthree> edburns: stated
[18:51:13] *** sgilda has quit IRC
[18:52:37] *** kpiwko has quit IRC
[18:52:41] *** mbg has joined #seam-dev
[18:52:42] *** ChanServ sets mode: +v mbg
[18:58:27] *** mbg has quit IRC
[19:00:22] *** mbg has joined #seam-dev
[19:00:22] *** ChanServ sets mode: +v mbg
[19:00:38] *** mbg has quit IRC
[19:01:16] *** maschmid has quit IRC
[19:06:18] *** sgilda has joined #seam-dev
[19:07:02] <lightguard_jp> clerum: Ideas for http://seamframework.org/Community/ExceptionWhenSendingEmail
[19:07:06] <lightguard_jp> ?
[19:09:52] *** lincolnthree1 has joined #seam-dev
[19:09:53] *** ChanServ sets mode: +v lincolnthree1
[19:10:00] *** lincolnthree has quit IRC
[19:10:28] *** lincolnthree has joined #seam-dev
[19:10:28] *** ChanServ sets mode: +v lincolnthree
[19:10:41] *** lincolnthree has quit IRC
[19:13:23] *** alesj has joined #seam-dev
[19:13:28] *** sgilda has quit IRC
[19:17:16] *** rruss has quit IRC
[19:18:06] <clerum> lightguard_jp: thats a known as7 bug
[19:18:25] <clerum> http://docs.jboss.org/seam/3/mail/snapshot/reference/en-US/html_single/#d0e28
[19:18:25] <lightguard_jp> Is there a JIRA that you can reference
[19:18:31] <clerum> AS7-1375
[19:18:32] <jbossbot> jira [AS7-1375] UnsupportedDataTypeException sending email [Resolved (Done) Bug, Major, Tomaz Cerar] https://issues.jboss.org/browse/AS7-1375
[19:18:40] <clerum> won't be fixed until 7.1
[19:18:41] <lightguard_jp> Ah
[19:18:50] <clerum> doesn't sound like they are gong to back port either
[19:18:53] <lightguard_jp> Okay, please respond to the thread with that.
[19:18:59] <lightguard_jp> Probably not
[19:19:00] <clerum> will do
[19:19:11] <lightguard_jp> Have wait for 7.0.3 or 7.1.0
[19:19:54] <lightguard_jp> It works if you use a snapshot of AS7 though, doesn't it?
[19:20:02] <clerum> don't think it will be in 7.0.3
[19:20:14] <clerum> yes or if you make the minior change in the docs
[19:21:07] <lightguard_jp> Okay cool.
[19:21:12] *** alesj has quit IRC
[19:22:14] *** sgilda has joined #seam-dev
[19:22:31] <clerum> http://seamframework.org/Community/ExceptionWhenSendingEmail#comment173153
[19:22:54] *** kevinpollet has joined #seam-dev
[19:23:06] <lightguard_jp> clerum: thanks
[19:24:07] <lightguard_jp> I think I'm going to go offline for a little bit, kids are getting crazy.
[19:24:36] <lincolnthree1> lightguard_jp: must be nice to get breaks
[19:24:51] <lightguard_jp> lincolnthree1: breaks from what?
[19:24:57] <lincolnthree1> lightguard_jp: *sarcasm* ;)
[19:25:03] <lightguard_jp> Ah
[19:25:19] <clerum> this guy doesn't search too hard for answers
[19:25:29] <clerum> I get that as the second result on google
[19:25:44] <lightguard_jp> Oldest also just had two teeth that were massively decayed pulled, so that doesn't help much.
[19:26:10] <lightguard_jp> clerum: No, Hansty doesn't search for much of anything, very annoying at times.
[19:26:37] <lightguard_jp> Nor does he really help. Just complains about problems he finds
[19:26:57] <lincolnthree1> lightguard_jp: yeah, he uses PF and Forge too
[19:27:19] <lincolnthree1> lightguard_jp: however annoying it may be, it does highlight places where we could probably improve if presented in a better way
[19:27:22] <lightguard_jp> Ah, so you've run into him there as well.
[19:27:30] <lightguard_jp> Yes, this is true.
[19:27:40] <lightguard_jp> That's why I continue to help him out.
[19:27:46] <lincolnthree1> The delivery is off though ;) i agree.
[19:27:46] <clerum> one thing I've noticed is the weld errors numbers
[19:27:49] <clerum> don't help a lot
[19:27:54] <clerum> when searching for them
[19:28:01] <lightguard_jp> I wish he'd help us out a bit more too, either in docs, tests, code, etc
[19:28:17] <lightguard_jp> clerum: because there's no where to look yet.
[19:28:18] <clerum> I'm guessing at some point someone was going to put together a doc explaining each error...but google hasn't found it for me
[19:28:26] <clerum> yep
[19:28:43] <lightguard_jp> Yeah, there will be a database with all the info for issue numbers.
[19:28:47] <clerum> great idea...as they map to content at some point :-)
[19:28:58] <lightguard_jp> It's planned, but I'm not sure how far that's come.
[19:29:21] <clerum> docs and examples really need to come next
[19:29:56] <lightguard_jp> Yeah, that's what 3.1.1 is going to be all about.
[19:29:59] <clerum> as more people seem to starting to use it
[19:30:05] <clerum> cool
[19:30:11] <lightguard_jp> Possibly some bug fixes, but mostly docs and examples.
[19:31:45] <lightguard_jp> Our docs are getting better with this release, but still a ways to go. Same with examples
[19:31:56] <clerum> examples a big one
[19:32:07] <clerum> I can't for the life of me get rewrite to work in the @ViewConfig
[19:32:13] <clerum> but I dunno if it's a config issue or a bug
[19:33:13] *** bleathem has joined #seam-dev
[19:33:13] *** ChanServ sets mode: +v bleathem
[19:33:41] <lightguard_jp> bleathem: There are some posts to the mailing list and some pull requests you should take a look at.
[19:34:08] <bleathem> will do, as soon as I get RichFace 4.1.M3 out the door
[19:34:16] <lightguard_jp> Cool
[19:34:17] <bleathem> I need to ask Pete domething
[19:34:22] <bleathem> where does he hang out on IRC?
[19:34:31] <clerum> here usually
[19:34:33] <lightguard_jp> He's typically here
[19:34:43] <bleathem> hmm
[19:34:55] <bleathem> do we have an openshift IRC channel?
[19:34:59] <lightguard_jp> I just sent him an IM, we'll see if he shows up
[19:35:01] <lightguard_jp> Yep
[19:35:05] <lightguard_jp> #openshift I think
[19:35:20] <bleathem> yeah, it's there
[19:35:24] <bleathem> thanks!
[19:35:50] *** pmuir has joined #seam-dev
[19:36:01] <pmuir> hi bleathem
[19:36:07] <bleathem> Hi Pete
[19:36:25] <bleathem> I'm publishing the RichFaces release blog, and I'm mentioning openshift
[19:36:58] <bleathem> I wanted to vet run the wording by you (a snippet) if that's ok
[19:37:24] <lightguard_jp> Send me an IM or email if anyone needs me. I'll be back probably in a couple of hours.
[19:38:25] *** gonzalad has quit IRC
[19:42:09] *** lightguard_jp has quit IRC
[19:44:27] *** pmuir has quit IRC
[19:50:25] *** alesj has joined #seam-dev
[19:55:41] *** echelog-2 has joined #seam-dev
[19:56:20] *** emmanuel has quit IRC
[20:02:19] *** mgoldmann has quit IRC
[20:38:25] <jbossbot> git [core] push master 6ea16ed.. Lincoln Baxter, III Added XML Bind to Forge Main
[20:38:25] <jbossbot> git [core] push master URL: http://github.com/forge/core/compare/fdb67d9...6ea16ed
[20:51:26] *** edburns is now known as edburns_away
[20:53:23] *** kevinpollet has quit IRC
[21:06:31] *** jamezp is now known as jamezp_afl
[21:06:33] *** jamezp_afl is now known as jamezp_afk
[21:24:14] *** rruss has joined #seam-dev
[21:38:13] *** koentsje has joined #seam-dev
[21:39:49] *** kevinpollet has joined #seam-dev
[21:43:05] *** jamezp_afk has quit IRC
[21:43:21] *** edburns_away is now known as edburns
[21:44:55] *** jamezp_afk has joined #seam-dev
[21:44:55] *** ChanServ sets mode: +v jamezp_afk
[22:09:14] *** jamezp_afk is now known as jamezp
[22:13:50] *** sgilda has quit IRC
[22:16:26] *** nilian has joined #seam-dev
[22:22:56] *** koentsje has quit IRC
[22:26:59] *** hannelita has joined #seam-dev
[22:39:42] *** hannelita has quit IRC
[22:44:22] *** nilian has quit IRC
[22:46:12] <edburns> lincolnthree1: Still here?
[22:46:20] <lincolnthree1> edburns: barely ;)
[22:47:39] <edburns> lincolnthree1: I want to change the proposal.  Instead of 2 events, how about 3? PostValuePutToFlashEvent, PostValueKeptInFlashEvent, PostFlashClearedEvent ?
[22:48:02] <edburns> We don't individually clear values from the flash, lincolnthree1.
[22:48:02] <lincolnthree1> edburns: no complaints! would be useful to have
[22:48:05] <edburns> ok
[22:48:06] <edburns> thanks
[22:48:14] <lincolnthree1> err
[22:48:14] <edburns> Far fewer events that way.
[22:48:28] <lincolnthree1> yeah that's good
[22:49:36] <edburns> That would be PreFlashClearedEvent.
[22:49:44] <edburns> To go along with the PreDestroy theme.
[22:49:45] <lincolnthree1> ah, yes
[22:49:51] <lincolnthree1> blanked that one
[23:05:22] *** jose_freitas has quit IRC
[23:16:16] *** oskutka has quit IRC
[23:43:34] *** rruss has quit IRC
[23:52:02] *** tsurdilo has quit IRC





top