March 22, 2011 
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31
March 22, 2011 [00:00:25] <lincolnthree1> it may require a few [00:00:28] <lincolnthree1> shouldn't be many [00:00:51] <sbryzak> lincolnthree1: hmm, in that case it would be nice to be able to configure it to scan both the lib and artifacts directories [00:01:26] <lincolnthree1> you can pass args into the $ forge command [00:01:37] <mojavelinux> we are going for something like this: http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_3/src/main/org/jboss/seam/async/ [00:01:45] <lincolnthree1> sbryzak: would you open an issue for this? [00:01:49] <lincolnthree1> so I don't forget :) [00:01:53] <mojavelinux> and since that package offered cron, then it makes sense to keep them grouped for seam 3 [00:01:53] <sbryzak> lincolnthree1: sure thing [00:02:04] <mojavelinux> I can open an issue to get the ball rolling [00:02:06] <lincolnthree1> let me know what you need as best as possible and I'll come back to you if I need more info [00:02:38] *** clerum has joined #seam-dev [00:02:40] <Royle> yeah please do [00:02:41] *** clerum has quit IRC [00:03:17] <mojavelinux> too bad, it won't be issue #1 ;) [00:03:23] <mojavelinux> someone beat me to it [00:03:29] <Royle> probably me I guess [00:03:32] <mojavelinux> ah, that was you hehehe [00:04:37] <bleathem> Ok, the qualifier cache has support for multiple security annotations now. [00:05:29] <bleathem> Now: Vanpool; Tonight: hopefully seamfaces-33 goes timbrr! [00:06:14] <bleathem> The timing of this is good. I need this feature in my day job. [00:06:49] <bleathem> I'll be coding up some nasty s:viewAction methods if this doesn't work out! [00:07:12] *** bleathem has quit IRC [00:08:01] <sbryzak> lincolnthree1: SEAMFORGE-80 [00:08:03] <jbossbot> jira [SEAMFORGE-80] Configurable classpaths for Forge [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFORGE-80 [00:08:06] <lincolnthree1> ty [00:08:29] <sbryzak> Royle: you're in brisbane right? [00:08:37] <Royle> yeah, and you too? [00:08:48] <sbryzak> yep, you north or south side? [00:09:02] <Royle> north side. work in mitchelton, live in staff heights [00:09:14] *** clerum has joined #seam-dev [00:09:16] <sbryzak> ah, cool.. i'm in daisy hill (south side) [00:09:30] <Royle> oh yeah col [00:10:14] <sbryzak> should catch up for a beer sometime and talk about the cron module :) [00:10:48] <Royle> yeah that would be cool :) [00:10:48] *** clerum has quit IRC [00:10:57] *** clerum has joined #seam-dev [00:17:52] <mojavelinux> SEAMCRON-2 [00:17:53] <jbossbot> jira [SEAMCRON-2] Implement asynchronous method invocation for managed beans [Open (Unresolved) Feature Request, Major, Peter Royle] https://issues.jboss.org/browse/SEAMCRON-2 [00:18:06] <Royle> thx [00:18:41] <mojavelinux> we might have to put the Australian flag on the Seam logo soon [00:19:12] *** daniel_hinojosa has quit IRC [00:19:15] <mojavelinux> I already added it to the seam home page next to shane's name...I was thinking of putting flags on each line to show the global diversity of seam :) [00:19:18] <mojavelinux> it's pretty cool [00:20:47] <mojavelinux> john will be happy that I left room for a JMS dispatcher [00:21:12] <mojavelinux> he'll likely be interested in helping with the design of the async support, his hand is johnament [00:21:27] <mojavelinux> he's been floating the jms module while jordan has been busy [00:21:29] <Royle> k i'll keep an eye out for him [00:24:39] <sbryzak> heh, yeah seam does have a lot of australian influence [00:24:41] <sbryzak> starting with gavin [00:25:36] <mojavelinux> yeah, but you guys still rock the home turf :) [00:27:48] <Royle> so this feels like a job for interceptors to me. would that be on the right track? [00:29:50] *** gastaldi has joined #seam-dev [00:30:28] <Royle> I just intercept it, wrap it and background it? [00:30:48] <gastaldi> hello everyone ! [00:31:02] <lightguard_jp> gastaldi: Hey [00:31:25] [00:31:50] [00:31:57] <gastaldi> :) [00:32:01] <lightguard_jp> gastaldi: Pretty good. Spent the last two hours fighting with a JAX-RS service just find out it was me using the wrong case on XML input [00:32:06] <lightguard_jp> gastaldi: haven't started yet [00:32:08] <lightguard_jp> April 4th [00:32:23] <gastaldi> hehe [00:32:33] <gastaldi> anxious ? [00:32:42] <lightguard_jp> Very [00:33:14] <gastaldi> I wish I had a red hat mug [00:33:20] <gastaldi> or that awesome jackets [00:33:26] <gastaldi> :P [00:33:31] <mojavelinux> Royle: yep, that's how it was done in seam 2 [00:34:02] <mojavelinux> the key is working out a nice dispatcher interface, then go ahead and just implement using a thread pool (configured via Seam Config) [00:34:13] <Royle> cool. so provider configuration boils down to interceptor config? [00:34:19] <mojavelinux> so just some properties that Seam Config can set [00:34:34] <Royle> ah k [00:34:35] <mojavelinux> exactly, which interceptor you enable likely [00:34:47] <mojavelinux> either that, or the dispatcher is an alternative [00:35:11] <mojavelinux> we can play around with it, figure out what works best [00:36:34] <Royle> ok gotchya [00:45:33] *** _gastaldi has joined #seam-dev [00:46:02] *** gastaldi has quit IRC [00:47:30] <jbossbot> git [forge] push master 728e0a2.. Lincoln Baxter, III git maven plugin fetching and installation is functional (basically) [00:47:30] <jbossbot> git [forge] push master b053c41.. Lincoln Baxter, III Maven builds are now embedded, and no longer require mvn to be installed (using 'project build') [00:47:31] <jbossbot> git [forge] push master 2955858.. Lincoln Baxter, III git verbosity update [00:47:31] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/a1ca374...2955858 [00:47:51] *** balunasj has joined #seam-dev [00:49:40] *** _gastaldi has quit IRC [00:49:49] *** aslak has quit IRC [00:52:00] *** gastaldi has joined #seam-dev [01:04:56] *** gastaldi is now known as gastaldi_away [01:11:05] <sbryzak> CR3 announcement is done: http://in.relation.to/Bloggers/Seam30CR3Released [01:15:24] <gastaldi_away> sbryzak: Is there a new seam-parent ? [01:15:28] *** gastaldi_away is now known as gastaldi [01:15:47] <sbryzak> gastaldi: not at this stage, no [01:16:22] <gastaldi> Strange, I am using CR8 on my project [01:17:04] <gastaldi> seam-bom = 3.0.0.CR8 [01:17:21] <sbryzak> CR9 [01:18:11] <gastaldi> :P Now I got totally confused [01:18:12] <gastaldi> :) [01:20:45] <jbossbot> git [jcr] push master d52bf20.. George Gastaldi Upgraded seam-bom to 3.0.0.CR9 [01:20:45] <jbossbot> git [jcr] push master URL: http://github.com/seam/jcr/compare/27bd9b4...d52bf20 [01:24:32] <sbryzak> don't worry, i'm confused too [01:26:51] <gastaldi> hehe [01:27:48] <gastaldi> @ExtensionManager has some functionality ? [01:27:55] <gastaldi> sorry @ExtensionManaged [01:28:03] <gastaldi> Or just a marker annotation ? [01:32:38] <lightguard_jp> Java primitives suck when it comes to reflection [01:32:44] <lightguard_jp> Just FYI [01:33:04] <gastaldi> lol [01:33:36] <gastaldi> lightguard_jp: I guess you must use the TYPE field on wrapper classes [01:34:25] <lightguard_jp> Yeah, doing a getMethod from a class and it doesn't autobox because it's using the Class [01:34:30] <lightguard_jp> grr [01:34:37] <gastaldi> :) [01:35:19] <gastaldi> Can anyone tell me what is @ExtensionManaged utility ? [01:35:32] <lightguard_jp> Used to be called @SeamManaged [01:35:38] <gastaldi> I knew that :) [01:35:45] <gastaldi> But why on Solder ? [01:35:50] <gastaldi> It seems a marker annotation [01:36:05] <lightguard_jp> It's a qualifier that essentially means the opposite of ContainerManaged [01:36:20] <lightguard_jp> Like Application Managed, but we're saying a CDI extension is managing it. [01:36:25] <gastaldi> humm [01:36:32] <lightguard_jp> Like with Persistence Units [01:37:05] <gastaldi> This annotation can be used on Extension classes ? [01:37:09] <gastaldi> I mean [01:37:16] <gastaldi> processed on Extension classes ? [01:38:10] *** balunasj has quit IRC [01:39:12] <gastaldi> humm... Managing instances on a HashMap ? Reallly ? [01:45:10] <gastaldi> hummmm [01:45:22] <gastaldi> Will the App Developer use that annotation ? [01:45:33] <lightguard_jp> Yep [01:45:52] [01:45:53] <lightguard_jp> Currently the use case is for producing an EntityManager using Seam Persistence [01:45:59] <gastaldi> hummm [01:46:16] <gastaldi> And ignoring others ? [01:47:48] <gastaldi> so the extension will manage its lifecycle ? [01:49:21] [01:49:52] <gastaldi> i believe the Uc is the same [01:52:06] <gastaldi> hey jose_freitas ! [01:52:14] <gastaldi> how was your Seam training ? [01:53:29] <gastaldi> *crickets* [01:59:22] <lightguard_jp> Boolean.TYPE.equals(((Boolean)true).getClass()) == false !!!!! WTF??? [01:59:23] *** jose_f_home has joined #seam-dev [01:59:33] <jose_f_home> hey mojavelinux [01:59:35] <gastaldi> lol [01:59:43] <jose_f_home> hello everyone [01:59:51] <gastaldi> hello jose_f_home [02:00:03] <lightguard_jp> stuartdouglas: You've done a lot of reflection stuff, yes? [02:00:45] <gastaldi> lightguard_jp: its surely false [02:00:57] <gastaldi> because the autoboxing [02:02:23] <lightguard_jp> Yeah, but that's SO messed up [02:02:28] <gastaldi> lightguard_jp: what are you trying to accomplish ? [02:02:32] <lightguard_jp> I need some solution... [02:02:50] <jbossbot> git [solder] push master c0b1bd5.. Dan Allen SOLDER-90 make extension constructor public for portability [02:02:51] <jbossbot> jira [SOLDER-90] Make extension constructors public [Open (Unresolved) Bug, Minor, Dan Allen] https://issues.jboss.org/browse/SOLDER-90 [02:02:51] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/18c3775...c0b1bd5 [02:03:11] <lightguard_jp> I need to Class#getMethod(String, Class[]) but I'm getting the Classes from Object[]. [02:03:20] <lightguard_jp> I may just need to make another method that takes the classes [02:03:34] <jbossbot> git [servlet] push master 4f47e41.. Dan Allen SEAMSERVLET-31 make constructor public for portability [02:03:35] <jbossbot> jira [SEAMSERVLET-31] Extension classes should have a public constructor [Open (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMSERVLET-31 [02:03:35] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/971ae94...4f47e41 [02:06:40] <gastaldi> Do u have a concrete example ? [02:07:45] <lightguard_jp> gastaldi: familiar with Seam 2 Component class? [02:09:11] <gastaldi> yup [02:09:48] <lightguard_jp> Don't ask the reason for madness :) [02:09:54] <gastaldi> :) [02:09:57] <stuartdouglas> lightguard_jp: yes [02:10:18] <lightguard_jp> I'm calling Component.getInstance(String, boolean) via reflection but it supports other classes as well. [02:10:28] <gastaldi> hummm [02:10:36] <lightguard_jp> stuartdouglas: What's the best way to get the class of a primitive if it comes in from an Object[] ? [02:10:37] <stuartdouglas> What is Boolean.TYPE.equals(((Boolean)true).getClass()) == false ? [02:10:46] <lightguard_jp> My current problem :) [02:10:55] <gastaldi> lots of ifs ? [02:10:57] <gastaldi> :) [02:11:03] <stuartdouglas> pretty much [02:11:18] <stuartdouglas> actually build up a hash table [02:11:22] <gastaldi> yep [02:11:24] <stuartdouglas> Map<Class,Class> [02:11:31] <lightguard_jp> But if I pass boolean.class to find a method that has a Boolean, they're not the same [02:11:36] <gastaldi> IdentityHashMap [02:12:03] <gastaldi> add the TYPE field as a key too [02:12:46] <gastaldi> like, Class.getPrimitiveClass("boolean") [02:13:08] <stuartdouglas> What exactly are you trying to do? [02:13:18] <lightguard_jp> Okay, imagine I have a class: public MyClass { public void myMethod(boolean) {} } [02:13:23] <gastaldi> ok [02:13:42] <lightguard_jp> Then I want to get the method of that class via Class#getMethod(String, Class[]) [02:13:47] <gastaldi> MyClass.class.getMethod("myMethod", new Class[]{Boolean.TYPE}); [02:13:56] <lightguard_jp> I also want to invoke it [02:13:59] <lightguard_jp> gastaldi: Hold on [02:14:05] <stuartdouglas> you can even use boolean.class these days [02:14:11] <gastaldi> :P [02:14:23] <lightguard_jp> So to save on method params I have findAndInvoke(String, Object[]) [02:14:34] <stuartdouglas> to invoke it you can just use a Boolean, reflection takes care of the unboxing [02:14:39] <gastaldi> yes [02:14:44] <lightguard_jp> I'm getting the classes for the getMethod by Object[] # each getClass [02:14:51] <stuartdouglas> you can't do that [02:14:59] <stuartdouglas> what if someone passes in a sub class? [02:15:05] <lightguard_jp> I need to pass both, right? [02:15:07] <stuartdouglas> then it will not find the method [02:15:10] <lightguard_jp> Class[] and Object[] [02:15:14] <lightguard_jp> Right [02:15:14] <stuartdouglas> yes [02:15:17] <gastaldi> You may use isAssignableFrom [02:15:20] <lightguard_jp> Bah [02:15:26] <lightguard_jp> gastaldi: Nope, tried that [02:15:34] <lightguard_jp> stuartdouglas: Okay, was afraid of that [02:15:37] <lightguard_jp> stuartdouglas: Thanks [02:15:54] <gastaldi> oh right [02:15:59] <gastaldi> Now I get it [02:16:00] <stuartdouglas> the issues is that if you have myMethod(Object) [02:16:19] <stuartdouglas> and you call findAndInvoke("myMethod","String Value") [02:16:25] <stuartdouglas> it will look for myMethod(String) [02:16:29] <gastaldi> Then you have to decide what is the most specialized one [02:16:30] <stuartdouglas> and not find it [02:16:52] <lightguard_jp> Right [02:16:53] <stuartdouglas> it is just generally bad [02:17:04] [02:18:36] <stuartdouglas> use generated bytecode instead :-) [02:19:02] <gastaldi> lol [02:19:05] <lightguard_jp> stuartdouglas: Nice idea, but a little late for this problem [02:19:45] <gastaldi> Deprecate the method and go get a beer ! :) [02:20:40] <lightguard_jp> gastaldi: lol [02:21:55] <gastaldi> Anyone from Brazil in here (other than me, of course) ? [02:22:12] <jose_f_home> =) mee [02:22:14] <jose_f_home> me [02:22:26] <gastaldi> jose_f_home: Where are u from ? [02:22:43] [02:22:47] <jose_f_home> you? [02:22:58] <gastaldi> No kidding, I am from Joinville and I am working in Floripa also [02:23:03] <gastaldi> :P [02:23:09] <jose_f_home> lol [02:23:15] <jose_f_home> lets get a beer [02:23:18] <gastaldi> yeah [02:23:21] <gastaldi> And pretty women [02:23:47] <jose_f_home> where do you work? [02:23:52] <gastaldi> TRT [02:23:54] <jose_f_home> parctec alfa? [02:24:19] *** Diablo-D3 has joined #seam-dev [02:24:23] <gastaldi> no, I work for a company located in Blumenau [02:25:15] <gastaldi> u ? [02:25:43] <jose_f_home> softplan [02:25:46] <jose_f_home> do you known? [02:25:50] <jose_f_home> parctec alfa [02:25:52] <gastaldi> sure [02:25:57] <gastaldi> I know some people there [02:26:18] <jose_f_home> :) [02:26:22] <jose_f_home> now you know me too [02:26:26] <gastaldi> yeah ! :D [02:26:36] <gastaldi> Do u usually eat on that crappy restaurant ? [02:26:37] <gastaldi> :P [02:26:47] <jose_f_home> we call it "big trash" [02:26:55] [02:26:57] <gastaldi> lol [02:27:24] [02:27:31] <gastaldi> Do u work with jCompany also ? [02:27:35] <jose_f_home> yeah, I kinda like it [02:27:38] <jose_f_home> nope [02:27:44] <jose_f_home> I work with research and development [02:27:49] <gastaldi> nice [02:27:52] <gastaldi> Are u using Seam ? [02:27:56] <jose_f_home> yeap [02:28:02] <gastaldi> Great [02:28:18] <gastaldi> Seam is one of the best frameworks ever written [02:28:35] [02:28:43] <gastaldi> hum... [02:28:51] <gastaldi> Why not wait for Seam 3 ? [02:29:13] <jose_f_home> well, its seam 3 [02:29:20] <jose_f_home> lol [02:29:22] <gastaldi> lol [02:29:26] <jose_f_home> I started this year [02:29:35] <gastaldi> nice [02:29:35] [02:29:48] <gastaldi> Are you a committer on any module ? [02:29:53] <gastaldi> Or contributor ? [02:29:57] <jose_f_home> just implemented some features using JAAS [02:30:04] <jose_f_home> faces, international and examples [02:30:08] <gastaldi> nice [02:30:20] [02:30:54] <gastaldi> yeah, I started studying JCR 2.0, and found another guy on the mailing list that needed to, so I decided to give it a try [02:30:55] <jose_f_home> congrats [02:31:00] <gastaldi> Thanks ! [02:31:37] <gastaldi> You know, someday we will all be hired by Red Hat and earn a lot of money, as they all do now :D [02:31:44] <jose_f_home> lol [02:32:46] <jose_f_home> I have to up some (many) levels just to think about it [02:33:17] <gastaldi> Good to know you are not one of those .NET guys [02:33:50] <gastaldi> well, gotta go now ! see ya ! [02:33:55] <jose_f_home> nice [02:34:03] *** gastaldi has quit IRC [02:34:05] <jose_f_home> when you have some time lets take a beer [02:38:25] *** lightguard_jp has quit IRC [02:38:29] <jose_f_home> stuartdouglas: I started using seam-config at seam-booking example [02:38:59] <jose_f_home> I configured the IdentityImpl from seam-security using it [02:39:20] <jose_f_home> the thing is that the beans.xml seems to have some seam 2 data [02:39:23] <jose_f_home> <s:specializes /> [02:39:51] <jose_f_home> is there anything that I can use to make use of a specializes func? [02:40:20] <jose_f_home> or something that do the job? [02:41:14] *** bleathem has joined #seam-dev [02:43:18] <stuartdouglas> what do you mean? [02:43:29] *** jganoff has joined #seam-dev [02:45:16] <jose_f_home> Well, let me try to find the real problem [02:45:21] <jose_f_home> <i18n:DefaultLocaleProducer defaultLocaleKey="en_US"> [02:45:22] <jose_f_home> <s:specializes /> [02:45:22] <jose_f_home> </i18n:DefaultLocaleProducer> [02:45:29] <jose_f_home> I had this on my beans.xml [02:46:45] <jose_f_home> it uses xmlns:s="urn:java:seam:core" [02:47:15] <jose_f_home> but it seemed that this filed was not read until I added the seam-config module [02:47:20] *** kenfinnigan has joined #seam-dev [02:47:26] <jose_f_home> actually the file is called seam-beans.xml [02:48:30] [02:48:33] <bleathem> Perhaps I should have started with this, [02:48:34] <bleathem> but On the way home today I thought about what the annoations should look like [02:48:40] <bleathem> I came up with this: [02:48:46] <bleathem> http://pastie.org/1698113 [02:49:12] <bleathem> The annotation and parameter names are strawmen, but I think demonstrate the principle [02:49:28] <bleathem> This is for SEAMFACES-33 by the way [02:49:33] <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 [02:49:49] <bleathem> sbryzak, the Seam Security annotations are all listed in the "security" parameter [02:50:25] <bleathem> The failed auth page is a seperate parameter (we go to the login page if the user is not logged in) [02:50:44] <bleathem> and the initial/postback request timings are listed as parameters [02:51:02] <bleathem> The nice thing about this, is that I only have one annotation to look for on a ViewPattern [02:51:19] <bleathem> rather than scanning through all annotations looking for the right qualifier. [02:51:45] <bleathem> the bummer part, is all that work I did for the @Qualifier cache in the ViewConfigStoreImpl is throw-away [02:51:53] <bleathem> oh well, it was fun to do! [02:52:04] <bleathem> Anyone have any feedback? [02:52:06] <jose_f_home> hehehe [02:52:24] <bleathem> What do you think jose? [02:52:26] <sbryzak> bleathem: i'll spend some time looking at it this afternoon [02:52:28] <sbryzak> where is the code? [02:52:47] <bleathem> About to code it up now [02:52:54] <bleathem> if the approach seems good [02:53:16] <bleathem> (the code I wrote until now was focused on having multiple Seam Security annotations on a ViewPattern) [02:53:49] <bleathem> I'm proposing scrapping that, in favor of the single annotation, with Seam Security annotations listed as a parameter [02:53:54] <sbryzak> hmm, wouldn't it be better to have those annotations on the method itself? [02:54:01] <bleathem> The propsed @ViewConfig would look like the pastie above [02:54:09] <sbryzak> i'm looking at the pastie now [02:54:21] <bleathem> that is what I started doing initially [02:54:28] <sbryzak> is the initial and postback really required? [02:54:53] <bleathem> We'll have sensible defaults [02:55:01] <bleathem> so the user doesn't have to include them [02:55:25] <bleathem> but it would be nice to include control as to when the security check gets applied [02:55:26] <sbryzak> i think i'd rather see the annotations at the top level, rather than nested [02:55:30] <sbryzak> it's more natural to code that way [02:55:59] <sbryzak> and the failview should be configurable on a global level [02:56:07] <bleathem> what I was thinking though [02:56:10] [02:56:28] *** jganoff has quit IRC [02:56:33] <jose_f_home> will the user have to create a view config for each page? [02:56:36] <bleathem> was that once we have persistence/transaction tags and rewrite tags, on top of Security tags [02:56:41] <bleathem> that it'll be a bit of tag soup [02:56:41] <sbryzak> the seam-config xml will be messy for that [02:56:50] <bleathem> this seamed like a nice way to group them [02:56:57] <bleathem> but I am by no means married to it:P [02:57:00] <jose_f_home> hm [02:57:04] <sbryzak> the grouping seems unnecessary [02:57:07] <bleathem> ok [02:57:12] <bleathem> feddback received :P [02:57:21] <bleathem> I'll carry on as before! [02:57:37] <sbryzak> in most cases, i imagine something like @ViewPattern("xxx/yyy") @Admin void INDEX(); would be the norm [02:57:38] <bleathem> i should have something solid by the end of my night [02:57:52] <bleathem> Probably [02:58:44] <bleathem> jose_f_home the viewPattern supports wild cards [02:58:54] <sbryzak> failview can be its own annotation also [02:59:03] <bleathem> ok [02:59:12] <sbryzak> maybe call it something else though [02:59:40] <bleathem> yeah, I thought of that in a hurry [02:59:59] <sbryzak> in seam 2 it's called login-view-id [03:00:20] <sbryzak> so maybe a @LoginView annotation would be consistent [03:01:02] <bleathem> I think the Login would be the same throughout and centrally configured [03:01:27] <sbryzak> agreed, but it should be overridable via annotation also [03:01:33] <jose_f_home> bleathem: agreed too [03:01:34] <bleathem> ok [03:01:48] <bleathem> 1 sec [03:02:09] <bleathem> More like: http://pastie.org/1698148 [03:02:11] <sbryzak> think of an application that consists of a set of views for normal users, and a set for admins [03:02:24] <sbryzak> admin users would have a separate login page [03:02:34] <sbryzak> we've actually had users with that exact use case in the past [03:02:42] <bleathem> We could have annoations on the class, adjacent to @ViewConfig [03:02:47] <bleathem> and have multiple classes [03:02:53] <bleathem> to support grouping of things like login pages [03:03:02] <bleathem> sorry, multiple interfaces [03:03:12] <sbryzak> that looks better [03:03:25] <sbryzak> @AuthFailedView is ambiguous [03:03:35] <sbryzak> auth could mean either authentication or authorization [03:03:46] <bleathem> right! [03:03:50] <bleathem> @DeniedView ? [03:04:00] <sbryzak> maybe call it @ErrorView [03:04:10] <sbryzak> and be able to configure a global error page also [03:04:43] *** tsurdilo has quit IRC [03:05:26] <sbryzak> we need to also differentiate between a failed login in terms of invalid credentials, or an error during the authentication process [03:05:27] <bleathem> http://pastie.org/1698159 [03:06:07] <sbryzak> that's looking good [03:06:08] <bleathem> I would prefer letting Catch handle errors, and deal only with access denied here [03:06:16] <bleathem> I like @DeniedView [03:06:23] <bleathem> and leave errors to catch [03:06:42] <sbryzak> ok, let's go with @DeniedView then [03:06:44] <bleathem> @AccessDeniedView [03:07:01] <sbryzak> sounds good [03:07:31] <sbryzak> so that page would just be used when the user is already logged in, and they try to access a view for which they don't have sufficient privileges [03:07:41] <bleathem> right [03:07:53] <bleathem> if they're not logged in, they go to the Login view [03:07:59] <bleathem> and if there is an error Catch decides [03:08:01] <sbryzak> if they're not logged in and try to access that page, they should be redirected to @LoginView [03:08:02] <sbryzak> exactly [03:08:08] <bleathem> last one: http://pastie.org/1698168 [03:08:29] <sbryzak> that looks good [03:08:36] <bleathem> Actually, we could support all annotations at the top level [03:08:47] <bleathem> have @Admin on the interface [03:08:55] <sbryzak> so the only required annotation should be @ViewPattern [03:09:00] <bleathem> would apply to all views in the interface [03:09:14] <sbryzak> can you have multiple interfaces? [03:09:22] <bleathem> I'm pretty sure [03:09:37] <bleathem> stuartdouglas desinged this to be configurable from multiple sources [03:09:47] <bleathem> f:metadata, xml, @Viewconfig [03:09:54] <sbryzak> ok, i guess that would be ok then [03:09:58] <bleathem> I don't see why we can't have multiple @ViewConfig interfaces [03:10:06] <stuartdouglas> sure you can [03:10:25] <bleathem> AdminPages, ItemPages, ProfilePages [03:10:32] <bleathem> kind of cool actually [03:10:48] <sbryzak> yep, i definitely like that idea [03:11:03] <sbryzak> allows for clean separation between application concerns [03:11:51] <bleathem> ok, thanks for the feedback. [03:11:59] <bleathem> I'll let you know when there is something to poke [03:12:16] <sbryzak> great, and i'll help put together an example for it [03:17:41] *** rruss has joined #seam-dev [03:18:15] *** gastaldi has joined #seam-dev [03:23:04] <bleathem> stuartdouglas I guess if I put an anotation at the interfaces, it's equivalent to putting on @ViewPattern("/*") [03:23:20] <stuartdouglas> it could be [03:23:39] <stuartdouglas> but it is not written like that ATM [03:23:41] <bleathem> I could stuff it into the existing data store that way [03:24:00] <bleathem> yeah, I'll make the appropriate modifications [03:32:05] *** kenfinnigan has quit IRC [03:33:07] <bleathem> Where's the javadoc for Seam Security? It's not linked to from the Module page [03:33:56] <bleathem> http://docs.jboss.org/seam/3/security/latest/api/ [03:34:10] <bleathem> faces doesn't have a link for it either (Catch does) [03:34:17] <bleathem> I'll add a link to the Faces page [03:34:55] <bleathem> mojavelinux: idea: All module pages should provide links to their respective javadoc [03:38:09] <bleathem> #git [03:38:36] <bleathem> there are over 700 people in the #git channel! [03:38:39] *** johnament has joined #seam-dev [03:38:49] <bleathem> Hey John [03:39:00] <johnament> hey brian [03:39:24] <bleathem> I was just commenting on the fact that there are over 700 people in the #git channel! [03:39:29] <bleathem> I'm to scared to say anything :P [03:39:51] * johnament joins #mercurial [03:40:10] <gastaldi> hey johnament ! [03:40:14] <johnament> hey gastaldi [03:40:33] <gastaldi> I updated the Seam version in Seam JCR [03:40:49] <gastaldi> @ExtensionManaged is available now [03:40:54] <johnament> bleathem: on that note, i'm waiting 12 calendar days for sys admins to give me local sudo access on a box to get our internal mercurial stuff runing [03:41:07] <johnament> we may as well wait [03:41:17] <bleathem> right on! [03:41:34] <bleathem> finally moving on from SCCS (or whatever it was)! [03:41:45] <johnament> final's coming up really soon. and "seam managed" is slated for beta1, unless you wanted to tackle that part. [03:41:55] <johnament> i have some skeleton stuff done for OCM support. [03:42:10] <johnament> but i want to get the bindings done first [03:42:15] <gastaldi> johnament: @SeamManaged has become @ExtensionManaged [03:42:25] [03:42:33] <johnament> gastaldi: i was referring tot he JCR issue for creating seam managed jcr sessions [03:42:48] <johnament> which now needs to be updated to read "Extension Managed JCR Sessions" [03:42:57] <johnament> all because i lost a vote. [03:43:00] <johnament> booo [03:43:13] <johnament> bleathem: how's that good?? 12 calendar days is ridiculous. [03:43:44] <johnament> they emailed me 2 days after getting the sign offs "hey we never created local accounts on this box yet... what do you need" which ir esponded promptly with "exactly what's in the ticket" [03:45:22] <gastaldi> johnament: Do u recall that suggestion of yours on placing @JcrConfiguration on @Stereotypes in order to separate config from the injection ? [03:45:35] <johnament> yes [03:45:45] <johnament> and there was going to be a repository resolver as well to support it [03:46:15] <johnament> where the repository resolver understood modeshape, exo, jackrabbit, etc. [03:46:19] <gastaldi> yeah [03:46:35] <johnament> is there an issue for that? [03:46:41] [03:46:49] * johnament grumble grumble [03:46:53] <gastaldi> :P [03:47:47] <gastaldi> Should @JcrConfiguration be a qualifier ? [03:47:57] [03:47:58] <johnament> is it right now? [03:48:02] <gastaldi> yes [03:48:21] <johnament> how so? [03:48:29] <johnament> because it only supports one property? [03:48:40] <gastaldi> no, because it does not qualify anything [03:48:49] <johnament> ? [03:48:58] <johnament> its more like a configuration annotation. [03:49:05] <gastaldi> Yes, not a Qualifier [03:49:29] <gastaldi> I mean, look at RepositorySessionProducer [03:49:53] <gastaldi> It merely reads the @JcrConfiguration from reflection [03:50:09] <gastaldi> So I suppose that making it a qualifier is useless [03:50:56] <gastaldi> WDYT ? [03:51:34] <johnament> i think when we introduce resolver behavior, the need for it will go away. [03:51:51] <johnament> essentially, with the resolver the developer defines their own qualifier. whatever they want. [03:52:07] <johnament> they define a single producer w/ the configuration data. [03:52:09] <johnament> we cache it [03:52:21] <johnament> that creates a repository. we cache it. [03:52:33] <gastaldi> so we have a use for JcrExtension finally ! [03:52:36] <johnament> they need a session, we look at the cached repository to get it [03:52:42] <johnament> how so? [03:53:05] <gastaldi> I believe that needs to be done on deploy time , right ? [03:53:07] <johnament> so far the only thing i've thought of to have a true extension is for "Extension Managed" JCR Session [03:53:14] <gastaldi> humm [03:53:20] <johnament> and OCM bindings. [03:53:26] <johnament> those need to be done at deploy type [03:53:27] <johnament> time [03:53:29] <johnament> wow. [03:53:36] <johnament> type is no where near time. [03:53:42] <gastaldi> lol [03:54:03] <johnament> we don't need an extension for this, and actually you probably don't want to use one. [03:54:11] <johnament> you can do it via dynamic bean look up [03:54:53] <johnament> we know the qualifiers on the annotated injection point. e.g. @GeorgeRepo [03:55:00] <gastaldi> yes [03:55:03] <bleathem> johnament let's be honest, you've been waiting for this for year{s}, 12 days is nothing! [03:55:27] <johnament> we lookup a bean that matches @GeorgeRepo Map<String,String> [03:55:42] <johnament> or it might be cached. [03:55:44] <gastaldi> What if none is provided ? [03:55:57] <johnament> exception gets thrown at runtime [03:56:06] <gastaldi> or deploy time ? [03:56:32] <johnament> a long time ago, it was believed that you can work with beans predeployment complete [03:56:46] <johnament> truth be told you can't. [03:56:55] <johnament> bleathem: SCCS FOREVER [03:57:25] <bleathem> sbryzak: the annotations in org.jboss.seam.security.annotations don't have a common qualifier [03:57:42] <johnament> gastaldi: if for any reason they want to work with a bean to provide the map, it won't work. [03:57:57] <gastaldi> johnament: Have you coded anything yet ? [03:58:07] <johnament> that's the only reason i'm hesitatnt to say. [03:58:09] <johnament> which part? [03:58:12] <gastaldi> the Resolver [03:58:14] <johnament> resolver? no [03:58:21] <sbryzak> bleathem: they're not all security bindings [03:58:28] <johnament> i'm just typing the ideas in my head [03:58:29] <bleathem> sbryzak: such as SecurityBindingType that user provided anotations have [03:59:02] <gastaldi> So are we still going to allow @JcrConfiguration on injected Repositories ? [03:59:33] <bleathem> sbryzak: thow would you recommend I scan for them? By name? By package? [03:59:42] <bleathem> sbryzak: could we add a qualifier to them? [03:59:53] <sbryzak> you don't need to scan for them [03:59:57] <bleathem> sbryzak: to the ones that are security bindings [04:00:00] <sbryzak> only annotations with @SecurityBindingType [04:00:25] <johnament> gastaldi: I don't see why not. [04:00:57] <johnament> gastaldi: in some ways, it makes sense to keep that as core API for JCR to be able to resolve [04:01:23] <bleathem> I'm missing a piece of this puzzle. [04:01:33] <bleathem> But I think it'll come out in the wash shortly [04:01:34] <johnament> gastaldi: the current code could probably end up a little refactored [04:01:45] <sbryzak> bleathem: ignore all the other annotations, they're not relevant to view security [04:01:48] <johnament> soggy puzzle pieces never fit right [04:01:56] <sbryzak> you only need to scan for annotations that are annotated @SecurityBindingType [04:02:10] <bleathem> ok, will do [04:03:23] <johnament> sbryzak: do you have a way to give me credentials? [04:03:37] <sbryzak> johnament: sure, just inject the Credentials bean [04:04:50] <johnament> sbryzak: so that's user driven credentials. [04:05:56] <sbryzak> yeah, i guess [04:06:10] <sbryzak> i'm not sure how credentials fit in with jcr, so you'll have to educate me :) [04:06:26] <gastaldi> sbryzak: There is a Credentials object [04:06:30] [04:06:37] <sbryzak> in the jcr spec? [04:06:39] <gastaldi> You use it to create Session [04:06:41] <gastaldi> yes [04:06:41] <johnament> it has no methods [04:06:48] <gastaldi> its a marker interface [04:06:52] <sbryzak> got a url to the api docs or something? [04:07:03] <gastaldi> sure, let me google it [04:07:29] <gastaldi> http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/Credentials.html [04:07:32] <gastaldi> :) [04:07:33] <johnament> http://www.day.com/specs/jcr/2.0/4_Connecting.html#4.2 Login [04:07:39] <johnament> doh [04:07:42] <sbryzak> thanks, taking a look now [04:07:44] <johnament> have to copy and paste that one [04:08:34] [04:08:43] <gastaldi> JCR Implementation [04:08:45] <gastaldi> specific [04:08:51] <johnament> sort of [04:08:57] <sbryzak> hmm [04:08:58] <johnament> there's 2 defined impls in the spec [04:09:03] <johnament> guest and simple [04:09:09] <sbryzak> just reading section 4.2.4 on that second page [04:09:25] <johnament> Is it full of adobe ads yet? [04:09:34] <sbryzak> we could probably use that to delegate authentication to seam security [04:09:46] <sbryzak> that way, the user logs into the app as usual [04:10:16] <sbryzak> then when they do something that accesses the jcr repository, it authenticates using the user's existing identity [04:10:44] <johnament> i think jcr also supports impersonate. [04:10:48] <johnament> hold on [04:11:31] <johnament> http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/Session.html#impersonate(javax.jcr.Credentials) [04:12:32] <johnament> sbryzak: the idea sounds feasible. [04:13:06] *** lincolnthree1 has quit IRC [04:13:09] <sbryzak> do we have a jcr example yet where we can test out stuff like this? [04:13:12] <johnament> the only thing i hate is related to whether credentials like this are user specific or more like database credentials [04:13:35] <johnament> martin started poking into one [04:13:45] <gastaldi> http://www.day.com/maven/jsr170/javadocs/jcr-2.0/index.html [04:14:58] <sbryzak> i think i need to read the jcr spec [04:15:03] <sbryzak> but i won't have time this week [04:15:13] <johnament> security's later on for us anyways [04:15:24] <johnament> this is probably the most relevant part though http://www.day.com/maven/jsr170/javadocs/jcr-2.0/javax/jcr/security/package-summary.html [04:15:29] <sbryzak> ah, it uses ACL's [04:15:39] <johnament> yep [04:15:40] <sbryzak> yep looking at that package now [04:15:45] <sbryzak> that should be a piece of cake [04:16:04] <johnament> really_long_path_to_some_deep_node_readwrite [04:16:42] <sbryzak> ok so i'm guessing we have to provide our own implementation for AccessControlManager [04:16:53] <sbryzak> will both jcr implementations allow us to do that? [04:16:56] <johnament> probably delegate [04:17:22] <johnament> we're already proxying the returned session. [04:17:36] [04:17:56] <johnament> gastaldi: for ExtensionManaged we need to proxy session as well. [04:18:01] <gastaldi> yup [04:18:05] <sbryzak> if you proxied the session you could control what Session.getAccessControlManager() provides [04:18:15] <johnament> yep [04:18:55] <sbryzak> ok, remind me to take a look at this next week after the final release is out [04:19:12] <gastaldi> johnament: I am replacing RepositorySessionProducer by RepositorySessionResolver, WDYT ? [04:20:11] <johnament> does it do the same thing? [04:20:13] <johnament> sbryzak: ok [04:20:22] *** clerum has quit IRC [04:20:35] <gastaldi> yes [04:20:38] <gastaldi> until now [04:20:39] <gastaldi> :) [04:21:41] *** jose_f_home has quit IRC [04:21:53] <johnament> gastaldi: so it produces and resolves? [04:21:59] <gastaldi> yep [04:22:05] <johnament> resolves is basically producing, but based around a dynamic lookup. [04:22:15] <johnament> the resolver should be app scoped i think, to handle the caching. [04:22:38] <johnament> or you maintain a separate bean that has jut the cache, and a dependent or similar scoped bean to handle the lookup and cache entry [04:22:42] <johnament> hmmm [04:22:45] * johnament shrugs [04:22:59] <gastaldi> :P [04:24:06] <johnament> just needs to be thread safe. [04:25:34] <bleathem> I'm trying to build an annotation, that takes as a value a list of annotations, and set the default list of annotations: [04:25:36] <bleathem> http://pastie.org/1698337 [04:25:42] <bleathem> The above is incorrect [04:26:00] <bleathem> Do I have to use literals to set the default values of the annotations? [04:26:06] <bleathem> will that work? [04:26:13] <gastaldi> no [04:26:34] <gastaldi> You must specify Class[] then [04:27:33] <bleathem> cool, that worked - thanks! [04:27:38] <bleathem> public Class[] value() default {Before.class, RenderScoped.class }; [04:27:59] <bleathem> well, it's syntactically correct. We'll see if it works! [04:28:21] <johnament> bleathem: but what if i want it to be RoutingType(EGRESS) as the default ? [04:28:39] <bleathem> huh? [04:29:02] <johnament> i dunno. [04:29:06] <johnament> its too late. i need sleep [04:29:10] <bleathem> lol [04:29:10] <johnament> i think i got 2 hours last night [04:29:27] <bleathem> that's not enough! [04:29:34] <bleathem> and I thought I was running on empty [04:29:39] <johnament> 2 might be rounding up [04:29:41] <johnament> well [04:29:58] <johnament> yeah i'm not getting into it. [04:30:00] <johnament> night [04:30:08] *** johnament has quit IRC [04:42:11] <mojavelinux> hey bleathem overall the view configuration is looking good [04:42:22] <bleathem> cool [04:42:34] <mojavelinux> i'm not quite feeling the phase configuration yet [04:42:51] <mojavelinux> right now, it's a bit to ambiguous to what it applies to [04:42:53] <bleathem> yeah, me neither [04:43:07] <mojavelinux> I think it needs to be something like [04:43:18] <bleathem> you're looking at: http://pastie.org/1698168 [04:43:20] <bleathem> ? [04:43:25] <mojavelinux> @EnforceConstraints [04:43:30] <mojavelinux> and then perhaps attributes to set the phases [04:43:32] <mojavelinux> like [04:43:57] <mojavelinux> @EnforceConstraints(initial = RestoreView.class, postback = InvokeApplication.class) [04:44:27] <bleathem> yeah, I like that [04:44:28] <mojavelinux> without that annotation, they are enforced during the default time [04:44:46] <mojavelinux> constraints might be too generic still, like is it security or validation [04:44:55] <mojavelinux> what does seam security call it? [04:45:40] <bleathem> i don't know [04:45:44] * bleathem looking at the api [04:46:19] <mojavelinux> wow, too much backlog in my window [04:46:23] <mojavelinux> I scroll and it goes back a day [04:46:25] <mojavelinux> hehehe [04:46:33] <mojavelinux> I think it's like @Restrict [04:46:35] <mojavelinux> so we can say [04:46:40] <bleathem> yeah, that's it [04:46:57] <mojavelinux> @EnforceRestrictions [04:47:01] <mojavelinux> or @EnforceSecurity [04:47:04] <mojavelinux> @ApplyRestrictions [04:47:35] <mojavelinux> @RestrictPhase(initial = RestoreView.class, postback = InvokeApplication.class) [04:47:36] <bleathem> @RestrictionPhases [04:47:51] <bleathem> nice, almost simultaneous [04:48:01] <bleathem> @RestrictPhase [04:48:04] <bleathem> I like [04:48:21] <mojavelinux> unfortuntately, one thing that royally sucks about annotations [04:48:29] <mojavelinux> is that you can't have an attribute of a custom type [04:48:31] <mojavelinux> sux [04:48:37] <mojavelinux> so you have to just say Class [04:48:39] <mojavelinux> boo [04:48:41] <bleathem> really [04:48:47] <mojavelinux> we could just use enums here [04:48:57] <mojavelinux> actually, we could allow the faces enums, why not? [04:49:15] <bleathem> I was trying to figure out how @JoinTable gets nested @JoinColumn annotations in it [04:49:45] <bleathem> JoinColumn[] joinColumns() default {}; [04:49:46] <mojavelinux> oh, yes [04:49:50] <mojavelinux> you can have an annotation as a type [04:49:52] <mojavelinux> yep [04:50:08] <bleathem> but not an arbitray annotation [04:50:13] <mojavelinux> but annotations can't inherit, so it's not all that much use [04:50:14] <mojavelinux> nope [04:50:16] <bleathem> I tried Annotation[] value... [04:50:26] <bleathem> 1 sec [04:50:29] <mojavelinux> believe me, I've walked that same road [04:51:07] <mojavelinux> bastards. PhaseId is not an enum [04:51:51] <bleathem> Well, we'll make it Class, we have to check for invalid phases anyways [04:52:09] <bleathem> we'll just do a positive check, rather than a negative one [04:52:31] <bleathem> storytime, back in a bit. [04:52:43] <bleathem> feel free to leave me any further feedback to read on my return [04:52:48] *** gastaldi has quit IRC [05:03:56] <bleathem> ok, back [05:05:55] <mojavelinux> yeah, so squeezing the security enforcement phase configuration to a single annotation is def a step in the right direction [05:07:05] <bleathem> looking like this so far: http://pastie.org/1698433 [05:07:28] <bleathem> should we create enums for the phases? [05:07:39] <bleathem> so we don't have to use classes? [05:08:07] <bleathem> would better support autocompletion in IDEs [05:09:54] <mojavelinux> yes [05:09:58] <mojavelinux> I would even say [05:10:07] <mojavelinux> that perhaps we should have enums for before and after phases [05:10:21] <mojavelinux> hmmm, wdyt? [05:10:22] <bleathem> I'd like that [05:10:27] <mojavelinux> or should we just leave the before/after as implied? [05:10:42] <bleathem> I don't like the way the before/after is currently implicit [05:11:21] <mojavelinux> hmm, so in pretty faces, just as an example [05:11:23] <bleathem> Create the num in org.jboss.seam.faces.event [05:11:27] <bleathem> ? [05:11:30] <mojavelinux> lincoln just as the control at the phase level [05:11:36] <mojavelinux> so it's like phaseId="RESTORE_VIEW" [05:12:01] <bleathem> we could do that, to be consistent [05:12:22] <bleathem> with the future support of URL rewriting, using this same configuration mechanism [05:12:39] <mojavelinux> i think otherwise we get too fine grained, into the details [05:13:24] <bleathem> After Render view would be meaningless, before Restore view is impossible, and after invoke application is before render [05:13:31] <bleathem> so theire isn't really any ambiguity [05:13:46] <bleathem> the fine art of rationalization :P [05:14:06] <mojavelinux> @RestrictPhase(onInitialRequest = RESTORE_VIEW, onPostback = INVOKE_APPLICATION) [05:14:18] <bleathem> nice [05:16:24] * bleathem looking for the pretty faces source [05:16:41] * bleathem found it [05:16:52] <mojavelinux> hmm, @RestrictDuringPhase(initialRequest = RESTORE_VIEW, postback = INVOKE_APPLICATION) [05:17:02] <mojavelinux> that might be the best way, like during or before or on [05:17:19] <mojavelinux> during sort of fits nicely [05:17:20] <bleathem> but it's not during [05:17:21] <mojavelinux> reads nicely [05:17:30] <bleathem> it's either before or after [05:17:36] <mojavelinux> well, it's effectively during...sure, but it's still that phase [05:17:56] <mojavelinux> even when you are before restore view, you are still at the restore view phase [05:18:04] <bleathem> ok [05:18:06] <mojavelinux> you just then have relative ordering of things that happen throughout that phase [05:18:16] <bleathem> but it seems a little verbose... [05:18:31] <mojavelinux> so if I say "restrict during invoke application", then you are likely going to assume that I mean before any actions are invoked [05:18:37] <mojavelinux> otherwise, it wouldn't make much sense [05:18:40] <bleathem> right [05:18:48] <mojavelinux> though, we can say "on" or "before" [05:18:57] <mojavelinux> ah! [05:18:59] <mojavelinux> I got it [05:19:03] <mojavelinux> @RestrictAtPhase [05:19:06] <bleathem> yes! [05:19:07] <mojavelinux> yeah? [05:19:20] <mojavelinux> yep, it says "hold the lifecycle, and do your restrictions when I get here" [05:19:40] <mojavelinux> if you like "on" better, I'm open to either way [05:20:16] <bleathem> no, I like "at", we have the "on" in the attributes [05:20:28] <mojavelinux> excellent [05:20:30] <bleathem> "at" is when we arrive at the phase [05:20:34] <mojavelinux> so let's go with that, plus the enum [05:20:43] <mojavelinux> I can't believe that JSF 2 doesn't have enum for phase id [05:20:48] <mojavelinux> I mean, at least just throw it in there [05:20:53] <mojavelinux> oh well, I guess we do it :) [05:21:09] <bleathem> we need something to keep us busy! [05:21:43] <bleathem> What's the enum class name in PrettyFaces? [05:23:18] <bleathem> Funny, PhaseId in JSF is a class, with an "ordinal" property [05:23:25] <bleathem> it's *trying* to be an enum [05:23:25] <mojavelinux> yeah, jsf 1.1 [05:23:28] <mojavelinux> hahaha [05:23:45] <mojavelinux> I think we should have PhaseIdType [05:25:31] <bleathem> in org.jboss.seam.faces.event right? [05:27:48] *** gastaldi has joined #seam-dev [05:33:38] <bleathem> next iteration: http://pastie.org/1698494 [05:34:25] <mojavelinux> let's go back to "initial" and "postback" [05:34:58] <mojavelinux> or "initialRequest" and "facesRequest" hmmm, jsf has an identity crisis [05:35:01] <mojavelinux> sometimes I think [05:35:19] <bleathem> I think simpler is better - it's clear with the context [05:35:38] <mojavelinux> initial and postback seem to be the most common terms [05:35:57] <bleathem> next iteration: http://pastie.org/1698499 [05:37:49] <bleathem> the part I'm missing in all of this, is how the SecurityBindingTypes are going to get applied [05:37:54] <gastaldi> ow ! Annotations will rule the world !! :D [05:38:22] <bleathem> sbryzak and I talked about firing an event, that Security would listen for, but then how does my phase listener get the result? [05:38:55] <sbryzak> bleathem: the result will be in the event object [05:39:06] <bleathem> oic [05:39:24] <bleathem> that makes sense [05:39:45] <bleathem> man you Seam people are smart! [05:40:07] <gastaldi> I Agree ! [05:41:10] <gastaldi> You know, so many annotations make me think that maybe Java is getting complicated [05:41:46] <mojavelinux> George, in a sense, yes, annotations can be abused, but what we are doing here is creating a DSL in effect [05:42:16] <mojavelinux> but one that we can then reference in Java code, via enums [05:42:23] <mojavelinux> so we are feeling it out [05:42:40] <gastaldi> good [05:42:47] <mojavelinux> of course, we could also provide a separate DSL that could look even cleaner...the important part to focus on here is what metadata are we building up [05:42:49] <bleathem> by the time JPA entities get there JAP anotations, Bean validation annotations, JAXB annotations [05:42:54] <bleathem> they are really anotaioned out [05:43:04] <gastaldi> Maybe some convention over configuration would be nice ? [05:43:05] <bleathem> gastaldi I know what you mean [05:43:25] <bleathem> in out case, we definitely are assuming sensible defaults [05:43:28] <bleathem> for the @ViewConfig [05:43:33] <mojavelinux> yeah, naturally, we will have defaults [05:43:37] <bleathem> most common use case will look like: [05:43:40] <mojavelinux> we are just looking at the annotations for when they are needed [05:43:49] <gastaldi> nop [05:43:52] <bleathem> @ViewPattern("/admin/*") @Admin [05:43:54] <bleathem> and that's it [05:43:59] <gastaldi> great [05:44:55] <gastaldi> But even with thousands of annotations, they are better than XML [05:45:00] <gastaldi> :p [05:45:06] <mojavelinux> you know it [05:45:14] <bleathem> stpe out of the fire and into the coals maybe :P [05:45:21] <gastaldi> haha [05:45:23] <gastaldi> Nice [05:45:32] <mojavelinux> btw, we definitely want that smooth login required -> original request cycle [05:45:55] <mojavelinux> and another btw, while putting this together, think about the API for anything you are setting [05:45:56] <bleathem> right [05:46:10] <mojavelinux> in other words, assume that the annotation-based configuration will one day be just one option for config [05:46:13] <gastaldi> a Builder ? [05:46:29] <bleathem> yeah, I'm building on what stuartdouglas did in that respect [05:46:30] <mojavelinux> yep, you could imagine like a dynamic configuration in a application initializer [05:46:35] <mojavelinux> or perhaps a Java-config [05:46:38] <mojavelinux> awesome [05:46:55] <bleathem> Multiple @ViewConfig interfaces seems compelling [05:47:00] <mojavelinux> even database-oriented configuration...but you are just worrying about the api [05:47:03] <bleathem> f:metaData configuration [05:47:06] <mojavelinux> yep [05:47:11] <gastaldi> hey, I got a question on Seam Persistence [05:47:42] <gastaldi> sorry interrupting the chat [05:48:04] <gastaldi> Does Seam Persistence supports Dynamic Finders ? [05:48:29] <gastaldi> Like the one described in Solder ServiceHandler ? [05:48:57] <mojavelinux> not yet, that code I believe is in theory [05:49:02] <mojavelinux> though we talked about doing it [05:49:05] <gastaldi> But works :) [05:49:08] <mojavelinux> unless I totally missed when it was added [05:49:27] <gastaldi> No, it really works. I am using something like that [05:49:47] <mojavelinux> right, but I mean that it would have to be coded [05:49:48] <gastaldi> But instead of making the method abstract, I made it native [05:50:03] <gastaldi> So that I could just use an interceptor on that [05:50:09] <gastaldi> But the abstract makes more sense [05:50:31] <mojavelinux> yeah, the difference is that the service handler saves you from having to even make something that is interceptable [05:50:34] <mojavelinux> in a sense [05:50:51] <mojavelinux> service handler, interceptors and decorators are all complementary [05:50:58] <mojavelinux> and cdi is missing the first...which we now realize [05:51:11] <gastaldi> Check http://pastie.org/1698519 [05:51:53] <gastaldi> This way my DAOs may be abstract and use QBE parameters [05:52:31] <gastaldi> It would be great if Seam Persistence could provide something like that [05:53:57] <gastaldi> Service Handler could be part of CDI 1.1 :) [05:54:11] <mojavelinux> it's planned I believe [05:54:47] <gastaldi> http://relation.to/Bloggers/CDI11 [05:54:58] <mojavelinux> I think the QBE should be in the application framework, which I believe we agreed to rename to the entity framework [05:55:02] <gastaldi> Someone must talk to pete about that [05:55:20] <gastaldi> humm yeah, that makes sense [05:55:49] <mojavelinux> strange, I thought that was a CDI 1.1 issue [05:55:49] <mojavelinux> hmm [05:56:47] [05:57:08] <gastaldi> just for the record [05:58:42] <mojavelinux> thanks [06:03:06] <gastaldi> CDI-110 [06:03:10] <jbossbot> jira [CDI-110] Allow proxying of abstract classes (Service Handler) [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/CDI-110 [06:03:47] <gastaldi> mojavelinux: I appreciate if you could comment it [06:05:16] <mojavelinux> you should emphasize that it should use the same binding strategy as is used by interceptors [06:05:33] <mojavelinux> so you would have @ServiceHandler on the invocation handler [06:05:43] <mojavelinux> @ServiceHandler on the @ServiceHandlerBindingType [06:05:50] <mojavelinux> and then whatever that annotation is, you annotate the interface [06:05:59] <mojavelinux> also, another key thing that the current service handler is missing [06:06:15] <mojavelinux> is that it should be possible to have an abstract class with regular methods that are not intercepted [06:06:24] <mojavelinux> only methods which have no implementation get handled [06:06:36] <gastaldi> Just like a decorator [06:06:38] <bleathem> mojavelinux: since you were asking, the @Setup method in this class demonstrates configuring the ViewConfigStore programatically: [06:06:40] <bleathem> https://github.com/bleathem/faces/blob/SEAMFACES-33_Security/impl/src/test/java/org/jboss/seam/faces/test/view/config/ViewConfigStoreTest.java [06:06:40] <gastaldi> Or kinda [06:06:41] <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 [06:06:48] <mojavelinux> sweet [06:08:14] <gastaldi> I copied/pasted your comments on the issue [06:08:17] <gastaldi> very good [06:09:14] <bleathem> sbryzak, given a SecurityBindingType, how can I find the method that @Secures it? Is there an API call that does that? [06:09:16] <bleathem> (I'm writing an event listener for testing purposes) [06:09:34] <sbryzak> yes... [06:09:53] <sbryzak> SecurityExtension.lookupAuthorizerStack() [06:10:09] <bleathem> thx [06:10:16] [06:10:23] <gastaldi> bye all ! Thanks ! [06:10:36] <sbryzak> bleathem: actually for that you need to pass in the method [06:10:43] <sbryzak> it will scan it for security binding types [06:10:49] *** gastaldi has quit IRC [06:10:59] <bleathem> right, it does that at deploy time I noticed [06:11:42] <bleathem> What I want to do, is retrieve my list of SecurityBindingTypes from the event, then retrieve the event that secures each of those annotations [06:12:08] <bleathem> is that possible? [06:13:31] <sbryzak> hmm, there's not really a method that will give you that [06:14:16] <sbryzak> i'll need to write it [06:14:35] <bleathem> is there another approach I should take to evaluate the SecurityBindingType authorizations? [06:14:48] <bleathem> ok [06:15:02] <bleathem> I'll skip it for now [06:15:25] <sbryzak> for testing purposes, i'd just mock it [06:15:46] <bleathem> yeah, my observer will set the authorization to true/false on the event [06:15:52] <bleathem> and be done with it for now [06:16:17] <bleathem> my event has a property in it: private final List<? extends Annotation> securityBindingTypes; [06:16:30] <bleathem> is the use of generics at this level bad? [06:16:38] <bleathem> ie. an infriendly API? [06:17:21] <sbryzak> well, it will be an SPI class because app developers won't be using it [06:17:45] <sbryzak> so that gives you a bit of leeway in terms of friendliness ;) [06:17:50] <bleathem> right, app developers won't be writing the event listener [06:17:56] <bleathem> just the @Secures methods [06:18:00] <sbryzak> right [06:18:02] <bleathem> ok, then I'm cool with it [06:37:39] <bleathem> I've got the SecurityBindingType annotations figured out, in terms of scanning for them, throwing an event, and getting the authorization reply [06:37:52] *** lightguard_jp has joined #seam-dev [06:38:12] <bleathem> Now I just need to figure out the other annotations, and we're set. [06:38:17] *** lightguard_jp has quit IRC [06:38:32] *** lightguard_jp has joined #seam-dev [06:39:47] <bleathem> hey jason [06:40:47] <bleathem> lightguard_jp any comments about the proposed @ViewConfig: http://pastie.org/1698499 [06:41:55] <lightguard_jp> All of our IRC bots are written in Java? Wow [06:42:28] <bleathem> how'd you figure that out? [06:42:28] <lightguard_jp> Went with an interface instead of enum? [06:43:02] <bleathem> yeah, weld wasn't scanning the enum [06:43:09] <lightguard_jp> Too bad [06:43:15] <lightguard_jp> I have the source for the bots [06:43:17] <lightguard_jp> Now [06:43:17] <bleathem> we get a few more characters of boilerplate [06:43:27] <bleathem> but it's not too bad [06:43:34] <lightguard_jp> Tie Catch into it so you can do a per view catch handler :) [06:43:51] <lightguard_jp> You can use stereotypes? [06:44:17] <bleathem> yeah, we could, but a lot of what's there is optional [06:44:24] <bleathem> we'll assume sensible defaults [06:44:29] <lightguard_jp> Fair enough [06:44:30] <bleathem> typical entry will look like: [06:44:41] <lightguard_jp> Each method will be a page? [06:44:52] <bleathem> @ViewPattern("/admin/*") @Admin void index(); [06:45:02] <bleathem> wildcards aupported [06:45:17] <bleathem> wildcards supported [06:47:16] <lightguard_jp> Fair enough [06:59:34] <mojavelinux> yeah, I doubt it looks for the enum since it's not technically a class [06:59:42] <mojavelinux> you could put the enum on a type [06:59:56] <mojavelinux> if you were really adamant about the enum [07:00:08] <bleathem> I'm not too worried about it [07:00:08] <mojavelinux> I will say that there was a reason for the enum choice, if you can/want to make it work [07:00:19] <bleathem> aside from cleanliness? [07:00:21] <lightguard_jp> It is a class, but they're final and no public no args constructor [07:00:22] <mojavelinux> it's so that you can do navigation via types [07:00:31] <mojavelinux> sort of like wicket [07:00:41] <bleathem> that'd be cool [07:00:44] <mojavelinux> return ViewConfig.SEARCH; [07:00:55] <bleathem> it's really easy to toggle between the interface and enum implementation [07:00:59] <bleathem> just a few lines [07:01:00] <mojavelinux> ahhhhhh [07:01:06] <mojavelinux> but what you could do that would be even more flexible [07:01:20] <mojavelinux> is to have the interface return a View (or Page) instead of void [07:01:31] <mojavelinux> then you can auto-implement the interface [07:01:35] <mojavelinux> and then you can do like [07:01:40] <mojavelinux> return viewConfig.search(); [07:01:48] <bleathem> nice! [07:02:01] <bleathem> how do you auto-implement it? [07:02:11] <mojavelinux> hehehe, check out the service handler in solder [07:02:17] <mojavelinux> you can use javassist [07:02:19] <bleathem> solder, of course! [07:02:34] <bleathem> maybe we'll do that post-final [07:02:36] <mojavelinux> i think solder has infrastructure for this...if not, it can be added [07:02:41] <mojavelinux> yep, we can look into that [07:02:54] <bleathem> do you have a minute to jira it? [07:03:24] <sbryzak> mojavelinux: i think another glassfish issue has come to bite us [07:03:30] <mojavelinux> uh oh [07:03:41] <sbryzak> https://issues.jboss.org/browse/SEAMSECURITY-42 [07:03:43] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42 [07:03:53] <sbryzak> could you take a look at that issue [07:04:08] <sbryzak> i think the problem is that the security api can't see any custom authenticators [07:04:24] <mojavelinux> oh crapola, I can't believe this bug is going to hit us [07:04:32] <mojavelinux> grrr, it's the one bug that isn't even resolved in 1.1 [07:04:42] <mojavelinux> there is a solution though, just not pretty [07:04:45] <sbryzak> we really need a workaround [07:04:48] <mojavelinux> you have to provide a producer method [07:04:53] <mojavelinux> and veto the type [07:04:54] <sbryzak> i can't [07:05:02] <mojavelinux> no, I mean the application developer has to [07:05:12] <sbryzak> IdentityImpl uses an Instance to iterate through the available authenticators [07:05:30] <mojavelinux> oh, there is another way :) [07:05:34] <mojavelinux> I have tricks up my sleeve [07:05:51] <sbryzak> https://github.com/seam/security/blob/master/impl/src/main/java/org/jboss/seam/security/IdentityImpl.java [07:05:58] <sbryzak> cool, i hope there's one for this :) [07:06:13] <sbryzak> take a look at that class, line 420 [07:06:25] <mojavelinux> see ELResolverProducer in solder [07:06:33] <mojavelinux> it's really, really horribly ugly, but it works [07:06:37] <sbryzak> actually it's line 447 [07:06:43] <mojavelinux> you basically have to reach back and get the BeanManager from JNDI [07:06:55] <mojavelinux> then you are in the web module's BeanManager [07:06:58] <mojavelinux> and it can see the class [07:07:03] <sbryzak> ok, i'm looking... [07:07:07] <mojavelinux> it's so fugly, but it works, i'm pretty sure [07:07:17] <bleathem> JNDI, nice... [07:07:22] <mojavelinux> it's the exactly same issue I think [07:07:27] <sbryzak> beanManager = new BeanManagerLocator().getBeanManager(); ? [07:07:32] <mojavelinux> yep [07:07:41] <mojavelinux> that gets the BeanManager of the application [07:07:49] <mojavelinux> then look at getReferences() [07:07:56] <mojavelinux> that's like a replacement for Instance [07:08:07] <sbryzak> faark... ok [07:08:17] <mojavelinux> such pretty code :P [07:08:22] <sbryzak> man why does GF suck so hard [07:08:35] <mojavelinux> it's really killing us...the thing is [07:08:39] <mojavelinux> this issue is not resolved in weld snapshot [07:08:50] <mojavelinux> and I think we need to find ales and figure out why [07:08:55] <sbryzak> we need to get onto ales' case about it [07:08:57] <mojavelinux> maybe stuart knows [07:09:03] <mojavelinux> yeah, all the other issues are resolved [07:09:12] <mojavelinux> if you just grab a weld-osgi-bundle from the jboss snapshots repo [07:09:25] <mojavelinux> and override glassfish/modules/weld-osgi-bundle.jar [07:09:29] <stuartdouglas> which issue? [07:09:33] <mojavelinux> at least that gives you a picture of where we are [07:09:43] <mojavelinux> bean archive visibility of application class [07:09:57] <mojavelinux> we hit this in ELResolverProduer and now in the security code looking for Authenticator [07:09:59] <stuartdouglas> web-inf/lib can't see web-inf/classes ? [07:10:02] <mojavelinux> yep [07:10:09] <stuartdouglas> thats a GF integration code problem [07:10:16] <mojavelinux> can web-inf/lib see a producer in web-inf/classes? [07:10:20] <sbryzak> i just know that this is going to bite us in other areas [07:10:22] <stuartdouglas> I pointed it out to them ages ago but it did not get fixed [07:10:26] <sbryzak> areas we haven't even thought of yet [07:10:31] <mojavelinux> we do have a test for this, btw [07:10:34] <mojavelinux> a compat test [07:10:40] <mojavelinux> so we can throw that at them [07:10:49] <mojavelinux> of course, they can't run the test right now [07:11:01] <mojavelinux> because that requires an interim snapshot of arquillian [07:11:04] <mojavelinux> until we move to alpha5 [07:11:20] <mojavelinux> but I could fork solder and update it if they really need it [07:11:23] <mojavelinux> ahead of time [07:11:45] <mojavelinux> the test is linked to in my blog entry [07:12:26] <mojavelinux> btw, we got a lot of nice bonus points for that blog entry :) glad I slaved over it [07:12:36] <mojavelinux> at least it was time well spent [07:13:21] <bleathem> that blog entry is indeed awesome! [07:13:43] <bleathem> Is it ok to put static constants in an annotation class? [07:13:48] <bleathem> or is that bad API? [07:13:54] <bleathem> public static PhaseIdType RESTRICT_INITIAL_DEFAULT = PhaseIdType.RENDER_RESPONSE; [07:13:58] <sbryzak> we definitely needed it, now we have a single place to point everyone to for GF issues [07:14:33] <bleathem> I want to put it in the RestrictAtPhase class [07:15:08] <bleathem> I'll go with Shane's (it's SPI) earlier answer. [07:16:20] <bleathem> meh, it doesn't let me set the default value of the annotation attribute using a static value. [07:16:20] *** oskutka has joined #seam-dev [07:16:23] <mojavelinux> I updated the entry to identify what is fixed and what isn't [07:16:23] <bleathem> bummer [07:16:34] <mojavelinux> weld pom.xml is messed up, it claimes it's 1.1.0-SNAPSHOT [07:16:42] <mojavelinux> but since 1.1.0.Final is released, that's invalid [07:16:42] <bleathem> I noticed that [07:16:47] <mojavelinux> it should be 1.1.1-SNAPSHOT [07:16:53] <bleathem> I thought they migh be using the CDI version [07:17:01] <mojavelinux> or 1.2.0-SNAPSHOT [07:17:09] <mojavelinux> nope, because it's cdi 1.0 [07:17:33] <mojavelinux> Library-to-application visibililty [07:17:33] <mojavelinux> Affects: GlassFish 3.1 (unresolved) [07:17:33] <mojavelinux> Issue report: GLASSFISH-15721 [07:17:33] <mojavelinux> Test case: VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest [07:17:34] <jbossbot> git [security] push master aa46715.. Shane Bryzak SEAMSECURITY-42 [07:17:35] <jbossbot> jira [GLASSFISH-15721] "injection points in one bean deployment archive cannot be satisfied by a bean in a separate bean archive, even when they are from libraries in the same module (web archive)" [Open (Unresolved) Bug, Critical, Sivakumar Thyagarajan] http://java.net/jira/browse/GLASSFISH-15721 [07:17:35] <mojavelinux> voila [07:17:36] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42 [07:17:36] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/a8beaba...aa46715 [07:17:38] <stuartdouglas> Here is the original issue: http://java.net/jira/browse/GLASSFISH-15721 [07:17:43] <sbryzak> ok i've implemented the workaround [07:17:53] <mojavelinux> yep, it's linked [07:17:57] <mojavelinux> the issue report that is [07:18:13] <sbryzak> i'll ask Aaron to test it [07:18:33] <mojavelinux> seriously, what is with that mug on java.net [07:18:41] <mojavelinux> i think they stole that from images.google.com [07:18:45] <mojavelinux> let's see if it's the first result [07:18:59] <bleathem> ok, it's late. I gotta get some sleep [07:19:09] <bleathem> thanks for all the feedback! [07:19:16] <mojavelinux> "bean spill mug" [07:19:20] <mojavelinux> nope, those are much prettier [07:19:25] <mojavelinux> so they didn't even steal a good one [07:19:50] <mojavelinux> I hate to "spill the beans", but java.net is one huge epic #fail [07:20:47] <mojavelinux> added test case to report [07:26:16] <Royle> guys, slightly off topic ... what's the best place to go if I want to describe a design problem and see if there are any JBoss/RedHat products designed to address that issue? [07:29:09] *** bleathem has quit IRC [07:30:09] <Royle> wait i think i just found it on the jboss.com homepage lol [07:31:16] *** jharting has joined #seam-dev [07:45:02] <mojavelinux> drat, no red hat or jboss acceptance for google summer of code? [07:45:08] <mojavelinux> wtf, jboss should do a goc [07:45:11] <mojavelinux> jsoc [07:45:19] <mojavelinux> we would actually get more done ;) [07:45:27] <mojavelinux> motion to start jsoc [07:45:33] <mojavelinux> I saw we announce at judcon [07:45:42] <lightguard_jp> +1 [07:48:02] <mojavelinux> e-mailed [07:48:04] <mojavelinux> time for bed [07:48:27] <sbryzak> seam 3 is already a jwoc [07:48:28] <mojavelinux> tomorrow, we will announce our plan to invade the colleges of the world :) [07:49:37] <mojavelinux> cool! [07:49:48] <mojavelinux> well, we'll take every angle we can :) [07:49:53] <mojavelinux> okay, time for rest [07:50:12] <sbryzak> g'night [08:30:40] *** lightguard_jp has quit IRC [08:31:38] *** kuuyee has joined #seam-dev [08:34:45] *** Royle has quit IRC [08:37:09] *** aslak has joined #seam-dev [08:54:26] * nickarls is banging his head against SEAMINTL-33 . how. can. it. be? [08:54:38] <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 [09:06:01] *** marekn has joined #seam-dev [09:13:57] *** shervin_a has joined #seam-dev [09:17:32] <oskutka> sbryzak: ping [09:17:47] <sbryzak> oskutka: pong [09:17:53] <oskutka> sbryzak: Hi Shane! [09:18:10] <oskutka> sbryzak: A just wanted to file an issue for https://github.com/seam/security/blob/3.0.0.CR3/impl/src/main/resources/META-INF/beans.xml [09:18:12] <sbryzak> good morning :) [09:18:28] <oskutka> sbryzak: There is org.jboss.seam.persistence.transaction. still used [09:18:41] <oskutka> sbryzak: Good evening! [09:18:41] <sbryzak> oh damn, i thought i fixed that [09:18:52] <sbryzak> i'll take care of it right now [09:19:19] <oskutka> sbryzak: But then I found, that this beans.xml is not used in the distributed jar. [09:19:49] <sbryzak> it isn't? [09:19:51] <jbossbot> git [security] push master 2623417.. Shane Bryzak fix interceptor package [09:19:51] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/aa46715...2623417 [09:21:01] <sbryzak> hmm you're right [09:21:14] <oskutka> sbryzak: Seems like the api's beans.xml is used instead [09:21:29] <sbryzak> that's unusual... [09:21:41] <sbryzak> i don't understand how the idmconsole example can work without it [09:22:02] <sbryzak> one sec while i test something [09:22:29] <oskutka> Well, are you sure idmconsole works? [09:23:01] <sbryzak> uh oh, nope it's broken [09:23:13] <sbryzak> i must have tested it before i updated the seam-bom version.. damn [09:23:58] <oskutka> :-/ [09:24:01] <sbryzak> and i'll read up about the maven shade plugin to work out how to include the correct beans.xml [09:24:08] <sbryzak> thanks for finding this [09:24:17] <oskutka> np ;-) [09:25:26] <oskutka> sbryzak: btw: `grep 'org.jboss.seam.persistence.transaction' -R security` finds a few more occurrences of the old transaction package [09:25:40] <sbryzak> in the security module? [09:26:21] <oskutka> sbryzak: yes. In idmconsole and authorization examples [09:26:35] <sbryzak> thanks, i'll fix those also [09:26:42] <oskutka> And two more examples in remoting [09:27:30] <oskutka> And one in faces, but that was worth submitting a jira (SEAMFACES-111) [09:27:32] <jbossbot> jira [SEAMFACES-111] TransactionPhaseListener @Requires refactored TransactionExtension [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/SEAMFACES-111 [09:28:17] *** alesj has joined #seam-dev [09:28:29] <oskutka> sbryzak: I may file a jira for the examples if you want. I was just not sure about the beans.xml not propagating into the .jar. [09:29:06] <sbryzak> oskutka: no problem [09:30:20] *** PeteRoyle has joined #seam-dev [09:36:01] *** PeteRoyle has quit IRC [09:37:33] *** PeteRoyle has joined #seam-dev [09:40:34] <jharting> sbryzak: ping [09:40:40] <sbryzak> jharting: pong [09:41:25] *** stuartdouglas has left #seam-dev [09:41:31] *** Georges has joined #seam-dev [09:41:47] *** stuartdouglas has joined #seam-dev [09:41:53] <jharting> sbryzak: Hi Shane, could you please go around all the modules and make sure appropriate version are specified in JIRA? For instance, catch has the CR1 as the latest version, while the actual version is CR3. [09:42:15] <sbryzak> yep, it's on my to-do list [09:42:24] <sbryzak> i've just been busy fixing issues all day [09:42:34] <jharting> sbryzak: ok, thanks [09:45:33] <Georges> hey guys [09:45:53] <Georges> any idea what would be the quickest way to get the old Seam2 Excel module to work with Seam3? :) [09:46:48] <sbryzak> Georges: become module lead? :) [09:47:18] <Georges> sbryzak: I was afraid you were gonna say that :) [09:47:24] *** PeteRoyle has quit IRC [09:47:35] <sbryzak> it's on the list for seam 3.1 [09:48:02] <Georges> sbryzak: Niklas still in charge? [09:48:13] <jbossbot> git [security] push master 27f593e.. Shane Bryzak use beans.xml from impl module [09:48:13] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/2623417...27f593e [09:48:44] <sbryzak> i didn't realise that nik had been working on it [09:49:08] <Georges> http://seamframework.org/Documentation/Seam3Modules#H-DocumentManagementLedByNicklasKarlssonWithNormanRichardsTomazCerarAndDanielRoth [09:49:21] <Georges> I know it's outdated, but it says he's in charge :) [09:49:47] <Diablo-D3> http://www.macrumors.com/2011/03/18/ipad-2-wife-says-no-but-apple-says-yes/ [09:49:55] <Diablo-D3> am I the only one here whos creeped out by apple? [09:50:00] <sbryzak> ah that page is really old [09:50:20] <sbryzak> we need to work out who'll take the lead on that after the 3.0 final is out next weekend [09:50:38] <Diablo-D3> so hows seam 3 coming? [09:51:14] <Georges> sbryzak: alright, it's not THAT urgent :) I'll check back in a couple of weeks, maybe I can help out [09:51:21] * nickarls recalls shouting for help on seam-dev last week but noone replied ;-) [09:51:47] <Diablo-D3> sbryzak: so seam 3 final is almost ready, it just needs to actually ship? [09:52:01] <sbryzak> we're just madly scrambling to fix all the remaining bugs [09:52:18] <Diablo-D3> I hate to inform you... but there will ALWAYS be remaining bugs ;) [09:52:39] <sbryzak> yes but as long as i'm not aware of them they don't exist [09:52:44] <Diablo-D3> hehehehe [09:52:57] <Diablo-D3> wait, thats a bad way of looking at it [09:53:11] <Diablo-D3> thats how small security issues become gaping holes [09:53:23] <Diablo-D3> (etc etc) [09:55:02] <jbossbot> git [security] push master bbf2a00.. Shane Bryzak remove remaining instances of org.jboss.seam.persistence.transaction package [09:55:03] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/27f593e...bbf2a00 [09:55:29] <sbryzak> oskutka: i've fixed those issues, don't bother with the jira [09:59:54] <oskutka> sbryzak: ok, thanks [10:01:17] <oskutka> sbryzak: In fact, QEs are appraised for the number of jiras they file. :-) [10:02:44] <sbryzak> oskutka: better raise one then :) [10:04:24] <oskutka> sbryzak: No problem. [10:12:51] <Diablo-D3> grrr [10:13:55] <Diablo-D3> I wish this Lincoln Baxter guy was on IRC [10:15:31] <Georges> he's on the US east coast [10:15:37] <Georges> it's 4am there [10:16:24] <Diablo-D3> Georges: yeah, but does he come on IRC at all? [10:16:30] <Diablo-D3> because Ive never seen him in here [10:16:47] <Georges> hmm, dunno :) I just pointed out why he's not here now :) [10:20:32] <Diablo-D3> heh [10:20:42] <Diablo-D3> and no, its 5:20 on the east coast [10:20:46] * Diablo-D3 lives in maine [10:21:31] *** PeteRoyle has joined #seam-dev [10:25:14] <kuuyee> Hi sbryzak! seam reference use po file for translate? [10:25:40] <Georges> Diablo-D3: huh? did you already change to daylight saving? [10:25:46] <Diablo-D3> yeah [10:25:52] <Diablo-D3> like last week or something [10:26:05] <Georges> Diablo-D3: aah, that explains it, we're only up next weekend [10:26:14] <Georges> we=Europe [10:26:41] <Diablo-D3> yeah, remember Bush fucked up the spacetime contiuum itself up and decided to change when we do it? [10:29:42] <sbryzak> kuuyee: yes, we use po files [10:30:39] <kuuyee> sbryzak I did not find the directory zh-CN [10:30:48] <sbryzak> kuuyee: create it [10:31:32] <kuuyee> how generate po file? use publican? [10:31:51] <kuuyee> or jdocbook pulgin? [10:31:55] *** Georges has quit IRC [10:32:02] <sbryzak> kuuyee: our documentation team use publican, i think it's easiest to use [10:34:07] <kuuyee> sbryzak: not find publican.cfg [10:34:19] <sbryzak> kuuyee: you'll need to create that [10:34:37] <sbryzak> we just use the maven jdocbook plugin to build the docs, it doesn't require any of the publican stuff [10:34:54] <sbryzak> publican should only be used for translations [10:35:01] <kuuyee> sbryzak: ok i see [10:35:25] <kuuyee> sbryzak: my pc installed publican [10:35:56] <sbryzak> great [10:36:14] <kuuyee> sbryzak: thanks! [10:55:12] *** aslak has quit IRC [10:55:51] *** aslak has joined #seam-dev [10:56:18] *** aslak has quit IRC [11:00:43] *** kuuyee has quit IRC [11:06:05] *** jose_f_home has joined #seam-dev [11:07:07] *** jose_f_home has quit IRC [11:35:53] *** PeteRoyle has quit IRC [11:39:17] <jbossbot> git [dist] push master 845e02c.. Shane Bryzak added credits chapter [11:39:18] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/84d528a...845e02c [11:41:51] *** aslak has joined #seam-dev [11:42:41] *** PeteRoyle has joined #seam-dev [11:48:23] *** PeteRoyle has quit IRC [12:20:51] *** josefreitas has joined #seam-dev [12:21:10] *** josefreitas has quit IRC [12:24:05] <Diablo-D3> argh! [12:24:12] <Diablo-D3> why does java hate me this week! [12:28:02] <Diablo-D3> wtf?! [12:28:22] <Diablo-D3> I added prettyfaces [12:28:36] <Diablo-D3> http://127.0.0.1:8080/project/faces/index.xhtml [12:28:42] <Diablo-D3> javax.servlet.ServletException: null source [12:28:42] <Diablo-D3> javax.faces.webapp.FacesServlet.service(FacesServlet.java:321) [12:28:43] <Diablo-D3> org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:63) [12:28:43] <Diablo-D3> org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [12:28:43] <Diablo-D3> com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:115) [12:29:39] <Diablo-D3> that is the worlds most unhelpful traceback [12:32:01] <Diablo-D3> and Im using prettyfaces-jsf2, its a javaee6 war with a web.xml version of 3 [12:32:11] <Diablo-D3> and web.xml has nothing of interest in it [12:33:19] * Diablo-D3 removes the mvn dep for prettyfaces [12:35:53] *** maschmid has joined #seam-dev [12:40:37] *** rruss has quit IRC [12:43:05] <sbryzak> Diablo-D3: that exception can sometimes indicate an error in the markup [12:47:41] <Diablo-D3> nope, Im even more retarded than originally suspected [12:47:43] <Diablo-D3> removing it [12:47:50] <Diablo-D3> and clearing everything out, etc [12:48:05] <Diablo-D3> javax.servlet.ServletException: null source [12:48:05] <Diablo-D3> javax.faces.webapp.FacesServlet.service(FacesServlet.java:321) [12:48:05] <Diablo-D3> org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:63) [12:48:05] <Diablo-D3> org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [12:48:08] <Diablo-D3> so wtf. [12:48:47] <sbryzak> not enough information there to tell [12:49:02] <sbryzak> can you pastebin your page? [12:56:31] <maschmid> sbryzak: is the text in the readme.txt supposed to go to the final? It looks kind of not actually about seam3... [12:57:06] <sbryzak> maschmid: which readme? [12:57:21] <maschmid> seam-3.0.0.CR3/readme.txt [12:58:04] <sbryzak> looking now... [12:58:12] <sbryzak> which bits aren't about seam 3? [12:58:49] <sbryzak> the jira url needs to be updated [12:59:29] <maschmid> sbryzak: well, it's just that it is that it is the text in the http://www.seamframework.org/, which I guess was meant to be general enough to be also about seam2... [13:00:00] <jbossbot> git [dist] push master 6b49c6b.. Shane Bryzak fix JIRA url [13:00:00] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/845e02c...6b49c6b [13:00:22] <sbryzak> ah, yeah that blurb is a bit outdated [13:23:34] <jbossbot> git [dist] push master 8f4c65f.. Shane Bryzak updated readme text [13:23:34] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/6b49c6b...8f4c65f [13:28:19] <jbossbot> git [dist] push master c18faa9.. Shane Bryzak use standard characters [13:28:20] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/8f4c65f...c18faa9 [13:32:26] <Diablo-D3> sbryzak: sorry, went afk for a second [13:32:55] <Diablo-D3> sbryzak: is there a problem with putting facelets in /faces ? [13:33:31] <Diablo-D3> http://pastebin.com/vTKJ6fby [13:33:51] <sbryzak> Diablo-D3: shouldn't be [13:33:53] <Diablo-D3> http://pastebin.com/9f6g1n9n [13:34:15] <Diablo-D3> but the strange part is, this WAS working [13:34:25] <sbryzak> what's changed? [13:34:32] <Diablo-D3> afaict, nothing [13:35:32] <sbryzak> remove the html tag [13:35:45] <sbryzak> put the namespace stuff in the ui:composition tag [13:36:02] <Diablo-D3> in index you mean? [13:36:10] <sbryzak> and i wouldn't mind seeing template.xhtml [13:36:18] <Diablo-D3> thats the second paste [13:36:33] * Diablo-D3 put two there =P [13:36:54] <sbryzak> ah ok, looking now [13:37:12] <sbryzak> so in the first one, try the changes that i suggested [13:37:51] <sbryzak> template seems ok [13:39:01] <Diablo-D3> changing it dosent fix it [13:39:36] <sbryzak> ok one moment while i play with it [13:39:52] <Diablo-D3> I wonder what I changed that broke it [13:40:59] <sbryzak> i'm going to deploy it and take a look [13:41:38] <sbryzak> hmm, it works [13:41:43] <sbryzak> which app server are you using? [13:41:49] <Diablo-D3> jboss as 6 [13:41:54] <sbryzak> same here [13:42:01] <sbryzak> ok, it must be a configuration issue then [13:44:25] <sbryzak> Diablo-D3: there's a thread on it here: http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=3776 [13:44:33] <sbryzak> dunno if any of that info will help [13:44:54] <sbryzak> the steps i would take though, is to deploy one of the seam 3 examples [13:45:03] <sbryzak> so that you have a working base [13:45:16] <sbryzak> then copy your view files into the example, and try them there [13:45:25] <sbryzak> if that works, compare the example war with your own war [13:45:51] * Diablo-D3 tries something [13:46:20] <Diablo-D3> Goddamnit. [13:46:29] <Diablo-D3> <servlet> [13:46:30] <Diablo-D3> <servlet-name>Faces Servlet</servlet-name> [13:46:30] <Diablo-D3> <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> [13:46:30] <Diablo-D3> <load-on-startup>1</load-on-startup> [13:46:30] <Diablo-D3> </servlet> [13:46:34] <Diablo-D3> adding that to web.xml fixes it [13:47:02] <sbryzak> interesting... web.xml should be optional [13:47:43] <Diablo-D3> I have a web.xml already [13:47:55] <Diablo-D3> its just almost empty [13:48:06] <Diablo-D3> no maps or servlets or anything defined in it [13:48:38] <Diablo-D3> can using EJBs or resteasy interfere with the process? [13:48:53] <sbryzak> doubtful [13:48:59] <Diablo-D3> yeah, I dont think so either [13:49:04] <sbryzak> i guess in our examples we have the faces servlet configured [13:49:17] <Diablo-D3> the interesting thing is [13:49:21] <Diablo-D3> I had that in my web.xml [13:49:23] <Diablo-D3> but I removed it [13:49:26] <Diablo-D3> and it didnt break [13:49:43] <Diablo-D3> I wonder if it didnt get published correctly [13:50:02] <Diablo-D3> btw http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html_single/index.html#web-xml [13:50:16] <Diablo-D3> seems to imply I dont need to define the servlet. [13:51:19] <sbryzak> that was my understanding also [13:58:37] <Diablo-D3> blergh [13:58:41] <Diablo-D3> I need to add the mappings too [13:58:52] <Diablo-D3> because now its just spitting the xml out [13:59:17] <Diablo-D3> <servlet-mapping> [13:59:18] <Diablo-D3> <servlet-name>Faces Servlet</servlet-name> [13:59:18] <Diablo-D3> <url-pattern>/faces/*</url-pattern> [13:59:21] <Diablo-D3> </servlet-mapping> [14:00:14] <Diablo-D3> ARGH [14:00:17] <Diablo-D3> sbryzak: its broken again [14:00:40] <sbryzak> again? is all the configuration there now? [14:00:51] <Diablo-D3> yeah [14:01:02] <Diablo-D3> but theres something I dont particularly like in the traceback [14:01:11] <Diablo-D3> org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:63) [14:01:29] <Diablo-D3> I wonder if resteasy is deciding to be clever [14:03:11] *** balunasj has joined #seam-dev [14:14:20] <Diablo-D3> ,,,,'t;welkstkajtrlakjralkrf [14:14:28] *** tsurdilo has joined #seam-dev [14:14:28] <Diablo-D3> sbryzak: something is very horribly wrong here [14:14:46] <Diablo-D3> I changed the mapping from /faces/* to *.xhtml [14:14:57] <Diablo-D3> not /faces/*.xhtml, just *.xhtml [14:15:00] <Diablo-D3> IT NOW WORKS FINE [14:15:52] <sbryzak> congrats? :) [14:15:59] <Diablo-D3> it doesnt make any sesne! [14:16:31] <sbryzak> you would usually use *.jsf [14:16:38] <sbryzak> i guess *.xhtml is ok though [14:16:52] <Diablo-D3> it shouldnt matter [14:16:59] <Diablo-D3> if its in faces, its a face of some sort [14:17:06] <Diablo-D3> I could name it giant.dongs and it should work [14:17:19] <sbryzak> so everything was in the /faces dir? [14:17:30] <Diablo-D3> yes [14:18:06] <sbryzak> hmm, weird [14:18:14] <sbryzak> i would ask bleathem when he comes online [14:18:19] *** gastaldi has joined #seam-dev [14:18:33] <sbryzak> i'm personally not a fan of jsf [14:21:05] <jbossbot> git [security] push master 325f77f.. Shane Bryzak uncomment required dependencies [14:21:06] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/bbf2a00...325f77f [14:24:25] *** rruss has joined #seam-dev [14:24:54] *** rruss has quit IRC [14:26:08] *** gastaldi has left #seam-dev [14:32:30] <jbossbot> git [security] push master 5432a79.. Shane Bryzak SEAMSECURITY-43 [14:32:36] <jbossbot> jira [SEAMSECURITY-43] security-idmconsole example fails with NPE [Open (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-43 [14:32:36] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/325f77f...5432a79 [14:33:45] <nickarls> shane: wasn't http://pastebin.com/msGcYZys in beans.xml supposed to suppress the login message? [14:33:57] <nickarls> with xmlns:security="urn:java:org.jboss.seam.security" [14:34:07] <jbossbot> git [security] push master decbcaf.. Shane Bryzak minor [14:34:08] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/5432a79...decbcaf [14:35:46] <jbossbot> git [remoting] push master 00af0ab.. Shane Bryzak SEAMREMOTING-24 [14:35:57] <jbossbot> jira [SEAMREMOTING-24] Manifest.mf files in jars generated from the module contain unreachable Implementation-URL [Reopened (Unresolved) Bug, Minor, Shane Bryzak] https://issues.jboss.org/browse/SEAMREMOTING-24 [14:35:58] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/1f15097...00af0ab [14:41:15] *** clerum has joined #seam-dev [14:44:55] <jose_freitas> hey clerum [14:44:57] <jose_freitas> morning [14:46:01] *** balunasj is now known as balunasj_busy [14:50:49] *** lightguard_jp has joined #seam-dev [14:51:58] *** sannegrinovero has joined #seam-dev [14:51:58] *** sannegrinovero has joined #seam-dev [14:57:50] *** jharting has quit IRC [14:58:20] <clerum> morning [15:00:09] <jose_freitas> Is there a CR for mail? [15:00:20] <clerum> not even an alpha yet :-) [15:01:03] <jose_freitas> np, i was hoping to have something that I could work for mails on booking example [15:01:23] *** shervin_a has quit IRC [15:01:24] <clerum> I think it's basically ready for alpha [15:01:32] <clerum> just missing reference docs and api doc cleanup [15:01:50] <clerum> mojavelinux is going to take a look at some arquillian test failing [15:02:01] <clerum> and I need render to have an non-snapshot release [15:02:20] <clerum> then I think it can be alpha and move pretty fast to final [15:02:39] <clerum> I think it's basically feature complete. just needing docs and the like [15:04:24] <clerum> I use the api in my seam 2 app [15:04:32] <clerum> and it seems to accomplish what I need [15:11:55] <jose_freitas> nice [15:15:33] *** monkeyden has joined #seam-dev [15:22:58] *** gastaldi has joined #seam-dev [15:23:02] <gastaldi> hey ho ! [15:24:04] <jose_freitas> *Hello*? [15:24:31] <lightguard_jp> hey [15:25:57] *** lincolnthree has joined #seam-dev [15:38:27] <lightguard_jp> lincolnthree: Morning [15:40:46] <Diablo-D3> heh sannegrinovero is even in here? [15:42:03] *** gastaldi has left #seam-dev [15:46:13] *** gastaldi has joined #seam-dev [15:46:22] <gastaldi> anyone here on seam-cron ? [15:47:52] <lincolnthree> lightguard_jp: hey jason [15:48:02] <gastaldi> I guess Royle is the only one on that [15:48:13] <lightguard_jp> gastaldi: Yeah, I think so [15:48:14] <sannegrinovero> Diablo-D3, hi what do you do here :) [15:48:58] <Diablo-D3> sannegrinovero: complain about bugs ;) [15:49:32] *** gastaldi has left #seam-dev [15:54:03] <sannegrinovero> Diablo-D3, it's not fair to complain with open source, fix it! :) [15:54:12] <lincolnthree> sannegrinovero: amen? :) [15:54:22] <lincolnthree> but lifes not fair [15:55:08] <Diablo-D3> sannegrinovero: I do on some projects. [16:01:31] *** balunasj_busy is now known as balunasj_mtg [16:04:58] *** nickarls has quit IRC [16:05:37] <lincolnthree> Hey all, I need a solutionfor embedded Git - but JGit does not support cloning remote repositories. Does anyone know of anything I could use? [16:07:06] <Diablo-D3> sannegrinovero: hey you, did you forget that IS ships with my code in it now? [16:07:17] <Diablo-D3> lincolnthree: yes it does [16:07:29] <lincolnthree> Diablo-D3: can you show me an example? [16:07:33] <Diablo-D3> lincolnthree: the eclipse ui for it is incomplete [16:07:43] <lincolnthree> ive been searching for hours [16:07:52] <sannegrinovero> Diablo-D3, didn't forget, thanks ;) [16:07:54] <Diablo-D3> but afaik the actual git "client" itself in jgit does it [16:08:01] <lincolnthree> hmmm [16:08:12] <lincolnthree> im pretty sure it doesn't do cloning of remotes, just locals, but i'll check [16:08:16] <Diablo-D3> lincolnthree: the bug report for it on egit implies what I said is true [16:08:26] <lincolnthree> interesting. got a link? [16:08:31] <Diablo-D3> nope [16:08:34] <lincolnthree> crap lol [16:08:40] <Diablo-D3> its been a few months since I last cared ;< [16:09:26] <jbossbot> git [dist] push master 1cd02c7.. Shane Bryzak SEAM-24 [16:09:28] <jbossbot> jira [SEAM-24] Seam 3.0.0.CR3 distribution missing some images from seam docs in the consolidated reference docs [Open (Unresolved) Bug, Minor, Shane Bryzak] https://issues.jboss.org/browse/SEAM-24 [16:09:28] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/c18faa9...1cd02c7 [16:10:36] <lincolnthree> oh WOW [16:10:39] <lincolnthree> I just found something amazing [16:10:53] <lincolnthree> People are using GitHub to create maven repositories for their projects [16:10:57] <lincolnthree> that's clever [16:10:58] <lincolnthree> very clever [16:16:37] <Diablo-D3> lincolnthree: thats not news [16:16:43] <lincolnthree> it is to me [16:16:44] <Diablo-D3> people have been doing shit like that for awile [16:16:50] <Diablo-D3> you can do it out of svn too [16:16:57] <Diablo-D3> problem is, it wastes github space [16:16:58] <lincolnthree> with webdav, sure [16:17:02] <Diablo-D3> I dont even put my downloads there [16:17:05] <lincolnthree> yes it does [16:18:16] <Diablo-D3> its not like its hard to host a repo [16:18:50] <lincolnthree> what's hard is getting your repo sync'd to central ; [16:18:51] <lincolnthree> ;) [16:19:12] <Diablo-D3> yeah, but see [16:19:14] <lincolnthree> for that you cannot use github or svn [16:19:23] <Diablo-D3> getting my stuff into central isnt a big deal for me [16:20:00] <Diablo-D3> I mean, its not like people dont have 9000 repos in their poms [16:20:07] <lincolnthree> I don't [16:20:09] <lincolnthree> ;) [16:20:12] <Diablo-D3> heh [16:20:17] <Diablo-D3> I have jboss's [16:20:38] <Diablo-D3> and the lwjgl one I host [16:25:29] <sbryzak> alesj: ping [16:28:35] *** oskutka has quit IRC [16:29:27] <Diablo-D3> sbryzak: hey, something more interesting [16:29:32] <Diablo-D3> I renamed those files from xhtml to jsf [16:29:48] <Diablo-D3> and then removed the stuff from web.xml [16:29:48] <alesj> sbryzak: shoot [16:29:49] <Diablo-D3> still breaks [16:30:01] <jbossbot> git [security] push master 35bafc3.. Shane Bryzak add null check for authentication status [16:30:01] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/decbcaf...35bafc3 [16:30:14] <sbryzak> Diablo-D3: interesting [16:30:22] <sbryzak> alesj: could you take a look at an issue for me? [16:30:31] <alesj> sure, which one? [16:30:32] <sbryzak> alesj: https://issues.jboss.org/browse/SEAMSECURITY-42 [16:30:33] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42 [16:30:45] <sbryzak> it's becoming quite epic [16:34:01] *** gastaldi has joined #seam-dev [16:44:29] *** daniel_hinojosa has joined #seam-dev [16:53:35] *** kpiwko has joined #seam-dev [16:56:19] <jbossbot> git [faces] push master d866413.. Shane Bryzak fix @Requires [16:56:20] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/0de13ed...d866413 [16:57:03] *** bleathem has joined #seam-dev [16:59:38] <jbossbot> git [remoting] push master f39b9c9.. Shane Bryzak update package references [16:59:38] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/00af0ab...f39b9c9 [17:00:00] <bleathem> mojavelinux: Do you think it would be possible to get SeamFaces-33 going with enums (instead of interfaces) ? [17:00:21] <bleathem> type safe viewIds are pretty compelling (I'd forgotten about this side of the argument) [17:04:20] *** kpiwko has quit IRC [17:08:32] *** kpiwko has joined #seam-dev [17:14:19] *** pmuir has joined #seam-dev [17:16:43] <jose_freitas> hey bleathem :) [17:16:53] <bleathem> hey jose_freitas [17:17:07] <bleathem> sorry I haven't looked at your documentation pull request yet [17:17:20] <bleathem> I've been swimming in seamfaces-33 [17:17:29] *** balunasj_mtg is now known as balunasj_away [17:27:47] <jose_freitas> np [17:28:01] <jose_freitas> SEAMFACES-33 [17:28:02] <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:28:13] <jose_freitas> NICE [17:28:14] <jose_freitas> ops [17:28:16] <jose_freitas> nice [17:28:41] <bleathem> I'm nearing the finish line [17:29:35] <jose_freitas> yesterday I couldn't see all the talk with sbryzak, but it seemed that it was getting solid [17:29:36] <bleathem> jose_freitas, have you looked at the short.ly example at all? [17:29:51] <jose_freitas> nope [17:30:03] <jose_freitas> do you assign me a jira about it? [17:30:08] <bleathem> yeah, I think we've got a good proposal for the API, and I've almost got it all wired together (sf-33) [17:30:13] <bleathem> not yet :P [17:30:28] <bleathem> SEAMFACES-101 [17:30:34] <jbossbot> jira [SEAMFACES-101] First request in the short.ly example returns weird action URL due to a bug in prettyfaces on JBossAS 6 [Open (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-101 [17:30:43] <bleathem> are you interested in taking a look at it? [17:31:14] <bleathem> actually, it looks pretty straight forward [17:31:18] [17:31:27] <bleathem> sure [17:31:34] <jose_freitas> I'm hooked with a training this week [17:31:35] <jose_freitas> 40h [17:31:45] <jose_freitas> cdi and seam 3 [17:31:51] <bleathem> cool! [17:31:54] <bleathem> how big a group? [17:31:58] <jose_freitas> 15 [17:32:25] <lincolnthree> jose_freitas: are you teaching? [17:32:26] <bleathem> have you done training with these topics before? [17:32:33] <jose_freitas> nope [17:32:39] <jose_freitas> yes lincolnthree [17:32:45] <lincolnthree> awesome :) [17:33:18] <jose_freitas> I'm not that good like you or dan allen but It's working fine [17:33:51] <jose_freitas> I've been preparing this for some time now [17:34:09] <bleathem> right on [17:34:23] <bleathem> I could use some training myself :P [17:34:23] <jose_freitas> the most difficult part is to make them understand the new development model [17:34:35] *** marekn has left #seam-dev [17:34:36] <jose_freitas> with stateful, events, and etc [17:35:12] *** kpiwko has quit IRC [17:35:41] <jose_freitas> I'll try to blog about some of the most common question [17:35:41] <jose_freitas> s [17:36:36] <jose_freitas> And I'm learning a lot myself [17:37:22] <bleathem> that'd be a useful series of blogs for sure [17:41:05] <jose_freitas> good luck with faces-33, I'll take a look at 101 this night, if it's that straight forward I'll pull a request. [17:41:13] <jose_freitas> got to go now [17:41:14] <jose_freitas> bye [17:41:33] *** jose_freitas has quit IRC [17:53:51] <lincolnthree> boom [17:53:54] <lincolnthree> got git clone working [17:53:55] <lincolnthree> huzzah [18:00:11] *** alesj has left #seam-dev [18:03:48] *** maschmid has quit IRC [18:07:17] *** cbrock has joined #seam-dev [18:07:17] *** cbrock has quit IRC [18:07:18] *** cbrock has joined #seam-dev [18:09:21] <gastaldi> hello [18:09:42] <Diablo-D3> hey bleathem [18:09:46] <gastaldi> Hey pmuir: thanks for making that JIRA issue more readable [18:09:47] <bleathem> hello! [18:09:53] <gastaldi> bleathem: Hello [18:09:59] *** lightguard_jp has quit IRC [18:10:20] <Diablo-D3> bleathem: I should be able to throw facelets into one of the default mappings, and have everything work right, right? [18:11:19] <Diablo-D3> bleathem: as in, a blank web.xml as per http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html_single/index.html#web-xml [18:11:27] <Diablo-D3> bleathem: because jboss as 6 isnt doing this [18:12:28] <Diablo-D3> bleathem: if I put facelets into, say, /faces/, it returns an exception [18:13:00] <Diablo-D3> bleathem: but if I define the servlet and servlet mapping, and the url pattern matches one of the defaults, it STILL fails [18:13:12] <Diablo-D3> if I define it as something thats not one of the defaults, it works. [18:13:31] <bleathem> you're using jsf 2? [18:13:42] <lincolnthree> Diablo-D3: thank you for encouraging me to take a closer look at JGit. I found what I needed. [18:13:58] <Diablo-D3> lincolnthree: I was right that it works? [18:14:27] <Diablo-D3> bleathem: yes, its a facelet [18:14:44] <lincolnthree> Diablo-D3: it supports it on the command line, but there was no direct java support for cloning without doing a LOT of work - that I ended up doing by taking one of their sources and modifying it [18:15:16] <Diablo-D3> lincolnthree: well, remember to submit patches or whatever ;) [18:15:25] <bleathem> ... I mean you're in JBoss AS 6, which has the JSF 1.2 libraries included as well as the 2.0 [18:15:26] <lincolnthree> of course... [18:15:28] <lincolnthree> already filed 3 issues [18:15:33] <bleathem> are you sure you're using the 2.0? [18:15:38] <Diablo-D3> bleathem: er.... I dont know. [18:15:43] <lincolnthree> Diablo-D3: ps, who are you? :p [18:15:56] <bleathem> it should tell you on app start up [18:16:13] <lincolnthree> or I should probably rephrase [18:16:15] <lincolnthree> Have we met? [18:16:21] <Diablo-D3> lincolnthree: dont think so [18:16:34] <Diablo-D3> lincolnthree: the real question is, who are you? [18:16:45] <lincolnthree> Well nice to meet you. It's good to see lots of folks here these days. [18:17:13] <lincolnthree> I think the best question is "what am I doing?" [18:17:35] <lincolnthree> And that is answered with a link: http://seamframework.org/Documentation/SeamForge [18:17:49] <Diablo-D3> bleathem: wait, if my faces-config.xml says version 2.0, Im on 2.0, right? [18:17:54] <lincolnthree> Diablo-D3: should be [18:17:56] <bleathem> right [18:18:02] <Diablo-D3> then Im on 2.0 [18:18:05] <bleathem> ok [18:18:17] <lincolnthree> If you're using AS6 and your faces-config.xml says version 2.0, then you're using 2.0 [18:18:19] <Diablo-D3> lincolnthree: wait, you're lincoln baxter? [18:18:20] <lincolnthree> But [18:18:33] <lincolnthree> You need to make sure that you have the correct schema and namespace or it barfs sometimes [18:18:38] <lincolnthree> Diablo-D3: yes :) [18:18:46] <Diablo-D3> bwhahahah [18:18:47] <Diablo-D3> dude [18:18:53] <bleathem> http://pastie.org/1700439 [18:18:56] <Diablo-D3> Im going to be using prettyfaces [18:18:57] *** gastaldi has quit IRC [18:18:59] <bleathem> that's my faces-config.xml [18:19:03] <bleathem> does yours look like that? [18:19:08] <lincolnthree> Awesome! What for? [18:19:09] <Diablo-D3> http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html_single/index.html#web-xml [18:19:14] <Diablo-D3> see figure 2.3 [18:19:18] <Diablo-D3> thats what mine looks like [18:19:37] <Diablo-D3> I think its the same thing [18:19:43] <lincolnthree> yes, those both look good [18:20:01] <Diablo-D3> lincolnthree: Im using it on something thats foss, small, and not ready to be unveiled yet [18:20:07] <lincolnthree> Diablo-D3: ah, i see your problem I think [18:20:20] <lincolnthree> Maybe... [18:20:45] <lincolnthree> But can I see your exception? [18:20:52] <lincolnthree> Before I put my foot in my mouth [18:21:02] <Diablo-D3> yeah just a sec [18:21:06] <Diablo-D3> gotta make it spit it out again [18:21:22] <lincolnthree> Diablo-D3: That's cool! Those are the projects that make me the happiest. Found a few bugs recently though, wish I had more time to work on it. [18:21:30] <lincolnthree> nothing serious.. just annoying [18:21:36] <Diablo-D3> oh [18:21:38] <Diablo-D3> speaking of which [18:21:40] <Diablo-D3> fix the docs [18:21:49] <lincolnthree> file an issue? [18:21:53] <lincolnthree> what's wrong with them [18:22:08] <Diablo-D3> think theres already an issue, its the view-id one [18:22:13] <lincolnthree> oh [18:22:16] <lincolnthree> 1 sec [18:22:20] <Diablo-D3> the schema doesnt match the intended issue [18:22:30] <Diablo-D3> I already figured out its supposed to be view-id value="" [18:22:36] <lincolnthree> ah yes, I believe that's fixed [18:22:59] <Diablo-D3> http://pastebin.com/ajGVgg3q [18:23:04] <lincolnthree> no, not fixed, shoot [18:23:09] <lincolnthree> must be on my local box [18:23:27] <lincolnthree> i distinctly recall fixing those view-id examples [18:23:31] <lincolnthree> however, it works both ways [18:23:37] <lincolnthree> you just get "validation errors" [18:23:40] <Diablo-D3> yeah but eclipse bitches because it doesnt validate [18:23:51] <Diablo-D3> and I hate warnings [18:24:02] <lincolnthree> Yeah I know, me too [18:24:16] <lincolnthree> Btw. Did you post this JSF error on my blog by any chance? [18:24:23] <Diablo-D3> no [18:24:26] <Diablo-D3> just arrived at it today [18:24:39] <Diablo-D3> I didnt notice it earlier because I was specifying the servlet with a mapping of *.xhtml [18:24:45] <Diablo-D3> and had my facelets named that [18:25:14] <lincolnthree> ah, slightly different error: http://ocpsoft.com/java/jsf-java/how-to-modular-jsf-applications-with-cdi-and-prettyfaces/#comment-2222 [18:25:17] <Diablo-D3> it ONLY triggers if either you have a blank web.xml, or you specify it with one of the default mappings [18:25:34] <Diablo-D3> change it to a non-default mapping of ANYTHING else, and bam it works [18:25:51] <Diablo-D3> it makes absolutely no sense [18:26:40] <lincolnthree> So you have facelets in /faces/ [18:26:46] <lincolnthree> and you are referencing them with .xhtml [18:26:53] <lincolnthree> and you get that NullSource ? [18:27:42] <Diablo-D3> I think its the mapping itself [18:28:08] <Diablo-D3> they're in /faces/, but as long as I dont use one of the three defaults as my mapping, it works [18:28:12] <Diablo-D3> as far as I can tell, anyways [18:28:52] <lincolnthree> sounds like an AS bug [18:29:09] <bleathem> your facelets are actually in a folder called "faces"? [18:29:25] <bleathem> they should be in the root [18:29:38] <Diablo-D3> bleathem: its supposed to be accepted [18:29:38] <bleathem> the mapping prepends the /faces [18:29:47] <Diablo-D3> see 3.3 of that url [18:29:48] <lincolnthree> yes, that's the problem [18:29:57] <lincolnthree> shoot, that's what i was thinking before but got confused [18:29:57] <bleathem> for kicks, try moving your facelets up one level [18:29:59] <lincolnthree> thanks bleathem [18:30:04] <bleathem> see if it works [18:30:05] <Diablo-D3> they WERE one level up before [18:30:10] <Diablo-D3> thats why I didnt catch it [18:30:17] <lincolnthree> using a folder called /faces/ means you need to reference them with /faces/faces/ [18:30:19] <lincolnthree> hmm [18:30:28] <Diablo-D3> lincolnthree: erm, nope [18:30:35] <Diablo-D3> er [18:30:37] <Diablo-D3> maybe? [18:30:40] <lincolnthree> pretty sure [18:30:42] <Diablo-D3> now Im confused [18:30:54] <Diablo-D3> because what happens if its a file named foo.jsf in the root [18:31:13] <Diablo-D3> http://docs.jboss.org/jbossas/6/JSF_Guide/en-US/html_single/index.html [18:31:16] <Diablo-D3> see chapter 3.3 [18:31:18] <bleathem> you have a foo.xhtml in the root [18:31:36] <bleathem> it gets *mapped* to the url /faces/foo.xhtml [18:31:45] <Diablo-D3> if I have a foo.jsf in the root, I should type in http://crap/app/foo.jsf and have it work [18:31:47] <bleathem> it should not *be* in that folder [18:32:20] <bleathem> right [18:32:23] <bleathem> that should work [18:32:49] <bleathem> no, you'd have foo.xhtml on the root [18:32:59] <bleathem> and http://...foo.jsf should work [18:33:27] <Diablo-D3> its a war that isnt taking over the root path [18:33:33] <bleathem> your facelets should not have .jsf extensions [18:33:49] <Diablo-D3> bleathem: blame sbryzak on that [18:34:02] <Diablo-D3> he said .xhtml is a weird extension for a facelet [18:34:07] <Diablo-D3> and suggested that instead [18:34:15] <bleathem> it gets mappe to the .jsf url [18:34:23] <bleathem> but the file should be .xhtml [18:35:24] <lincolnthree> http://example.com/app/test.jsf -> WebContent/test.xhtml [18:35:34] <Diablo-D3> thats horrible. [18:35:39] <lincolnthree> http://example.com/app/faces/test.xhtml -> WebContent/faces/test.xhtml [18:36:01] <lincolnthree> http://example.com/app/test.xhtml -> 404 [18:36:05] <lincolnthree> or rather [18:36:10] <lincolnthree> what you'll probably get is the source of that page [18:36:18] <lincolnthree> but it wont be "rendered" [18:36:23] <lincolnthree> it is bad, yes [18:36:26] <bleathem> I restrict acces to *.xhtml in my web.xml [18:36:28] <lincolnthree> blame JSF [18:36:39] <lincolnthree> I use prettyfaces after I restrict access [18:36:43] <lincolnthree> to get rid of all JSF junk [18:36:44] <lincolnthree> I hate it [18:36:56] <Diablo-D3> so wait [18:37:09] <Diablo-D3> theres no automatic servlet mapping for facelets? [18:37:48] <bleathem> there is, the facelet gets mapped accoring to the examples lincoln showed above [18:38:02] *** lightguard_jp has joined #seam-dev [18:38:12] <Diablo-D3> goddamnit eclipse, stop fucking stalling on publishing [18:38:58] <Diablo-D3> okay so, in the root, I have index.xhtml [18:39:02] <Diablo-D3> its a facelet [18:39:05] <Diablo-D3> my web.xml is empty [18:39:58] <bleathem> so goto http://.../index.jsf [18:40:11] <bleathem> or http://.../faces/index.xhtml [18:40:23] <lincolnthree> bleathem: not sure the second will work [18:40:26] <bleathem> of http://.../index.faces [18:40:33] <Diablo-D3> http://127.0.0.1:8080/DiabloPool/index.jsf -> 404 [18:40:36] <bleathem> why not? [18:41:11] <bleathem> Diablo-D3 check your context root maybe? [18:43:12] <lincolnthree> what about index.faces? [18:43:48] <Diablo-D3> bleathem: its not /index.jsf or /index.xhtml either [18:44:08] <lincolnthree> and /index.faces ? [18:44:29] <Diablo-D3> AHAH [18:44:33] <Diablo-D3> its /faces/index.xhtm [18:44:34] <Diablo-D3> er [18:44:36] <Diablo-D3> its /faces/index.xhtml [18:44:52] <Diablo-D3> sorry, its /DiabloPool/faces/index.xhtml [18:44:55] <Diablo-D3> just to make that clear [18:45:06] <lincolnthree> weird that the .jsf didnt work [18:45:30] <Diablo-D3> /DiabloPool/faces/index.jsf gives an exception [18:46:16] <Diablo-D3> javax.servlet.ServletException: Context is already active [18:46:18] *** pmuir has quit IRC [18:47:23] *** pmuir has joined #seam-dev [18:47:24] *** pmuir has quit IRC [18:47:24] *** pmuir has joined #seam-dev [18:48:54] <bleathem> I created a file in my test src tree called: [18:48:56] <bleathem> org.jboss.seam.security.extension.SecurityExtension [18:49:12] <bleathem> to satisfy a @Requires, so I could get an Arquillian test to run [18:49:30] <bleathem> is that going to cause problems somehow? [18:49:45] <Diablo-D3> lincolnthree: okay so, what do I put in pretty-config.xml to map this right? pattern of /, view-id of /index.xhtml? [18:50:03] <lincolnthree> view id of whatever comes after the context root in the browser [18:50:15] <lincolnthree> so it sounds like in your case "/faces/index.xhtml" [18:50:33] <Diablo-D3> http://127.0.0.1:8080/DiabloPool/ -> 404 [18:50:41] <lincolnthree> are you in Development mode? [18:50:51] <lincolnthree> you'll need to redeploy if not [18:51:08] <Diablo-D3> what, jboss as? [18:51:13] <lincolnthree> the app, yes [18:51:19] <lincolnthree> not the whole server [18:51:26] <lincolnthree> but show me your config [18:51:39] <Diablo-D3> jboss as server is running in debug, the app is ran in debug mode [18:51:43] <Diablo-D3> jboss tools++ [18:51:53] <lincolnthree> did PrettyFilter start up? [18:52:31] <Diablo-D3> er goddamnit [18:52:36] *** alesj has joined #seam-dev [18:52:41] <Diablo-D3> I forgot I commented it out in my pom.xml [18:52:46] <lincolnthree> :-D [18:52:56] <Diablo-D3> lets try this again [18:53:19] <Diablo-D3> FINALLY [18:53:21] <Diablo-D3> SHIT WORKS [18:55:23] <lincolnthree> congrats! [18:55:39] <Diablo-D3> yeah but [18:55:48] <Diablo-D3> it was working before, before I screwed with it :< [18:56:48] <Diablo-D3> lincolnthree: now theres only one thing left to do [18:56:56] <lincolnthree> make it do something? [18:57:07] <Diablo-D3> no, get rid of pretty-config.xml [18:57:13] <lincolnthree> Annotations [18:57:28] <Diablo-D3> yeah, but how do you annotate an xml file [18:57:39] <lincolnthree> i personally don't like it [18:57:42] <lincolnthree> but the docs are there :) [18:57:58] <lincolnthree> http://ocpsoft.com/docs/prettyfaces/snapshot/en-US/html_single/#config.annotations [18:58:26] <Diablo-D3> heh [18:58:32] <Diablo-D3> thats for beans, not faces [18:58:38] <Diablo-D3> btw, thats also nuts [18:58:48] <lincolnthree> how do you mean? [18:58:53] <Diablo-D3> if someone is going to bother doing that, why not just use reateasy [18:59:12] <lincolnthree> slightly different use case ;) [18:59:30] <Diablo-D3> it still uses the sane urls, and resteasy doesnt imply you're doing actual rest [19:00:18] <lincolnthree> harder to integrate with JSF though [19:00:49] <bleathem> sbryzak: I suggested yesterday we have annotations supported on the interface itself [19:01:12] <Diablo-D3> lincolnthree: yeah, but this implies theres some sort of relation of beans to faces [19:01:24] <bleathem> sbryzak turns out it's a lot easier to just have people use the @ViewPattern("/*") to set global configs [19:01:25] <lincolnthree> that's why I don't like it [19:01:36] <lincolnthree> I prefer XML [19:01:41] <Diablo-D3> yeah but... [19:01:43] <Diablo-D3> I dunno [19:01:45] <lincolnthree> but you said you wanted to get rid of XML [19:01:54] <lincolnthree> You can do this all in Java as well. [19:02:00] <bleathem> sbryzak are you ok with dropping the interface level annotations as global configs? [19:02:09] <Diablo-D3> this is why I refused to use java for the first decade of it's life [19:02:13] <Diablo-D3> this bizzaro obsession with xml [19:02:13] <bleathem> sbryzak maybe we can add it in at a later revision [19:02:14] <lincolnthree> http://ocpsoft.com/docs/prettyfaces/snapshot/en-US/html_single/#ConfigurationProvider [19:02:39] <Diablo-D3> lincolnthree: yeah, but what Im saying is, since jsf is all about using xml namespaces [19:02:52] <Diablo-D3> lincolnthree: why cant I put the faces configuration xml in the file its configuring [19:03:13] <lincolnthree> would be nice [19:03:23] <Diablo-D3> it'd effectively be annotations for xml [19:03:32] <lincolnthree> and then we'd have spring [19:03:34] <lincolnthree> yay! [19:03:42] <Diablo-D3> spring inherently isnt bad [19:03:47] <lincolnthree> nope [19:03:51] <Diablo-D3> its the whole culture around it that screws it over [19:04:11] <lincolnthree> can you explain that? [19:04:15] <lincolnthree> just curious on your thoughts [19:04:23] <Diablo-D3> I dunno, something about it just irks the hell out of me [19:04:35] <Diablo-D3> it feels like Ive wandered into a room full of suits, but I cant see any [19:05:08] <bleathem> Spring places the open word, as in open-source. What the java ecosystem needs are open-standards [19:05:11] <bleathem> it's a different open [19:05:34] <bleathem> Spring is a proprietary solution, despite being open source [19:05:43] <Diablo-D3> exactly [19:05:48] <Diablo-D3> thats exactly whats wrong with it [19:06:04] <Diablo-D3> I couldnt even get past the first few pages of the website [19:06:06] *** balunasj_away has quit IRC [19:06:10] <bleathem> the annoying part is how much they play that open card [19:06:20] <Diablo-D3> and oh holy god is that website ugly [19:06:55] <Diablo-D3> I think Ive been in foss to long or something [19:07:15] <Diablo-D3> I cant handle corporate culture shit [19:07:16] <bleathem> lincolnthree Does Faces have a central way of redirecting navigation? [19:07:29] <lincolnthree> bleathem: what do you mean? [19:07:42] <Diablo-D3> well, isnt that what prettyfaces is for? :D [19:07:43] <bleathem> Do I just call up the nav handler and ask for a redirect [19:08:06] <bleathem> or does Faces provide some simpler way of achieving a redirect [19:08:24] <Diablo-D3> bleathem: faces can redirect from one page to another internally [19:08:25] <bleathem> One think I was thinking of was throwing a redirectRequested event [19:08:42] <bleathem> by Faces, I mean Seam Faces [19:08:48] <lincolnthree> return "view.xhtml?faces-redirect=true" [19:08:50] <Diablo-D3> ahh [19:08:50] <lincolnthree> that's faces [19:08:57] <lincolnthree> bleathem: no it doesn't [19:08:58] <lincolnthree> it shoul [19:08:59] <lincolnthree> d [19:08:59] <bleathem> ok I mean programatically [19:09:05] <lincolnthree> well sure [19:09:12] <bleathem> like authorization fails, redirect to a page [19:09:17] <lincolnthree> navHandler.performNavigation("view" ...) [19:09:25] <Diablo-D3> ... you know what. [19:09:34] <Diablo-D3> this webapp, if/when its done [19:09:36] <bleathem> yeah, that's what I started my question with [19:09:42] <lincolnthree> im half here [19:09:44] <Diablo-D3> is essentially written entirely with jboss software [19:09:46] <bleathem> sorry, poorly phrased [19:09:51] <bleathem> nevermind [19:09:55] <bleathem> I'll jira the idea [19:10:31] <Diablo-D3> its only being tested on jboss as, it uses resteasy and richfaces and prettyfaces (which from what I heard is mutating into a seams module) [19:10:47] <lincolnthree> Diablo-D3: bundled with seam [19:10:51] <bleathem> not mutating [19:10:55] <bleathem> but being used by [19:11:01] <Diablo-D3> still [19:11:18] <Diablo-D3> oracle is probably going to buy redhat now :< [19:11:32] *** alesj has left #seam-dev [19:11:41] * Diablo-D3 puts on his tinfoil hat [19:11:50] <Diablo-D3> everytime Ive come to like something, oracle has managed to screw it over [19:12:07] <Diablo-D3> its a conspiracy. [19:12:41] <lincolnthree> :) [19:19:01] <jbossbot> git [forge] push master 26b6997.. Lincoln Baxter, III SEAMFORGE-82 Maven builds are now embedded, and no longer require mvn to be installed (using 'project build') [19:19:08] <jbossbot> jira [SEAMFORGE-82] Forge should embed maven to prevent need for separate installation [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SEAMFORGE-82 [19:19:08] <jbossbot> git [forge] push master 2ffc805.. Lincoln Baxter, III git verbosity update [19:19:08] <jbossbot> git [forge] push master 0133ca8.. Lincoln Baxter, III tags/branches are now referred to as refs, since they checkout command is the same [19:19:08] <jbossbot> git [forge] push master 13bb029.. Lincoln Baxter, III added missing source folder [19:19:08] <jbossbot> git [forge] push master 8ae2948.. Lincoln Baxter, III SEAMFORGE-83 embedded git [19:19:09] <jbossbot> jira [SEAMFORGE-83] Forge should embed git to prevent need for separate installation [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SEAMFORGE-83 [19:19:09] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/2955858...8ae2948 [19:19:36] <Diablo-D3> alright [19:19:39] <Diablo-D3> Im going to bed [19:19:40] <Diablo-D3> it works [19:19:43] <Diablo-D3> Im happy for now [19:19:45] <lincolnthree> sleep contently! [19:19:51] <Diablo-D3> lets see if I can break something else tommrow [19:19:56] <bleathem> cya [19:20:06] <Diablo-D3> and yes, before anyone asks, I do sleep during the day [19:20:09] <Diablo-D3> its 2pm [19:20:19] <Diablo-D3> night all [19:20:27] <bleathem> good afternoon [19:20:45] <mojavelinux> seam 3 unresolved by name and priorty https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12314289 [19:21:02] <mojavelinux> I encourage anyone to create and share their own filters...sure saves time looking for issues to address [19:21:10] <mojavelinux> and you can add them to your dashboard in jira [19:21:34] <mojavelinux> that filter I created was just a test, we can create something more specific for 3.0.0 if need be [19:24:42] *** Diablo-D3 has quit IRC [19:28:57] <bleathem> Can i throw an exception in JSF that corresponds to a 401 error? [19:30:33] <lincolnthree> https://www.ohloh.net/p/seam3/contributors [19:31:28] <lincolnthree> https://www.ohloh.net/p/seam3 [19:31:33] <lincolnthree> i think it's still importing sources [19:31:37] <lincolnthree> i added all seam 3 git repos [19:32:36] <bleathem> should I sign up for it? [19:32:40] <lincolnthree> meh [19:32:42] <lincolnthree> just did it for fun [19:32:47] <lincolnthree> if you want [19:32:58] <bleathem> can't see a reason to [19:33:06] <bleathem> aside from uploading my picture :P [19:33:15] <lincolnthree> gravitar.com [19:33:20] <lincolnthree> http://gravitar.com [19:33:36] <lincolnthree> now the contributors list is a little more full :) [19:34:12] <lincolnthree> brian. you have 13 commits [19:34:34] <bleathem> http://en.gravatar.com/ you mean! [19:34:39] <lincolnthree> yea [19:37:43] *** tsurdilo1 has joined #seam-dev [19:39:34] <bleathem> response.sendError(401); [19:40:29] *** tsurdilo has quit IRC [19:44:36] <bleathem> it's 4:44 am in Brisbane right now. I don't think sbryzak got my ealier IRC messages! [19:46:34] *** pmuir has quit IRC [19:58:32] <mojavelinux> bleathem: I added a link to the API for each module that has one published [19:58:54] <mojavelinux> good suggestion...in general, we still have some alignment to do of the module pages, since some are being [19:59:01] <mojavelinux> behind the current standard layout [19:59:02] *** sannegrinovero has quit IRC [19:59:06] <mojavelinux> though it's mostly older ones like servlet [20:05:35] *** nickarls has joined #seam-dev [20:08:39] <bleathem> mojavelinux cool thanks! [20:09:35] <bleathem> yeah, who's in charge of that rusty old servlet module anyway! :P [20:10:17] <bleathem> in it's defense, it probably has the most polished package structure of all the modules! [20:10:44] *** cbrock has quit IRC [20:16:57] <mojavelinux> I think that lanyrd.com would make an awesome example application [20:21:56] *** oranheim_ has quit IRC [20:23:13] *** monkeyden has quit IRC [20:25:46] <bleathem> So apparently it *is* bad to put properties in an annotation. Something to do with clinit [20:26:20] <bleathem> too bad, it was a sensible place to put them. [20:26:49] <stuartdouglas> bleathem: I belive that is a compiler bug [20:27:06] <bleathem> any workarounds that you know of? [20:27:12] <stuartdouglas> but a very common one, so it will cause a lot or problems [20:27:17] *** gastaldi has joined #seam-dev [20:27:24] <stuartdouglas> other than 'don't do it' no [20:30:48] <bleathem> is it easy to retrieve the default values from an annotation's properties? [20:31:30] <stuartdouglas> you get the corresponding Method then us Method.getDefaultValue() [20:31:34] <stuartdouglas> or something like that [20:31:51] <stuartdouglas> have a look in annotation instance provider, I think it is used there [20:32:00] <stuartdouglas> AnnotationInstanceProvider I mean [20:32:01] <bleathem> thx [20:35:11] *** bitshuffler has joined #seam-dev [20:35:36] <bleathem> I can't build solder [20:35:47] <bleathem> 'dependencies.dependency.version' for org.jboss.logmanager:jboss-logmanager:jar is missing. @ line 77, column 19 [20:35:53] <mojavelinux> good news, fisheye and jira are linked to github for seam modules [20:36:05] <mojavelinux> that's a removal from dist or parent no doubt [20:36:45] <mojavelinux> go to a project like Seam Faces: https://issues.jboss.org/browse/SEAMFACES [20:36:47] <mojavelinux> then click on Source [20:37:53] <bleathem> I like the one where you click on Source for an issue [20:37:55] <mojavelinux> still missing Social and Validation, waiting on ops [20:38:04] <mojavelinux> yep, really nice :) [20:38:05] <bleathem> and it shows the commits and code changes that relate to that issue [20:38:08] <bleathem> I use that alot [20:40:28] <bleathem> I need advice [20:41:14] <bleathem> I want to have the default initial phase for security restrictions be the default value of the annotation property [20:41:21] <bleathem> but I want to use that value else where [20:41:47] <bleathem> do I store it in two places, once as the default value, and another as a static property (on some other class) [20:42:11] <bleathem> or do I use reflection to look it up everytime? [20:42:27] <bleathem> I guess I could use reflection, and store it in an application scoped producer [20:42:55] <mojavelinux> e-mailed list [20:43:42] <mojavelinux> probably best just to decide what it will be and use it two places [20:43:48] <lightguard_jp> bleathem: That sounds like a good way of doing it. [20:43:48] <mojavelinux> as long as it's documented, it should be fine [20:44:07] <bleathem> ok, I guess it's not like it's going to change [20:44:08] <lightguard_jp> Find it on startup and cache it [20:44:45] <bleathem> hmm, conflicting advice [20:46:51] <mojavelinux> I've added a fisheye link on the Seam Faces module [20:46:55] <mojavelinux> feel free to add it to other modules [20:47:54] <mojavelinux> i think it just might be a little bit of overkill when it's a default we establish (a well-known constant) [20:48:26] <mojavelinux> you aren't violating dry in this case since if you change it, you'd have to change the docs (guide and api docs) and probably examples [20:48:30] *** gastaldi has quit IRC [20:48:59] <mojavelinux> so when you have a case like this, then I think it's okay to reference it in two places...okay, three to four places, now that changes the story [20:49:00] <bleathem> good enough for me [20:49:10] <mojavelinux> man there is a lot of backlog to read, this place is on fire [20:49:14] <mojavelinux> now I have to read twitter and irc [20:49:15] <mojavelinux> and email [20:49:18] <mojavelinux> oh geez [20:49:19] <mojavelinux> hahaha [20:49:38] <mojavelinux> and denis' emails [20:49:49] <bleathem> lol [20:51:38] <lightguard_jp> mojavelinux: It's hard to keep up on [20:51:39] *** cbrock has joined #seam-dev [20:51:39] *** cbrock has quit IRC [20:51:39] *** cbrock has joined #seam-dev [20:51:57] <lightguard_jp> bleathem: If it's something you're doing A LOT cache it, otherwise do what stuartdouglas said and just read it. [20:52:02] *** tsurdilo1 has quit IRC [20:53:03] <bleathem> I could read it, lazily initalising a static property. [20:53:11] <bleathem> best of both worlds maybe. [20:53:24] <lightguard_jp> A static property? [20:53:37] <lightguard_jp> I liked the producer idea [20:53:38] <bleathem> as it is, it's a static right now [20:54:07] <bleathem> i know, statics are bad, but it's an enum constant [20:54:43] <lightguard_jp> True [20:54:57] <lightguard_jp> Just curious why you went with the static [20:55:28] <bleathem> public static final - isn't that how you do shared constants in java? [20:55:51] <bleathem> oh, you meant you were clarifying why you asked... [20:56:26] <lightguard_jp> Yeah [20:56:36] <bleathem> I'm a little underslept at the moment [20:56:47] <lightguard_jp> Yes though, public static final would be the correct way to share constants. [20:56:51] <lightguard_jp> :) [20:57:42] <bleathem> Effective java had a simple way of lazy loading statics [20:57:50] <bleathem> that was thread safe [20:58:29] <lightguard_jp> Still nasty :) [20:58:49] <lightguard_jp> Lock, make it volatile, etc [20:59:35] <stuartdouglas> put it in a static inner class [21:00:11] <stuartdouglas> it won't get loaded till it is referenced, and the JVM takes care of the tread safety for you [21:00:33] <lightguard_jp> stuartdouglas: good idea, hadn't thought of that [21:00:35] <stuartdouglas> otherwise double checked locking is probably the way to go [21:02:06] <lightguard_jp> If you do double checking you have to use volatile [21:02:13] <stuartdouglas> yes [21:02:35] <stuartdouglas> unless the object you are lazily loading has only final fields [21:03:03] * bleathem looks up from Josh's book [21:03:13] <lightguard_jp> True [21:03:19] <bleathem> yeah that's item 71 in eff java 2nd edition [21:05:22] <mojavelinux> arun made the comment on twitter [21:05:25] <mojavelinux> "Trying to run an app on JBossAS6 after using Glassfish3.1 makes you really appreciate Glassfish & OSGi. Dependency conflicts!" [21:05:33] <mojavelinux> um, yes, and it makes me appreciate AS 6 :) [21:05:36] <lightguard_jp> That was a retweet [21:05:49] <lightguard_jp> I was thinking the same thing when I read it [21:06:09] <lightguard_jp> Makes me appreciate an app server that works according to the specs (more often than not) [21:06:20] <lightguard_jp> GF has been a huge thorn in our sides [21:06:56] <mojavelinux> yeah, i mean neither is innocent in all this, but I would think that you don't criticize another when your problems are causing more pain :) [21:06:57] <mojavelinux> hehehe [21:08:00] <lightguard_jp> I'm pretty sure the OP wasn't doing anything like we were [21:08:18] <lightguard_jp> Probably having issues with things like hibernate vs eclipselink, jsf versions, etc [21:10:30] <mojavelinux> yeah, likely [21:21:49] <bleathem> flogging a dead horse now, but this is interesting... [21:21:59] *** gastaldi has joined #seam-dev [21:22:05] <bleathem> how about forgoing the lazy part, and just using a static initilizer: [21:22:08] <bleathem> http://pastie.org/1701218 [21:24:08] *** gastaldi has left #seam-dev [21:26:41] <lightguard_jp> That will probably work too [21:29:04] <bleathem> response.sendError(401); isn't doing it for me [21:32:31] <mojavelinux> what response are you using? [21:34:05] <bleathem> 1 sec, I was following the wrong logic branch [21:34:20] <bleathem> (using: HttpServletResponse response = (HttpServletResponse) facesContext.getExternalContext().getResponse();) [21:34:46] <bleathem> sweet it works [21:35:05] <bleathem> I threw in a facesContext.responseComplete(); for good measure [21:35:24] <mojavelinux> I was about to suggest that [21:35:48] <bleathem> I now go to a 401 page if no @LoginViewId is specified, otherwise I redirect to @LoginViewId.value [21:36:17] <bleathem> Gonna have to store the initially requested viewId somewhere [21:36:26] <mojavelinux> I think you want ExternalContext#setResponseStatus(401); [21:36:35] <bleathem> yes, that's better! [21:36:37] <mojavelinux> the idea of external context is that it allows faces to work in a portal [21:36:44] <mojavelinux> if you cast to HttpServletResponse you break that [21:37:05] <mojavelinux> I have to admit that I don't really know all the portlet rules, because I find portlets unteresting personally [21:37:24] <mojavelinux> but, it's important if you are working on the faces module to either respect the rules, or to decide one way or another [21:37:30] <mojavelinux> if you don't, you'll get a lot of complaining :) [21:37:31] <mojavelinux> hehehe [21:37:49] <mojavelinux> rule #1 is don't cast to HttpServlet anything [21:37:53] <bleathem> no reason to break the rules for no reason [21:38:08] <lightguard_jp> mojavelinux: unteresting -- inventing new words? [21:38:16] <mojavelinux> blah [21:38:32] <mojavelinux> I don't type as well on this keyboard, the keys are too wide [21:39:52] <bleathem> mojavelinux: [21:39:55] <bleathem> I suggested yesterday we have annotations supported on the interface itself [21:39:57] <bleathem> turns out it's a lot easier to just have people use the @ViewPattern("/*") to set global configs [21:39:59] <bleathem> are you ok with dropping the interface level annotations as global configs? [21:40:00] <bleathem> maybe we can add it in at a later revision [21:40:18] <bleathem> ( I asked this earlier of sbryzak, but I think he was sleeping at the time!) [21:51:25] <jbossbot> git [forge] push master 4d1da2e.. Lincoln Baxter, III SEAMFORGE-84 [21:51:26] <jbossbot> jira [SEAMFORGE-84] Forge distributed plugin system should support cloning and building a git/mvn project to be installed as a plugin [Closed (Done) Enhancement, Major, Lincoln Baxter III] https://issues.jboss.org/browse/SEAMFORGE-84 [21:51:26] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/8ae2948...4d1da2e [21:51:52] <lincolnthree> Start writing your plugins ;) [21:52:07] <lincolnthree> The Forge is about to catch fire. [22:05:59] * nickarls confesses he has never used Forge ;-) [22:06:08] <nickarls> and ducks [22:06:45] <lightguard_jp> It's okay, nor have I [22:25:28] <mojavelinux> bleathem: that's fine [22:25:35] <mojavelinux> I know you were asking about the use of enum vs interface [22:25:41] <bleathem> yeah, that too [22:26:08] <mojavelinux> as I mentioned, you could annotate an interface and then have any number of enums on it [22:26:22] <mojavelinux> then you don't need the @ViewConfig on the enum, but rather on the interface [22:26:27] <mojavelinux> so like [22:26:41] <bleathem> have a look at Pete's comment at the end of: http://seam-framework.2283336.n4.nabble.com/Replacing-pages-xml-td3272512.html [22:26:48] <mojavelinux> k [22:27:07] <bleathem> he indicated a weld extension should/might be possible to support enum scanning by weld [22:27:23] <bleathem> "We can't do it in plain CDI, but a portable extension can be written to do this (well, it can be added to Weld extensions)." [22:27:48] <lightguard_jp> It wouldn't be portable [22:28:35] <bleathem> a portable extension wouldn't be portable? [22:28:58] <lightguard_jp> I doubt you could add types to be scanned in a portable way. [22:29:08] <lightguard_jp> maybe though [22:29:48] <lightguard_jp> I don't think enums would work though. They're classes, but all final and you can't do anything with them unless you pull out the bytecode manipulator [22:29:51] <mojavelinux> it would be something we would need in cdi 1.1 [22:30:08] <lightguard_jp> Yeah, it would be nice in CDI 1.1 if it works [22:30:09] <bleathem> we don't need to do anything with the enums [22:30:15] <bleathem> just reference them [22:30:20] <lightguard_jp> Ah [22:30:52] <mojavelinux> basically, my idea is to use a wrapper interface [22:30:53] <bleathem> With embedding the enums inside the interface, referencing them would be a bit of a pain [22:30:57] <mojavelinux> but then you can use the enum inside of it [22:31:12] <mojavelinux> not if it's static [22:31:13] <bleathem> but at least they would be referenceblt [22:31:18] <mojavelinux> then you can just import the enum [22:31:19] <bleathem> ^referencable [22:31:28] <bleathem> right [22:31:40] <mojavelinux> basically, we just need a container to cheat a little bit [22:31:50] <bleathem> do you think it's worth it? [22:31:54] <mojavelinux> let's get a pastie [22:34:05] <bleathem> http://pastie.org/1701507 [22:34:08] <bleathem> top vs. bottom [22:34:47] <bleathem> (That top one is from a working example!) [22:35:36] <bleathem> on pastire.org: "All your pastes are belong to us." lincolnthree would get a kick out of that [22:35:58] <lincolnthree> lol. nice [22:36:46] <mojavelinux> "All that is necessary for the triumph of evil is that good men do nothing. Do something." [22:36:49] <mojavelinux> amen brother [22:38:06] <bleathem> profound statement [22:38:17] <bleathem> tweetworthy [22:38:24] <mojavelinux> lincoln, get on that [22:39:02] <lightguard_jp> Who said that? [22:39:20] <mojavelinux> as seen on pastie [22:40:11] <bleathem> I see, it's a random quote: [22:40:12] <bleathem> Use Pastie in your quest to save humanity, not in your evil plots to take over the world! [22:40:14] <lightguard_jp> Hm, disputed [22:40:20] <lightguard_jp> http://en.wikiquote.org/wiki/Edmund_Burke [22:40:36] <bleathem> Be nice. :-) Use Pastie for good, not evil. [22:40:50] <bleathem> any thoughts on the enum debacle? [22:43:36] <bleathem> Aside from this issue, I think seamfaces-33 is otherwise ready for the Seam security integration [22:44:22] * mojavelinux is testing something [22:46:07] <bleathem> looking at SEAMFACES-103 [22:46:09] <jbossbot> jira [SEAMFACES-103] Create an api for doing a redirect to another view [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-103 [22:46:14] <mojavelinux> just as I suspected [22:46:21] <mojavelinux> the public is not required on "static enum" [22:46:27] <bleathem> Why advantage does this provide other than using the navigation handler? [22:46:38] <mojavelinux> the navigation handler requires a rule [22:46:44] <lightguard_jp> public isn't needed in an interface [22:46:53] <lightguard_jp> Everything declared in an interface is public [22:46:54] <mojavelinux> I wasn't sure if it applied to statics [22:47:03] <bleathem> ok, verbosity-- [22:47:49] <mojavelinux> we can put some scenarios in the issue report, see what is required in each case [22:47:56] <mojavelinux> and see if it's sufficient [22:48:03] <mojavelinux> see if it's digestable [22:48:13] <bleathem> (SF-103) but with implicit navigation, you don't need rules [22:48:19] <bleathem> ok [22:48:37] <mojavelinux> yeah, but implicit navigation has catches [22:48:53] <mojavelinux> for one, it's slower and jsf still treats it as a developer mode option [22:49:04] <mojavelinux> it's still a second class citizen in my mind [22:49:26] <bleathem> didn't know it was slower! [22:49:42] <mojavelinux> and by that I mean if you look in the source code, it's treated as like a fallback error scenario (or warning scenario) [22:50:00] <mojavelinux> i'd link you to the source code if mojarra was online anywhere [22:50:23] <bleathem> That article in SF-103 almost looks like a torpedo against jsf [22:50:32] <bleathem> for most people the nav handler is enough [22:50:32] <mojavelinux> to put it simpler, it's a catchall [22:50:43] <bleathem> the article makes it look really complicated :P [22:51:04] <bleathem> something for the wicket guys to hold up and say "see!" [22:51:19] <bleathem> (not to pick on the wicket guys!) [22:51:45] <bleathem> I guess the key is in the title "Efficient way to..." [22:51:56] <bleathem> I was thinking we could handle this by throwing an event [22:52:09] <bleathem> a "RedirectRequestedEvent" [22:52:12] <bleathem> or something like that [22:52:24] <bleathem> easy for developers to tap into [22:52:47] <mojavelinux> true...SendRedirectEvent [22:52:56] <bleathem> but then, navigation in jsf isn't really an event based thing [22:53:01] <bleathem> might feel out of place [22:53:25] *** cbrock has quit IRC [22:53:35] <mojavelinux> another way to go about it [22:53:39] <mojavelinux> is to make it part of view config [22:53:43] <mojavelinux> so that you can return a redirect [22:53:57] <mojavelinux> the main issue with the navigation system in jsf is that I absolutely refuse to use XML for it [22:54:07] <mojavelinux> I Hate that crap, it's so strutsy [22:54:16] <mojavelinux> once I saw wicket, I was like...done [22:54:19] <mojavelinux> that's what I want [22:54:28] <mojavelinux> for page flow, it's okay [22:54:33] <mojavelinux> that actually makes some sense [22:54:36] <bleathem> I should look more at wicket. For inspiration. [22:54:50] <mojavelinux> but for just programmatic navigation, the xml is so horrible [22:54:52] <mojavelinux> wicket in action [22:54:55] <mojavelinux> you'll enjoy it [22:55:01] <mojavelinux> I don't think it will make you hate jsf so much as respect it [22:55:04] <mojavelinux> and what it can be [22:55:05] <bleathem> will have to pick it up [22:55:22] <mojavelinux> super good ideas in there [22:55:30] <bleathem> JSF is something wicket can never be [22:55:53] <mojavelinux> I think if they boxed, they would just go so many rounds the crowd would leave [22:56:04] <mojavelinux> and they would be both a bloody pulp [22:56:14] <bleathem> lol [22:56:32] <bleathem> wicket is to JSF as Spring is to JavaEE [22:56:46] <bleathem> it's the open standard that's important [22:57:07] <mojavelinux> I personally think that wicket should become a jsr, after reading wicket in action [22:57:08] <bleathem> We (as part of the JSF community) just have to make sure that it gets better. [22:57:16] <mojavelinux> it's clear that they are distinct enough in approach that you need both [22:57:23] <bleathem> cool [22:57:34] <mojavelinux> and then, they can definitely share bits [22:57:39] <mojavelinux> like converters don't have to be done twice [22:57:44] <mojavelinux> we should just have one conversation framework [22:58:02] <lightguard_jp> Lincoln's been saying that for awhile. [22:58:12] <bleathem> makes good sense! [22:58:14] <mojavelinux> yeah, I'm all for it, seam-convert [22:58:32] <mojavelinux> or I guess, seam-conversion to align with validation [22:58:42] <mojavelinux> though I still like seam-validate (shhh, you didn't hear that from me) [22:58:57] <mojavelinux> anyway, I like the enums for now [22:58:58] <lightguard_jp> We have seam-validate [22:59:13] <mojavelinux> for one, it saves us from having to do extra proxying work, and that's good (for using them) [22:59:22] <mojavelinux> for using them programatically [22:59:29] <mojavelinux> btw, the redirect could be done using a @ViewConfig [22:59:45] <mojavelinux> you just have an enum that configures a redirect [22:59:57] <mojavelinux> as an idea [23:00:12] <bleathem> That's a bit along the lines of what @LoginViewId and AccessDeniedViewId are doing [23:00:24] <bleathem> but for specific cases [23:02:04] <mojavelinux> yep, just plugging in the hooks [23:06:08] <mojavelinux> so move forward with the enums for now? [23:06:18] <mojavelinux> what's cool is that you can inject into the interface [23:06:26] <mojavelinux> wait, that would only work if you had an instance [23:06:29] <mojavelinux> of the enum [23:06:50] <mojavelinux> hmmm, we'll see about conditional logic, that might come in a separate jira [23:07:25] *** tsurdilo has joined #seam-dev [23:07:37] *** bitshuffler has quit IRC [23:12:15] <mojavelinux> i gotta run soon, you set with the approach bleathem? [23:14:32] <sbryzak> morning everyone [23:14:45] <lightguard_jp> sbryzak: Morning [23:15:23] <mojavelinux> that's my sign for dinner hahaha [23:15:24] <mojavelinux> :) [23:15:32] *** wdrai has joined #seam-dev [23:16:09] <bleathem> mojavelinux all set! [23:16:17] <bleathem> Good afternoon sbryzak! [23:16:18] <sbryzak> need...coffee... [23:23:09] *** tsurdilo1 has joined #seam-dev [23:24:46] <jbossbot> git [dist] push master d243281.. Shane Bryzak added more contributor names [23:24:47] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/1cd02c7...d243281 [23:24:59] *** clerum has quit IRC [23:26:50] *** tsurdilo has quit IRC [23:39:36] *** PeteRoyle has joined #seam-dev [23:44:24] <bleathem> Arranging travel to JUDCon [23:44:34] <bleathem> is there only one airportin Boston?