[00:11:31] *** cbrock has quit IRC
[00:24:14] *** wdrai has left #seam-dev
[00:33:13] *** kenfinnigan has joined #seam-dev
[00:59:04] *** alesj has quit IRC
[01:10:45] *** kenfinnigan_ has joined #seam-dev
[01:12:14] <jbossbot> git [conversation] push master 872ecf9.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR1
[01:12:14] <jbossbot> git [conversation] push master URL: http://github.com/seam/conversation/compare/505feb0...872ecf9
[01:12:26] <jbossbot> git [conversation] push master a775eb0.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[01:12:26] <jbossbot> git [conversation] push master URL: http://github.com/seam/conversation/compare/872ecf9...a775eb0
[01:14:59] *** kenfinni has joined #seam-dev
[01:15:08] *** kenfinnigan is now known as Guest10515
[01:15:22] *** kenfinni has quit IRC
[01:15:44] *** kenfinni has joined #seam-dev
[01:20:54] *** Guest10515 has quit IRC
[01:20:58] *** kenfinni has quit IRC
[01:21:19] *** kenfinnigan has joined #seam-dev
[01:46:40] *** aslak has quit IRC
[01:47:00] <jbossbot> git [solder] push master 1eccaa0.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[01:47:01] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/acfc758...1eccaa0
[01:47:11] <jbossbot> git [solder] push master 4cd0315.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[01:47:11] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/1eccaa0...4cd0315
[01:53:48] *** bleathem has joined #seam-dev
[02:00:15] <jbossbot> git [dist] push master 33aaba7.. Shane Bryzak updated module versions
[02:00:16] <jbossbot> git [dist] push master 4599163.. Shane Bryzak Merge remote branch 'origin/master'
[02:00:16] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/536b64d...4599163
[02:03:38] <jbossbot> git [dist] push master 3f4c3a7.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR6
[02:03:39] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/4599163...3f4c3a7
[02:03:48] <jbossbot> git [dist] push master d4de25e.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[02:03:48] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/3f4c3a7...d4de25e
[02:09:17] <jbossbot> git [config] push master 82addae.. Shane Bryzak updated seam-bom version
[02:09:18] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/7737894...82addae
[02:23:55] <jbossbot> git [config] push master e397a86.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[02:23:56] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/82addae...e397a86
[02:24:05] <jbossbot> git [config] push master 1229535.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[02:24:05] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/e397a86...1229535
[02:26:36] <jbossbot> git [international] push master 9c2df6d.. Ken Finnigan Update seam-bom to 3.0.0.CR5
[02:26:36] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/b1b09da...9c2df6d
[02:33:29] <kenfinnigan> sbryzak: ping
[02:33:47] *** johnament has joined #seam-dev
[02:34:35] <sbryzak> kenfinnigan: pong
[02:34:56] <kenfinnigan> what are the plans around upgrading Seam modules to use arquillian alpha5?
[02:35:01] <kenfinnigan> before final or after?
[02:35:29] <sbryzak> good question
[02:35:36] <sbryzak> at this stage, probably after
[02:35:38] <johnament> I vote after.  API change in pretty big.
[02:35:47] <sbryzak> we're too close to final now to change it
[02:35:57] <kenfinnigan> ok
[02:36:20] <kenfinnigan> are there any plans around 3.0.1 or 3.1 for Seam yet?
[02:36:22] <sbryzak> we'll probably release a seam 3.0.1 a few weeks after 3.0, so we'll upgrade it for that
[02:36:33] <kenfinnigan> ok cool
[02:36:45] <sbryzak> 3.1 will probably be around september
[02:36:49] <johnament> you think the maintenance is going to be that bad?
[02:37:13] <sbryzak> johnament: in what respect?
[02:37:23] <johnament> sbryzak: 3.0.1 in only a few weeks after
[02:37:42] <sbryzak> johnament: i'm just guessing at this stage
[02:37:49] <johnament> sbryzak: oh ok
[02:37:50] <sbryzak> but what i imagine will happen
[02:38:01] <sbryzak> is that a lot more people will start using 3.0 once it goes final
[02:38:15] <sbryzak> it's only the people on the bleeding edge who have been trying out the betas, CR's etc
[02:38:21] <johnament> definitely
[02:38:38] <sbryzak> and with that additional exposure, there's sure to be many issues discovered
[02:38:52] <sbryzak> especially since this is the first seam release based on cdi
[02:39:01] <sbryzak> it's practically a new framework
[02:39:11] <johnament> it is, it's all new code.
[02:39:35] <sbryzak> that's why i'm guessing we'll need to do a 3.0.1 in a few weeks
[02:39:40] <kenfinnigan> sbryzak: when is a good time to push fix for SOLDER-85?
[02:39:42] <sbryzak> we'll see though :)
[02:39:43] <jbossbot> jira [SOLDER-85] Better separation of i18n and logging concerns [Open (Unresolved) Enhancement, Major, Ken Finnigan] https://issues.jboss.org/browse/SOLDER-85
[02:40:03] <sbryzak> kenfinnigan: probably after the final
[02:40:09] <sbryzak> everything should be frozen now
[02:40:22] <sbryzak> except for bug fixes, examples and documentation
[02:42:00] <johnament> sbryzak: do you figure the little modules will end up on a separate release track then? e.g. have 3.0.0.Finals somewhere between now and mid summer leading up to 3.1's for everything in September?
[02:42:47] <sbryzak> johnament: you mean for modules that aren't in the 3.0 bundled release?
[02:43:10] <johnament> sbryzak: yeah, everything defined until now that isn't included
[02:43:34] <johnament> and who knows what else will pop up between now and then.
[02:43:36] <sbryzak> johnament: yep we'll release them as 3.0.0.Final when they're done
[02:43:41] <sbryzak> and then include them in the 3.1 release
[02:44:05] <johnament> sbryzak: ok, so not forcing them into a 3.1.0.X release cycle?
[02:44:58] <sbryzak> johnament: there shouldn't be a need
[02:45:04] <sbryzak> the 3.0 release is a special case
[02:45:29] <johnament> sbryzak: gotcha
[02:45:51] <sbryzak> we won't require anything like the number of "pre" releases that we've had in 3.0, for 3.1
[02:46:21] <johnament> sbryzak: so then all modules going forward are just going to start at 3.0.0.X ?
[02:47:02] <sbryzak> johnament: that's the plan
[02:47:18] <sbryzak> we may refine it further as we go, we are in new territory after all
[02:47:18] <johnament> ok
[02:50:11] <johnament> just removed a reference to weld-extensions in JMS :/
[02:56:34] *** cbrock has joined #seam-dev
[02:56:34] *** cbrock has quit IRC
[02:56:34] *** cbrock has joined #seam-dev
[03:02:52] <jbossbot> git [persistence] push master e677242.. Shane Bryzak update seam-bom version, rename SeamManaged to ExtensionManaged
[03:02:52] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/e149eb8...e677242
[03:04:12] <johnament> sbryzak: isn't that supposed to be in solder?
[03:04:49] <sbryzak> johnament: it is in solder, i just updated persistence to use the new solder version
[03:05:02] <johnament> sbryzak: ah.  didn't see that solder already was updated.  nevermind.
[03:05:36] <johnament> sbryzak: hm. i guess the persistence SeamManaged is more than deprecated? the pull request I sent used both.
[03:06:17] <sbryzak> i think stuart removed it completely
[03:06:25] <stuartdouglas> yea
[03:06:36] <stuartdouglas> I moved it to solder, and then it was renamed
[03:06:45] <sbryzak> reduces confusion that way
[03:07:59] <johnament> oh ok, i thought you wanted it deprecated.
[03:08:09] <johnament> makes sense.
[03:18:56] <jbossbot> git [persistence] push master a0473db.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[03:18:56] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/e677242...a0473db
[03:19:07] <jbossbot> git [persistence] push master 80f9779.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[03:19:08] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/a0473db...80f9779
[03:24:35] *** kenfinnigan has quit IRC
[03:33:19] <johnament> stuartdouglas: i sort of have my head around the issues w/ MDB in JMS.  since MDBs aren't managed in any way, and since they really exist out side of any existing scope, injecting in to them is limited (to dependent and application scoped I believe), we run into problems.
[03:33:20] *** bleathem has quit IRC
[03:33:25] *** bleathem has joined #seam-dev
[03:34:12] <johnament> In most cases, I can use application scoped, except in a few cases where it doesn't work (can't be an app scoped bean for various unnameable reasons).  dependent doesn't work well either.
[03:39:50] <johnament> sbryzak: I'm playing with an idea that should eliminate needing to have MDBs if you use Seam JMS.  Is there going to be an issue if we don't support MDBs in the API?
[03:40:33] <sbryzak> hmm, possibly not
[03:41:49] <johnament> sbryzak: i can deal with the background thread issue, but to provide consistent transaction support i need to own the incoming and outgoing messages.
[03:42:19] <johnament> and i have a feeling that MDBs aren't going to end up being portable to support
[03:43:33] <sbryzak> if it's not portable, probably not worth supporting it then
[03:43:57] <johnament> we'd need to figure out ways to test the module against glassfish, websphere, weblogic, etc.
[03:44:08] <johnament> which I'm sure redhat has.
[03:44:40] <johnament> well glassfish since I don't think any of those others have full CDI support yet.
[03:45:05] <sbryzak> i'm sure the QE team can help out with that
[03:45:41] <jbossbot> git [remoting] push master a43eb42.. Shane Bryzak fix dependencies
[03:45:42] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/d116423...a43eb42
[03:46:55] <johnament> is it worth it to try to have arquillian tests against glassfish 3.1 at this point?
[03:47:42] *** bitshuffler has joined #seam-dev
[03:56:57] <bleathem> Am I missing something obvious?
[03:56:59] <bleathem> public void enforce (@Observes PostConstructViewMapEvent event)
[03:57:10] <bleathem> I would think this would get invoked on every page view
[03:57:20] <bleathem> but my logger isn't registering anything
[03:57:29] <bleathem> JBoss AS 6
[03:58:16] <bleathem> Are there any of the bean visibility problems in AS 6?
[04:00:01] * bleathem *crickets*
[04:00:14] <johnament> what fires it?
[04:00:38] <bleathem> It's supposed to be fired by Seam Faces
[04:00:48] <bleathem> good call though, I should check that it's being fired :P
[04:01:40] <johnament> i get stuck on that all the time w/ JMS.  why aren't messages hitting my queue??? oh, they're not being fired :/
[04:03:38] <jbossbot> git [remoting] push master e7afdab.. Shane Bryzak fix seam-conversation dependencies, model example
[04:03:38] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/a43eb42...e7afdab
[04:03:44] <bleathem> stinking obvious once you say it.  I have to forgo the assumption that the libbrary is doing what it's supposed to, when I'm the one responsible for that library!
[04:03:47] *** cbrock has quit IRC
[04:04:03] <johnament> stuartdouglas: ping
[04:04:35] <stuartdouglas> johnament: pong
[04:05:14] <johnament> bleathem: that's the danger of being one of your own users.  you neglect to realize that you may have coded it wrong :-)
[04:06:25] *** bitshuffler_ has joined #seam-dev
[04:07:40] <bleathem> johnament the event is getting fired :|
[04:07:44] <bleathem> thanks!
[04:09:43] *** johnament has quit IRC
[04:10:20] *** bitshuffler has quit IRC
[04:11:43] <jbossbot> git [remoting] push master 9657a68.. Shane Bryzak update interceptor class, use ExtensionManaged annotation
[04:11:43] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/e7afdab...9657a68
[04:16:47] *** johnament has joined #seam-dev
[04:16:52] <johnament> grrr
[04:20:38] <jbossbot> git [remoting] push master 4fd755c.. Shane Bryzak update example artifactIds
[04:20:38] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/9657a68...4fd755c
[04:23:42] *** bitshuffler__ has joined #seam-dev
[04:23:56] <jbossbot> git [remoting] push master 4b35b50.. Shane Bryzak fix artifact IDs to conform with naming standard
[04:23:56] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/4fd755c...4b35b50
[04:26:45] *** bitshuffler_ has quit IRC
[04:28:10] <bleathem> ping mojavelinux OR lincolnthree1
[04:28:38] * bleathem wonders if "away"
[04:28:46] <bleathem>  /me is really "away"
[04:28:54] * bleathem fail
[04:29:04] <johnament> bleathem: still didn't work?
[04:29:26] <bleathem> Digging deeper, have some Faces questions for the previous tenants
[04:29:30] <jbossbot> git [remoting] push master 074dd87.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR2
[04:29:30] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/4b35b50...074dd87
[04:29:40] <sbryzak> bleathem: is faces module ok for a release?
[04:29:43] <jbossbot> git [remoting] push master 40962f7.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[04:29:43] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/074dd87...40962f7
[04:29:53] <bleathem> sbryzak, 1 sec
[04:30:16] <sbryzak> i don't mean this second ;)
[04:30:26] <sbryzak> later today perhaps
[04:30:27] <bleathem> Sorry, jsut wanted to review the jira
[04:30:31] <sbryzak> np
[04:30:37] <johnament> I have a wrapper API for JMS's session, connection, producer/consumer, etc.  i need a name for it
[04:30:53] <bleathem> seems like a good time for a release to me
[04:31:12] <bleathem> I'll make no further commits before a release, so when ever you are ready go for it
[04:31:15] <sbryzak> bleathem: great, i'll get it done tonight
[04:31:44] <bleathem> sbryzak cool, thanks for doing that
[04:32:17] <bleathem> johnament JmsSessionConnectionProducerConsumer not good enough for you?
[04:33:15] <bleathem> johnament, sorry, forgot the Wrapper at the end :D
[04:34:37] <bleathem> I'm dying to know why the SystemEventBridge is not registered as a System Event Listener in the Seam Faces config.xml (cc: mojavelinux lincolnthree1)
[04:34:43] <bleathem> By design, or omission?
[04:35:01] *** johnament has quit IRC
[04:41:26] *** bitshuffler has joined #seam-dev
[04:42:55] *** bitshuffler__ has quit IRC
[04:47:22] *** gastaldi has joined #seam-dev
[05:01:41] *** bitshuffler_ has joined #seam-dev
[05:02:15] <jbossbot> git [servlet] push master 1027283.. Shane Bryzak update seam-bom version
[05:02:16] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/25eb3d6...1027283
[05:02:57] <bleathem> Maybe I'm supposed to use the DelegatingSystemEventListener instead of the SystemEventBridge
[05:05:04] *** bitshuffler has quit IRC
[05:05:53] *** gastaldi has quit IRC
[05:06:59] <jbossbot> git [servlet] push master f04ea9f.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR2
[05:06:59] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/1027283...f04ea9f
[05:07:09] <jbossbot> git [servlet] push master 028a7e9.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[05:07:09] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/f04ea9f...028a7e9
[05:12:17] <bleathem> Slowly coming together... the DelegatingPhaseListener gets a list of all classes that implement SystemEventListener, and delegates JSF system events to them
[05:13:10] <bleathem> the SystemEventBridge is one of those SystemEventListeners to which the DelgegatingSystemListener delegates (mis-typed DelegatingPhaseListener in the line above)
[05:14:03] <bleathem> So the SystemEventBridge *is* registered in the faces-config.xml file, by nature of the DlegatingSystemEventListener being registered.
[05:14:30] <bleathem> in other words: nevermind mojavelinux and lincolnthree1
[05:16:08] <bleathem> Still doesn't explain my problem though - back to square 1
[05:35:07] *** gastaldi has joined #seam-dev
[05:36:57] *** gastaldi has quit IRC
[05:51:45] <jbossbot> git [catch] push master 161683e.. Shane Bryzak update seam-bom version, dependencies
[05:51:46] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/41ea4de...161683e
[05:56:38] <jbossbot> git [catch] push master 80ef901.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR2
[05:56:39] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/161683e...80ef901
[05:56:49] <jbossbot> git [catch] push master c154d9c.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[05:56:50] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/80ef901...c154d9c
[06:11:18] <bleathem> I've tried adding a <system-event-listener> to the faces-confgi.xml
[06:11:22] <bleathem> and even a @ListenerFor(systemEventClass=PostConstructViewMapEvent.class)
[06:11:49] <bleathem> An I can't get the DelegatingSystemEventListener to listen to a PostConstructViewMapEvent
[06:11:51] <bleathem> What gives
[06:15:17] <jbossbot> git [international] push master 82865e8.. Shane Bryzak update seam-bom version
[06:15:17] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/9c2df6d...82865e8
[06:22:32] <jbossbot> git [international] push master 171ffe3.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[06:22:33] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/82865e8...171ffe3
[06:22:43] <jbossbot> git [international] push master 71abb6a.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[06:22:43] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/171ffe3...71abb6a
[06:24:37] <bleathem> enough for tonight.
[06:25:24] *** rruss has quit IRC
[06:29:17] <mojavelinux> sorry about screwing things up by renaming SeamManaged to ExtensionManaged in solder; i didn't realize any module had started using it yet
[06:29:37] <mojavelinux> so I thought that the rename was safe since it was a new api
[06:29:40] <mojavelinux> my bad
[06:30:04] <mojavelinux> looks like it got resolved anyway, so we forge ahead :)
[06:30:41] <mojavelinux> sbryzak: i know that we *want* to be in freeze right now, but I think solder-85 needs to happen before final. the packaging was just plain screwy
[06:31:10] <mojavelinux> I can't imagine anyone is actually using the typed loggers prior to know, primarily because they flat out were broken before
[06:31:18] <mojavelinux> so now is the time to make them right before we actually let anyone use them
[06:31:28] <sbryzak> mojavelinux: one sec while i see what SOLDER-85 is :)
[06:31:30] <jbossbot> jira [SOLDER-85] Better separation of i18n and logging concerns [Open (Unresolved) Enhancement, Major, Ken Finnigan] https://issues.jboss.org/browse/SOLDER-85
[06:31:55] <mojavelinux> basically, we got the annotation processor separated out so that we didn't have all this bizarre dependencies on jboss logging annotations
[06:32:13] <mojavelinux> and now, we just want to make the annotations our own (as in defined by solder) and have them be sensical
[06:32:35] <sbryzak> hmm, that would require another API change
[06:32:48] <mojavelinux> right, but in this case, no one should have actually used this api yet
[06:33:00] <mojavelinux> in a sense, now is the time to make it right
[06:33:04] <sbryzak> are they likely to use it in the final release?
[06:33:07] <mojavelinux> so we don't have to break the api again
[06:33:16] <mojavelinux> very likely now that we have documentation for it
[06:33:22] <mojavelinux> the only dependent module is seam servlet
[06:33:27] <mojavelinux> since that's the only module that uses the annotations so far
[06:33:31] <mojavelinux> and that hasn't been released yet
[06:33:42] <sbryzak> it has now
[06:33:44] <mojavelinux> ah
[06:33:56] <sbryzak> i've done a new release of solder today
[06:33:56] <mojavelinux> you must have done that in the last day then...didn't see it
[06:34:01] <sbryzak> because of the ExtensionManaged change
[06:34:06] <mojavelinux> i mean seam servlet
[06:34:15] <sbryzak> servlet is released also
[06:34:25] <sbryzak> and about half a dozen other modules
[06:34:30] <mojavelinux> bah! cashed html page
[06:34:34] <mojavelinux> cached html page
[06:34:35] <mojavelinux> I see it now
[06:34:51] <mojavelinux> had to do Ctrl+Refresh on nexus web view
[06:35:04] <sbryzak> what's the ramifications here if we change it after final
[06:35:33] <sbryzak> which classes are actually user-facing
[06:35:47] <mojavelinux> the annotations on the typed logger and message bundles
[06:35:58] <mojavelinux> but it's also *really* hard to deprecate one annotation in favor of a rename
[06:36:18] <mojavelinux> because the annotation processor can't easily support both the old and new names
[06:36:34] <sbryzak> argh, this sucks
[06:36:36] <mojavelinux> so we really want it correct out of the gate...and the packaging was just screwy
[06:36:51] <sbryzak> i've spent all day getting releases ready for CR3
[06:37:09] <mojavelinux> this feature was just so poorly done to begin with, that ken and I have really pressed and worked to get it exactly right, but this is the final straw
[06:37:11] <sbryzak> how quick can we get the changes made?
[06:37:48] <mojavelinux> the changes to the api are pretty small, I think ken has them sitting on his local repo
[06:38:11] <sbryzak> hmm, ok as long as it can be done ASAP, let's proceed with it
[06:38:20] <sbryzak> but that's absolutely the last API change before the final release
[06:38:45] <mojavelinux> totally understand...trust me, I hate even having to ask this
[06:38:54] <sbryzak> CR3 will have to be delayed by a day or so i guess
[06:39:21] <mojavelinux> but I really believe that we save ourselves a lot of pain if we do it now, in terms of having to not break an api post final
[06:39:24] <sbryzak> it's ok, better to break stuff now though
[06:40:01] <sbryzak> btw, i was testing the catch example
[06:40:15] <sbryzak> it was throwing some exceptions which i don't think it should have been
[06:40:16] <mojavelinux> okay, let me e-mail ken and give him a chance to push the changes...if he doesn't get to it by tomorrow morning, I can push up the changes
[06:40:32] <sbryzak> seems one of the servlet producer methods is returning a null value
[06:40:48] <sbryzak> once jason comes online i'll ask him to check it out
[06:40:53] <sbryzak> it might be a bug in seam-servlet though
[06:41:12] <sbryzak> thanks
[06:41:22] <sbryzak> let me know as soon as it's done, i'll restart the release process
[06:42:10] <mojavelinux> k
[06:43:01] <mojavelinux> my timing is a bit off because I absolutely ran out of gas after last night and slept for a long time
[06:43:07] <mojavelinux> I'm sure you are ready to do the same
[06:47:14] *** sbryzak has quit IRC
[06:56:43] <mojavelinux> okay, i e-mailed ken and updated the jira with helpful pointers to make sure it's done absolutely right
[06:57:02] <mojavelinux> i'll prepare a pull request as a backup if ken doesn't respond by his tomorrow morning (~8 hrs from now)
[06:57:26] <mojavelinux> I'll verify the tests, and also I'll update seam servlet
[06:57:30] <mojavelinux> starting on it now
[06:58:04] *** sbryzak has joined #seam-dev
[07:15:33] <jbossbot> git [solder] push master bfb90e7.. Dan Allen fix compliance of LoggerInjectionTest...
[07:15:34] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/4cd0315...bfb90e7
[08:34:48] *** daniel_hinojosa has quit IRC
[09:09:48] *** jharting has joined #seam-dev
[09:22:15] *** bitshuffler_ has quit IRC
[09:30:40] <jbossbot> git [solder] push master 7fc1098.. Dan Allen SOLDER-85 repackage typed message bundle and logger...
[09:30:41] <jbossbot> jira [SOLDER-85] Better separation of i18n and logging concerns [Open (Unresolved) Enhancement, Major, Ken Finnigan] https://issues.jboss.org/browse/SOLDER-85
[09:30:42] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/bfb90e7...7fc1098
[09:49:50] <jbossbot> git [servlet] push master 16fe9c7.. Dan Allen SOLDER-85 update typed message bundle and loggers...
[09:49:51] <jbossbot> jira [SOLDER-85] Better separation of i18n and logging concerns [Open (Unresolved) Enhancement, Major, Ken Finnigan] https://issues.jboss.org/browse/SOLDER-85
[09:49:51] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/028a7e9...16fe9c7
[09:51:44] <jbossbot> git [international] push master d876d37.. Dan Allen SOLDER-85 repackage typed message bundle and logger...
[09:51:45] <jbossbot> jira [SOLDER-85] Better separation of i18n and logging concerns [Open (Unresolved) Enhancement, Major, Ken Finnigan] https://issues.jboss.org/browse/SOLDER-85
[09:51:46] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/71abb6a...d876d37
[09:59:37] <mojavelinux> that should do it. off to bed now :)
[11:12:04] *** alesj has joined #seam-dev
[12:07:36] <jbossbot> git [dist] push master 352a076.. Shane Bryzak updated module versions
[12:07:36] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/d4de25e...352a076
[12:10:09] <jbossbot> git [dist] push master 1804cd1.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR7
[12:10:09] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/352a076...1804cd1
[12:10:19] <jbossbot> git [dist] push master 50ec064.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[12:10:19] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/1804cd1...50ec064
[12:16:15] <jharting> sbryzak: ping
[12:16:23] <sbryzak> jharting: pong
[12:17:09] <jharting> sbryzak: Hi Shane, I will do the CR2 release of the REST module if it does not conflict with your plan
[12:17:25] <jharting> sbryzak: *do the release later today
[12:17:47] <sbryzak> jharting: no problem, the new seam-bom version is 3.0.0.CR7
[12:17:57] <sbryzak> does it use solder?
[12:18:14] <jharting> sbryzak: yes, it dependes on solder and catch
[12:18:26] <jharting> *depends
[12:18:31] <sbryzak> ok, i haven't done those releases yet
[12:18:35] <sbryzak> they should be done shortly though
[12:19:45] <jharting> sbryzak: I believe I've seen the CR2 of catch already
[12:20:06] <jharting> sbryzak: is this version going into the release? or should I wait for CR3?
[12:20:08] <sbryzak> it needs another release
[12:20:25] <jharting> sbryzak: ic
[12:20:50] <jharting> sbryzak: then just ping me or drop me an e-mail once those two modules are released so that I can begin
[12:21:21] <sbryzak> no problem
[12:23:26] <jbossbot> git [solder] push master 4d0765b.. Shane Bryzak update seam-bom version
[12:23:27] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/7fc1098...4d0765b
[12:25:59] <jbossbot> git [dist] push master ae2d32c.. Shane Bryzak got the version wrong for solder.. :(
[12:26:00] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/50ec064...ae2d32c
[12:26:13] <sbryzak> jharting: seam-bom version will actually be 3.0.0.CR8, i screwed up
[12:27:08] <jbossbot> git [dist] push master 5c2e59e.. Shane Bryzak oops
[12:27:08] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/ae2d32c...5c2e59e
[12:28:18] <jbossbot> git [dist] push master 95afab4.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR8
[12:28:18] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/5c2e59e...95afab4
[12:28:27] <jbossbot> git [dist] push master 6459754.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[12:28:27] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/95afab4...6459754
[12:31:44] <jbossbot> git [solder] push master 9c0743a.. Shane Bryzak updated seam-bom version
[12:31:44] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/4d0765b...9c0743a
[12:35:14] <nickarls> sounds like a seam release is in the air
[12:39:30] *** alesj has left #seam-dev
[12:39:42] <jbossbot> git [solder] push master f3b607c.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR4
[12:39:43] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/9c0743a...f3b607c
[12:39:53] <jbossbot> git [solder] push master 5a5f6c4.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[12:39:54] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/f3b607c...5a5f6c4
[12:48:39] *** aslak has joined #seam-dev
[12:48:39] *** aslak has quit IRC
[12:48:39] *** aslak has joined #seam-dev
[12:55:09] <nickarls> hmm, how come when I have an interceptor that catches and rethrows as an @ApplicationException, my EJB still dies?
[12:55:21] <jbossbot> git [config] push master abfd8cd.. Shane Bryzak update seam-bom version
[12:55:22] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/1229535...abfd8cd
[12:56:15] <nickarls> interceptors wrap another WeldException on top?
[13:00:08] <jbossbot> git [config] push master 04e23a5.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR4
[13:00:08] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/abfd8cd...04e23a5
[13:00:19] <jbossbot> git [config] push master c38ab33.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[13:00:19] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/04e23a5...c38ab33
[13:12:57] <jbossbot> git [servlet] push master 7eea109.. Shane Bryzak update seam-bom version
[13:12:57] <jbossbot> git [servlet] push master eb84d43.. Shane Bryzak Merge remote branch 'origin/master'
[13:12:57] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/16fe9c7...eb84d43
[13:20:34] <jbossbot> git [servlet] push master a898d1b.. Shane Bryzak fixed dependency versions
[13:20:34] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/eb84d43...a898d1b
[13:25:15] <jbossbot> git [servlet] push master 6f017ea.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[13:25:15] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/a898d1b...6f017ea
[13:25:26] <jbossbot> git [servlet] push master 971ae94.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[13:25:26] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/6f017ea...971ae94
[13:35:01] <jbossbot> git [catch] push master 3a481ab.. Shane Bryzak updated seam-bom version
[13:35:02] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/c154d9c...3a481ab
[13:39:44] <jbossbot> git [catch] push master 5e2ecf2.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[13:39:45] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/3a481ab...5e2ecf2
[13:39:54] <jbossbot> git [catch] push master e7d8e19.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[13:39:54] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/5e2ecf2...e7d8e19
[13:49:17] *** gastaldi has joined #seam-dev
[13:50:32] <sbryzak> jharting: solder and catch are released now
[13:50:47] <jharting> sbryzak: ok, thanks
[13:51:15] <jbossbot> git [persistence] push master 16c56e5.. Shane Bryzak update seam-bom version
[13:51:15] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/80f9779...16c56e5
[13:58:45] <gastaldi> hey aslak !
[13:58:54] <aslak> gastaldi, heya
[13:59:30] <gastaldi> Does arquillian alpha-5 run on Weld 1.1 ?
[13:59:41] <aslak> gastaldi, should
[13:59:53] <aslak> tested with 1.1.0.Final
[13:59:57] <jbossbot> git [persistence] push master d83da5f.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR4
[13:59:57] <gastaldi> great
[13:59:57] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/16c56e5...d83da5f
[14:00:08] <jbossbot> git [persistence] push master 78e2973.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[14:00:08] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/d83da5f...78e2973
[14:00:19] <gastaldi> we had to change our poms because of that
[14:00:51] 
[14:01:02] <gastaldi> and let u know if anything happens
[14:01:28] *** lincolnthree1 has quit IRC
[14:08:22] <gastaldi> sbryzak: Do we have any new seam-parent pom ?
[14:08:41] <sbryzak> gastaldi: no, just seam-bom
[14:08:51] <gastaldi> ok
[14:09:28] <gastaldi> which version would that be ?
[14:09:32] <gastaldi> 3.0.0.CR5 ?
[14:10:07] <sbryzak> CR8
[14:11:23] <gastaldi> tks
[14:15:10] <gastaldi> Is Seam Render a new module ?
[14:16:29] *** alesj has joined #seam-dev
[14:16:48] <gastaldi> Could become part of Seam Reporting
[14:21:59] <jbossbot> git [international] push master 84494d7.. Shane Bryzak updated seam-bom version
[14:21:59] <jbossbot> git [international] push master 9e36922.. Shane Bryzak Merge remote branch 'origin/master'
[14:22:00] <jbossbot> git [international] push master 8373482.. Shane Bryzak [maven-release-plugin] rollback the release of 3.0.0.CR4
[14:22:00] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/d876d37...8373482
[14:38:12] <jbossbot> git [international] push master c1724f3.. Shane Bryzak update solder version
[14:38:12] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/8373482...c1724f3
[14:43:24] <jbossbot> git [international] push master f0a471d.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR4
[14:43:24] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/c1724f3...f0a471d
[14:43:34] <jbossbot> git [international] push master 5fb0e18.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[14:43:35] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/f0a471d...5fb0e18
[14:45:38] <gastaldi> aslak: addManifestResource was changed to addAsManifestResource ?
[15:02:44] <aslak> gastaldi, yea
[15:12:11] *** kuuyee has joined #seam-dev
[15:14:18] <kuuyee> ??
[15:23:08] *** johnament has joined #seam-dev
[15:24:35] <gastaldi> hey johnament !
[15:24:43] <johnament> hey gastaldi
[15:25:03] <gastaldi> I upgraded Seam JCR to Arquillian 1.0.0.Alpha5
[15:25:33] <johnament> we don't have a arquillian.xml right?
[15:25:38] <gastaldi> no
[15:25:47] <johnament> that should work pretty straightforward then i think
[15:25:56] <gastaldi> I already pushed into my fork
[15:26:08] <johnament> did it run?
[15:26:12] <gastaldi> yes
[15:26:14] <johnament> cool
[15:26:20] <gastaldi> Weld 1.1 final
[15:26:52] <gastaldi> Should I create a pull request or directly merge into trunk ?
[15:27:06] <johnament> you should always create a pull request, and an issue preferrably
[15:27:09] <gastaldi> ok
[15:27:39] <johnament> did you have to change any code, or did it just work?
[15:28:14] <jbossbot> git [faces] push master 189f4ff.. Shane Bryzak updated seam-bom version, seam-transaction imports
[15:28:15] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/9d1210b...189f4ff
[15:28:34] <sbryzak> bleathem: ping
[15:29:19] <gastaldi> I had to change one line on each test: addManifestResource was changed to addAsManifestResource
[15:29:28] <gastaldi> each class, I mean
[15:30:01] <johnament> ok, so just a shrinkwrap change. cool
[15:30:26] <gastaldi> Pull request and SEAMJCR-15 created
[15:30:28] <jbossbot> jira [SEAMJCR-15] Upgrade to Arquillian 1.0.0Alpha-5 [Open (Unresolved) Library Upgrade, Major, Unassigned] https://issues.jboss.org/browse/SEAMJCR-15
[15:30:34] <aslak> johnament, gastaldi, you don't use any AS_CLIENT testing ?
[15:31:07] <gastaldi> aslak: We are using just arquillian-weld-se-embedded-1.1
[15:31:19] <aslak> ok :)
[15:31:57] <gastaldi> But of course, a different AS client is something we should be using
[15:32:11] <johnament> gastaldi: i'm pulling and building now
[15:32:17] <gastaldi> great
[15:32:27] <gastaldi> I ignored that bizarre randomly failing test
[15:32:33] <johnament> aslak: no, we test against Weld 1.1 embedded, not against an app server deployment.
[15:32:40] <gastaldi> from jackrabbit
[15:32:53] <johnament> does it happen now still?
[15:33:11] <gastaldi> still
[15:33:18] <johnament> only on hudson?
[15:33:20] 
[15:33:30] <gastaldi> no, it fails on mvn test
[15:33:35] <gastaldi> But passes on Eclipse
[15:33:42] <johnament> it was passing for me.
[15:33:55] <johnament> is it possibly due to not having a clean workspace each time?
[15:33:59] <gastaldi> could be
[15:34:18] 
[15:34:29] <johnament> can we perhaps turn on debug for jackrabbit to see what's happening?
[15:34:51] <johnament> modeshape wouldn't have this issue as it's using an in memory repository, not file system based.
[15:35:13] <johnament> can we switch jackrabbit to use an in memory repository ?
[15:36:22] <jbossbot> git [jcr] push master 182c49b.. George Gastaldi Updated seam-bom
[15:36:22] <jbossbot> git [jcr] push master 83ecb70.. George Gastaldi Updated to Arquillian 1.0.0.Alpha5
[15:36:22] <jbossbot> git [jcr] push master bc64fcd.. John Ament Minor changes to listener tests.
[15:36:22] <jbossbot> git [jcr] push master 8a938c4.. John Ament Merge branch 'master' of github.com:seam/jcr...
[15:36:22] <jbossbot> git [jcr] push master 27bd9b4.. John Ament Merge branch 'master' of https://github.com/gastaldi/jcr
[15:36:23] <jbossbot> git [jcr] push master URL: http://github.com/seam/jcr/compare/e103520...27bd9b4
[15:38:38] <gastaldi> Ok, closed JIRA issue
[15:40:19] <johnament> i forgot to mark alpha1 released :-(
[15:40:53] <gastaldi> My maven-plugin would do that automatically :)
[15:41:16] *** kuuyee has quit IRC
[15:42:04] <johnament> aslak: is the conversion for jbossas-managed-6 too rough for alpha5?
[15:42:29] <johnament> I may as well upgrade Seam JMS now.
[15:42:48] <gastaldi> maybe a new seam-parent would help ?
[15:43:45] <johnament> gastaldi: no, the projects in 3.0.0.Final are waiting until after the release to upgrade
[15:44:15] 
[15:45:21] <johnament> gastaldi: JCR's a really simple case, since it deploys locally.  in the case of JMS, it's a remote deployment including deploying message queues/topics.
[15:46:39] <gastaldi> Which servers are u testing on ?
[15:48:21] <johnament> AS6.
[15:49:01] <gastaldi> What about ActiveMQ ?
[15:49:52] <johnament> gastaldi: one of my near term goals.  the project lead's gone MIA though :/
[15:50:09] <gastaldi> :)
[15:50:22] <johnament> really we should be able to test it against remote, but it currently only looks at initial context to lookup the resources.
[15:50:40] <gastaldi> right
[15:52:29] <gastaldi> hummmm we could use some ideas in JCR also
[15:52:30] <mojavelinux> john and george, since you are both on right now, I wanted to share something with you
[15:52:41] <gastaldi> mojavelinux: go on
[15:52:44] <mojavelinux> I'm especially proud of the seam jcr module because it's the first time in Seam's history
[15:52:53] <mojavelinux> that we've had a module for a technology with reps from two implementations
[15:53:05] <mojavelinux> that would be like having an eclipselink person on the seam jpa/persistence module
[15:53:07] <mojavelinux> plus
[15:53:08] <sbryzak> mojavelinux: we have a test failure in the faces module
[15:53:20] <mojavelinux> it's the first time we've ever done jcr
[15:53:27] <mojavelinux> so it's like doubly exciting ;)
[15:53:27] <gastaldi> :)
[15:53:33] <gastaldi> agreed
[15:53:39] <johnament> mojavelinux: i'm glad you're happy with it.
[15:53:45] <mojavelinux> it's awesome to watch you guys share perpectives
[15:53:46] <mojavelinux> and yes
[15:53:47] <johnament> we're getting good support from the modeshape folks.
[15:53:49] <mojavelinux> it's a huge opportunity
[15:53:56] <sbryzak> mojavelinux: http://pastebin.com/pMcEe0m5
[15:53:58] <mojavelinux> to do cross application server testing
[15:54:01] <mojavelinux> k, got it shane
[15:54:20] <sbryzak> mojavelinux: seems to be a problem with the international module and message bundles
[15:54:20] 
[15:54:22] <mojavelinux> so we can test on jboss as and we can test on tomcat w/ activemq or something
[15:54:38] <mojavelinux> oops, crossing thoughts
[15:54:42] <mojavelinux> that's for jms ;)
[15:54:50] <mojavelinux> I mean jackrabbit
[15:55:18] <johnament> mojavelinux: we don't use app servers in JCR
[15:55:35] 
[15:55:41] <mojavelinux> hahaha, true
[15:55:46] <johnament> mojavelinux: ideally, i think we can remove that need from JMS as well.
[15:56:10] <mojavelinux> though testing it may still come in handy for integration purposes
[15:56:19] <mojavelinux> after all, we don't need an app server for cdi, but just look at glassfish :)
[15:56:31] <mojavelinux> it's important to check all runtime environments anyway
[15:56:40] <johnament> agreed, we shouldn't remove it as a possible testing scenario, but ideally it remove it as the default one.
[15:57:09] <johnament> similar to how george setup the JCR tests, I want to setup embedded HornetQ & ActiveMQ test cases.
[15:57:20] <mojavelinux> absolutely
[15:58:34] <johnament> at least in most cases when i've done JMS implementations before, the JMS server is running standalone somewhere, and the producers & consumers are all remote.  MDBs are ok, but not great solutions.
[15:59:21] <johnament> I just added a MessageBuilder API & IMPL for this exact purpose, testing when you're away from the server.
[16:01:10] <gastaldi> ok, gotta go
[16:01:13] <gastaldi> see ya !
[16:01:19] <johnament> bye bye
[16:01:35] *** gastaldi has quit IRC
[16:03:05] <mojavelinux> sbryzak:  it was missing some classes in the deployment archive, likely from other changes to i18n
[16:03:10] <mojavelinux> want me to push ?
[16:03:19] <sbryzak> mojavelinux: yes please
[16:03:39] <jbossbot> git [faces] push master c1570a9.. Dan Allen add missing classes for test
[16:03:39] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/189f4ff...c1570a9
[16:04:21] <jbossbot> git [examples] push master bb418c7.. Dan Allen SOLDER-85 update to use repackaged annotations
[16:04:23] <jbossbot> jira [SOLDER-85] Better separation of i18n and logging concerns [Resolved (Done) Enhancement, Major, Dan Allen] https://issues.jboss.org/browse/SOLDER-85
[16:04:23] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/d5932ae...bb418c7
[16:04:34] <mojavelinux> I realized I had forgotten to push the changes to booking
[16:04:37] <mojavelinux> now it's correct
[16:04:52] <sbryzak> faces builds now, thanks :)
[16:04:56] <mojavelinux> time for breakfast ;)
[16:08:08] <nickarls> BTW, does catch have a interceptor for catch (Exception) e and firing an event for it?
[16:11:04] <jbossbot> git [faces] push master 24e01f9.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR2
[16:11:05] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/c1570a9...24e01f9
[16:11:15] <jbossbot> git [faces] push master da0cc20.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[16:11:15] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/24e01f9...da0cc20
[16:12:19] *** alesj has left #seam-dev
[16:12:37] <sbryzak> nickarls: you need to ask those questions when the module lead is online ;)
[16:22:43] <jbossbot> git [remoting] push master 46b24e3.. Shane Bryzak updated seam-bom version
[16:22:43] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/40962f7...46b24e3
[16:28:01] <jbossbot> git [remoting] push master b7c8124.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[16:28:02] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/46b24e3...b7c8124
[16:28:12] <jbossbot> git [remoting] push master 1f15097.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[16:28:13] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/b7c8124...1f15097
[16:33:23] <johnament> who did XML config? sbryzak ?
[16:33:36] <mojavelinux> stuart
[16:33:39] <sbryzak> johnament: stuartdouglas wrote it
[16:33:48] <johnament> i should have read first.
[16:37:49] <johnament> ok, i want to use alternatives anyway.
[16:41:39] <bleathem> mojavelinux did you have time to read my email by any chance?
[16:42:10] <bleathem> the one about DelegatingSystemEventListener?
[16:42:16] <mojavelinux> haven't made it down that far yet...though I saw you mentioning something about that in the IRC logs
[16:42:19] <mojavelinux> let me take a look
[16:42:35] <bleathem> Yeah, the email is a summary of my IRC diary
[16:42:59] <mojavelinux> hahaha
[16:45:33] <johnament> mojavelinux: i want to recommend the current dev branch (e.g. mine) as Seam JMS Alpha2, but I haven't heard from Jordan in a while...
[16:46:30] <mojavelinux> ah...at the rate you've been progressing, you might earn the module lead spot :)
[16:46:36] <johnament> :/
[16:46:44] <johnament> I don't want to kick him out.
[16:46:47] <mojavelinux> i'd really like to see a release out of jms, because as pete said, it's really an exciting module
[16:47:04] <mojavelinux> it's alright, we hand off
[16:47:12] <mojavelinux> like a quarterback and running back, both stars :)
[16:47:16] <johnament> haha
[16:47:46] <mojavelinux> bleathem: has stepped up like a champ, and lincoln is probably just as excited ;)
[16:47:57] <mojavelinux> plus, bleathem gets to banter "the former owners" hahaha
[16:47:59] <johnament> the problem, I think, was after SEAMJMS-6 got pushed and it failed in Martin's testing, I think he lost some interest
[16:48:01] <jbossbot> jira [SEAMJMS-6] Routes should be produced instead of returned from an annotated method [Closed (Done) Feature Request, Major, Jordan Ganoff] https://issues.jboss.org/browse/SEAMJMS-6
[16:48:08] <bleathem> lol
[16:48:32] <mojavelinux> yeah, you guys really had to take some rough news in stride
[16:48:56] <mojavelinux> but the discovery was soooooo important for cdi 1.1
[16:49:00] <johnament> it was.
[16:49:40] <johnament> I was thinking of backing out the change, so that the old behavior worked again.
[16:49:43] <mojavelinux> if nothing else, you could say that the biggest success of the jms module was hitting the roadblock
[16:50:05] <johnament> and with the way i implemented observer method interfaces, it'll all just fall into line and start working
[16:50:26] <mojavelinux> I've been wanting to take a close look, but as you can probably imagine, i've been a bit flooded :)
[16:50:34] <mojavelinux> awesome!
[16:50:40] <johnament> well someone had to make seam work on glassfish
[16:51:27] <bleathem> I feel bad asking mojavelinux questions :P Trust me, I've been restraining myself knowing how busy you are!
[16:51:29] <mojavelinux> yeah, no kidding, we got put through the grinder on that one
[16:52:11] <bleathem> I need to expand the Faces developer pool, to have more people to toss ideas around with
[16:52:27] <johnament> we probably need to get glassfish jms testing working.
[16:52:31] <mojavelinux> i've been lobbying to get you some richfaces guys
[16:52:54] <mojavelinux> yep, john, i was waiting for alpha5 to push that, because we really needed to have descriptor deployment
[16:53:01] *** johnament is now known as johnament_away
[16:53:05] <mojavelinux> which we now have (or the infra for)
[16:53:19] <bleathem> mojavelinux that'd be cool, some neat synergy could be achieved with RichFaces (to use an annoying buzzword)
[16:53:23] <johnament_away> the problem in the module is that we force the deployment of a hornetq artifact
[16:53:37] <johnament_away> in the war file.
[16:53:44] <mojavelinux> yep, we have the same issue in our arquillian showcase
[16:53:45] <johnament_away> so we need to get that removed.
[16:53:55] <bleathem> breakfast time, back in a bit
[16:53:56] <mojavelinux> we just assume we've got a known jboss queue
[16:54:06] <mojavelinux> yep, but with alpha5, so much is possible now
[16:54:13] <johnament_away> yeah, i need to dig into it.
[16:54:17] <johnament_away> but i've gotta run for now.
[16:54:19] <mojavelinux> and if you find a bug, alpha6 isn't so far away
[16:54:19] <mojavelinux> k
[16:54:21] <mojavelinux> take care
[16:54:25] <johnament_away> cya
[16:54:29] <mojavelinux> bleathem: i'm checking out your roadblock
[16:55:46] <aslak> we might not have Descriptors, but we do have Descriptor deployment support: https://github.com/arquillian/arquillian/blob/master/containers/jbossas-managed-6/src/test/java/org/jboss/arquillian/container/jbossas/managed_6/DescriptorDeploymentTestCase.java
[16:55:48] <aslak> ;)
[16:57:22] <mojavelinux> awesome
[16:57:41] <mojavelinux> exactly
[16:57:50] <mojavelinux> btw, did we decide yet on the test enablement?
[16:58:08] <mojavelinux> meaning test selected based on container? so we can have one test for glassfish and another for jboss as?
[16:58:16] <aslak> nope
[16:58:20] <mojavelinux> k
[16:58:37] <mojavelinux> sounds like a good topic for the next meeting :)
[16:58:40] <mojavelinux> arquillian meeting that is
[16:58:42] <aslak> yea
[16:58:44] <mojavelinux> cool
[16:58:53] <aslak> that and how to split up the build
[16:59:01] <mojavelinux> absolutely
[16:59:11] <mojavelinux> perhaps next week?
[16:59:30] <aslak> yea, monday good for you?
[16:59:33] <mojavelinux> also, we can use the meeting bot in jbosstesting
[16:59:40] <aslak> sure
[16:59:51] <mojavelinux> i think jason set that up for us, though max I think was involved
[16:59:56] <mojavelinux> it's really nice
[17:00:22] <mojavelinux> monday could work, let's check with alr
[17:00:43] <mojavelinux> gotta chase down a bug for bleathem atm
[17:01:12] <aslak> sure
[17:02:30] <jbossbot> git [rest] push master afad6ce.. Jozef Hartinger updated release notes
[17:02:30] <jbossbot> git [rest] push master 473cc28.. Jozef Hartinger bump bom version
[17:02:30] <jbossbot> git [rest] push master URL: http://github.com/seam/rest/compare/ec2bf52...473cc28
[17:06:16] <mojavelinux> aslak btw!
[17:06:27] <mojavelinux> my wife has been e-mailing alex to add events to the calendar
[17:06:43] <mojavelinux> alex just about fell out of his (her?) chair
[17:06:53] <aslak> ?
[17:07:10] <aslak> she used her own email or ?
[17:07:13] <mojavelinux> mine
[17:07:16] <mojavelinux> stealth
[17:07:19] <aslak> right
[17:07:30] <aslak> to many events ?
[17:07:48] <mojavelinux> just that we replied
[17:07:55] <mojavelinux> oops, axel
[17:07:57] <mojavelinux> hahaha
[17:08:02] <mojavelinux> like axel rose
[17:08:25] <mojavelinux> also she's been putting it in lanyrd
[17:08:37] <mojavelinux> http://www.jboss.org/events.html
[17:08:39] <aslak> i'm not following? He was shocked to get emails about events ?
[17:10:01] <mojavelinux> yep, surprised that "we" actually sent him something
[17:10:10] <mojavelinux> but the long and short of it is, we are on the calendar now :)
[17:10:18] <aslak> cool
[17:10:23] <mojavelinux> "i'll" send in your talks for geecon
[17:10:36] <bleathem> mojavelinux, let me pull back the urgency on my blocker, I've got it working with a prerenderviewevent, we can swap in the more appropriate event later when there is more time to figure out what's wrong
[17:10:40] <aslak> i sent him something around the extra jug in berlin during judcon
[17:10:58] <mojavelinux> cool...i had been meaning to do it, but you know, time
[17:11:11] <mojavelinux> bleathem: I'm still interested to know what's going on, so i'm looking ;)
[17:11:14] <bleathem> In the mean time I can build up the whole Seam Security integration
[17:11:44] <bleathem> indeed, interest is why I dug into it so much last night
[17:11:49] <jbossbot> git [validation] push master 31de508.. Shane Bryzak update seam-bom version, fix example
[17:11:49] <jbossbot> git [validation] push master URL: http://github.com/seam/validation/compare/d6e4b3f...31de508
[17:11:58] <bleathem> when things don't work as they are supposed to, I need to know why!
[17:14:10] <mojavelinux> that is *exactly* my philosophy
[17:14:43] <mojavelinux> I'm a tortured soul :) but it pays out, no doubt
[17:15:12] *** Diablo-D3 has quit IRC
[17:16:48] <jbossbot> git [validation] push master fa7370c.. Shane Bryzak updated example artifact ID
[17:16:48] <jbossbot> git [validation] push master URL: http://github.com/seam/validation/compare/31de508...fa7370c
[17:18:11] <jbossbot> git [validation] push master c51c3bd.. Shane Bryzak updated example artifact ID
[17:18:12] <jbossbot> git [validation] push master URL: http://github.com/seam/validation/compare/fa7370c...c51c3bd
[17:22:03] <bleathem> mojavelinux I think it's how we all ended up contributing to open source.  We've start with some library that doesn't do quite what it should, and down the rabbit hole we go!
[17:22:06] <jbossbot> git [validation] push master 1824a28.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR2
[17:22:06] <jbossbot> git [validation] push master URL: http://github.com/seam/validation/compare/c51c3bd...1824a28
[17:22:16] <jbossbot> git [validation] push master e79214d.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[17:22:17] <jbossbot> git [validation] push master URL: http://github.com/seam/validation/compare/1824a28...e79214d
[17:27:00] <nickarls> sbryzak: the module lead might be somewhere shouting "push!" right now (not referring to git) ;-)
[17:27:15] <sbryzak> nickarls: ah yes, i almost forgot about that
[17:28:12] <jbossbot> git [rest] push master 0314fef.. Jozef Hartinger minor
[17:28:12] <jbossbot> git [rest] push master URL: http://github.com/seam/rest/compare/473cc28...0314fef
[17:29:46] <bleathem> I've been happily running/deploying to JBoss AS 6 from the command line, since AS 6 isn't working right with Netbeans 7 beta 2
[17:29:49] <bleathem> Now I want to debug
[17:30:01] <bleathem> Guess I'm going to have to bite the Eclipse bullet
[17:30:23] <bleathem> or maybe I should invest time in learning IDEA instead of re-learning Eclipse
[17:30:34] <bleathem> JBoss tools is very compelling though
[17:31:44] <bleathem> The dilemmas faced by a modern Java developer... if only we were a more poetic group, we have so much material!
[17:31:51] <mojavelinux> if you install eclipse java ee bundle, then go into eclipse marketplace and get jboss tools and m2eclipse, it should open the project right out of the box
[17:32:13] <mojavelinux> not that I love eclipse, but atm, it gets the job done for me :)
[17:32:31] <mojavelinux> only downside is, glassfish plugin for eclipse seems to be hosed
[17:32:36] <mojavelinux> ever since the java.net debacle
[17:32:58] <mojavelinux> I have it installed on an old eclipse installation of eclipse, and I keep copying that bundle around ;)
[17:33:51] <bleathem> It's turning into Netbeans for Glassfish, and Eclipse/JBoss tools for JBoss AS 6
[17:34:21] <nickarls> anyone know if there is AS 7 support in JBT trunk yet? ;-)
[17:34:43] <sbryzak> 2.30am, time for bed.. night guys
[17:34:44] <bleathem> nickarls and people accuse me of being bleeding edge!
[17:34:59] <bleathem> sbryzak long day!
[17:37:32] <aslak> mojavelinux, axel kandel right ?
[17:37:42] <mojavelinux> yes
[17:41:10] <jbossbot> git [rest] push master b0570e6.. Jozef Hartinger [maven-release-plugin] prepare release 3.0.0.CR2
[17:41:10] <jbossbot> git [rest] push master URL: http://github.com/seam/rest/compare/0314fef...b0570e6
[17:41:14] <jbossbot> git [rest] push master 33d5d33.. Jozef Hartinger [maven-release-plugin] prepare for next development iteration
[17:41:15] <jbossbot> git [rest] push master URL: http://github.com/seam/rest/compare/b0570e6...33d5d33
[17:41:42] <bleathem> I wonder if I can use my NebeansProjects folder as my eclipse workspace
[17:42:12] <bleathem> or I should say: "I'm going to see if I can use my NetbeansProjects folder as my eclipse worskspace"
[17:42:23] <bleathem> That's worth a tweet
[17:42:33] <mojavelinux> should be fine, eclipse just puts a .eclipse there
[17:44:19] <mojavelinux> 12:41:18,015 INFO  [org.jboss.seam.faces.event.DelegatingSystemEventListener] Processing javax.faces.event.PostConstructViewMapEvent
[17:44:45] <mojavelinux> "This must happen on the first time a call is made to UIViewRoot#getViewMap on a UIViewRoot instance. The source for this event is the UIViewRoot."
[17:45:03] <mojavelinux> I created a @ViewScoped bean and referenced it from EL
[17:45:13] <mojavelinux> so it's only called when you hit the ViewMap the first time
[17:45:16] <mojavelinux> that event
[17:48:20] <bleathem> Ok, but can you observe is programatically?
[17:48:40] <bleathem> With an SystemEventListener?
[17:48:46] <mojavelinux> sure
[17:48:52] <bleathem> I couldn't get the DelegatingSystemEventListener to listen for it
[17:49:06] <bleathem> it's possible some other Faces stuff was getting in the way
[17:49:08] <mojavelinux> right, that's what I'm saying, my log message shows that DelegatingSystemEventListener caught it
[17:49:15] <bleathem> oh, ok
[17:49:23] <bleathem> sorry, read that too fast
[17:49:26] <mojavelinux> but only if the application has a @ViewScoped bean that is called on that request
[17:49:34] <bleathem> oh, I see
[17:49:34] <mojavelinux> or I should say, with that view
[17:49:46] <mojavelinux> so you could force creation of the map
[17:49:49] <mojavelinux> if you need it
[17:49:51] <mojavelinux> on every view
[17:50:04] <bleathem> that seems like too much overhead
[17:50:12] <mojavelinux> somewhere in seam-faces you would just have to call getViewMap()
[17:50:22] <bleathem> maybe it's the wrong event to listen to
[17:50:33] <mojavelinux> I seriously doubt it would slow things down...after all, it's likely an empty map on a huge component tree state
[17:50:34] <bleathem> I could do this with a phase listener just as effectively
[17:51:08] <mojavelinux> so what's the end goal you are trying to accomplish? (perhaps start there)
[17:51:17] <bleathem> good call :P
[17:51:32] <bleathem> SEAMFACES-33
[17:51:34] <jbossbot> jira [SEAMFACES-33] Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting configuration [Open (Unresolved) Feature Request, Blocker, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-33
[17:51:53] <bleathem> I want to restrict access to a page, based on @ViewConfig annotations
[17:52:07] <bleathem> allowing f:metadata overides in the future
[17:52:32] <bleathem> I want to decide access rules before anything in the app runs that could have side-effects
[17:52:54] *** frgomes__ has quit IRC
[17:53:03] * bleathem looking at JSF lifecycle graph
[17:53:30] <mojavelinux> I have an idea for this, let me check something...
[17:53:34] * mojavelinux goes and checks something
[17:53:48] <bleathem> After the Reconstitute Request phase is probably appropriate
[17:54:08] <bleathem> the component tree would be present to inspect (for f:metadata overrides)
[17:54:22] <bleathem> and no action/valuechange listeners could be invoked
[17:55:30] <bleathem> In hindsight, I misunderstood what the View Map was.  I thought is was where the component tree would be stored.
[17:55:49] <bleathem> I really have to read through the rest of the JSF spec.  These details are starting to matter more to me!
[17:58:48] <bleathem> Or maybe after the apply request values.  the security access could depend on the particular "objects" being viewed
[17:59:48] <bleathem> no wait, I have this wrong, the action/value change listeners would be applied on postback, which is to the view you already had access to
[18:00:20] <bleathem> you then get redirected to another view, so we could safely progress through more of the JSF lifecycle without worrying abuot side-effects getting applied
[18:01:00] <bleathem> Maybe pre-render response is an appropriate event to listen to
[18:01:45] <bleathem> that way all values are present for Seam Securoty to inspect, without having to parse to look at the Servlet Reqeust values.
[18:01:57] <mojavelinux> the proper place to do this is the PreRenderViewEvent
[18:02:02] <mojavelinux> what bugs me a little about the history here
[18:02:26] <mojavelinux> is that I had written this code, and it got totally erased about a year ago
[18:02:33] <bleathem> I agree, PreRenderViewEvent
[18:02:35] <mojavelinux> clarification
[18:02:48] <mojavelinux> I had written code which provided a chain processing for the PreRenderViewEvent
[18:02:57] <mojavelinux> what I'm going to do is send you a zip of seam-faces at that time
[18:03:12] <mojavelinux> and you can take a look at what I had for this particular concern (ignore the rest of the module)
[18:03:14] <bleathem> is this from SEAMFACES-79?
[18:03:16] <jbossbot> jira [SEAMFACES-79] Provide <s:restrictView> tag for securing pages [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-79
[18:03:53] <bleathem> I've been looking at some of your (currently removed) code to support the s:restrictview tag.
[18:04:33] <mojavelinux> yep, you'll get the full picture of that
[18:04:36] <mojavelinux> since some bits are missing
[18:04:39] <mojavelinux> the idea is this
[18:05:00] <mojavelinux> the PreRenderViewEvent more than likely is handling front-controller concerns
[18:05:12] <mojavelinux> and in a front-controller, there is a very high chance you will shortcircuit
[18:05:31] <mojavelinux> such as invalid credentials or for url rewriting (though prettyfaces handles that at a higher level)
[18:05:54] <mojavelinux> so I have a chain so that the commands are processed in a particular order
[18:05:59] <mojavelinux> and it's possible to stop execution
[18:06:37] <mojavelinux> plus, I have a utility for extracting <f:metadata> components
[18:06:40] <bleathem> Why is this code not in the current Faces?
[18:06:44] <mojavelinux> which should be in the JSF API, but isn't
[18:06:49] <bleathem> nice, I could use that utility!
[18:06:53] <mojavelinux> because someone (I won't point fingers) nuked it all
[18:06:58] <mojavelinux> rm -Rf mycode
[18:07:38] <bleathem> ok, well we need it now!
[18:07:40] <mojavelinux> okay, so i'm sending you the zip
[18:07:45] <mojavelinux> and look in this package
[18:07:52] <mojavelinux> org.jboss.seam.faces.lifecycle
[18:08:16] <mojavelinux> some of the stuff in there is now outdated, such as how the system/phase events are propagated to the cdi event bus
[18:08:25] <mojavelinux> however, you may want to restore the PreRenderViewEventProcessor chain
[18:08:38] <mojavelinux> or name it that instead of SystemEventProcessor (since that's probably too generic)
[18:08:50] <mojavelinux> though, if you have other events that require a chain, it could be useful
[18:08:56] <mojavelinux> btw, I sort of copied the idea from struts chain
[18:09:07] <mojavelinux> which was a very successful pattern/project in it's own right
[18:09:51] <bleathem> interesting.  It's good to have sources of inspiration!
[18:11:12] <mojavelinux> that should help you a ton, hopefully
[18:11:24] <mojavelinux> I want to see how the view actions are done right now, without this
[18:13:46] <mojavelinux> oh yeah, we changed it to use the broadcast method on the UIViewAction component
[18:13:52] <mojavelinux> so it was more like a UICommand
[18:13:54] <mojavelinux> hmm
[18:14:11] <mojavelinux> the question is, where is that going to get fired in relation to the PreRenderViewEvent
[18:14:20] <mojavelinux> because you would think the security would be applied first
[18:16:29] <bleathem> Yes, we want Seucirty fired before any side-effects can take place
[18:16:31] <mojavelinux> and just so you know
[18:16:40] <mojavelinux> it's okay to change the viewId in a PreRenderViewEvent listener
[18:16:42] <bleathem> viewActions are a definite source of side-effects
[18:16:48] <mojavelinux> I made sure I put that hook in JSF 2.0 :)
[18:17:01] <bleathem> you mean using the navigation handler?
[18:17:06] <bleathem> or something more direct?
[18:17:08] <mojavelinux> let me check the relationship of the firing, this is the part where you really have to dig into jsf
[18:17:10] <mojavelinux> it's a pita
[18:17:21] <mojavelinux> yes
[18:17:46] * mojavelinux is checking the order of things
[18:17:59] <mojavelinux> btw, you have the mojarra source, right?
[18:18:23] * mojavelinux is checking out mojarra on his new box
[18:18:49] * mojavelinux is annoyed mojarra isn't in github
[18:19:07] * mojavelinux wonders if brian wants to fork mojarra into github using svn2git
[18:19:59] <mojavelinux> i love this, this is where it takes you when you go to the source code link for mojarra
[18:20:01] <mojavelinux> http://java.net/projects/javaserverfaces/sources/svn/show/trunk?rev=3219
[18:20:04] <mojavelinux> the website source
[18:20:06] <mojavelinux> ah yes, so useful
[18:20:53] <mojavelinux> attempt #2
[18:20:54] <mojavelinux> http://java.net/projects/svn/svn/mojarra~svn/trunk/
[18:20:56] <mojavelinux> not found
[18:22:04] <mojavelinux> ahhhhhhhh
[18:22:07] <mojavelinux> where is the source?
[18:22:10] <bleathem> yeah I've got the source, checked out from SVN.  edburns had to persoanlly give me access to view the source IIRC.  Seemed not very open at the time
[18:22:18] *** bitshuffler has joined #seam-dev
[18:22:35] * bleathem checking...
[18:23:24] <mojavelinux> geez, even my current checkouts give 404
[18:23:27] <mojavelinux> on attempt to update
[18:23:29] <bleathem> Anyone know off hand the svn command to show the url?
[18:23:45] <bleathem> https://mojarra.dev.java.net/svn/mojarra/trunk
[18:23:50] <bleathem> svn info
[18:24:17] <mojavelinux> svn: Repository moved temporarily to 'http://mojarra.java.net/svn/mojarra/trunk'; please relocate
[18:24:28] <bleathem> lol
[18:24:37] <mojavelinux> haha, recursive!
[18:24:48] <bleathem> guess my checkout is out of date :D
[18:24:50] <mojavelinux> svn: Repository moved temporarily to 'http://java.net/projects/mojarra/svn/mojarra/trunk'; please relocate
[18:25:02] <mojavelinux> wait, that's another repo
[18:25:20] <mojavelinux> svn: OPTIONS of 'http://java.net/projects/mojarra/svn/mojarra/trunk': 200 OK (http://java.net)
[18:25:23] <mojavelinux> #fail
[18:26:13] <mojavelinux> I guess this is Oracle's way of saying it's closed source now
[18:26:16] <mojavelinux> on to myfaces
[18:27:03] <bleathem> Yes, creating a github mirror of the mojarra source would be very much appreciated by the community, I'm sure!
[18:27:26] <mojavelinux> it makes you realize just how accessible github projects are
[18:27:29] <mojavelinux> yeah for seam
[18:28:24] <bleathem> yes, github is the new world order
[18:28:43] <bleathem> back in 2 minutes
[18:29:06] *** sbryzak has quit IRC
[18:29:18] <nickarls> mojavenux: can the faces module do any magic so we can override ResourceBundle get and hook into properties loading (faces and val.msg etc)?
[18:29:35] <nickarls> or is that CL bound?
[18:31:05] <mojavelinux> no, we should be able to add that option -> jira
[18:31:07] <mojavelinux> in fact
[18:31:14] <mojavelinux> john wrote a blog entry about this
[18:31:22] <mojavelinux> so it may just be tapping into that for ideas
[18:31:43] <mojavelinux> http://john-ament.blogspot.com/2010/03/dyanmic-resourcebundles-in-cdi.html
[18:32:05] <mojavelinux> definitely on the table
[18:32:24] <mojavelinux> i think now that ken has gotten the logging situation sorted out in solder, he's back on international and ready to tackle these ideas
[18:32:38] <mojavelinux> and it would be the international module btw
[18:33:54] <mojavelinux> oh, I remember now bleathem
[18:34:00] <mojavelinux> okay, time to do a brain dump on you
[18:34:04] *** lincolnthree1 has joined #seam-dev
[18:34:09] * bleathem ready for it
[18:34:17] <mojavelinux> man, this story has a long history, I will make it as brief and condense as possible
[18:34:19] <bleathem> lincolnthree1 welcome!
[18:34:38] <mojavelinux> so there was this turning point conversation in the EG
[18:34:44] <mojavelinux> that we had one afternoon before 2.0
[18:34:51] <mojavelinux> when we were discussing view actions
[18:35:02] <mojavelinux> and the day the metadata facet was born
[18:35:46] <mojavelinux> andy schwartz pointed out that the PreRenderViewEvent is not sufficient for doing front controller operations
[18:35:48] <mojavelinux> the reason is
[18:35:57] <mojavelinux> by that point, the whole component tree has been built
[18:35:59] <mojavelinux> it's before render
[18:36:02] <mojavelinux> not before build
[18:36:20] <mojavelinux> so we needed something that would allow us to have a front-controller before we spent all the time building the component tree
[18:36:57] <mojavelinux> we thought about the idea of having a separate xml configuration file like page.xml in Seam 2
[18:37:09] <mojavelinux> that would be read in before the template is read
[18:37:16] <mojavelinux> however, there were two problems with that approach
[18:37:31] <mojavelinux> first, it's another file that would have to be maintained and everyone generally disliked that idea
[18:37:54] <mojavelinux> second, it didn't benefit from the templating features of facelets
[18:38:18] <mojavelinux> ah, and it didn't benefit from the UI component infrastructure
[18:38:21] <mojavelinux> framework
[18:38:27] <mojavelinux> so three reasons it was no good
[18:38:38] <mojavelinux> so we decided to make a facet of the view that held configuration
[18:38:39] <bleathem> and it's xml
[18:38:43] <mojavelinux> right
[18:38:49] <mojavelinux> hence f:metadata
[18:38:56] <mojavelinux> now, that alone wasn't enough
[18:39:03] <mojavelinux> what we needed was a point in the lifecycle when that was processed
[18:39:07] <bleathem> I really like the f:metadata facet
[18:39:07] <mojavelinux> and that *had* to be in restore view
[18:39:20] <mojavelinux> and it's possible, anyway
[18:39:26] <mojavelinux> for an extension of jsf
[18:39:32] <mojavelinux> to provide it's own metadata
[18:39:58] <mojavelinux> by just overriding the view template reader (or whatever class it is, I need to check)
[18:40:23] <mojavelinux> now here's the kicker
[18:40:27] <mojavelinux> though it has a caveat
[18:41:05] <mojavelinux> we want to process the full jsf lifecycle on an initial request
[18:41:26] <mojavelinux> however, until render response, the view only contains the f:metadata
[18:41:38] <mojavelinux> so, that's how UIViewAction is implemented in seam faces
[18:41:52] <mojavelinux> jsf goes through the regular lifecycle, so UIViewAction is a UICommand
[18:41:55] <mojavelinux> just like you clicked a button
[18:41:59] <mojavelinux> but you just requested a URL
[18:42:03] <mojavelinux> voila
[18:42:07] <mojavelinux> now, for the huge caveat
[18:42:15] <mojavelinux> that only happens
[18:42:22] <mojavelinux> if there is a UIViewParameter inside f:metadata
[18:42:31] <mojavelinux> because of a huge misunderstanding by Ed
[18:42:41] <bleathem> right, I remember lincolnthree1 pointing that out to me
[18:42:50] <mojavelinux> now, the question would be, can we change that behavior somehow
[18:42:52] <bleathem> looking forward to the day JSF fixes that
[18:42:52] <mojavelinux> we might be able to
[18:43:00] <bleathem> that would be nice!
[18:43:07] <mojavelinux> it may be fixed in 2.1, I"m not sure, we would have to check
[18:43:17] <mojavelinux> should be easy enough for you to find where that logic occurs anyway
[18:43:20] <bleathem> last time I checked with lincolnthree1, he said no
[18:43:24] <mojavelinux> but let's not worry about that at the moment
[18:43:26] <bleathem> it wasn't fixed in 2,1
[18:43:27] <mojavelinux> because guess what?
[18:43:38] <mojavelinux> you can add a fake UIViewParameter into the view
[18:43:40] <mojavelinux> programmatically
[18:43:43] <mojavelinux> which, I think we do
[18:43:47] <mojavelinux> in seam faces
[18:43:52] <mojavelinux> if not, we should
[18:43:56] <bleathem> We should
[18:43:59] <mojavelinux> just bind something bogus to something bogus
[18:44:11] <bleathem> I don't think we do, because the viewParam is required to get the viewAction to fire
[18:44:11] <mojavelinux> so here's the thing
[18:44:18] <mojavelinux> right now, can you tell me, based on what I've told you
[18:44:26] <mojavelinux> where UIViewAction is processed (invoked)
[18:44:37] <mojavelinux> assuming an initial request
[18:45:10] <bleathem> early in the life cycle, I would guess post apply request values
[18:45:18] <mojavelinux> think of a UICommand
[18:45:39] <bleathem> or do validations occur first?
[18:45:48] <mojavelinux> it's just like a regular jsf postback
[18:45:51] <bleathem> Invoke application then?
[18:45:53] <mojavelinux> yep!
[18:45:55] <bleathem> then!
[18:45:57] <mojavelinux> it's the real deal
[18:46:10] <mojavelinux> that's why UIViewActions are so awesome in seam faces
[18:46:19] <mojavelinux> it's a front-controller, plus...!
[18:46:24] <bleathem> That's a message the we need to sell
[18:46:25] <mojavelinux> you get the normal JSF stuff
[18:46:26] *** sbryzak has joined #seam-dev
[18:46:41] <mojavelinux> meaning the UIViewParameters are processed and validated
[18:46:55] <bleathem> I think people don't really get the power of viewAction, and why it's different than the f:viewParam setter
[18:46:59] <mojavelinux> it's basically like a postback, except the form is the URL
[18:47:07] <mojavelinux> exactly!
[18:47:23] <mojavelinux> and why it's better than f:event preRenderView="#{bean.invoke}"
[18:47:34] <mojavelinux> because that happens *after* the component tree is built
[18:47:36] <mojavelinux> which has side effects
[18:47:43] <bleathem> nice, so *all* viewParams are processed, before the viewAction is invoked
[18:47:45] <mojavelinux> as andy schwartz so carefully pointed out (he is a hero)
[18:47:47] <mojavelinux> yep
[18:48:05] <mojavelinux> now, if you think about security
[18:48:16] <mojavelinux> then invoke application is too late likely
[18:48:16] <bleathem> so we need to invoke security, before the viewAction is invoked
[18:48:18] <mojavelinux> or
[18:48:23] <mojavelinux> even better, we can say which phase
[18:48:45] <mojavelinux> so we can say this is an early or late enforced security
[18:48:51] <mojavelinux> we can select good names for it
[18:48:57] <bleathem> and if a developer has side effects in a viewParam setter, that's there own damn fault right?
[18:49:05] <mojavelinux> early processing means before the lifecycle starts on view metadata
[18:49:20] <mojavelinux> late processing means before invoke application (or at the start)
[18:49:26] <lincolnthree1> yes, exactly
[18:49:36] <mojavelinux> and what I might do is this
[18:49:36] <lincolnthree1> getter setter side effects = you're stupid
[18:49:41] <mojavelinux> if you want late processing, you could
[18:49:48] <mojavelinux> programmatically register a UIViewAction
[18:49:51] <lincolnthree1> :-D
[18:49:55] <mojavelinux> that's just one idea
[18:49:57] <bleathem> it's the only workaround to not having viewAction in JSF 2
[18:50:09] <lincolnthree1> you need a viewParam to have a view action though
[18:50:14] <lincolnthree1> they havent' fixed that yet
[18:50:14] <mojavelinux> for early processing, we need to hook into the createMetadataView()
[18:50:20] <mojavelinux> yes, but lincoln
[18:50:23] <mojavelinux> we can add one dyanmically
[18:50:24] <mojavelinux> :)
[18:50:31] <mojavelinux> let me check where we can hook in
[18:50:35] <mojavelinux> because I know we can do it
[18:50:50] <bleathem> that'll make viewAction much more palatable!
[18:51:25] <bleathem> the current plan is to use Seam Security annotations in the @ViewConfig
[18:51:30] <mojavelinux> yep indeed
[18:51:39] <mojavelinux> also, you should study UIViewAction closely
[18:51:47] <mojavelinux> because we've had to do some not so pretty logic around navigation
[18:51:57] <mojavelinux> because it's really, really hard to force a navigation to occur at that point
[18:52:01] <bleathem> So we'll need some qualifiers that the user uses for quilifying early/late security enforcement
[18:52:09] <mojavelinux> and also, we have to ask, how do we know a navigation happened
[18:52:21] <mojavelinux> we need to be clear about what our rules are in the docs
[18:52:31] <mojavelinux> I think so, yes
[18:52:54] <mojavelinux> I hate to use the word immediate, but it comes to mind
[18:52:59] <mojavelinux> people hate that word in jsf :)
[18:53:30] <mojavelinux> how about BEFORE_BUILD
[18:53:36] <mojavelinux> and BEFORE_INVOKE
[18:53:36] <bleathem> id viewAction is evaluated in the invoke application phase, then it should be trivial to request a navigation, no?
[18:53:49] <mojavelinux> hahaha, well, you'd be surprised
[18:54:07] <mojavelinux> ah
[18:54:10] <mojavelinux> that's not the issue
[18:54:23] <mojavelinux> the issue is, should a navigation event stop subsequent actions from invoking
[18:54:30] <mojavelinux> there is a flag for that
[18:54:43] <bleathem> oic
[18:54:57] <mojavelinux> but actually, I think we may have this logic elsewhere in seam faces
[18:54:59] <mojavelinux> so they should be aligned
[18:55:12] <mojavelinux> the problem in jsf is that it does not give an indication that navigation was carried out
[18:55:33] <mojavelinux> but lincoln added a notification
[18:55:37] <mojavelinux> by overriding the navigation handler
[18:55:46] <mojavelinux> so I think we can go back into the UIViewAction and fix that logic
[18:55:56] <mojavelinux> now that we know the navigation event actually happened
[18:56:08] <mojavelinux> it's amazing that jsf does not give a signal that navigation has taken place
[18:56:26] <mojavelinux> but you can see in that UIViewAction how much checking is required to find out if it has
[18:56:48] <mojavelinux> checking if viewId changed, checking if response is complete and checking if the viewRoot is actually a different object (same viewId)
[18:56:50] * bleathem mid eclispe install, itching to look at UIViewAction
[18:57:46] * bleathem importing exisitng maven projects
[18:57:49] <mojavelinux> hahah, oh yeah, we also had to proxy the call to responseComplete() or else we can't get out of the component :)
[18:57:52] <mojavelinux> without an error
[18:59:16] <bleathem> what package?
[18:59:52] <mojavelinux> org.jboss.seam.faces.component
[19:00:19] <bleathem> oh, it's in API
[19:00:24] <mojavelinux> btw, we should *definitely* move RenderScoped to org.jboss.seam.faces.context
[19:00:37] <mojavelinux> yeah, it has to be an API unfortunately
[19:00:43] <mojavelinux> because of screwy JSF
[19:00:50] <mojavelinux> though I guess we could split it into a renderer
[19:00:58] <mojavelinux> I was just a little lazy
[19:00:59] <mojavelinux> :)
[19:01:16] <mojavelinux> oh, and I was doing it like JSF...you know all the logic of UICommand is in UICommand :)
[19:02:00] <mojavelinux> what's interesting is that even today it is possible to do security using viewAction
[19:02:14] <mojavelinux> but it's a lot of work compared to what we can achieve w/ the view config integration
[19:02:16] <bleathem> yeah, I was commenting on that to stuart the other day
[19:02:24] <mojavelinux> it's a fallback option I think
[19:02:33] <bleathem> this will work
[19:02:38] <bleathem> I'm sure of it :P
[19:03:05] <mojavelinux> absolutely...so I'm looking for the tie in still...hang tight
[19:03:39] <bleathem> ok, I need to summarize this, going to use meetbot
[19:03:43] <bleathem> #startmeeting
[19:03:50] <jbott> Meeting started Sat Mar 19 18:00:51 2011 UTC.  The chair is bleathem. Information about MeetBot at http://wiki.debian.org/MeetBot.
[19:03:50] <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
[19:04:16] <bleathem> #meetingtopic SEAMFACES-33
[19:04:17] <jbossbot> jira [SEAMFACES-33] Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting configuration [Open (Unresolved) Feature Request, Blocker, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-33
[19:04:29] <mojavelinux> grr, here is the code that I hate
[19:04:32] <mojavelinux>                    // Only skip to render response if there are no view parameters
[19:04:32] <mojavelinux>                     Collection<UIViewParameter> params =
[19:04:32] <mojavelinux>                           ViewMetadata.getViewParameters(viewRoot);
[19:04:32] <mojavelinux>                     if (params.isEmpty()) {
[19:04:32] <mojavelinux>                         facesContext.renderResponse();
[19:04:32] <mojavelinux>                     }
[19:04:38] <mojavelinux> why???
[19:04:48] <mojavelinux> okay, so it's very clear that we need to hook into this
[19:04:56] <mojavelinux> ViewMetadata metadata = vdl.getViewMetadata(facesContext, viewId);
[19:04:56] <mojavelinux>                 if (metadata != null) { // perhaps it's not supported
[19:04:56] <mojavelinux>                     // and use it to create the ViewRoot.  This will have, at most
[19:04:56] <mojavelinux>                     // the UIViewRoot and its metadata facet.
[19:04:56] <mojavelinux>                     viewRoot = metadata.createMetadataView(facesContext);
[19:05:04] <mojavelinux> vdl == view declaration language
[19:05:07] <bleathem> #topic which faces event/phase to listen for, to invoke a security check
[19:06:00] <mojavelinux> we are tackling a few things, first, we need to add a dummy view parameter if one doesn't exist
[19:06:14] <mojavelinux> and there are any other components in the facet
[19:06:28] <mojavelinux> so we need to override createMetatdataView
[19:06:36] <mojavelinux> so how do we register our own vdl
[19:06:36] <bleathem> #info we want the security check to take place before any side effects can occur
[19:07:22] <bleathem> #info viewAction is a source of side effects
[19:07:37] <mojavelinux> view-declaration-language-factory
[19:07:44] *** cbrock has joined #seam-dev
[19:07:44] *** cbrock has quit IRC
[19:07:44] *** cbrock has joined #seam-dev
[19:08:04] <bleathem> #action we want to add a dummy view parameter programatically so that  the viewAction is always called
[19:09:09] <bleathem> #info We want to allow the end user to specify if security should be enforced before/after viewActions are called
[19:09:23] <bleathem> #action We will need Seam Security qualifiers for this
[19:09:44] <bleathem> guess I should be more clear what "this" is
[19:10:12] <bleathem> #action We will need Seam Security qualifiers for enforcing security before/after viewActions are called
[19:10:56] <bleathem> mojavelinux the corresponding events to listem to would be ?? and PreRenderViewEvent
[19:11:06] <mojavelinux> hang on, getting to it
[19:11:37] <bleathem> ok, that's what you are looking up?
[19:12:08] <mojavelinux> I'm looking up how we are going to tie into this whole thing, almost there
[19:13:02] <bleathem> #action implement/resurrect the PreRenderViewEventProcessor chain / SystemEventProcessor to allow sequencing of system events listeners
[19:13:18] <mojavelinux> okay, I think all we need to do is override the ViewHandler
[19:13:35] <bleathem> rather than listening for events?
[19:13:50] <mojavelinux> which we don't yet do
[19:13:54] <mojavelinux> here's the idea
[19:14:11] <mojavelinux> the topic is adding a dummy UIViewParameter
[19:14:17] <mojavelinux> because this is the first step in this process
[19:14:18] <bleathem> #chair mojavelinux
[19:14:26] <jbott> Current chairs: bleathem mojavelinux
[19:14:50] <bleathem> #topic adding a dummy UIViewParameter
[19:14:55] <mojavelinux> #info if we override ViewHandler, then we can return a wrapped version of the ViewDeclarationLanguage
[19:15:26] *** lincolnthree1 has left #seam-dev
[19:15:35] <mojavelinux> #info when createMetadataView is called, we delegate to parent, then, if there are components in the view metadata, but no UIViewParameter, we add a dummy instance
[19:16:12] <mojavelinux> #info we override view handler by using <view-handler> in faces-config.xml
[19:16:32] <mojavelinux> we can look into other ways to do this, let's just go with this as a prototype
[19:16:33] <bleathem> and createMetadataView *is* called even though ni UIViewParamter is present?
[19:16:55] <mojavelinux> meaning, we could go lower and provide a custom ViewDeclarationLanguageFactory and wrap the ViewDeclarationLanguage instead
[19:16:55] *** lightguard_jp has joined #seam-dev
[19:17:07] <mojavelinux> yes, createMetadataView is always called
[19:17:13] <bleathem> ok
[19:17:21] <mojavelinux> i'll reiterate the mojarra code
[19:17:27] <mojavelinux> oh, info that
[19:18:03] <bleathem> #info mojavelinux: we could go lower and provide a custom ViewDeclarationLanguageFactory and wrap the ViewDeclarationLanguage instead
[19:18:14] <mojavelinux> #info createMetadataView is always called
[19:18:17] <mojavelinux> if (vdl != null) {
[19:18:17] <mojavelinux>                 // If we have one, get the ViewMetadata...
[19:18:17] <mojavelinux>                 ViewMetadata metadata = vdl.getViewMetadata(facesContext, viewId);
[19:18:17] <mojavelinux>                 if (metadata != null) { // perhaps it's not supported
[19:18:17] <mojavelinux>                     // and use it to create the ViewRoot.  This will have, at most
[19:18:17] <mojavelinux>                     // the UIViewRoot and its metadata facet.
[19:18:17] <mojavelinux>                     viewRoot = metadata.createMetadataView(facesContext);
[19:18:18] <mojavelinux>                     // Only skip to render response if there are no view parameters
[19:18:18] <mojavelinux>                     Collection<UIViewParameter> params =
[19:18:19] <mojavelinux>                           ViewMetadata.getViewParameters(viewRoot);
[19:18:19] <mojavelinux>                     if (params.isEmpty()) {
[19:18:20] <mojavelinux>                         facesContext.renderResponse();
[19:18:20] <mojavelinux>                     }
[19:18:21] <mojavelinux>                 }
[19:18:29] <bleathem> oic, if params.isEmptuy
[19:18:53] <mojavelinux> yeah, so see where we can inject our own stuff
[19:19:01] <mojavelinux> is by overriding createMetadataView
[19:19:02] <bleathem> yep
[19:19:07] <mojavelinux> and weaving
[19:19:17] * lightguard_jp is having fun going through new hire info :)
[19:19:23] <mojavelinux> hehehe
[19:19:38] <mojavelinux> okay, so that solves our UIViewParameter problem, I'll jira that
[19:20:04] <bleathem> lightguard_jp probably the happiest paperwork you had to go through in a long time
[19:20:06] <mojavelinux> #action file jira for adding dummy UIViewParameter if there are other non-UIViewParameter children in the metadata view
[19:20:19] <lightguard_jp> Oh, did you start a meeting?
[19:20:24] <bleathem> next topic?
[19:20:25] <mojavelinux> yep
[19:20:36] <mojavelinux> #topic where to hook in security restrictions
[19:20:41] <bleathem> lightguard_jp ype, the IRC logs for this conversation got *really* long
[19:20:47] <lightguard_jp> bleathem: Yeah, and it actually makes sense. I read the NDA and all the legal stuff and it was actually understandable.
[19:21:04] <bleathem> i wonder if there is some way to delete my first topic
[19:21:12] <bleathem> oh well, we can disregard it
[19:21:34] <mojavelinux> #info disregard first topic on hooking in seam security in favor of subsequent info lines
[19:22:14] <mojavelinux> aha!
[19:22:16] <mojavelinux> idea
[19:22:28] <mojavelinux> we can fire and event for post create metadata view
[19:22:30] <mojavelinux> :)
[19:22:38] <mojavelinux> yeah, more hooks
[19:22:41] <bleathem> nice
[19:22:52] <mojavelinux> so we want this one to be really nice ;)
[19:23:05] <mojavelinux> okay, so we have built the view with just the ui view metadata
[19:23:19] <mojavelinux> now is the best time for early security
[19:23:52] <bleathem> #idea mojavelinux fire an event for post create metadata view
[19:23:52] <mojavelinux> the next thing that happens in the jsf lifecycle is apply request values to the components in the metadata facet
[19:24:11] <mojavelinux> I guess we could do before too :)
[19:24:16] <mojavelinux> for the event
[19:24:21] <mojavelinux> we'll see if that's useful
[19:24:40] <mojavelinux> but these are critical points in the lifecycle, sure is nice to be able to tie into them
[19:24:45] <bleathem> #action fire pre and post create-metadata-view events
[19:25:43] <bleathem> so the early seam security check will be post-create-metadataview
[19:25:57] <bleathem> and late seam security check will be prerenderview
[19:26:11] <mojavelinux> now here's the question, do you want to transfer the view config into view metadata components at this point?
[19:26:18] <mojavelinux> as though the user defined them in the template?
[19:26:23] <bleathem> I would think the other way around
[19:26:34] <mojavelinux> k, it's up to you, either way
[19:26:47] <bleathem> I don't think we can define them in the template
[19:26:53] <bleathem> one sec
[19:27:13] <mojavelinux> why not? well, you could have s:restrictView for EL restrictions
[19:27:19] <mojavelinux> but it would be different
[19:27:30] <mojavelinux> true, okay, so you are correct, we can't have a 1-to-1 mapping
[19:27:34] <mojavelinux> it will be an aggregate
[19:28:01] <bleathem> "Note line 4. The page author must ensure that the <f:metadata> element does not appear on a template or included page. It must reside on the root page that corresponds to the viewId."
[19:28:07] <bleathem> http://javaserverfaces.java.net/nonav/docs/2.0/pdldocs/facelets/f/metadata.html
[19:28:29] <mojavelinux> yes, but you can still use templating
[19:28:47] <mojavelinux> you just have to pass the <f:metadata> into a <ui:define> block
[19:28:52] <mojavelinux> we do this in booking
[19:28:54] <mojavelinux> and weld permalink
[19:28:55] <bleathem> right
[19:29:00] <mojavelinux> it's just sort of quirky
[19:29:11] <bleathem> but the metadata has to be defined per page
[19:29:17] <mojavelinux> and you can use ui:include inside of <f:metadata>
[19:29:29] <mojavelinux> #info you can use ui:include inside of <f:metadata>
[19:29:29] <bleathem> right, that's the trick, ui:include
[19:29:35] <mojavelinux> you just can't do it outside
[19:29:51] <mojavelinux> it's not ideal, but it can get almost the same result
[19:29:59] <mojavelinux> you just have a lot of repeat ui:include blocks
[19:30:10] <bleathem> boilerplate
[19:30:21] <bleathem> which is where the @ViewConfig comes in nice
[19:30:22] <mojavelinux> yep, though remember, we can programmatically add them
[19:30:26] <mojavelinux> exactly
[19:30:30] <bleathem> f:metadata for prototyping
[19:30:33] <mojavelinux> we could provide view actions view @ViewConfig!
[19:30:38] <mojavelinux> :)
[19:30:43] <bleathem> nice
[19:30:46] <mojavelinux> exactly
[19:30:48] <mojavelinux> sweet
[19:30:49] <bleathem> this is coming along nicely
[19:30:51] <mojavelinux> very
[19:31:02] <bleathem> #idea mojavelinux: we could provide view actions view @ViewConfig!
[19:31:11] <mojavelinux> excellent
[19:31:28] <bleathem> have we got our hook points settled?
[19:31:48] <bleathem> postCreateMetadataViewEvent and PreRenderView?
[19:32:08] <mojavelinux> just a sec
[19:32:15] <mojavelinux> wife is talking
[19:32:22] <bleathem> got it!
[19:33:02] <mojavelinux> there should be a code for that ;)
[19:33:23] <mojavelinux> there are two paths we can take here
[19:33:30] <bleathem> Seam Security Qualifiers?
[19:33:46] <mojavelinux> one path is to register a security executor component
[19:34:01] <mojavelinux> as the first component in the view metadata
[19:34:06] <mojavelinux> w/ immediate = true
[19:34:18] <mojavelinux> and let it execute and we tie into that
[19:34:41] <mojavelinux> the other approach is to tie into our own post create metadata view event
[19:34:47] <mojavelinux> the only problem with events is the ordering
[19:34:55] <bleathem> <s:restrictView immediate="true"> corresponds to the postCreateViewMetadataEvent
[19:35:13] <mojavelinux> right
[19:35:35] <mojavelinux> how I worked around this in seam servlet is this
[19:35:38] <bleathem> And we would have a corresponding Seam Security qualifier for use in @ViewConfig
[19:35:47] <mojavelinux> I fire two events for a lifecycle point
[19:35:58] <mojavelinux> the first has an @Internal qualifier
[19:35:59] <bleathem> We only need one qualifier to correspond to immediate, the default shoud be late
[19:36:02] <mojavelinux> the second is a public one
[19:36:17] <bleathem> ok
[19:36:40] <bleathem> So we can act on an event before the end-developer can
[19:36:43] <mojavelinux> I think we don't need a qualifier for the immediate , it is jsut an attribute on the security annotation
[19:36:45] <mojavelinux> perhaps
[19:36:53] <bleathem> ok
[19:36:58] <bleathem> that's better
[19:37:04] <mojavelinux> in a sense, PreRenderViewEvent is perfectly useless
[19:37:11] <mojavelinux> because it's just way too late
[19:37:26] <mojavelinux> however, consider this
[19:37:45] <mojavelinux> the post create metadata view event isn't good either
[19:37:50] <mojavelinux> because that only happens on initial request
[19:37:56] <mojavelinux> useful event, but not for the purpose of security
[19:38:03] <bleathem> right
[19:38:04] <mojavelinux> what we really need is post-restore view
[19:38:11] <bleathem> we can re-visit the view, with changed data
[19:38:13] <mojavelinux> at that point, we know we have a metadata facet
[19:38:28] <mojavelinux> also, we need to have a security "on-postback" flag
[19:38:42] <mojavelinux> that determines if it's enforced on postback or not
[19:38:47] <mojavelinux> though the default should be that it is
[19:39:10] <bleathem> #idea mojavelinux: we need to have a security "on-postback" flag - that determines if it's enforced on postback or not (default true)
[19:39:13] <mojavelinux> view actions are the opposite, default onPostack=false
[19:39:28] <mojavelinux> because they are designed for initial requests
[19:39:29] <bleathem> #info view actions are the opposite, default onPostack=false
[19:39:31] <mojavelinux> security is something you always want
[19:39:40] <mojavelinux> or 99% of the time
[19:39:41] <bleathem> right makes sense
[19:39:57] <mojavelinux> so I would tie into post-restore view phase for enforcing security
[19:40:07] <bleathem> always?
[19:40:20] <bleathem> what about for initial requests?
[19:40:24] <mojavelinux> same
[19:40:29] <mojavelinux> oh, for immediate
[19:40:32] <mojavelinux> for immediate security
[19:40:39] <bleathem> we won't have application data to inspect
[19:40:41] <mojavelinux> for late security, PreRenderViewEvent is fine
[19:40:46] <bleathem> oh, ok
[19:41:04] <bleathem> Which should be default?
[19:41:08] <bleathem> late?
[19:41:11] <mojavelinux> early
[19:41:19] <bleathem> I think most security would need to be checked against application data
[19:41:35] <mojavelinux> why isn't application data available though?
[19:41:40] <bleathem> which would be available early on post back
[19:41:45] <mojavelinux> you are saying that things like view parameters aren't yet resolved
[19:41:53] <bleathem> an initial request, post restore view
[19:41:58] <bleathem> yes
[19:41:58] <mojavelinux> so like what's the blog entry for instance
[19:42:02] <mojavelinux> or which user are we viewing
[19:42:03] <mojavelinux> got it
[19:42:28] <bleathem> mabye default late for intial request, early for postback
[19:42:30] <mojavelinux> okay, so early checking would be like this
[19:42:40] <mojavelinux> viewId and current user session
[19:42:51] <mojavelinux> like, okay, you are joe shmo and the viewId is /admin/
[19:42:53] <mojavelinux> deny
[19:43:09] <bleathem> right
[19:43:19] <bleathem> thtat would be an early one
[19:43:31] <mojavelinux> then let's say, for PreRenderView
[19:43:35] <mojavelinux> we've looked up the user
[19:43:42] <mojavelinux> let's say the blog entry
[19:43:46] <mojavelinux> no, let's say a document
[19:43:50] <mojavelinux> we get a document
[19:43:51] <bleathem> you are joe shmo and view is /view?entry=JohnsItem
[19:43:55] <mojavelinux> in like a view action
[19:44:09] <mojavelinux> then we see if the current user can view that document, perhaps via a rules engine or something
[19:44:11] <mojavelinux> or acl
[19:44:19] <mojavelinux> then deny
[19:44:28] <mojavelinux> we could do security before the view actions
[19:44:37] <mojavelinux> but after the view parameters, but that seems like a very rare condition
[19:44:46] <mojavelinux> chances are, the view actions are pulling the application data
[19:45:02] <mojavelinux> but there is another case
[19:45:12] <mojavelinux> what about on postback, you clicked delete
[19:45:17] <mojavelinux> you can do security in PreRenderView
[19:45:20] <mojavelinux> can't
[19:45:28] <mojavelinux> because the document will be gone by then :)
[19:45:32] <mojavelinux> so then, you need early
[19:45:41] <mojavelinux> which should be available in the application data memory
[19:45:46] <mojavelinux> so then you know what we need
[19:45:55] <mojavelinux> early and late needs to be per initial request or postback
[19:45:57] <mojavelinux> so like this
[19:46:01] <bleathem> right, I think a sensible default might be:  default late for intial request, early for postback
[19:46:11] <mojavelinux> initial = "late", postback="early"
[19:46:18] <mojavelinux> yep, and then we can have never
[19:46:24] <mojavelinux> initial = "never", postback = "early"
[19:46:34] <mojavelinux> okay, idea that one
[19:46:45] <bleathem> wait, what's the "never"
[19:46:46] <bleathem> one?
[19:47:25] *** cbrock has quit IRC
[19:48:20] <mojavelinux> dont' apply security in that case
[19:48:25] <mojavelinux> I think we need 4 options
[19:48:54] <bleathem> default: initial = "late", postback="early"
[19:48:58] <mojavelinux> initial | postback = AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER
[19:49:07] <bleathem> ok
[19:49:17] <bleathem> that sumamrises it nicely
[19:49:21] <mojavelinux> #idea timing for security enforcement is  initial | postback = AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER
[19:49:39] <mojavelinux> #idea default timing is initial = BEFORE_RENDER, postback = AFTER_RESTORE
[19:49:51] <mojavelinux> or should it be postback = BEFORE_INVOKE?
[19:50:09] <bleathem> for the default?
[19:50:12] <mojavelinux> yeah
[19:50:20] <bleathem> yeah, I think so
[19:50:24] <bleathem> no side effects
[19:50:29] <bleathem> but viewParams are all present
[19:51:10] <mojavelinux> okay, cool, so we can fine tune all that...that's just the details
[19:51:37] *** gmorling has joined #seam-dev
[19:51:38] <bleathem> ratehr than BEFORE_RENDER, We could be AFTER_INVOKE, to make sure we get applied before other BEFORE_RENDER events
[19:52:08] <mojavelinux> yeah, I think so...only trick bit is, we don't have a hook for that in jsf
[19:52:11] <mojavelinux> though we could make one
[19:52:13] <bleathem> #idea  postback coud be BEFORE_INVOKE rather than AFTER_RESTORE - no side effects, yet viewParams are all present
[19:52:18] <mojavelinux> by adding a metadata component
[19:52:24] <mojavelinux> like securityenforcer
[19:52:27] <bleathem> we have the after phase listener
[19:52:33] <mojavelinux> duh
[19:53:06] <bleathem> but that is a FINEST details :P
[19:53:10] <mojavelinux> hehehe
[19:53:23] <mojavelinux> okay, so I see these steps
[19:53:26] <bleathem> so se have out JSF event tie-ins
[19:53:40] <bleathem> what else do we need...
[19:53:43] <mojavelinux> #1 create an security enforcer
[19:53:50] <mojavelinux> #2 hook it into the life cycle
[19:54:15] <mojavelinux> #3 override ViewMetadata and add the dummy UIViewParameter if there are any non-UIViewParameter components but no UIViewParameter
[19:54:22] <mojavelinux> sorry, ViewHandler
[19:54:43] <mojavelinux> override ViewHandler, to wrap ViewDeclarationLanguage to override createMetadataView
[19:54:59] <mojavelinux> that will fix our UIViewAction problem too
[19:55:05] <bleathem> Side note: can we get sub-tasks in the JBoss jira?
[19:55:19] <bleathem> These would be good issues as sub-tasks of seamfaces-33
[19:55:21] <mojavelinux> oh, we intentially disabled those because they were annoying, do you like them?
[19:55:22] <mojavelinux> true
[19:55:28] <mojavelinux> we just use linked issues
[19:55:30] <mojavelinux> depends-on
[19:55:36] <bleathem> they're annoying in that they are only 1 level deep
[19:55:38] <bleathem> ok
[19:55:41] <bleathem> depends on is fine
[19:55:46] <mojavelinux> let's use that
[19:56:18] <mojavelinux> cool! I think we are much further along now, woot
[19:56:29] <bleathem> Is ViewMeta (as a replacement for ViewData) to similar in name to JSF's ViewMetadata?
[19:56:38] <bleathem> yes, the path ahead is clear
[19:58:18] <bleathem> The initial first pass on this was going to be to use the @Viewconfig, and add in the f:metadata tags later, possibly post 3.0
[19:58:59] <bleathem> Are we still ok with this, given that our discussion was f:metadata centric?
[20:00:10] <bleathem> And I think we need qualifiers rather than attributes for the timing, since the end developers create the Seam Security annotations themselves.
[20:00:22] <bleathem> No qualifier present, = the default behaviour agreed to above
[20:01:23] <jbossbot> git [faces] push master 6b0d9f5.. Dan Allen ignore faces-config dia files
[20:01:23] <jbossbot> git [faces] push master da97474.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR2
[20:01:24] <jbossbot> git [faces] push master 142bb53.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[20:01:24] <jbossbot> git [faces] push master 5ae0dcb.. Dan Allen Merge branch 'master' of github.com:seam/faces
[20:01:24] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/da0cc20...5ae0dcb
[20:01:43] <bleathem> Then when we scan for the SeamSecurity annotations qualified with @SecurityBindingType, we can check for the timing qualifiers @BeforeInvoke, @AfterRestore, @BeforeRender
[20:02:10] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/5ae0dcb...da0cc20
[20:02:16] <bleathem> #commands
[20:02:20] <jbott> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #rejected #restrictlogs #save #startmeeting #topic #unchair #undo #unlurk
[20:02:44] <bleathem> #info
[20:02:47] <jbossbot> git [faces] push master 1f1e3d8.. Dan Allen ignore faces-config dia files
[20:02:47] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/da0cc20...1f1e3d8
[20:03:09] <mojavelinux> sorry, screwed up that push at first
[20:03:28] <mojavelinux> yep
[20:04:14] <mojavelinux> the f:metadata discussion was important for context, we've determined that we can get our hooks using what's available
[20:04:37] <mojavelinux> well, sort of
[20:04:51] <mojavelinux> remember, without a UIViewParameter, you don't get invoke application on an initial request
[20:05:17] <bleathem> but do we need that?
[20:05:51] <mojavelinux> so what are the decided on hook points again? meaning what exactly will you use as the tie in (I know we discussed the available timing, but I'm looking for the actual relationships)
[20:06:02] <bleathem> ok
[20:06:09] <mojavelinux> so the after restore is in a phase listener?
[20:06:20] <bleathem> yes
[20:06:22] <mojavelinux> I suppose you can use the delegating phase listener
[20:06:32] <bleathem> before render  could be either phase or system
[20:06:33] <mojavelinux> to launch it, like w/ the transactions
[20:06:50] <bleathem> yes, then you get the injection
[20:07:10] <mojavelinux> I think the system event is probably best for pre-render
[20:07:22] <bleathem> BEFORE_INVOKE would be skipped on initial request, if there were no viewAction
[20:08:00] <mojavelinux> true, let's just say that for now you need a view action for security to be called at that point on intiial request
[20:08:06] <bleathem> general curiosity, why is the system event prefered over the phase listener?
[20:08:17] <bleathem> ok
[20:08:20] <mojavelinux> and the view action is current dependent on a view parameter (which we will fix either before or after 3.0)
[20:08:35] <bleathem> in essence, BEFORE_INVOKE is meaningless if you have no action to invoke
[20:08:39] <mojavelinux> right
[20:08:46] <bleathem> I'd like to see that fixed before 3.0
[20:08:51] *** kenfinnigan has joined #seam-dev
[20:08:59] <bleathem> it'll get lots of questions/complaints in the forum
[20:09:00] <mojavelinux> I can probably take that one...I think I know what needs to be done
[20:09:09] <bleathem> that'd be good
[20:09:21] <mojavelinux> we really need jsfunit tests, that's something which we may not have time for though
[20:09:29] <bleathem> ok, does that wrap it up?  I'll file some jiras, and we're good to go?
[20:09:30] <mojavelinux> but a lot of this testing is manual w/o it
[20:09:37] <mojavelinux> yep
[20:09:45] <bleathem> Don't get me started on the need for JSFUnit tests
[20:09:52] <mojavelinux> as for the system event vs phase for prerender
[20:09:54] <bleathem> we'll be here another 3 hours!
[20:10:24] <mojavelinux> it's hard to say, probably the same really
[20:10:33] <mojavelinux> just more fine-grained if you do system
[20:10:38] <bleathem> one more question: should the Qualifiers we spoke about be Seam Security qualifiers, or Faces Qualifiers?
[20:10:43] <mojavelinux> because you know that you don't interfere with application phase listeners
[20:10:51] <mojavelinux> faces
[20:11:00] <bleathem> ok
[20:11:12] <mojavelinux> you might just be able to use what you have, as in @Before @Render
[20:11:31] <mojavelinux> @Before @RenderResponse
[20:11:42] <mojavelinux> only downside is that you might think you can use any combination
[20:11:45] <bleathem> Then we might get people trying unsupported combinations
[20:11:45] <mojavelinux> but you could fail at startup
[20:12:00] * bleathem is a slower typer than mojavelinux
[20:12:04] <mojavelinux> when processing the enum
[20:12:26] <mojavelinux> you could also just say that the timing is assumed
[20:12:31] <mojavelinux> and then just do @RenderResponse
[20:12:52] <mojavelinux> they tell you which phase, the timing within the phase is fixed
[20:13:02] <bleathem> We could ignore unsupported qualifiers, assume the default, and log an error
[20:13:13] <mojavelinux> fail is better
[20:13:19] <mojavelinux> it's like having a bad injection point
[20:13:29] <bleathem> ok
[20:13:35] <bleathem> how do I do that?
[20:13:43] <bleathem> Is there another class I can look at for an example?
[20:14:33] <mojavelinux> the view config extension currently has the code for processing the enum
[20:14:41] <mojavelinux> it does isAnnotationPresent
[20:14:47] <mojavelinux> you would want to do getAnnotations()
[20:14:55] <bleathem> #idea use the exisitng Faces qualifiers to qualify the Seam Security annotations (eg. @RenderResponse_
[20:15:01] <mojavelinux> and make sure that only the allowed phases are there
[20:16:01] <mojavelinux> I would play with some ideas in the jira comments about how it will look for the user
[20:16:07] <bleathem> ok, is that done at application startup?
[20:16:21] <bleathem> the allowed phases stuff
[20:16:28] <bleathem> or when the @ViewConfig is processed
[20:16:41] <bleathem> nevermind
[20:16:48] <mojavelinux> yep
[20:16:55] <bleathem> getting confused with f:metadat which is processed on first visit
[20:17:02] <mojavelinux> btw, are you going to change @ViewData to @ViewPattern?
[20:17:12] <mojavelinux> @ViewPattern("/admin/*")
[20:17:15] <bleathem> I changed ViewData to VeiwMeta
[20:17:21] <bleathem> oh wait
[20:17:23] <mojavelinux> ah, right
[20:17:24] <bleathem> let me check
[20:17:26] <mojavelinux> actually, you know what
[20:17:29] <mojavelinux> you should do
[20:17:59] <bleathem> yeah, I'd done ViewMeta
[20:18:03] <bleathem> but I'm not married to it
[20:18:03] <mojavelinux> @ViewMeta(patterns = {"/admin/*", "/admin.xhtml"})
[20:18:08] <kenfinnigan> mojavelinux: You fixed SOLDER-86 as part of SOLDER-85 didn't you?
[20:18:11] <jbossbot> jira [SOLDER-86] Split up LoggerProducers [Open (Unresolved) Task, Minor, Ken Finnigan] https://issues.jboss.org/browse/SOLDER-86
[20:18:12] <jbossbot> jira [SOLDER-85] Better separation of i18n and logging concerns [Resolved (Done) Enhancement, Major, Dan Allen] https://issues.jboss.org/browse/SOLDER-85
[20:18:15] <mojavelinux> yep!
[20:18:22] <kenfinnigan> cool, will mark it done
[20:18:36] <mojavelinux> or perhaps @ViewMeta(viewIds = {})
[20:18:56] <mojavelinux> what if you do
[20:19:01] <bleathem> What other parameter would go in ViewMeta, that would warrant adding a parameter name?
[20:19:25] <bleathem> How about @ViewIds()
[20:19:26] <bleathem> ?
[20:19:58] <mojavelinux> ah, in that case, you probably want @ViewPattern
[20:20:10] <bleathem> Ok, I'll go with @ViewPattern
[20:20:19] <bleathem> but the rest should stay as @ViewMeta I think
[20:20:24] <mojavelinux> and you can do @ViewPatterns({@ViewPattern("/admin/*"), @ViewPattern("/admin.xhtml")})
[20:20:28] <bleathem> It's bigger than just ViewPattern
[20:20:36] <bleathem> nice
[20:20:45] <mojavelinux> the thing is, each enum value is the meta
[20:20:46] <bleathem> #topic Naming convention
[20:20:50] <mojavelinux> so the annotation can't be ViewMeta
[20:20:57] <mojavelinux> because then that means everything is in that one annotation
[20:21:01] <mojavelinux> when in fact, it's stacked
[20:21:11] <bleathem> #idea rename @ViewMeta to @ViewPattern
[20:21:21] <mojavelinux> or ViewMapping
[20:21:22] <bleathem> #idea, one can suport @ViewPatterns({@ViewPattern("/admin/*"), @ViewPattern("/admin.xhtml")})
[20:21:33] <bleathem> View mapping is good too
[20:21:49] <bleathem> but I like the pattern part to support the "*"
[20:22:10] <johnament_away> so if you have an admin section of your app, you always secure it
[20:22:12] <mojavelinux> right, the value is a collection of patterns
[20:22:13] *** johnament_away is now known as johnament
[20:22:39] <bleathem> ok, I'll end the meeting then, and create some jiras.
[20:22:42] <mojavelinux> @ViewMapping({"/admin/*", "/admin.xhtml"})
[20:23:11] <bleathem> I don't feel strongly about either, if you have a preference
[20:23:19] <mojavelinux> not really, we can see what the masses thing
[20:23:21] <mojavelinux> think
[20:23:47] <mojavelinux> btw, internally, ViewMetadata is fine
[20:23:49] <bleathem> #idea or maybe instead @ViewMapping({"/admin/*", "/admin.xhtml"})
[20:23:59] <mojavelinux> in a sense, this is a superset, or complement to template view metadata
[20:23:59] <bleathem> rather than ViewMeta?
[20:24:16] <mojavelinux> so it's really a very similar purpose
[20:24:20] <bleathem> If they are indeed analagous, then ViewMeatadata is better
[20:24:36] <mojavelinux> I would say it's either ViewMetadata or ViewConfiguration
[20:24:36] <bleathem> I'll go with ViewMetadata then
[20:24:43] <mojavelinux> cool
[20:24:51] <bleathem> ViewMetadataStore
[20:25:04] <bleathem> ViewConfiguration sounds to similar to Viewconfig
[20:25:31] <mojavelinux> yep, though honestly I wouldn't mind @ViewConfiguration
[20:25:32] <bleathem> Or we could use ViewConfigStore
[20:25:47] <bleathem> Since it is storing the ViewConfig
[20:25:55] <bleathem> rahter then ViewmetaDataStore
[20:26:14] <bleathem> ^rather than ViewMetadataStore
[20:26:16] <mojavelinux> I like the Store suffix for the holder
[20:26:21] <mojavelinux> that works
[20:27:48] <mojavelinux> we could do @ViewMetadata, but hard to pluralize that
[20:28:02] <bleathem> #action renamve @ViewMeta to @ViewMapping
[20:28:17] <bleathem> #action rename @ViewMetaStore to @ViewConfigStore
[20:28:30] <mojavelinux> i know, we are saying that the view configuration associates metadata with various views
[20:28:47] <bleathem> ok, I got myself all turned around.
[20:29:04] <bleathem> I'll mess around with the naming in code, and come up with something that captures the intent nicely
[20:29:12] <mojavelinux> wait, ViewConfigStore isn't an annotation
[20:29:17] <mojavelinux> is it?
[20:29:19] <mojavelinux> it's just like this
[20:29:22] <bleathem> No, it's not
[20:29:29] <bleathem> I cpoy and paster the previous line
[20:29:39] <bleathem> copy and paste alway intorduces error :P
[20:29:54] <bleathem> my typing is going downhill altogether at the moment
[20:30:05] <bleathem> #closemeeting
[20:30:17] <bleathem> #endmeeting
[20:30:22] <jbott> Meeting ended Sat Mar 19 19:27:25 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[20:30:22] <jbott> Minutes:        http://people.redhat.com/~manderse/irc.freenode.org/meetings/seam-dev/2011/seam-dev.2011-03-19-18.00.html
[20:30:22] <jbott> Minutes (text): http://people.redhat.com/~manderse/irc.freenode.org/meetings/seam-dev/2011/seam-dev.2011-03-19-18.00.txt
[20:30:22] <jbott> Log:            http://people.redhat.com/~manderse/irc.freenode.org/meetings/seam-dev/2011/seam-dev.2011-03-19-18.00.log.html
[20:31:07] <bleathem> Just reread my few previous lines.
[20:31:09] <mojavelinux> @ViewConfiguration
[20:31:09] <mojavelinux> public enum BookingViewConfiguration
[20:31:09] <mojavelinux> {
[20:31:09] <mojavelinux>    @ViewPattern("/booking.xhtml")
[20:31:09] <mojavelinux>    BOOKING;
[20:31:10] <mojavelinux> }
[20:31:16] <bleathem> that was really bad typing
[20:31:27] <bleathem> yes, that looks nice
[20:31:52] <bleathem> You prefer the "Configuration" over the shorter "Config"?
[20:32:06] <mojavelinux> that should be more like BookingSiteConfiguration or something
[20:32:25] <mojavelinux> hard to say, might need to take it to the jury
[20:32:36] <mojavelinux> you could always tweet it
[20:32:45] <mojavelinux> use doodle to show options
[20:32:57] <bleathem> yeah, drum up community interest
[20:32:57] <mojavelinux> via pastie
[20:33:07] <mojavelinux> the idea is, what do the developer think makes sense
[20:33:17] <mojavelinux> put together some samples
[20:33:25] <mojavelinux> we need this in booking, so that's a good place to start
[20:33:39] <mojavelinux> for instance, the book.xhtml needs to be secured, and account.xhtml needs to be secured
[20:33:57] <mojavelinux> and you can stub in some view actions for good measure
[20:36:24] <kenfinnigan>  mojavelinux: do you know if forge can handle multi module maven projects that it didn't create?
[20:37:36] <bleathem> Created SEAMFACES-105
[20:37:38] <jbossbot> jira [SEAMFACES-105] Addi a dummy UIViewParameter if there are other non-UIViewParameter children in the metadata view [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-105
[20:38:04] <bleathem> Corrected SEAMFACES-105
[20:38:06] <jbossbot> jira [SEAMFACES-105] Add a dummy UIViewParameter if there are other non-UIViewParameter children in the metadata view [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-105
[20:39:41] <bleathem> I think all other action items are covered by seamfaces-33
[20:39:49] <bleathem> I just need to *do* them
[20:40:34] <bleathem> tha'll come tonight hopefully, for now I have to go enjoy the sunshine - it's been a few months since I last saw it!
[20:40:45] <bleathem> thanks for your time mojavelinux!
[20:41:23] <mojavelinux> you bet
[20:41:42] <mojavelinux> super! go relax and clear your head
[20:42:18] <kenfinnigan> anyone know if forge can handle multi module maven projects?
[20:46:24] <mojavelinux> i'm going to say no
[20:46:39] <kenfinnigan> ok
[20:46:50] <kenfinnigan> didn't think so but wanted to clarify
[20:47:05] <kenfinnigan> might do some digging into the error I'm getting to make sure it's related to that
[20:47:10] <kenfinnigan> and not some windows user bug!
[20:47:42] <johnament> definitely sounds like a windows bug
[20:49:02] <mojavelinux> yeah, it's called a "lincoln thinks you shouldn't be using that" bug
[20:49:06] <mojavelinux> it's not simple
[20:49:07] <mojavelinux> hahah
[20:49:11] <kenfinnigan> probably
[20:49:27] <mojavelinux> in truth, it's the same reason I've punted on making an ear archetype
[20:49:38] <kenfinnigan> though it looks like using the snapshot in a non distributed fashion doesn't get the same error as the distribution
[20:49:40] <mojavelinux> i think about how hard it is to do a war archetype
[20:49:44] <mojavelinux> then I just cry
[20:50:01] <kenfinnigan> that's always my challenge
[20:50:14] <kenfinnigan> war vs ear and how fine grained to split down the modules!
[20:50:50] <mojavelinux> don't get me wrong, I think ear is very useful now that I've studied some more projects that use them
[20:50:59] <mojavelinux> it's just that maven makes it damn near impossible to use
[20:51:07] <mojavelinux> i didn't realize how simple ears were
[20:51:10] <mojavelinux> until I used shrinkwrap
[20:51:17] <mojavelinux> then it was so damn simple
[20:51:25] <mojavelinux> now if I could just get shrinkwrap for my build
[20:51:47] <kenfinnigan> could probably write a forge plugin for that
[20:51:56] <mojavelinux> yeah, or gradle
[20:52:09] <kenfinnigan> was actually thinking the other day it would be cool to offer a forge plugin to generate message classes from the annotations
[20:52:21] <kenfinnigan> to provide option of compile tooling or pre-compile through forge
[20:52:35] <mojavelinux> hell yes! now I know i'm not insane since I tried to suggest that to lincoln
[20:52:47] <kenfinnigan> he didn't like the idea?
[20:52:49] <mojavelinux> also, it would be really nice if you could generate the properties files
[20:52:53] <mojavelinux> oh, I think he ignored me
[20:52:56] <mojavelinux> hahaha
[20:53:03] <kenfinnigan> generate property files?
[20:53:16] <mojavelinux> yeah, the language files
[20:53:23] <mojavelinux> it would go to google translate
[20:53:26] <kenfinnigan> you mean if the developer created annotated version for each language?
[20:53:32] <kenfinnigan> oh ok
[20:53:33] <mojavelinux> and translate the messages in @Message() and write them to the file
[20:53:37] <mojavelinux> yeah
[20:53:43] <kenfinnigan> ok, that could work
[20:53:43] <mojavelinux> so you could say, give me a french file
[20:53:44] <mojavelinux> go
[20:53:50] <johnament> don't use google translate to translate text.
[20:53:55] <kenfinnigan> if nothing else it would be a good starting point for translations
[20:53:59] <mojavelinux> exactly
[20:54:00] <kenfinnigan> if not always completely accurate
[20:54:04] <mojavelinux> or whatever service
[20:54:12] <johnament> contexts make the big difference.
[20:54:47] <mojavelinux> true, it's not an idea way
[20:54:51] <mojavelinux> one thing you could do instead
[20:55:00] <mojavelinux> it's more for devs to test
[20:55:05] <kenfinnigan> do you think there's a need to generate the classes from the annotated classes at bootup of the server?
[20:55:18] <kenfinnigan> or we should only support pre deploy options
[20:55:40] <mojavelinux> I'd like to see that personally, just so that people don't need the annotation processor, but it's not as high priority
[20:55:56] <mojavelinux> btw, I like the idea of forge generating the metadata classes for jpa
[20:55:57] <kenfinnigan> thought it might be nice to have
[20:55:58] <johnament> I feel great today.
[20:55:58] <johnament> Me siento muy bien hoy.
[20:55:58] <johnament> I feel very well today.
[20:56:15] <kenfinnigan> that would be handy
[20:56:26] <johnament> that would be a great thing.
[20:56:36] <johnament> the way it works with maven is a real PIA.
[20:56:41] <kenfinnigan> indeed
[20:56:47] <mojavelinux> since seriously, you don't need that annotation processor spinning it's wheels on every build
[20:56:51] <lightguard_jp> Anything with maven is a pain
[20:57:03] <mojavelinux> think about it, you write jpa entities over a period of a week
[20:57:05] <mojavelinux> let's say
[20:57:07] <lightguard_jp> Save Hello World :)
[20:57:10] <mojavelinux> it builds maybe 500 times
[20:57:17] <mojavelinux> then, that app is developed for 2 more years
[20:57:22] <mojavelinux> about a million builds
[20:57:26] <lightguard_jp> That's a lot of extra annotation processing going on :(
[20:57:31] <mojavelinux> and you have the generate the classes on all those builds
[20:57:34] <kenfinnigan> very true
[20:57:34] <mojavelinux> seriously
[20:57:56] <mojavelinux> and what forge could do is make sure that you are up to date
[20:58:05] <mojavelinux> so instead of just generating the classes, it can prune old ones
[20:58:16] <kenfinnigan> if we had a forge plugin, that could be embedded into jboss tools to generate that whenever the source changes
[20:58:31] <kenfinnigan> as part of the save process
[20:58:32] <mojavelinux> yeah, like something actually intelligent
[20:58:43] <mojavelinux> but back to the i18n real quick
[20:58:47] <kenfinnigan> sure
[20:58:55] <mojavelinux> instead of translating, it could just put the properties file for a language in place
[20:59:04] <kenfinnigan> with all the keys
[20:59:09] <johnament> mojavelinux: do you know if shrinkwrap can give me an input stream to the generated archive?
[20:59:09] <mojavelinux> yep
[20:59:24] <kenfinnigan> think that would provide a big help to most people
[20:59:57] <mojavelinux> good question
[21:00:11] <kenfinnigan> do we need/want to support translated content within the annotated interface itself?
[21:00:19] <kenfinnigan> or only through properties?
[21:01:08] <mojavelinux> you are thinking like a method per language per key?
[21:01:19] <mojavelinux> like @Message @Locale("en")
[21:01:22] <kenfinnigan> something like that
[21:01:24] <mojavelinux> @Message @Locale("fr")
[21:01:28] <mojavelinux> I think that was proposed at one point
[21:01:30] <mojavelinux> so sure
[21:01:32] <kenfinnigan> wasn't really sure how it would work
[21:01:42] <kenfinnigan> either on the same interface or sub interfaces per language
[21:01:45] <mojavelinux> ah, better way
[21:01:49] <mojavelinux> got a better way
[21:01:54] <kenfinnigan> on the same interface would make it very crowded
[21:01:57] <kenfinnigan> cool
[21:02:23] <mojavelinux> @Messages({ @Message(lang = "en", value = "hi"), @Message(lang = "fr", value = "bonjour")})
[21:02:39] <mojavelinux> except we have to kill the Messages class ;)
[21:02:52] <kenfinnigan> lol
[21:03:08] <kenfinnigan> that's the best way I've seen to do multiple languages in the one file
[21:03:13] <mojavelinux> sweet!
[21:03:24] <mojavelinux> I guess we could name is @LocalizedMessages
[21:03:26] <mojavelinux> or something
[21:03:32] <kenfinnigan> I guess if an app needs 10 languages they would not take that approach as it would be very unreadable
[21:03:34] <mojavelinux> to indicate that we are doing the localization inline
[21:03:39] <kenfinnigan> makes sense
[21:03:54] <mojavelinux> yeah, this would definitely be for the "don't need the overkill solution" developers
[21:03:56] <kenfinnigan> indicate there are multiple @Message items to process
[21:04:00] <mojavelinux> yep
[21:04:11] <mojavelinux> and what's cool is this!
[21:04:14] <kenfinnigan> should be able to handle that in the processor
[21:04:17] <mojavelinux> you can now say what the default language is
[21:04:26] <mojavelinux> even if you are only doing one language
[21:04:37] <mojavelinux> like @Message(value = "hi", locale = "en")
[21:04:54] <mojavelinux> kind of a little hint
[21:05:01] <kenfinnigan> very true
[21:05:17] <mojavelinux> for completeness :) but it also justifies that we need to add locale() to message
[21:05:24] <kenfinnigan> would we put a default locale on @MessageBundle on the interface?
[21:05:40] <mojavelinux> you could, sure
[21:05:55] <kenfinnigan> actually, probably don't need that with the locale stuff we already have
[21:06:04] <kenfinnigan> that is also more flexible as it can be changed through config
[21:06:10] <kenfinnigan> forget that
[21:06:10] <mojavelinux> true
[21:06:25] <mojavelinux> hey, what's cool about LocalizedMessages idea
[21:06:26] <mojavelinux> is that
[21:06:31] <mojavelinux> you could add those via Seam Config
[21:06:42] <mojavelinux> so you can do your localization there
[21:06:55] <mojavelinux> granted, you can't generate the classes that way
[21:07:13] <mojavelinux> though I suppose the annotation processor could look for that configuration...sort of getting round about at that point
[21:07:14] <kenfinnigan> am I right in thinking that would only work if we had run time annotation generation?
[21:07:24] <mojavelinux> see previous comment :)
[21:07:27] <kenfinnigan> ah yes
[21:07:36] <mojavelinux> btw
[21:07:47] <mojavelinux> make sure the annotation processor supports the XML version of properties files
[21:07:53] <mojavelinux> because it allows UTF-8 :)
[21:07:58] <mojavelinux> huge thing for translations
[21:08:05] <mojavelinux> in fact, the XML should be the preferred syntax
[21:08:11] <kenfinnigan> will have to check that
[21:08:14] <mojavelinux> see latest version of Wicket for notes about that
[21:08:20] <mojavelinux> they make an important case for it
[21:08:22] <kenfinnigan> have only tried it with regular property files at present
[21:08:29] <mojavelinux> yep, me too, but chinese
[21:08:33] <mojavelinux> you are screwed with .properties files
[21:08:37] <mojavelinux> you can't even open them in vim
[21:08:43] <mojavelinux> but with XML, you can
[21:08:43] <lightguard_jp> Any multi-byte language
[21:08:45] <kenfinnigan> good point
[21:08:46] <mojavelinux> yep
[21:08:59] <mojavelinux> i'll find that page on the wicket site, one second
[21:09:04] <kenfinnigan> cool
[21:09:45] <mojavelinux> https://issues.apache.org/jira/browse/WICKET-2035
[21:09:53] <mojavelinux> btw, you can have .utf8.properties
[21:09:56] <mojavelinux> in java 6
[21:10:05] <kenfinnigan> good tip
[21:10:35] <mojavelinux> :) nice improvement before they even know we didn't think of it
[21:10:39] <mojavelinux> thanks wicket in action
[21:10:54] <kenfinnigan> lol
[21:12:49] <mojavelinux> btw, SEAMFACES-104 should really be in i18n
[21:12:51] <jbossbot> jira [SEAMFACES-104] Dynamic resource bundles [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-104
[21:14:03] <kenfinnigan> think we already have a jira around being able to subclass ResourceBundle.Control and have i18n use it to load resources
[21:14:11] <kenfinnigan> also raised by Nicklas
[21:14:47] <kenfinnigan> yesp, SEAMINTL-13
[21:14:49] <jbossbot> jira [SEAMINTL-13] Support Java 6 ResourceBundle.Control [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMINTL-13
[21:15:23] *** alesj has joined #seam-dev
[21:16:27] <mojavelinux> i'll close as a dup
[21:16:33] <mojavelinux> the faces one
[21:18:34] <mojavelinux> linked and closed
[21:18:41] <mojavelinux> I moved the reference to john's blog as well
[21:20:12] *** alesj has left #seam-dev
[21:21:32] <kenfinnigan> cheers
[21:21:59] <johnament> that blog post is a year old now O_O
[21:22:19] <kenfinnigan> mojavelinux: are there any restrictions on which arquillian containers are suitable for testing application scope injection into request scope?
[21:22:39] <kenfinnigan> had done a test using weld ee embedded for this scenario and it would sometimes pass and sometimes not!
[21:23:56] <kenfinnigan> sometimes the application scoped injection was null, which caused the failure
[21:24:43] <johnament> request scoped needs to be wrapped around an HTTP request, right?
[21:25:03] <kenfinnigan> think so
[21:25:06] <johnament> it doesn't make a lot of sense outside of at least a servlet container
[21:25:15] <johnament> i don't think weld ee embedded emulates that.
[21:26:05] <kenfinnigan> ah ok
[21:27:18] <kenfinnigan> is there a way to access a session scoped bean from within the application scope in a safe manner?
[21:28:12] <mojavelinux> well, concurrency won't be handled
[21:28:18] <mojavelinux> but you will get the right instance
[21:28:32] <mojavelinux> actually, I was thinking, seam really needs the concurrency control that is in ejb 3.1
[21:28:36] <mojavelinux> that would be really useful
[21:28:42] <mojavelinux> perhaps another job for seam cron
[21:28:45] <kenfinnigan> ok, just trying to think how to solve SEAMINTL-33
[21:28:46] <jbossbot> jira [SEAMINTL-33] Injections null when Bundles.get(String) is called [Open (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-33
[21:29:49] <johnament> kenfinnigan: what if the injection occurs as arguments to the method?
[21:30:11] <johnament> i forget if it matters
[21:30:31] <kenfinnigan> that's a thought
[21:30:49] <kenfinnigan> so the session scoped locale is an argument to the method on the app scope bean
[21:31:58] <johnament> hrm
[21:32:29] <johnament> kenfinnigan: can bundles provide a producer that matches?
[21:32:46] <kenfinnigan> not sure what you mean
[21:32:47] <johnament> just reread the code
[21:33:05] <johnament> well, Nicklas has code in the issue.
[21:33:59] <kenfinnigan> the code he has is injecting the request scoped bean
[21:34:10] <kenfinnigan> so to use the app scoped one he would also need to provide the locale
[21:34:50] <johnament> which one is?
[21:35:13] <johnament> i figured bundles was app scoped
[21:35:24] <kenfinnigan> no, that's the request scoped one#
[21:36:32] <johnament> you provided or he provided?
[21:36:43] <kenfinnigan> i18n provided
[21:42:27] *** kenfinnigan has quit IRC
[21:45:35] <johnament> doh
[21:47:33] <nickarls> johnament: combined
[21:48:48] <nickarls> I have no clue how the same proxy can look different for two invocations in a row
[21:49:52] <johnament> oh, there you are.
[21:50:02] <johnament> what app server? AS 6?
[21:50:11] <nickarls> yep.
[21:50:52] <nickarls> The get is really strange. I put a breakpoint in it and in shows null injections
[21:51:07] <nickarls> I put a breakpoint in size(), it shows injections
[21:51:09] <johnament> do you have this code somewhere?
[21:51:43] <nickarls> there's not much more than what's in the JIRA
[21:52:07] <nickarls> I listen for PostApplicationContructed event and load my custom resourcebundle from DB and stick it in ApplicationBundles
[21:52:48] <nickarls> the I thought I'd make a shorthand producer so I don't have to do #bundles['foo']['bar']
[21:53:07] <nickarls> instead just something like #{foo['bar']}
[21:53:31] <lightguard_jp> With as many impromptu meetings as happen I think we need to modify (or create our own) meeting bot and make the logs more visibl.
[21:53:32] <nickarls> but my producer which is accessing the Bundles is acting strange
[21:53:43] <nickarls> well, Bundles is
[21:54:00] <nickarls> it's just as if the get() is not hitting the expected method
[21:54:11] <lightguard_jp> nickarls: I was thinking of something a little more indepth than the code you pasted in SEAMCATCH-50
[21:54:13] <jbossbot> jira [SEAMCATCH-50] Interceptor that propagates exceptions [Open (Unresolved) Feature Request, Major, Jason Porter] https://issues.jboss.org/browse/SEAMCATCH-50
[21:54:49] <lightguard_jp> something that would wrap the exception into a SeamCatch exception and have the params of the method that caused the exception.
[21:55:06] <lightguard_jp> That way you'd have a little more insight into what caused it (hopefully)
[21:55:10] <nickarls> jp: sure, I was just going for something "catch all" that would keep my EJBs from croaking
[21:55:28] <nickarls> tried re-throwing but it got wrapped in a WeldException
[21:55:45] <nickarls> and not being @ApplicationException, croaking followed.
[21:56:03] <lightguard_jp> Ah
[21:56:35] <lightguard_jp> I was thinking of having them auto added by catch around every method, but that may be a little heavy handed
[21:56:57] <nickarls> john: in fact, I think that the NPE should be reproducable from and call to an injected Bundles.get(String)
[21:58:10] <johnament> both objects are null? bundles and locale?
[21:58:17] <nickarls> yep.
[21:58:41] <johnament> what does your injection point for bundles look like?
[21:59:45] *** gmorling has quit IRC
[22:00:09] <nickarls> @Inject Bundles bundles, there's not that many ways to inject ;-)
[22:00:26] <johnament> what about @Inject @Named Bundles bundles
[22:00:41] <johnament> or @Inject @Named("bundles") Bundles bundles;
[22:01:02] <nickarls> didn't try. but it resolves the Bundles correctly
[22:02:45] <johnament> humor me if you don't mind :-)
[22:03:36] <nickarls> I don't have the exact case at my current machine but I'll try
[22:03:42] <nickarls> trying to reproduce the original bug first
[22:04:15] <johnament> i would understand if you were trying to inject a request scoped bean into an application scoped bean.
[22:04:18] <johnament> that it would fail.
[22:04:21] <johnament> but it's opposite here.
[22:05:03] <johnament> the only odd thing I see is that the class is decorated @Named and while @Inject Bundles bundles should still work, the more accurate resolution would be @Inject @Named("bundles") Bundles bundles;
[22:09:14] <nickarls> I don't think @Named should ever be used in injections
[22:09:54] <johnament> don't get me started on @named and @requestscoped
[22:10:03] <johnament> what happens when I'm not running in a servlet container?!?!
[22:12:06] <nickarls> ?
[22:12:30] <nickarls> @Named is needed for EL, it doesn't count when resolving
[22:13:34] <johnament> http://download.oracle.com/javaee/6/api/javax/inject/Named.html
[22:13:49] <nickarls> oops, wrong i18n, ApplicationBundles didn't exist in CR1
[22:15:59] <nickarls> john: bad example ;-) Gavin would call that "legacy injection used by Lesser Frameworks" :-)
[22:16:50] <nickarls> johnament: http://pastebin.com/LaerYpcv
[22:17:14] <nickarls> gives the NPE
[22:17:20] <nickarls> 3.0.0-SNAPSHOT
[22:17:52] <nickarls> CR1 gave the missing resource exception but that was before the ApplicationBundles stuff
[22:19:54] <nickarls> @Named("bundles") gave unresolved exception
[22:20:06] <nickarls> which is strange on a bean @Named Bundles
[22:20:19] <johnament> hold on, let me get an app up.
[22:20:55] <nickarls> @Inject @Named Bundles also unresolved
[22:21:44] <johnament> O_o
[22:33:27] *** daniel_hinojosa has joined #seam-dev
[22:36:15] <johnament> nickarls: i got the expected result...
[22:36:48] <johnament> which was an error from the application bundles, showing me that it wasn't null.
[22:36:57] <johnament> because i didn't create a foo bundle.
[22:37:11] <johnament> i hate to ask... where's your beans.xml?
[22:38:55] <nickarls> WEB-INF (war packed)
[22:39:50] <johnament> want me to put my app on github to take a look?
[22:40:05] <johnament> its your fooproducer, and a jax-rs resource.
[22:40:45] <nickarls> attached to jira
[22:40:53] <nickarls> my sample
[22:41:31] <nickarls> there is some extra stuff in it but put a breakpoint in FooProducer
[22:41:48] <nickarls> going to the context root will EL-ref #foo which triggers the producer
[22:45:41] <johnament> nickarls: i'll take a look a bit more later.
[22:45:50] <johnament> you can see my sample at https://github.com/johnament/intl-request
[22:47:19] <johnament> i can however see the producer method getting invoked in the logs, so something's working.  i'll try again w/ EL resolution.
[22:47:28] *** johnament is now known as johnament_away
[23:09:50] *** jharting has quit IRC
[23:15:06] *** tsurdilo has quit IRC
[23:43:15] <mojavelinux> solution for SEAMFACES-105 sent
[23:43:17] <jbossbot> jira [SEAMFACES-105] Add a dummy UIViewParameter if there are other non-UIViewParameter children in the metadata view [Pull Request Sent (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-105
[23:43:31] <mojavelinux> found a naaaaaaaaaasty swallowed exception in Mojarra that cost me an hour
[23:43:48] <mojavelinux> if an exception occurs in createViewMetadata, it gets swallowed up
[23:44:11] <mojavelinux> you can reproduce by including a bogus tag in the <f:metadata>
[23:44:17] <mojavelinux> would be interested to see if it happens in glassfish
[23:44:56] <mojavelinux> correction, in Mojarra 2.1
[23:48:00] <lightguard_jp> I'm starting to wonder if myfaces is any better
[23:48:24] <lightguard_jp> Digging down into some core mojarra classes really starts showing its blemishes.
[23:48:37] <mojavelinux> fixed in MOjarra 2.1
[23:48:58] <mojavelinux> that's good news, but I think part of that was my issue reports of don't freakin' swallow exceptions
[23:49:06] <mojavelinux> they did a code review apparantely for all try {}
[23:49:10] <mojavelinux> I guess this one came up
[23:49:23] <mojavelinux> try { } finally { }
[23:49:28] <mojavelinux> is about the most evil thing ever
[23:49:45] <mojavelinux> actually, correction
[23:50:11] <mojavelinux> doing serial logic in a finally block is evil
[23:50:18] <mojavelinux> don't proceed if you have a pending exception
[23:50:28] <mojavelinux> which is what the case was here
[23:50:37] <mojavelinux> it's like, well, something failed, but just keep processing the tree anyway
[23:50:40] <mojavelinux> oh, what?
[23:50:42] <mojavelinux> there's no tree?
[23:50:53] <mojavelinux> why is that? maybe has something to do with that exception you just left in the dust
[23:51:25] <mojavelinux> oh yeah, there is this major but in mojarra 2.1 that is breaking all of our forms in booking
[23:51:37] <mojavelinux> code that has worked since the first jsf 2.0 release
[23:51:43] <mojavelinux> I get this message
[23:52:42] <mojavelinux> ...
[23:53:45] <lightguard_jp> They fixed something in 2.1 which completely broke existing stuff?
[23:54:06] <mojavelinux> The form component needs to have a UIForm in its ancestry. Suggestion: enclose the necessary components within <h:form>
[23:54:15] <mojavelinux> um, they are
[23:54:17] <mojavelinux> fools
[23:54:34] <mojavelinux> and how about giving me an indication of *which components!*
[23:54:36] <mojavelinux> just saying
[23:54:39] <mojavelinux> it would be helpful
[23:55:03] <lightguard_jp> Lol
[23:55:10] <lightguard_jp> Dan's a little irked right now.
[23:55:18] <lightguard_jp> Wicket anyone?
[23:58:01] <lightguard_jp> *chirp* *chirp*
[23:58:14] <jbossbot> git [examples] push master 848604a.. Dan Allen add note about known issue
[23:58:14] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/bb418c7...848604a
[23:59:02] <mojavelinux> haha
[23:59:13] <lightguard_jp> That's great... nice job guys





top