[00:01:28] <bleathem> the vanpool calls
[00:01:31] <bleathem> later all
[00:01:35] <lightguard_jp> later
[00:01:41] *** bleathem has quit IRC
[00:14:59] *** lightguard_jp has quit IRC
[00:29:54] *** wdrai1 has joined #seam-dev
[00:31:38] *** wdrai has quit IRC
[00:33:03] <sbryzak> mojavelinux: ping
[00:42:30] *** johnament has joined #seam-dev
[00:48:05] <johnament> nickarls: ping
[00:54:14] *** stuartdouglas has left #seam-dev
[00:59:52] *** tsurdilo1 has quit IRC
[01:08:51] *** lincolnthree has quit IRC
[01:09:00] *** lincolnthree has joined #seam-dev
[01:11:05] *** lincolnthree has left #seam-dev
[01:15:42] <johnament> what time is the meeting now? still 2100 utc?
[01:17:26] *** wdrai has joined #seam-dev
[01:18:18] <sbryzak> johnament: i've set you up with github rights for the seam/jms module
[01:18:26] *** wdrai1 has quit IRC
[01:18:33] <sbryzak> johnament: looks like mojavelinux already updated the module page, he's quick ;)
[01:19:03] <johnament> yeesh
[01:19:09] <johnament> sbryzak: now i feel like a grave robber
[01:19:15] *** gastaldi has joined #seam-dev
[01:19:24] <sbryzak> johnament: hehe, why?
[01:19:28] <gastaldi> hey !
[01:19:46] <johnament> gastaldi: hola!
[01:20:04] <gastaldi> hehe johnament: Hola ! Que tal ?
[01:20:06] <johnament> sbryzak: i just looked, looks like mojavelinux updated it before 3pm today.
[01:21:38] <sbryzak> johnament: i guess he assumed you'd agree :)
[01:21:56] <gastaldi> hey PeteRoyle !
[01:22:03] <gastaldi> Are you the Seam Cron man ?
[01:22:06] <johnament> sbryzak: actually, i think there's a bug on sfwk.
[01:22:19] <johnament> sbryzak: when i diff rev 50 (current) and rev 49 (previous) i get an api change.
[01:22:22] <sbryzak> johnament: only one?
[01:22:27] <johnament> lol
[01:22:27] <gastaldi> Can I help on those open issues ?
[01:22:31] <daniel_hinojosa> Hey everyone, is there a way to make change or change requests to documentation?
[01:22:45] <johnament> daniel_hinojosa: send a pull request or issue!
[01:22:53] <gastaldi> If only they were placed on Github...
[01:22:56] <sbryzak> daniel_hinojosa: certainly, raise a JIRA and (optionally) a pull request
[01:23:01] <daniel_hinojosa> I would, but they're not on github
[01:23:05] <johnament> sbryzak: rev 50 vs. rev 48 shows the user change.
[01:23:09] <johnament> daniel_hinojosa: seam 2?
[01:23:14] <daniel_hinojosa> 3
[01:23:21] <daniel_hinojosa> johnament: 3
[01:23:29] <sbryzak> daniel_hinojosa: which docs?
[01:23:46] <daniel_hinojosa> sbryzak: Some of the web docs I am reading as reference
[01:23:49] <johnament> there's something seam 3 not in git? O_o
[01:24:03] <sbryzak> you mean on sfwk.org?
[01:24:21] <daniel_hinojosa> sbryzak: Some stuff is incorrect, just slightly I haven't seen anything major
[01:24:39] <johnament> there's something seam 3 not in git? O_o
[01:24:39] <sbryzak> url?
[01:24:49] <daniel_hinojosa> sbryzak: Kind of the reason that I'd rather just fix it than make it an entire process.
[01:25:30] *** aslak has quit IRC
[01:25:44] <sbryzak> daniel_hinojosa: got an example?
[01:26:07] <daniel_hinojosa> sbryzak: Yes.
[01:27:19] <daniel_hinojosa> sbryzak: Ok, http://docs.jboss.org/seam/3/servlet/latest/reference/en-US/html_single/#events.servlet_request_lifecycle_events
[01:27:30] <gastaldi> johnament: I created a branch on my fork of Seam JCR with some refactoring done on Repository injection
[01:28:24] <daniel_hinojosa> sbryzak: the filter class is wrong for catch
[01:29:15] <daniel_hinojosa> sbryzak: org.jboss.seam.servlet.CatchExceptionFilter should be org.jboss.seam.servlet.exception.CatchExceptionFilter
[01:29:39] <sbryzak> daniel_hinojosa: the source is here: https://github.com/seam/servlet/blob/master/docs/src/main/docbook/en-US/servlet-events.xml
[01:29:58] <sbryzak> if you submit a pull request and let dan know, he'll merge your patch
[01:30:43] <johnament> gastaldi: ok
[01:30:50] <johnament> ugh, i have to restart 200 stores.
[01:30:53] <daniel_hinojosa> sbryzak: Oh, so there is documentation on github!
[01:31:05] <sbryzak> certainly is
[01:31:05] <daniel_hinojosa> sbryzak: Is that a standard on all modules?
[01:31:10] <sbryzak> yes
[01:31:15] <sbryzak> they all follow the same structure
[01:31:20] <gastaldi> cool huh ?
[01:31:34] <gastaldi> These people from Seam 3 really rock !
[01:31:44] <daniel_hinojosa> sbryzak: Ah, someone told me it wasn't on github, or I misinterpreted what they said
[01:31:47] <sbryzak> not really, it's our tools that rock
[01:31:56] <sbryzak> daniel_hinojosa: slap them
[01:32:06] 
[01:32:07] <gastaldi> :P
[01:32:18] <gastaldi> But the Module front page is not on Github, right ?
[01:33:39] <daniel_hinojosa> sbryzak + gastaldi : Oh that's probably what it was.  The front pages.  We'll from an email I think there was talk about making those pages as lean as possible.
[01:34:17] <gastaldi> yeah
[01:34:31] <daniel_hinojosa> sbryzak + gastaldi :  So now it all makes sense why the docs should be more on the github than on the website.
[01:34:56] <gastaldi> agreed
[01:34:57] <sbryzak> which front page are you guys referring to?
[01:35:10] <gastaldi> The ones on seamframework.org
[01:35:24] <sbryzak> oh, for the modules?
[01:35:27] <gastaldi> yeah
[01:35:33] <sbryzak> e.g. http://www.seamframework.org/Seam3/FacesModule ?
[01:35:41] <sbryzak> no they're not on github
[01:35:45] <sbryzak> it doesn't make sense to put them there
[01:35:48] <daniel_hinojosa> sbryzak + gastaldi: yeah or this one : http://seamframework.org/Seam3/PersistenceModule
[01:35:58] <gastaldi> sbryzak: why not ?
[01:36:15] <sbryzak> gastaldi: because they're not supposed to be documentation
[01:36:26] <daniel_hinojosa> Well take a look at the persistence one I sent, that's quite a heavy page.
[01:36:28] <gastaldi> :P
[01:36:31] <sbryzak> basically just a landing page that points you to relevent information about the module
[01:36:48] <sbryzak> there's way too much information on that page
[01:36:59] <sbryzak> we'll most likely trim them right down after the final release
[01:37:04] <daniel_hinojosa> sbryzak: Got it, so that's not the norm
[01:37:13] <sbryzak> up to this point they've kind of been used as a drawing board
[01:37:34] <sbryzak> but honestly i think something like google wave would have been more suitable for a collaborative design process
[01:38:01] <daniel_hinojosa>  sbryzak: So I will just report here or on JIRA if I find issue with the landing pages, and I will just do a pull req for core module docbook stuff.
[01:38:20] <gastaldi> sbryzak: Yeah, if google wave were not a total failure  :)
[01:38:39] <sbryzak> daniel_hinojosa: yep, JIRA is good for module page issues
[01:38:47] <daniel_hinojosa> I loves the google wave.  Underappreciated.
[01:38:49] <daniel_hinojosa> thanks sbryzak + gastaldi
[01:38:55] <sbryzak> daniel_hinojosa: pull request, then hound the module lead for doc updates
[01:39:08] <sbryzak> gastaldi: i don't think it was a failure, just misunderstood
[01:39:13] <daniel_hinojosa> sbryzak: aye aye
[01:39:14] <gastaldi> could be
[01:39:32] <sbryzak> and they're relaunching it as something you can download and install on your local server
[01:39:44] <gastaldi> Personally it is a great idea
[01:39:57] <gastaldi> But focused on the wrong people
[01:40:41] <PeteRoyle> gastaldi: yessir!
[01:40:53] <gastaldi> PeteRoyle: There is a pull request for you :)
[01:41:15] <gastaldi> PeteRoyle: on Seam Cron
[01:42:20] <PeteRoyle> gastaldi: right. guess that means it's time I learned how to use git :)
[01:43:38] <gastaldi> PeteRoyle: No worries, I am learning too
[01:44:20] <PeteRoyle> hah, well spotted :)
[01:44:29] <gastaldi> :)
[01:45:12] <PeteRoyle> Maybe I shouldv'e added that hour-long unit test after all :P
[01:45:36] <gastaldi> lol
[01:45:55] <gastaldi> is github slow or is just me ?
[01:46:55] <gastaldi> sbryzak: You already solved SEAMFACES-111
[01:47:03] <jbossbot> jira [SEAMFACES-111] TransactionPhaseListener @Requires refactored TransactionExtension [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/SEAMFACES-111
[01:49:56] <sbryzak> gastaldi: thanks, i'll close it
[01:53:40] <johnament> sbryzak: so... i'm going to push stuff into master for JMS.  Martin's already been toying with what I have, when do you think we should do a JMS release and what should it be named?
[01:54:00] <sbryzak> we should look at it after the final
[01:54:05] <sbryzak> i'd still call it 3.0.0.Final
[01:54:14] <sbryzak> to align it with the other modules
[01:54:19] <johnament> final?
[01:54:26] <johnament> no beta/cr ?
[01:54:46] <sbryzak> well yeah, create whichever pre-releases you require for QA :)
[01:55:24] <johnament> well, everything on the module homepage is done. and almost all of the JIRAs are done at this point.
[01:55:32] <johnament> API wise it should be complete.
[01:55:36] <johnament> so Beta1?
[01:55:49] <sbryzak> sounds good to me
[01:57:45] *** jose_freitas has joined #seam-dev
[01:57:59] <jose_freitas> evening
[01:58:45] *** kenfinnigan has joined #seam-dev
[01:59:48] <gastaldi> evening jose_freitas !
[02:00:29] 
[02:00:58] <jose_freitas> well
[02:01:02] 
[02:01:03] <jose_freitas> hehehe
[02:01:04] 
[02:01:06] <johnament> kenfinnigan: hey!
[02:01:13] <kenfinnigan> hey johnament
[02:01:21] <jose_freitas> I exchanged this day with a day in carnival
[02:01:31] <gastaldi> nicely done
[02:01:31] <johnament> kenfinnigan: so nickarls ' issue is that he's missing the necessary bundle files.
[02:01:50] <kenfinnigan> isn't it more than just that?
[02:02:05] <johnament> kenfinnigan: no, the error I get is because the bundle named foo does not exist.
[02:02:08] <jose_freitas> hey kenfinnigan!
[02:02:18] <kenfinnigan> hey jose_freitas
[02:03:06] <kenfinnigan> have been making some slight changes to that code anyway
[02:03:23] <kenfinnigan> I have found problems in injection the application scoped bundles into the request scoped
[02:03:32] <kenfinnigan> sometimes it is null in my arquillian tests
[02:05:31] *** jose_freitas has quit IRC
[02:06:03] <johnament> really?
[02:07:41] <kenfinnigan> I had written a test that put a bundle and then gets it in the next line of the test
[02:07:54] <kenfinnigan> the first call had a non null application scoped bundle
[02:08:04] <kenfinnigan> the get failed on a null pointer because it was null
[02:08:44] *** bleathem has joined #seam-dev
[02:09:14] <johnament> stacktrace?
[02:09:21] <johnament> or code?
[02:09:38] <johnament> BTW - warning. code's going into JMS, possible flood.
[02:10:23] *** gastaldi has quit IRC
[02:10:23] <jbossbot> git [jms] push master c12a9b1.. John Ament SEAMJMS-15 Added ARM support.
[02:10:27] <jbossbot> jira [SEAMJMS-15] Support automatic resource management for a few closeable types [Resolved (Done) Feature Request, Major, John Ament] https://issues.jboss.org/browse/SEAMJMS-15
[02:10:28] <jbossbot> git [jms] push master 9cd12be.. John Ament SEAMJMS-3 For egress, added additional API to Route and RouteImpl.
[02:10:28] <jbossbot> jira [SEAMJMS-3] Event Mapping Observer Method Interfaces - Egress [Resolved (Done) Feature Request, Blocker, John Ament] https://issues.jboss.org/browse/SEAMJMS-3
[02:10:29] <jbossbot> git [jms] push master d8646ce.. John Ament SEAMJMS-3 Added observer support for interfaces defined with methods that have @Observes.
[02:10:29] <jbossbot> git [jms] push master 79b5701.. John Ament SEAMJMS-15 Added disposers for built in producers.
[02:10:29] <jbossbot> git [jms] push master 7b0a133.. John Ament SEAMJMS-3 Fixed a bug in the test case.
[02:10:29] <jbossbot> git [jms] push master 83c8f4e.. John Ament Fixed code to work with ingress listeners.
[02:10:29] <jbossbot> git [jms] push master 0d88b31.. John Ament SEAMJMS-3 and SEAMJMS-4.  Added support for explicitly adding routes to only a single route type (egress vs. ingress).
[02:10:30] <jbossbot> jira [SEAMJMS-4] Event Mapping Observer Method Interfaces - Ingress [Resolved (Done) Feature Request, Blocker, John Ament] https://issues.jboss.org/browse/SEAMJMS-4
[02:10:30] <jbossbot> git [jms] push master 5d23241.. John Ament Modified code base to be able to support dynamic qualifiers based on feedback from Pete Muir.
[02:10:30] <jbossbot> git [jms] push master b084850.. John Ament Moved code that was bound to request scoped to be dependent.  Fixed TCCL issue.  Added preloading support for destinations....
[02:10:31] <jbossbot> git [jms] push master 1f2890d.. John Ament If qualifiers are empty, set the observed qualifiers to be default.
[02:10:31] <jbossbot> git [jms] push master b7f3eab.. John Ament Added log message.
[02:10:32] <jbossbot> git [jms] push master 717b3b3.. John Ament Attempting to clean up test cases.
[02:10:54] <kenfinnigan> NPE in Bundles.get()
[02:13:45] <bleathem> sbryzak calling Security!
[02:13:56] <PeteRoyle> I'm not sure I even have write access to the new git repo. mojavelinux do you know how I can check?
[02:14:00] <sbryzak> bleathem: i'm here
[02:14:15] <sbryzak> PeteRoyle: what's your github username?
[02:14:22] <PeteRoyle> peteroyle
[02:14:35] <johnament> PeteRoyle: if you visit the module in github, you'll see a native protocol type of url instead of https
[02:14:43] <bleathem> have you had a chance to look at creating a way to retrieve the #Secures methods for a list of @SecurityBindingType annotations?
[02:14:57] <PeteRoyle> nah i get https
[02:15:24] <sbryzak> PeteRoyle: just added you, it should work now
[02:15:44] <PeteRoyle> sorted, thanks
[02:16:55] <sbryzak> bleathem: no, but is that what you really need?
[02:17:05] <bleathem> don't know
[02:17:16] <sbryzak> bleathem: from a consumer point of view, you really just need the event
[02:17:19] <bleathem> I fire an event, with a list of SecurityBindingType annoations
[02:17:48] <sbryzak> give me half an hour and i'll have something written
[02:17:55] <bleathem> ok
[02:19:57] <PeteRoyle> sbryzak I don't suppose you could also add me to https://github.com/weld/core/tree/master/environments/se while you're at it?
[02:20:01] <PeteRoyle> (pls :) )
[02:20:17] <sbryzak> i don't have that power, sorry
[02:20:24] <PeteRoyle> k no probs :)
[02:20:44] <PeteRoyle> mojavelinux, do you have the power?
[02:21:41] <sbryzak> PeteRoyle: you need to talk to pmuir or alesj
[02:21:54] <PeteRoyle> ok will do, thx
[02:27:27] <PeteRoyle> right, gastaldi that's in. Thanks :)
[02:28:33] <jbossbot> git [international] push master 0bb11cd.. Ken Finnigan SEAMINTL-33 Bundles injections are null
[02:28:34] <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
[02:28:35] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/5fb0e18...0bb11cd
[02:35:33] *** wdrai has left #seam-dev
[02:38:23] <jbossbot> git [jms] push master 7d99c8e.. John Ament Removed file.
[02:38:23] <jbossbot> git [jms] push master URL: http://github.com/seam/jms/compare/6a2bb15...7d99c8e
[02:38:38] <jbossbot> git [security] push master 459490a.. Shane Bryzak SEAMFACES-33
[02:38:39] <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:38:39] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/35bafc3...459490a
[02:38:49] <sbryzak> bleathem: i just checked in a new event class called AuthorizationCheckEvent
[02:42:31] <bleathem> ok
[02:42:42] <bleathem> I'll try it out
[02:43:38] <jbossbot> git [international] push master c4affd2.. Ken Finnigan SEAMINTL-34 BundleTemplateMessage should use @Client Locale
[02:43:38] <jbossbot> jira [SEAMINTL-34] BundleTemplateMessage always using Application Locale to retrieve bundles [Open (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-34
[02:43:39] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/0bb11cd...c4affd2
[02:46:11] <sbryzak> bleathem: i haven't written the observer yet, however you could mock one for testing purposes
[02:46:55] <bleathem> yeah, I've got an event/observer mocked out tested already.  I'll repeat with the new event however
[02:47:31] <bleathem> ^ignore the word "tested"
[02:47:38] <bleathem> I don't know why it's there
[02:48:26] <johnament> so you didn't test it yet?
[02:48:48] <bleathem> got it
[02:48:56] <bleathem> put an "and" before the word "tested"
[02:49:03] <bleathem> that makes more sense!
[02:49:13] <johnament> so you no longer deny testing
[02:49:35] <bleathem> I'm not denying anything!
[02:49:43] <sbryzak> now we know who the resident grammar nazi is ;p
[02:49:45] <bleathem> I deny denying anything!
[02:51:26] <bleathem> you can pick up your badge here: http://bit.ly/fA7JKp
[02:51:37] <bleathem> oh nevermind
[02:51:42] <bleathem> sill google images
[02:51:51] <johnament> woo hoo! seam jms build 248 was successful :-)
[02:52:25] <johnament> http://www.google.com/imgres?imgurl=http://www.toothpastefordinner.com/081005/grammar-police-arrest-this-man.gif&imgrefurl=http://www.toothpastefordinner.com/archives/2005/Aug/&usg=__jQWCGhp73MOYD0w93ILWzy9qHdM=&h=454&w=516&sz=30&hl=en&start=0&zoom=1&tbnid=IE3oLKtUwb-jiM:&tbnh=122&tbnw=139&ei=TFKJTYLkJ-S10QGBtcW_Dg&prev=/images%3Fq%3Dgrammar%2Bpolice%26um%3D1%26hl%3Den%26client%3Dfirefox-a%26sa%3DX%26rls%3Dorg.mozilla:en-US:offici
[02:52:25] <johnament> al%26biw%3D1920%26bih%3D975%26tbs%3Disch:1&um=1&itbs=1&iact=hc&vpx=492&vpy=114&dur=32&hovh=211&hovw=239&tx=139&ty=126&oei=TFKJTYLkJ-S10QGBtcW_Dg&page=1&ndsp=73&ved=1t:429,r:3,s:0
[02:52:32] <bleathem> Looking at your event sbryzak
[02:52:56] <johnament> that one is a double benefit - officer jenkins :-)
[02:53:05] <bleathem> how will you differentiate between login required, and autorization failed?
[02:53:27] <sbryzak> you need to make that determination
[02:53:31] <sbryzak> and redirect accordingly
[02:54:06] <bleathem> so if they are not logged, I redirect them to a log in page.  If they are logged in, Then it's an authorization thing
[02:54:08] <bleathem> got it
[02:55:38] <bleathem> Why use an array (Annotation[]) instead of a Collection for the bindings?
[02:56:12] <sbryzak> i can change it if you like
[02:58:08] <jbossbot> git [security] push master bc5faf8.. Shane Bryzak use a Collection
[02:58:08] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/459490a...bc5faf8
[02:58:16] <sbryzak> bleathem: get the latest again, i've updated it
[02:58:17] <bleathem> So far I've been working with List<? extends Annotation>
[02:58:20] <bleathem> ok
[02:58:51] <sbryzak> ah ok, wait one sec and i'll modify it again
[02:58:58] <sbryzak> that way we'll have conformity :)
[02:59:41] <jbossbot> git [security] push master f3fcc2a.. Shane Bryzak change to List
[02:59:41] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/bc5faf8...f3fcc2a
[02:59:44] <sbryzak> bleathem: done
[03:00:07] <bleathem> right on, thx
[03:03:59] <bleathem> sbryzak, so you're taking care of wiring up the list of Bindings to thei @Secures method?
[03:05:05] <sbryzak> the extension does that, you just need to worry about raising the event
[03:05:26] <bleathem> That's done already?
[03:05:49] <sbryzak> i'm working on the event observer now
[03:05:53] <bleathem> ok cool
[03:06:02] <johnament> what if the event gets sent over JMS?
[03:06:21] <bleathem> also, is it safe to assume all @SecurityBindingType require a the user to be logged in?
[03:06:43] <sbryzak> nope, you can't assume that
[03:07:05] *** kuuyee has joined #seam-dev
[03:07:16] <bleathem> but if the check fails, and they are not logged in, I can assume they need to be log in?
[03:07:38] <sbryzak> yep, and redirect them to the login page
[03:08:03] <bleathem> so they log in, and try again, and might still fail
[03:08:13] <bleathem> ok
[03:08:17] <sbryzak> yep, in which case they then get redirected to an error page
[03:08:27] <bleathem> right
[03:09:12] <johnament> sbryzak: does everything in security revolve around firing events?
[03:09:41] <sbryzak> johnament: no, but i think it's a good solution for view security because it's decoupled
[03:10:02] <sbryzak> it can be re-used for gwt, wicket, etc
[03:10:11] <johnament> sbryzak: agreed. i'm just wondering what happens if you accidentally receive an async event.
[03:10:31] <sbryzak> accidentally?
[03:11:15] <johnament> suppose someone binds a security event to JMS's routing api.
[03:11:45] <bleathem> who would use JMS?
[03:11:47] <bleathem> j/k
[03:12:18] <sbryzak> the scope for this is bound to view technology integration
[03:12:31] <sbryzak> as long as bleathem doesn't accidentally send me an async event, we'll be fine ;)
[03:12:47] <bleathem> lol
[03:12:55] <johnament> sbryzak: but to both the caller and receiver, they can be blind to whether it was async or not.
[03:13:12] <sbryzak> the caller and receiver are well defined in this use case
[03:13:24] <bleathem> but what would happen is Security would evaluate the authorization, and set the passed property of the event
[03:13:35] <bleathem> something would need to check that property and act on it
[03:13:42] <bleathem> if it was async, I think nothing would be checking
[03:13:59] <sbryzak> if it was async, the authorization check would most likely just fail
[03:14:17] *** gastaldi has joined #seam-dev
[03:14:25] <sbryzak> as bleathem's view code would read the event state immediately after firing the event
[03:14:33] <johnament> i'm just wondering if we (e.g. I) need to mention something like that somewhere
[03:14:43] <sbryzak> i'll put a note in the javadoc
[03:14:59] <johnament> don't define routes using security events.
[03:15:01] <johnament> :-)
[03:15:23] <sbryzak> this particular event should only be used internally anyway
[03:15:43] <johnament> true
[03:16:15] *** _gastaldi has joined #seam-dev
[03:16:23] <bleathem> Seam will be fun to re-write when we get module in Java 8
[03:16:57] <bleathem> "for some value of fun"
[03:18:23] *** gastaldi has quit IRC
[03:18:53] <johnament> 12GR1
[03:19:16] <bleathem> 35FX2
[03:20:23] <johnament> i don't believe we'll see JDK 8.  We'll see Oracle Environment for Java Development 12G R1.
[03:20:35] *** tsurdilo has joined #seam-dev
[03:20:53] <bleathem> And there I was thinking I'd stumbled accross your twitter password!
[03:23:31] <johnament> I have two laptops up.  Both are working on completely unrelated JMS applications.
[03:24:55] <jbossbot> git [security] push master 7c53dcf.. Shane Bryzak SEAMFACES-33
[03:24:56] <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
[03:24:56] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/f3fcc2a...7c53dcf
[03:25:08] <sbryzak> bleathem: event observer is done, not tested yet
[03:25:18] <sbryzak> bleathem: if you could try it out it would be great
[03:25:43] <bleathem> will do!
[03:25:45] *** gastaldi has joined #seam-dev
[03:26:51] *** _gastaldi has quit IRC
[03:27:16] <gastaldi> yo !
[03:30:46] <bleathem> we're not doing another CR release are we?
[03:31:01] <bleathem> would be nice to test this in the wild
[03:31:15] <bleathem> guess that's what X.0.1 releases are for :P
[03:31:39] <bleathem> Are modules going to do minor release independent from the rest of the stack?
[03:31:59] <bleathem> For instance, could I push out Faces 3.0.1 if a critical issue was found?
[03:32:28] <sbryzak> no more CRs
[03:32:46] <sbryzak> bleathem: yes, you can push out a new seam-faces release
[03:32:51] <sbryzak> we'd just update the bom
[03:33:05] <bleathem> cool
[03:33:34] <kenfinnigan> sbryzak: quick question on seam-bom
[03:33:44] <kenfinnigan> post the Final release
[03:33:45] <sbryzak> kenfinnigan: shoot
[03:33:58] <kenfinnigan> is it intended that the seam-bom would reflect the latest version of the modules
[03:34:10] <kenfinnigan> or a set of modules that will work together
[03:34:24] <kenfinnigan> was thinking about this today and thought that people would assume the latter
[03:34:29] <sbryzak> kenfinnigan: both if possible
[03:34:30] <kenfinnigan> when it is probably more the former
[03:34:45] <sbryzak> latter takes priority
[03:35:27] <kenfinnigan> so does that mean post Final we won't be releasing the seam-bom except as part of a full Seam release
[03:35:52] <kenfinnigan> and between those times modules just update their internal dependencies to the versions they want/need
[03:35:59] <sbryzak> no, we'll release one any time we do a module release
[03:36:11] <sbryzak> but we'll use a different versioning scheme
[03:37:01] <sbryzak> afk for a little bit
[03:37:17] <kenfinnigan> ok
[03:37:58] <kenfinnigan> thanks for clarifying
[03:40:02] *** kenfinnigan has quit IRC
[03:44:08] *** johnament has quit IRC
[03:48:12] <bleathem> sbryzak it works!
[03:50:53] <bleathem> ok, next I want to see if I can get the @ViewConfig to use enums nested in the interface
[03:51:37] <bleathem> I also need to "remember" the viewId requested before they were redirected to the login page.
[03:56:31] *** tsurdilo1 has joined #seam-dev
[03:57:59] <gastaldi> sbryzak: How many issues left for Seam 3.0.0.Final ?
[03:59:59] *** tsurdilo has quit IRC
[04:01:48] <bleathem> gastaldi areo you not on the mailing list?
[04:03:27] <bleathem> https://lists.jboss.org/mailman/listinfo/seam-dev
[04:04:08] <gastaldi> Yes, but it seems that it the number has decreased
[04:04:15] <bleathem> http://lists.jboss.org/pipermail/seam-dev/2011-March/003395.html
[04:04:23] <bleathem> oh, nevermind then :P
[04:04:45] <gastaldi> :)
[04:05:08] <gastaldi> doh, I just need to check on JIRA :P
[04:05:31] * gastaldi is feeling stupid right now
[04:05:57] * bleathem the correct action is *facepalm*
[04:06:05] <gastaldi> :)
[04:06:12] <bleathem> :D
[04:09:36] <gastaldi> It seems that only three is left
[04:09:53] <gastaldi> https://issues.jboss.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+SEAM+AND+fixVersion+%3D+12315980+AND+status+in+%28Open%2C+%22Coding+In+Progress%22%2C+Reopened%29
[04:11:00] <bleathem> Faces alone has 7 left
[04:11:10] <bleathem> so somethings is not right with yur query
[04:12:00] <gastaldi> yeah, I thought so
[04:14:00] <gastaldi> is Mark Proctor still on Red Hat ?
[04:14:22] <bleathem> no idea
[04:14:25] <gastaldi> Jboss Rules / Guvnor ?
[04:14:59] <bleathem> Good evenin' Guvnor, and a fine evenin' 'tis!
[04:15:05] <gastaldi> :)
[04:19:43] <bleathem> ok, @ViewConfig uses nested enums not
[04:19:51] <bleathem> ok, @ViewConfig uses nested enums now
[04:20:28] <bleathem> I can trivially make it work with both enums and methods.  Any use case for that?
[04:20:37] <bleathem> would probably just introduce confusion
[04:21:15] <bleathem> Dear diary, today I am very excited because I am almost finished seamfaces-33
[04:21:19] <bleathem> lol
[04:21:44] <bleathem> Is it low-brow to "lol" at yourself in IRC?
[04:26:15] <bleathem> I take that back, I was using a stale build
[04:26:23] <bleathem> It does not work with enums (yet)
[04:28:40] <gastaldi> :)
[04:31:48] <bleathem> Using reflection, how do I iterate over a classes static inner classes?
[04:31:53] <bleathem> getFields()?
[04:32:00] <bleathem> doesn't seem to be doing it
[04:32:54] <bleathem> getClasses
[04:35:41] <bleathem> ok, then I getEnumConstants() on that clazz
[04:35:57] <bleathem> wich returns an Object
[04:37:47] <bleathem> looks like I want to use getFields instead of getEnumconstants
[04:39:56] <bleathem> ok, now it works with enums nested in interfaces!
[04:40:09] <gastaldi> hooray !
[04:42:05] <gastaldi> why there is a javax.faces.bean.RenderScoped class on Seam-faces-api ?
[04:44:45] *** Diablo-D3 has joined #seam-dev
[04:44:59] <mojavelinux> see jira
[04:46:36] <gastaldi>  SEAMFACES-106 ?
[04:46:38] <jbossbot> jira [SEAMFACES-106] Move @RenderScoped to org.jboss.seam.faces.context [Open (Unresolved) Enhancement, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-106
[04:50:49] <bleathem> gonna do that as soon as I close Seam faces 33
[04:51:38] <bleathem> mojavelinux any suggestions of the best way to deal with redirecting to the original viewId after login?
[04:54:00] <bleathem> we need to stuff the value somewhere
[04:54:41] <bleathem> could stuff it in the flash
[04:55:04] <bleathem> but that won't survive long enough
[04:55:49] <mojavelinux> man, you guys are hard core
[04:55:51] <mojavelinux> I love it
[04:55:56] <gastaldi> :)
[04:56:03] <bleathem> Final is fast approaching!
[04:56:12] <Diablo-D3> I just had a horrid idea.
[04:56:19] <mojavelinux> so a quick comment on the discussion about the wiki pages vs documentation
[04:56:48] <mojavelinux> the whiteboard stuff on the wiki pages is a remanent from when Seam 3 was just a scratchpad
[04:57:06] <mojavelinux> and we broke it up into module pages and sort of never touched the stuff...or in some cases it was just so directions to get something happening
[04:57:14] <mojavelinux> anyway, it's all really time to clean that crap up
[04:57:35] <mojavelinux> and that's on the docket for post-seam 3.0.0.Final :)
[04:57:43] <mojavelinux> so, I agree, time to trim
[04:58:36] <mojavelinux> we don't even have to stick with the whiteboard idea, again it was mostly just trying to sort through that massively horrible document we had when Seam 3 was getting off the ground
[04:59:02] <bleathem> I prefer tracking things in jira myself
[04:59:05] <mojavelinux> i like how brian and lincoln use jira
[04:59:09] <mojavelinux> do what they do
[04:59:14] <mojavelinux> :)
[04:59:24] <mojavelinux> what we really need are some nice report views for the module
[04:59:27] <mojavelinux> the idea is to
[04:59:42] <mojavelinux> a) conveniently link to everything you could possibly need in your first 5 minutes with the module, or daily
[04:59:52] <mojavelinux> b) show that this thing is breathing
[05:00:04] <mojavelinux> hence the contributor list and the jira reports
[05:00:15] <mojavelinux> see the rest module for a nice example of what's to come, with a little effort
[05:00:21] <gastaldi> how  about adding an ohloh sign ?
[05:00:22] <mojavelinux> http://seamframework.org/Seam3/REST
[05:00:53] <mojavelinux> we can add an ohloh sign, sure...i've been trying to keep the module pages in line, but right now it's not optimal because it requires a lot of hand editing
[05:01:07] <mojavelinux> we'll be looking at making this all more template-oriented for our own santity
[05:01:18] <gastaldi> agreed
[05:02:04] <mojavelinux> brian, if you want to copy what jozef did on the rest page and scrap your whiteboard, go for it (post final of course, don't want to take you out of your groove) :)
[05:02:26] <mojavelinux> let's go with this assumption, so you can answer questions if they come up
[05:02:34] <mojavelinux> if there is something we are doing right now that seem suboptimal
[05:02:38] <mojavelinux> it's likely because it is
[05:02:59] <mojavelinux> and we need to establish a better way, plan for it, and make the switch
[05:03:11] <mojavelinux> because there is *a lot* of room for improvement in keeping things up to date across the project
[05:03:13] <mojavelinux> we live and learn
[05:03:22] <mojavelinux> or learn as we go
[05:03:24] <mojavelinux> or learn on the job
[05:03:27] <gastaldi> inspiring words
[05:03:27] <mojavelinux> however you like to think of you
[05:03:33] <mojavelinux> and you are part of the solution, welcome :) hahaha
[05:04:14] <mojavelinux> now, question from brian
[05:04:20] <mojavelinux> about keeping the viewId
[05:04:31] <mojavelinux> so this is something we want to get right in seam 3
[05:04:36] <mojavelinux> because in seam 2, it was a little shaky
[05:04:43] <mojavelinux> however, we don't have to make it perfect right now
[05:04:51] <mojavelinux> so let's go with a two pronged approach
[05:05:18] <mojavelinux> i'm thinking you need to use a view scope for now
[05:05:28] <mojavelinux> maybe, or conversation scope
[05:05:35] <mojavelinux> because remember, login could fail
[05:05:43] <mojavelinux> so it will be more than one request possibly
[05:05:52] <mojavelinux> in the long run, i'm thinking of this
[05:06:04] <mojavelinux> we need to have a hook for "pre-login passivation"
[05:06:08] <mojavelinux> perhaps an event
[05:06:22] <mojavelinux> this hook will let the application developer store whatever information they need to store from the request, session, whatever
[05:06:32] <mojavelinux> then, we have a post-login activation
[05:06:37] <mojavelinux> in which information can be restored
[05:06:46] <bleathem> where would it be stored in the mean time?
[05:06:48] <mojavelinux> because, no matter what we do, someone will be unhappy with it
[05:06:52] <mojavelinux> well, that's the nice thing
[05:06:56] <mojavelinux> let's assume, for a second
[05:07:04] <mojavelinux> that you posted a form, like some sort of comment form
[05:07:08] <mojavelinux> and you need to login to post
[05:07:13] <mojavelinux> or the view expired or some crap
[05:07:24] <mojavelinux> so we can let the app developer capture all that data and stick it somewhere
[05:07:32] <mojavelinux> perhaps the session, perhaps a cache, perhaps a database
[05:07:42] <mojavelinux> then, the user logs in, and we can restore that information in the application
[05:07:45] <mojavelinux> how sweet is that?
[05:07:51] <gastaldi> cool
[05:07:53] <mojavelinux> then, we just need some nice apis for capturing information
[05:08:00] <bleathem> ok
[05:08:03] <mojavelinux> like for instance, give me a bundle with all the form data or something
[05:08:05] <mojavelinux> for now
[05:08:07] <bleathem> can we do a rough version of that now?
[05:08:11] <mojavelinux> I think we should just store the viewId
[05:08:21] <mojavelinux> then make a jira
[05:08:27] <mojavelinux> because we want this to be awesome
[05:08:27] <bleathem> maybe do it as a view in the session
[05:08:34] <bleathem> sorry, as a map in the session
[05:08:38] <gastaldi> If state is persisted in client, you have that information, no ?
[05:08:42] <bleathem> that could be emptied out post-passivate
[05:09:06] <mojavelinux> thinking...
[05:09:14] <mojavelinux> let's consider this real quick
[05:09:19] 
[05:09:20] <bleathem> session is by far the most robust at this point, without incurring extra query string parameters
[05:09:26] <mojavelinux> okay, in seam 2, when a login is required
[05:09:56] <mojavelinux> the listener starts a conversation (if one is not running), stores the request parameters
[05:09:57] <bleathem> gastaldi a hidden field is not very robust, and subject to tampering
[05:09:59] <mojavelinux> redirects to the login page
[05:10:04] <mojavelinux> the login page is a conversation
[05:10:07] <gastaldi> bleathem: Right
[05:10:19] <bleathem> mojavelinux: listening...
[05:10:23] <gastaldi> session would be better, if not working on multiple tabs
[05:10:29] <mojavelinux> then, after login, it ends the conversation, and redirects back to the original page with the url parameters included
[05:10:35] <mojavelinux> the benefit of conversation
[05:10:43] <gastaldi> yeah, so far so good
[05:10:52] <mojavelinux> is that you could be logging in as multiple users, but then, oh wait
[05:10:53] <bleathem> ok, and live with the query string parameters in the url
[05:11:02] <mojavelinux> user is session-scoped and none of that matters
[05:11:06] <mojavelinux> so, in hindsight
[05:11:11] <mojavelinux> the use of conversation here is pretty pointless
[05:11:15] <mojavelinux> and session would do
[05:11:22] <gastaldi> session it is
[05:11:27] <mojavelinux> yep
[05:11:44] <mojavelinux> now, the url parameters are likely needed because the viewId alone is very likely meaningless
[05:11:57] <gastaldi> How about serializing ?
[05:12:00] <mojavelinux> however, in seam 2, if you postback to a viewId that requires a login
[05:12:00] <gastaldi> hummm....
[05:12:09] <mojavelinux> then it just fails when you return
[05:12:16] <mojavelinux> because it's like wtf? you have no data
[05:12:20] <mojavelinux> this is where we can do much better
[05:12:32] <gastaldi> how does the container do ?
[05:12:34] <mojavelinux> because what we really want to do is be able to preserve information that was sent to the server
[05:13:06] <mojavelinux> so i'm thinking for the initial cut
[05:13:22] <mojavelinux> you create some sort of request preserver object
[05:13:27] <mojavelinux> that holds the viewId and the query parameters
[05:13:28] <gastaldi> Tough one. :)
[05:13:33] <bleathem> or delegate the job of preserving the information to the developer, by firing an event to the developer t
[05:13:50] <bleathem> ok
[05:14:01] <gastaldi> a Map ?
[05:14:04] <mojavelinux> right, we can just establish the events for intent to authenticate
[05:14:06] <bleathem> good call on the query parameters
[05:14:07] <mojavelinux> and post authenticate
[05:14:37] <mojavelinux> these may duplicate the events in Seam security, but I think it's reasonable since we are working at a higher level
[05:14:41] <bleathem> Course this won't work if the dev is using web.xml for authentication
[05:14:59] <mojavelinux> no, the philosophy of Seam has always been, java ee has no security
[05:15:05] <bleathem> hehe
[05:15:09] <gastaldi> lol
[05:15:19] <mojavelinux> because I looked at that once and was like wtf is this crap, I'm using spring security
[05:15:25] <mojavelinux> or asegi at the time
[05:15:28] <gastaldi> ha ha ha
[05:15:28] <mojavelinux> then finally seam came
[05:15:34] <bleathem> yeah, it's what I'm using, and it hurts
[05:15:35] <mojavelinux> and there was much rejoicing
[05:15:49] *** tsurdilo1 has quit IRC
[05:15:59] <bleathem> end up doing a lot of phase listeners, servlet listeners, web.xml configs
[05:16:04] <bleathem> painful to say the least
[05:16:20] <bleathem> story time.. back in a few minutes
[05:16:31] <mojavelinux> yep, I tried it once, then threw myself on a sword
[05:16:41] <mojavelinux> thankfully, it was dream, I woke up and could keep living
[05:16:54] <mojavelinux> tell that story :)
[05:17:58] <Diablo-D3> [11:56:16] <Diablo-D3> I just had a horrid idea.
[05:18:01] <Diablo-D3> sorry, was drug afk
[05:18:06] <gastaldi> lol
[05:18:25] <Diablo-D3> a native java bytecode generator for... php.
[05:18:31] <gastaldi> hahahaha
[05:18:32] <Diablo-D3> in the same idea as jython and jruby
[05:18:58] 
[05:19:22] <Diablo-D3> it doesnt exist, right?
[05:19:29] <gastaldi> I doubt
[05:19:33] <Diablo-D3> thank god
[05:21:27] <gastaldi> Have you ever used Yale University CAS ?
[05:21:41] <gastaldi> A SSO solution
[05:21:49] <mojavelinux> i've read about it
[05:21:51] <mojavelinux> but never used it
[05:22:05] 
[05:22:08] <mojavelinux> I've used it in my mind
[05:22:29] <gastaldi> It mostly deals with cookies on the browser side
[05:22:41] <gastaldi> And SSL in the background
[05:23:38] <gastaldi> When u talked about Spring Acegi, that came to my mind
[05:23:57] <mojavelinux> sbryzak: great job on the blog entry. I really appreciate the straightforward and transparent news and I know the community is responding to it well also
[05:25:22] <bleathem> I'm thinking of closing seamfaces-33, and doing the viewId persitence stuff in a new JIRA.
[05:25:44] <bleathem> that way people have a couple of days to try out the security bindings, and see if they work
[05:25:57] <mojavelinux> yes, that's a good idea
[05:26:43] <bleathem> ok,  I'll polish off SEAMFACEs-33 tonight, and define some new jiras of how to improve on it.
[05:27:05] <bleathem> some of these improvements will come post final
[05:27:21] <bleathem> but it's hard to triage them when they are bundled in SF-33
[05:27:41] <bleathem> sorry, you agreed, but I had to fully convince myself :P
[05:30:56] <mojavelinux> yeah, sf-33 was way too wide of a scope for a jira
[05:31:04] <jbossbot> git [faces] push master f03c77b.. Brian Leathem SEAMFACES-106: Move @RenderScoped to org.jboss.seam.faces.context
[05:31:05] <jbossbot> jira [SEAMFACES-106] Move @RenderScoped to org.jboss.seam.faces.context [Open (Unresolved) Enhancement, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-106
[05:31:05] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/d866413...f03c77b
[05:31:07] <mojavelinux> you've done a superb job of working through it and sorting it out
[05:31:14] *** daniel_hinojosa has quit IRC
[05:31:29] *** daniel_hinojosa has joined #seam-dev
[05:31:32] <bleathem> thx! Most fun I've had developing in a while!
[05:31:36] <mojavelinux> now feel free to break up the remaining tasks as you would feel appropriate
[05:31:55] <mojavelinux> it's a huge feature, definitely will get a lot of press
[05:32:31] <mojavelinux> I was going to suggest that after you push out this release, we should work together to create a dedicated blog entry for Seam Faces features separate from the seam 3 final release announcement
[05:32:51] <bleathem> we can do another CR release before Final?
[05:32:57] <mojavelinux> that way, we can take our time itemizing these features in particular
[05:33:01] <gastaldi> I  believe Seam Faces is one of the most important modules in Seam
[05:33:05] <bleathem> if so, we'll need a Seam Security release too
[05:33:08] <mojavelinux> whatever the release is called :)
[05:33:30] <mojavelinux> I said CR, I should say "the release" :)
[05:33:30] <bleathem> ok, I thought there were no more release until Final
[05:33:37] <bleathem> but this whole release thing confuses me greatly
[05:34:01] <bleathem> oh nevemind
[05:34:06] <bleathem> I misread altogether
[05:34:11] <mojavelinux> we are dealing with two very less-than-ideal pressures
[05:34:14] <bleathem> I though you said we should push out a release
[05:34:20] <bleathem> it's getting too late...
[05:34:30] <mojavelinux> one, that someone mandated that we have a final release at some point before JBW, which is just water of the damn at this point
[05:34:31] <bleathem> Agreed
[05:34:45] <mojavelinux> and second, because of that, modules are releasing close together and that causes cascading releases
[05:34:48] <bleathem> Agreed to the blog entry
[05:34:53] <mojavelinux> cool
[05:35:09] <bleathem> I'll be focused on that area in prep for JUDCon
[05:35:14] <bleathem> so the timing will be good
[05:35:15] <mojavelinux> normally, you don't need so many simultaneous releases because the apis are more stable
[05:35:21] <mojavelinux> indeed, timing will be awesome
[05:35:41] *** gastaldi has quit IRC
[05:35:56] <bleathem> So I guess Sun isn't the only company that does/did conference-driven-development
[05:36:08] <bleathem> funny, I never correlated the Seam 3 release with JBW
[05:36:17] <bleathem> it is pretty obvious now that you say it
[05:36:23] <mojavelinux> hehe, yeah
[05:36:46] <mojavelinux> but i've rationalized it with a compass that I can live with, which is
[05:37:11] <mojavelinux> a) we needed to materialize the project so that it could actually be taken seriously
[05:37:42] <mojavelinux> b) we needed to pull things together so that we can see how this modular thing is going to work out, without going too far on assumptions
[05:37:49] <mojavelinux> so, it's been exceptionally useful in both regards
[05:37:56] <bleathem> there is also something to be said about how a deadline makes things happen.
[05:38:02] <mojavelinux> exactly
[05:38:23] <bleathem> there's been a lot of activity lately, I'm sure it will translate into buzz post-release
[05:38:38] <mojavelinux> not only is Red Hat taking Seam seriously, they are seriously impressed by the amazing amount of activity
[05:39:21] <mojavelinux> plus, we have such an great group of devs here, that it just makes every day epic
[05:39:23] <bleathem> glad to hear they are noticing!
[05:39:23] <mojavelinux> :)
[05:39:35] <bleathem> it's a lively channel at times for sure!
[05:41:13] <Diablo-D3> firefox 4 final is out
[05:42:17] <sbryzak> bleathem: i'm back, how's the view config stuff going?
[05:42:38] <bleathem> done!
[05:42:42] <sbryzak> mojavelinux: still around?
[05:42:44] <bleathem> just going to do some cleanup
[05:42:48] <sbryzak> bleathem: done, really?
[05:42:48] <bleathem> push it out
[05:42:57] <bleathem> some satelite jiras to create
[05:43:06] <sbryzak> so the authorization works?
[05:43:12] <bleathem> stuff that may or may not get addressed before Final
[05:43:18] <bleathem> yes, the authorisation works!
[05:43:26] <bleathem> Well, with my simple so far tests
[05:43:26] <sbryzak> wow, i wasn't expecting it to work first time
[05:43:44] <sbryzak> is there an example?
[05:43:49] <bleathem> lol, it usually doesn't!
[05:44:02] <bleathem> I've got a simple example, not part of faces though
[05:44:12] <sbryzak> could you add it?
[05:44:27] <bleathem> yeah, but it's pretty messy :P
[05:44:35] <daniel_hinojosa> mojavelinux: Ping!
[05:44:38] <bleathem> I'll clean it up, and throw it in
[05:44:54] <sbryzak> awesome, great job
[05:44:58] <bleathem> thx
[05:45:18] <sbryzak> i can't wait to try it out :)
[05:45:44] <bleathem> hehe, I hope to get it pushed tonight
[05:46:08] <mojavelinux> yo
[05:46:34] <sbryzak> mojavelinux: could you take a look at an issue for me?
[05:47:04] <sbryzak> ales had a look, but only provided a possibly diagnosis, and what i need is a fix or workaround
[05:47:37] <daniel_hinojosa> mojavelinux: couple of things are wrong on the documentation for seam-servlet, I'll have a couple pull-requests for you in the next minute or so
[05:48:20] <bleathem> daniel_hinojosa Seam Faces docs could use some love too!
[05:49:21] <daniel_hinojosa> I will check it out
[05:49:30] <mojavelinux> daniel great!
[05:49:31] <daniel_hinojosa> bleathem: I will check it out
[05:49:32] <bleathem> I've got a snapshot dependency on Seam Security in my Faces pom.  That's ok, right?  So long as it get's removed before Final release?
[05:49:48] <sbryzak> yep as long as its removed before final
[05:49:55] <mojavelinux> yeah, at this point I would assume sbryzak will correct snapshots during release
[05:49:55] <mojavelinux> :)
[05:49:56] <bleathem> daniel_hinojosa right on!
[05:50:09] <daniel_hinojosa> bleathem: Going to hit that for case study, so if something don't look right, I'll either scream or make a pull request
[05:50:12] <mojavelinux> simpler when one person is worrying about that, otherwise you end up clashing
[05:50:19] <bleathem> daniel_hinojosa cool!
[05:50:34] <mojavelinux> yeah, sorry you didn't realize the docs were in github
[05:50:34] <bleathem> ok, good. I'll leave it in there then
[05:50:41] <sbryzak> mojavelinux: the issue is SEAMSECURITY-42, but it's really turned into a glassfish issue
[05:50:42] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42
[05:50:49] <mojavelinux> k, looking...
[05:51:13] <mojavelinux> btw, documentation is published nightly so you can see the changes once they are merged in
[05:52:01] <mojavelinux> daniel I added a link to your project here: http://seamframework.org/Community/LinksToExternalCDIAndWeldDocumentation
[05:52:19] <mojavelinux> we need to do a better job with the directory for tutorials, articles and examples
[05:52:27] <mojavelinux> the diigo effort has not really taken off
[05:52:33] <mojavelinux> another post-final goal :)
[05:52:45] <mojavelinux> this is beginning to sound like when I was finshing my book
[05:52:56] <mojavelinux> you would think the world was due for a makeover by the time I finished I promised so much
[05:53:01] <mojavelinux> then I published, and hid
[05:53:02] <mojavelinux> hahaha
[05:53:27] <sbryzak> mojavelinux: agreed, diigo hasn't turned out so well
[05:53:37] <sbryzak> i think we need to just put together our own page
[05:55:00] <mojavelinux> Argument bean must not be null is that other bug in weld
[05:55:09] <mojavelinux> that it doesn't validate injection points on obsevers and producers
[05:55:19] <mojavelinux> so you get the error at runtime, I have a jira for this
[05:55:26] <mojavelinux> weld-870?
[05:55:48] <mojavelinux> WELD-870
[05:55:49] <jbossbot> jira [WELD-870] Add injection point information to exception message when injection into observer fails [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/WELD-870
[05:55:52] <mojavelinux> wake up you dumb bot
[05:55:53] <mojavelinux> there we go
[05:55:56] <sbryzak> so...
[05:56:01] <mojavelinux> super super not helpful message
[05:56:13] <sbryzak> i didn't think there was an observer for that event
[05:56:14] <mojavelinux> just saying, that is why that stacktrace sucks so much
[05:56:25] <sbryzak> so why is weld complaining
[05:56:28] <mojavelinux> i'm just saying, the issue we happen to be having is another example of this unhelpful message
[05:56:38] <mojavelinux> side note
[05:56:52] <mojavelinux> oh look, ales sighted that
[05:56:53] <mojavelinux> hahah
[05:57:03] <mojavelinux> okay, so i'm still analyzing
[05:57:44] <mojavelinux> so the error is in the producer
[05:57:49] <mojavelinux> sorry
[05:57:51] <mojavelinux> blah!
[05:57:58] <mojavelinux> the error is in the observer
[05:58:05] <mojavelinux> where is the observer?
[05:58:09] <mojavelinux> or what is the observer in this case?
[05:58:35] <mojavelinux> all ales did was tell us what we already know
[05:58:40] <mojavelinux> that WELD-870 sucks
[05:58:41] <jbossbot> jira [WELD-870] Add injection point information to exception message when injection into observer fails [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/WELD-870
[05:58:49] <sbryzak> there is no observer...
[05:59:00] <mojavelinux> there must be, it's trying to be called
[05:59:02] <mojavelinux> by fireEvent
[05:59:04] <sbryzak> at least i don't think there is
[05:59:15] <sbryzak> one moment while i search...
[05:59:29] <mojavelinux> beanManager.fireEvent(new PostAuthenticateEvent());
[05:59:32] <sbryzak> ah wait there is
[05:59:34] <mojavelinux> something must be trying to observe that
[05:59:37] <sbryzak> SecurityEventMessages
[05:59:45] <mojavelinux> yep, and this is why weld-870 sucks so bad
[05:59:50] <sbryzak> hang on, this was the first issue
[05:59:51] <mojavelinux> because it tells you absolutely nothing
[06:00:16] <mojavelinux> and, it proves that injection points are not being validated on observer methods
[06:00:30] <sbryzak> https://github.com/seam/security/blob/master/impl/src/main/java/org/jboss/seam/security/SecurityEventMessages.java
[06:00:49] <sbryzak> method signature is public void postAuthenticate(@Observes PostAuthenticateEvent event, Messages messages)
[06:00:58] <sbryzak> so it's trying to inject Messages
[06:02:08] <sbryzak> why can't it find it... seam-international is included in the war
[06:02:35] <sbryzak> i'll apply daniel's pull request
[06:03:49] <mojavelinux> I know this is going to sound crazy, but at runtime, there is a chance the alpha-bravo issue is reversed
[06:04:32] <mojavelinux> so at deployment, it validates injection points and trips up if the provider jar is after the consumer jar in alphabetical order
[06:04:37] <sbryzak> geez, really?
[06:04:49] <mojavelinux> but at runtime, it fails to inject if the provider jar is before the consumer jar in alphabetical order
[06:04:54] <mojavelinux> and that would perfectly explain
[06:05:08] <mojavelinux> why seam-faces can inject Messages into an observer but not into a field
[06:05:14] <mojavelinux> which I didn't understand before
[06:05:42] <sbryzak> if that's true, then GF is seriously broken when it comes to CDI
[06:05:45] <mojavelinux> I could write an arquillian test to try it out, but that could very well be the case
[06:06:06] <sbryzak> portable extensions are broken more specifically
[06:06:16] <mojavelinux> well, this isn't even extensions
[06:06:20] <mojavelinux> this is just regular old cdi
[06:06:30] <mojavelinux> i just don't know where the hell the tests are for this
[06:06:37] <mojavelinux> how did glassfish possibly pass the tck
[06:06:50] <mojavelinux> unless we just didn't consider these library cases
[06:07:02] <sbryzak> i don't believe the tck tested any libraries
[06:07:14] <sbryzak> test cases are all simple and focussed
[06:07:27] <mojavelinux> dang
[06:07:43] <mojavelinux> what's amazing is the tck for cdi is one of the most extensive suites i've seen for a spec
[06:07:52] <mojavelinux> of course, not like I can see the damn test suites anyway, being that they are all closed
[06:07:56] <sbryzak> it's easy for stuff like this to be overlooked
[06:07:57] <mojavelinux> anyway, I digress
[06:08:06] <sbryzak> the tck is responsible for testing the assertions that the spec makes
[06:08:17] <mojavelinux> yep
[06:08:17] <sbryzak> there weren't really any describing visibility between libraries
[06:08:32] <mojavelinux> yeah, that was more at the EE level
[06:08:46] <mojavelinux> at the module rules
[06:08:51] <mojavelinux> drat
[06:08:56] <bleathem> any feedback to give on the name: ViewConfigSecurityEnforcer ?
[06:09:07] <sbryzak> i've got the feeling that this means we won't have glassfish support for seam, until they fix all the issues
[06:09:12] <mojavelinux> I'm compelled to write a test at this point, but I'm pausing to think about a possible workaround
[06:09:36] <sbryzak> bleathem: what's this for?
[06:10:06] <bleathem> It's the phase listener that calls the throws the Seam Security event
[06:10:21] <bleathem> applies the ViewConfig annotations
[06:10:25] <sbryzak> ah, i'd just call it SecurityPhaseListener
[06:10:32] <bleathem> ok
[06:10:37] <mojavelinux> yeah, that works
[06:10:40] <bleathem> I though it was getting ab it too nouny
[06:11:22] <mojavelinux> one approach, shane, though ugly, is to use the same glassfish hack you did for authenticator
[06:11:31] <bleathem> (sorry to interupt)
[06:11:39] <sbryzak> daniel_hinojosa: your pull request has produced a ton of merge conflicts
[06:11:41] <mojavelinux> any cross-module references are just eating away at us
[06:11:51] <daniel_hinojosa> sbryzak: whoa
[06:12:07] <daniel_hinojosa> sbryzak: I just changed one file
[06:12:09] <sbryzak> mojavelinux: you mean use the looked-up bean manager?
[06:12:19] <sbryzak> daniel_hinojosa: weird...
[06:12:45] <sbryzak> hmm, must be something on my end then.. i'll try it again
[06:13:16] <mojavelinux> you can see here https://github.com/seam/servlet/forkqueue
[06:13:26] <mojavelinux> it says "won't apply cleanly"
[06:13:33] <daniel_hinojosa> sbryzak: https://github.com/dhinojosa/servlet/commit/ff41c58953d72992cf6ff93e224354014f4e4a0b
[06:13:34] <jbossbot> git [servlet] ff41c58.. dhinojosa corrected documentation in servlet-installation.xml there was no servlet-mapping and the catch filter class was incorrect
[06:13:59] <daniel_hinojosa> added 6 line removed 1
[06:14:07] <mojavelinux> strange
[06:14:11] <sbryzak> yeah i saw that too.. git is being temperamental
[06:14:59] <mojavelinux> oh, the bridge isn't mean to be mapped
[06:15:02] <mojavelinux> in fact, it shouldn't be
[06:15:27] <mojavelinux> though perhaps a comment is in order
[06:15:43] <mojavelinux> it's a hack to take advantage of the init() method on a servlet to fire a post-startup event
[06:15:50] <daniel_hinojosa> oh
[06:15:53] <mojavelinux> given that it has the highest order of any servlet, it will be last
[06:16:04] <mojavelinux> but we should mention specifically that it should not be mapped to a url
[06:16:04] <daniel_hinojosa> ok, that threw me off]
[06:16:10] <mojavelinux> understandable :)
[06:16:34] <mojavelinux> how about do an XML comment inline
[06:16:43] <mojavelinux> writing...
[06:16:54] <daniel_hinojosa> ok
[06:16:56] <daniel_hinojosa> thanks'
[06:17:21] <mojavelinux> <!-- An unmapped Servlet that is used to fire the post-startup application event in the init() method -->
[06:18:02] <mojavelinux> crap, we lost code again
[06:18:11] <mojavelinux> it should have another XML node, the startup order
[06:18:15] <mojavelinux> hang on, checking log
[06:20:08] <mojavelinux> <!-- Make load-on-startup large enough to be initialized last (thus destroyed first) -->
[06:20:08] <mojavelinux> <load-on-startup>99999</load-on-startup>
[06:20:59] <mojavelinux> here is the whole block
[06:21:01] <daniel_hinojosa> I was attempting to deploy that on an older Jetty which is how I found that.
[06:21:12] <sbryzak> mojavelinux: i think it would be useful if we had a qualified producer method for BeanManagerLocator
[06:21:29] <mojavelinux> <servlet>
[06:21:29] <mojavelinux>     <!-- An unmapped Servlet that is used to fire the post-startup application event in the init() method -->
[06:21:29] <mojavelinux>     <servlet-name>Servlet Event Bridge Servlet</servlet-name>
[06:21:29] <mojavelinux>     <servlet-class>org.jboss.seam.servlet.event.ServletEventBridgeServlet</servlet-class>
[06:21:29] <mojavelinux>     <!-- Make load-on-startup large enough to be initialized last (thus destroyed first) -->
[06:21:30] <mojavelinux>     <load-on-startup>99999</load-on-startup>
[06:21:30] <mojavelinux> </servlet>
[06:21:41] <mojavelinux> crap, let me gist it
[06:22:14] <mojavelinux> https://gist.github.com/882664
[06:22:17] <mojavelinux> there, that's what it should be
[06:22:32] <mojavelinux> 999999 is an arbitrary number, I guess I could have made it e ;)
[06:22:55] <mojavelinux> well, technically BeanManagerLocator shouldn't be used from inside of CDI :)
[06:23:01] <mojavelinux> so it wouldn't need a producer
[06:23:08] <mojavelinux> the whole point of it is that you use it when you aren't in cdi
[06:23:10] <mojavelinux> but we have to hack atm
[06:23:55] <bleathem> I really like the enum in interface idea you had mojavelinux
[06:23:57] <daniel_hinojosa> Maybe a less passive comment, mojavelinuc
[06:23:59] <bleathem> way to save the day!
[06:24:38] <daniel_hinojosa> "Do not map this servlet.  It is used to fire the post-startup application event in the init() method."
[06:25:17] <daniel_hinojosa> Show them who's Boss! JBoss that is, ohhh......
[06:25:24] <mojavelinux> that's why I keep him around guys, he's my editor  :)
[06:25:42] <mojavelinux> yes, sounds good
[06:26:07] <mojavelinux> bleathem: cool! I don't make these things up, they just come to me
[06:26:20] <bleathem> divine inspiration maybe!
[06:26:31] <mojavelinux> what's funny is I was reading aslak's arquillian post for alpha5
[06:27:00] <bleathem> sbryzak, is it ok if I include the sample app in faces without all the usual "fixings" - to be added later
[06:27:06] <mojavelinux> and I was like, omg, I can't believe the annotations I suggested when I was half dead at jfokus actually took
[06:27:11] <bleathem> ie. it's fully standalone
[06:27:12] <sbryzak> bleathem: sure
[06:27:45] <bleathem> mojavelinux sometimes the strawman turns out to be a 300 lb linebacker!
[06:27:49] <mojavelinux> just kick me, some ideas might come out I guess :)
[06:28:04] <mojavelinux> I have no control over it, that's all I know
[06:28:10] <bleathem> strawman proposal, that's not a Canadian expression is it?
[06:28:25] <mojavelinux> it's funny, in the US, that's usually consider a condoning thing
[06:29:04] <mojavelinux> like, when you can't win an argument, you throw out a strawman argument, and that's supposed to be like so generic it's not defensible either way
[06:29:14] <mojavelinux> but I guess if you put "proposal" on the end, then it works for suggestions :)
[06:30:16] <bleathem> huh, I still have to include the joda time jar
[06:31:01] <bleathem> We use strawman to mean you put out an idea to get a conversation started, with the intention it gets knocked down
[06:31:15] <bleathem> or rather that's how I use it, I don't really speak for my country!
[06:31:45] <mojavelinux> solder trunk is still broken
[06:32:14] *** gastaldi has joined #seam-dev
[06:32:20] <mojavelinux> "A straw man is a component of an argument and is an informal fallacy based on misrepresentation of an opponent's position."
[06:32:30] <gastaldi> heu
[06:32:31] <gastaldi> hey
[06:32:38] <mojavelinux> http://en.wikipedia.org/wiki/Straw_man
[06:32:40] <gastaldi> Kinda late, but worth: http://www.theserverside.com/news/thread.tss?thread_id=62071
[06:32:40] <bleathem> ahhh!
[06:32:41] <bleathem> java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory
[06:32:41] <mojavelinux> that's how I understand it
[06:32:53] <bleathem> I thought that had gone away with all the GF fixes
[06:33:23] <daniel_hinojosa> "This guy told me that Seam sucked, I told him he had no idea how to program or what he was doing, he realized I was right" - My Strawman
[06:33:33] <bleathem> ok, I'm going to stop using the term" strawman proposal" !
[06:34:11] <bleathem> http://en.wikipedia.org/wiki/Straw_man_proposal
[06:34:17] <bleathem> vindicated!
[06:34:18] <daniel_hinojosa> I think it's named because you make someone up, so you can easily knock it down.
[06:34:42] <daniel_hinojosa> whoa!
[06:35:18] <bleathem> (and no, that wasn't enough time for me to type the article up)
[06:36:00] <daniel_hinojosa> bleathem: Wow, I am going to use that
[06:36:17] <bleathem> cool!  Just don't forget the proposal part at the end of it
[06:36:22] <daniel_hinojosa> bleathem: Straw man proposal
[06:36:30] <bleathem> GLASSFISH-16061
[06:36:31] <jbossbot> jira [GLASSFISH-16061] could not find Factory: javax.faces.context.FacesContextFactory [Open (Unresolved) Bug, Major, rogerk] http://java.net/jira/browse/GLASSFISH-16061
[06:37:03] <bleathem> I never followed up with GLASSFISH_16061, thought it was gone
[06:37:18] <gastaldi> bleathem: is jsf-impl on classpath ?
[06:37:29] <bleathem> no
[06:38:06] <bleathem> weird.  the difference is it's consistent now...
[06:38:13] <bleathem> I'll try reverting the changes in my pom
[06:39:06] <bleathem> nope
[06:39:26] <gastaldi> try placing the jsf-impl on your app and see if it works
[06:40:15] <bleathem> needed this to get it going:
[06:40:19] <bleathem>     <servlet>
[06:40:21] <bleathem>         <servlet-name>Faces Servlet</servlet-name>
[06:40:22] <bleathem>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
[06:40:23] <bleathem>         <load-on-startup>1</load-on-startup>
[06:40:25] <bleathem>     </servlet>
[06:40:26] <bleathem> in my web.xml
[06:44:09] *** echelog-2 has joined #seam-dev
[06:44:17] <bleathem> web.xml fragments are supposed to take care of that
[06:44:39] 
[06:45:59] <mojavelinux> glassfish and jboss as both setup the FacesServlet if faces-config.xml is present
[06:46:03] <mojavelinux> automatically
[06:46:13] <mojavelinux> it's not even web fragments, since it's at the appserver level
[06:46:23] <mojavelinux> jboss as happens to use a ServletContainerInitializer SPI
[06:46:30] <gastaldi> hum, I knew I saw something on that before
[06:46:53] <gastaldi> But that is JBoss 5+ behavior right ?
[06:47:21] <gastaldi> I remember having some issues on JBoss 4.2
[06:47:37] <mojavelinux> jboss 5 may have implemented something like that too
[06:47:40] <mojavelinux> but it was not to spec
[06:47:48] <mojavelinux> in fact, it's not to spec in EE 6 either
[06:47:57] <mojavelinux> because they "forgot" to add it
[06:48:01] <gastaldi> But works anyway :)
[06:49:13] <gastaldi> it may break some compatibilty when using another JEE server, but who cares ?
[06:49:24] <gastaldi> JEE is not THAT portable at all
[06:49:46] <gastaldi> because you need a custom descriptor also
[06:50:14] <mojavelinux> with ee 6, you shouldn't, at least, that's where we are trying to get
[06:50:31] <gastaldi> yeah, we pray for that
[06:50:33] <gastaldi> :)
[06:50:51] <bleathem> mojavelinux, did you see my error, glassfish issue, and resolution above?
[06:51:14] <kuuyee> seamframework.org can't visit
[06:51:58] <sbryzak> kuuyee: hmm, i'll restart the server
[06:52:11] <gastaldi> :) Standard procedure
[06:53:03] <gastaldi> We use that on Windows also: "If it does not work, try restarting the server.".
[06:53:17] <gastaldi> It works on 99 % of the cases
[06:53:38] <kuuyee> Oh
[06:54:55] <gastaldi> what has become on Seam Report module ?
[06:55:22] <kuuyee> sbryzak: what programm used seamframework website
[06:55:49] <sbryzak> kuuyee: Seam, of course ;)
[06:56:20] <gastaldi> kuuyee: That does NOT mean that a restart is always required on apps developed on Seam
[06:56:24] <sbryzak> gastaldi: we're going to look at it after next week
[06:56:56] <mojavelinux> yep, new modules are on the table next week, after final :)
[06:57:10] <gastaldi> great, more fun then
[06:57:11] <kuuyee> sbryzak: website app server is jboss?
[06:57:21] <mojavelinux> yeah, I reproduced weld-870 with an arquillian test
[06:57:23] <sbryzak> kuuyee: yes
[06:57:33] <mojavelinux> now i'm testing my alpha-bravo hypothesis
[06:57:38] <sbryzak> mojavelinux: great
[06:57:50] <mojavelinux> so beware, injection points on observer methods are not validated on startup
[06:57:51] <sbryzak> mojavelinux: do you mind if i assign that issue to you?
[06:58:08] <mojavelinux> well, I'm not sure I can resolve the issue, did you try to BeanManagerLocator fix?
[06:58:29] <mojavelinux> let me see if we actually have the problem I think we have first
[06:58:31] <sbryzak> kuuyee: web site is back up again
[06:58:44] <sbryzak> mojavelinux: np
[06:58:44] <mojavelinux> it took me a while to get arquillian running again with my hacked glassfish container version :)
[06:58:51] <mojavelinux> i'm sort of in between arquillian versions atm
[06:59:01] <sbryzak> mojavelinux: btw it's easy to reproduce apparently, just deploy the security-simple example
[06:59:02] <mojavelinux> because we need to upgrade solder to alpha5 to use the released version of the glassfish adapter
[06:59:13] <mojavelinux> nothing is proven until proven by arquillian :)
[06:59:36] <gastaldi> Good catch phrase
[06:59:43] <gastaldi> Should be part of Arquillian logo
[07:00:25] <jbossbot> git [faces] push master d302f5b.. Brian Leathem SEAMFACES-33 Created the annotation for restricting view access
[07:00:26] <bleathem> here it comes
[07:00:26] <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
[07:00:26] <jbossbot> git [faces] push master dc7cf59.. Brian Leathem SEAMFACES-33 Added a system event listener to enforce @ViewConfig view restrictions
[07:00:26] <jbossbot> git [faces] push master 8d1895f.. Brian Leathem SEAMFACES-33 Refactored ViewData* to ViewConfig*
[07:00:26] <jbossbot> git [faces] push master bbfa59a.. Brian Leathem SEAMFACES-33 added trace message to ViewConfigExtension
[07:00:26] <jbossbot> git [faces] push master 2c0c519.. Brian Leathem SEAMFACES-33 Changed the @ViewConfig annotations to work with interfaces, rather than enums
[07:00:27] <jbossbot> git [faces] push master de0a747.. Brian Leathem SEAMFACES-33 Refactored the ViewConfigStore
[07:00:27] <jbossbot> git [faces] push master ef00f7e.. Brian Leathem SEAMFACES-33 Trying the qualifier parsing - fails
[07:00:27] <jbossbot> git [faces] push master 7d3d3c6.. Brian Leathem SEAMFACES-33 Added a test demonstrating the failure of qualifier retrieval of the ViewConfigStoreImpl
[07:00:28] <jbossbot> git [faces] push master 1b2de43.. Brian Leathem SEAMFACES-33 Fixed the failing test for the Qualifier cache
[07:00:28] <jbossbot> git [faces] push master 6861cc7.. Brian Leathem SEAMFACES-33 Fixed the annotation return type for the Qualifier cache
[07:00:29] <jbossbot> git [faces] push master a9d2062.. Brian Leathem SEAMFACES-33 Added support for multiple security annotations per ViewParam
[07:00:29] <jbossbot> git [faces] push master 7157f6a.. Brian Leathem SEAMFACES-33 Refined the @ViewConfig annotations
[07:00:30] <jbossbot> git [faces] push master 84cd0e1.. Brian Leathem SEAMFACES-33 Changed the security enforcer to a phase listener
[07:00:31] <kuuyee> sbryzak: website prototype is examples/wiki?
[07:00:50] <sbryzak> kuuyee: yes, but it's undergone many changes
[07:01:24] <mojavelinux> yeah!!!!!!!! major commit!
[07:01:28] <kuuyee> sbryzak: version is seam2 or seam3?
[07:01:32] <bleathem> :D
[07:01:38] <sbryzak> seam 2
[07:01:38] <mojavelinux> and there was much rejoicing
[07:01:39] <mojavelinux> yeah
[07:01:42] <bleathem> I hope it works!
[07:01:51] <gastaldi> Have you guys experienced any strange behavior on ViewScoped Extension ?
[07:01:51] * bleathem said with confidence
[07:02:07] <gastaldi> Like, JSF 2 events not getting fired ?
[07:02:14] <kuuyee> sbryzak: ok! thanks!
[07:02:23] <gastaldi> and objects not being cleaned ?
[07:08:53] *** gastaldi has quit IRC
[07:09:34] <mojavelinux> eclipse needs to have a fluent api formatting ruleset
[07:09:41] <mojavelinux> it's so dumb w/ fluent apis
[07:16:35] <bleathem> ok, updated http://java.net/jira/browse/GLASSFISH-16061
[07:16:36] <jbossbot> jira [GLASSFISH-16061] could not find Factory: javax.faces.context.FacesContextFactory [Open (Unresolved) Bug, Major, rogerk] http://java.net/jira/browse/GLASSFISH-16061
[07:16:55] <bleathem> at least I have a workaround (this bug hit me bad at the office)
[07:17:58] <bleathem> sbryzak, feel free to beef up the  Faces Security example,
[07:18:02] <bleathem> do what you can to break it!
[07:18:09] <sbryzak> bleathem: sure thing
[07:19:05] <mojavelinux> damn, I can't reproduce our problem within a normal cdi context
[07:19:14] <mojavelinux> but what I realized is that the authenticator is being called from el
[07:19:15] <daniel_hinojosa> Wow, you guys make me wish I didn't have customer I didn't need to attend to
[07:19:18] <mojavelinux> so the problem could be there
[07:19:36] <mojavelinux> this visibility is so screwy
[07:19:42] <mojavelinux> also, I don't see how it's possible
[07:19:50] <bleathem> tomorrow triage of the open jira issues.
[07:19:51] <mojavelinux> that @Inject private Messages messages would fail
[07:19:53] <bleathem> tonight sleep
[07:20:02] <bleathem> later all!
[07:20:13] *** bleathem has quit IRC
[07:20:31] <mojavelinux> so actually, putting Messages on the observer parameter doesn't help at all
[07:20:33] <mojavelinux> thanks brian!
[07:20:45] <mojavelinux> the problem is more in why it can't find Messages
[07:20:45] <sbryzak> mojavelinux: yeah, it just moved the error somewhere else
[07:21:01] <sbryzak> mojavelinux: so you can reproduce it?
[07:21:02] <mojavelinux> well, it didn't even move it
[07:21:06] <mojavelinux> it's been a null pointer all along
[07:21:11] <mojavelinux> it just happened at a different place
[07:21:23] <mojavelinux> well, that's the thing
[07:21:24] *** oskutka has joined #seam-dev
[07:21:27] <mojavelinux> I can't figure out why it's null
[07:21:38] <mojavelinux> unless, it's breaking because it's invoked via EL
[07:21:43] <mojavelinux> so the problem is not what I first suspected
[07:22:47] <sbryzak> hmm
[07:23:08] <sbryzak> pretty much everything in a JSF app is going to be invoked via EL
[07:26:48] <mojavelinux> that requires setting up a jsfunit test, which it's a little late to do now...
[07:27:09] <mojavelinux> though I could try something quick in the booking example that would be the same premise
[07:27:22] <mojavelinux> see if that fails...the key for me is always duplicating it when there are no other possible things going on
[07:27:25] <mojavelinux> then we know we really found i
[07:27:27] <mojavelinux> it
[07:27:54] <sbryzak> back in 10
[07:32:14] <nickarls> and i18n d00dz around?
[07:33:26] <sbryzak> nickarls: ken was on earlier
[07:34:30] <nickarls> I noticed that SEAMINTL-33 was fixed by http://is.gd/5eQpHj
[07:34:32] <jbossbot> jira [SEAMINTL-33] Injections null when Bundles.get(String) is called [Resolved (Done) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-33
[07:34:46] <nickarls> but wasn't @Named bundles the entry point to EL?
[07:35:14] <nickarls> in which case the cure killed the patient ;-)
[07:35:43] <sbryzak> that's one for ken i'm afraid
[07:36:09] <nickarls> yep, I'll comment on the JIRA
[07:45:55] *** daniel_hinojosa has quit IRC
[07:46:54] <mojavelinux> dang it, I added seam-security, and it failed because slf4j is not present, so I added that, and now I get
[07:46:55] <mojavelinux> [#|2011-03-23T02:44:27.838-0400|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=93;_ThreadName=Thread-1;|Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: java.lang.IllegalArgumentException: javax.servlet.ServletException: com.sun.enterprise.container.common.spi.util.InjectionException:
[07:48:04] <mojavelinux> shoot, that means we might have a real problem with EL and libraries
[07:48:07] <mojavelinux> oh my goodness
[07:48:22] <mojavelinux> that's two signs of this now
[07:49:07] <mojavelinux> only problem is, we really need a jsfunit test to be able to prove it since it requires EL to be configured...I guess we could use Solder's EL resolver, but that might not generate the same problem
[07:49:21] <sbryzak> i didn't think i was using slf4j
[07:50:08] <sbryzak> does jsfunit work with arquillian?
[07:50:20] <mojavelinux> yes
[07:50:21] <sbryzak> maybe it's something oskutka can help out with
[07:50:33] <mojavelinux> but what you really want is alpha5, because the integration is much better
[07:50:40] <mojavelinux> yeah, this EL thing looks like it could be a deeper issue
[07:51:01] <mojavelinux> it all comes down to what BeanManager you have
[07:51:04] <mojavelinux> what is the context
[07:51:10] <mojavelinux> because that's where the visibility problems start
[07:51:20] <mojavelinux> in jboss as there is only one, but on glassfish there are more than one
[07:51:32] <sbryzak> more than one BeanManager?
[07:51:34] <mojavelinux> or they are layered or something
[07:51:37] <mojavelinux> yes
[07:51:41] <mojavelinux> that's why we have all these issues
[07:51:43] <sbryzak> why is that??
[07:51:51] <mojavelinux> stuart explained it at some point
[07:52:09] <mojavelinux> they implemented it as though these were modules in an ear
[07:52:18] <mojavelinux> except they are jars in a war
[07:52:23] <mojavelinux> it's really screwed up imho
[07:52:35] <mojavelinux> and it could be that it's not multiple BeanManagers, but effectively that way
[07:52:45] <mojavelinux> because there are different stacks of beans
[07:53:01] <mojavelinux> so you may have one BeanManager instance, but the stack it has when it's looking for beans is changing out from underneath it
[07:53:01] <sbryzak> as far as i understand there should be one per deployment archive
[07:53:11] <sbryzak> i'm surprised the spec doesn't define this clearly
[07:53:19] <mojavelinux> I think it does
[07:53:27] <mojavelinux> I just think glassfish has it really messed up
[07:53:31] <mojavelinux> yes, jboss is too lose
[07:53:37] <mojavelinux> but what glassfish is doing is really screwed up
[07:54:02] <mojavelinux> it's like, depending on what execution path you take to get to a bean
[07:54:08] <mojavelinux> the other beans may or may not be there
[07:54:27] <sbryzak> that is screwed up
[07:54:29] <mojavelinux> because this stack of bean definitions is changing
[07:54:41] <sbryzak> we need to determine if the spec is clear on this
[07:54:48] <sbryzak> and then present that to siva
[07:54:54] <mojavelinux> and that stack is maintained by what they call a "bean deployment archive"
[07:55:03] <nickarls> isn't jboss method one BM per BDA so a ear with a war has two and the BMs have the visibility of the archives?
[07:55:14] <mojavelinux> so you move between these bean deployment archives as you execute and what it resolves is changing
[07:55:47] <mojavelinux> yes, BDA should be per java ee module
[07:55:53] <mojavelinux> in glassfish, BDA is per jar
[07:56:30] <mojavelinux> or it's acting that way
[07:57:00] <mojavelinux> i'm getting pretty tired of trying to figure out what is going to work and what isn't, because the rules seem to be changing as we go
[07:57:07] <sbryzak> i just went through my inbox
[07:57:27] <sbryzak> found the e-mail thread for this issue
[07:57:41] <mojavelinux> if we get to a point where we are just stuck
[07:57:43] <sbryzak> the conversation died out prematurely
[07:57:54] <sbryzak> siva was actually waiting on a response from pete and/or ales
[07:57:59] <mojavelinux> I think Red Hat or JBoss needs to come out with a bold statement to say that we think GlassFish is in violation of the spec
[07:58:07] <mojavelinux> because we need to be backed up on this by JBoss
[07:58:08] <sbryzak> the glassfish issue is GLASSFISH-15721
[07:58:08] <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:58:13] <nickarls> did the "child manager" context make it to CDI final spec? it was there at some point
[07:58:19] <mojavelinux> otherwise, it just becomes a "seam is broken" discussion
[07:58:21] <sbryzak> http://java.net/jira/browse/GLASSFISH-15721
[07:58:31] <sbryzak> oh wow, jbossbot is smart
[07:58:40] <mojavelinux> yea
[07:58:53] <sbryzak> so anyway, that issue is still unresolved
[07:59:10] <sbryzak> so i believe that issue is our problem
[07:59:37] <mojavelinux> so we worked around that using the BeanManagerLocator hack
[07:59:49] <mojavelinux> but this problem with resolving Messages is a new issue
[07:59:56] <mojavelinux> that seems to stem from EL
[08:00:04] <mojavelinux> but I'm just doing a best guess there
[08:00:11] <mojavelinux> because I can't get the injection to fail any other way
[08:00:22] <mojavelinux> and I haven't setup a test for the specific case
[08:00:26] <sbryzak> ok.. dan could you please work with the QE guys to get a test case put together that demonstrates this
[08:00:36] <sbryzak> i noticed you have one in the issue comments
[08:00:58] <mojavelinux> yep, I can send them an e-mail
[08:01:06] <sbryzak> but i think it is worth providing multiple tests
[08:01:20] <sbryzak> we need to update their jira as well, so they have a record of it
[08:02:04] <sbryzak> when ales comes online we'll get him involved
[08:03:02] <sbryzak> WELD-846
[08:03:47] <sbryzak> dammit, jira is down
[08:04:14] <sbryzak> reindexing.. 73% complete
[08:07:12] *** jharting has joined #seam-dev
[08:07:14] <sbryzak> WELD-846
[08:07:22] <sbryzak> jbossbot: wake up
[08:07:25] <jbossbot> jira [WELD-846] Incorrect handling of cyclic dependencies between BeanDeploymentArchives [Closed (Done) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/WELD-846
[08:08:09] <sbryzak> so stuart handled that issue...
[08:08:15] <sbryzak> we need to chat to him and ales
[08:12:32] *** oskutka has quit IRC
[08:14:11] *** oskutka has joined #seam-dev
[08:14:44] <mojavelinux> okay, I think I explained that well
[08:14:48] <mojavelinux> btw
[08:14:55] <mojavelinux> have you tested this with weld snapshot?
[08:15:05] <mojavelinux> if not, you should, just to see where you get
[08:15:24] <mojavelinux> it would be interesting to know if this is a 1.1.0.Final problem or whether it still exists
[08:15:29] <mojavelinux> snapshots are in the maven repo
[08:15:34] <mojavelinux> weld-osgi-bundle
[08:15:44] <mojavelinux> simply copy it over the one in glassfish/modules/
[08:15:46] <mojavelinux> takes a second
[08:15:59] <mojavelinux> I e-mailed ondrej the details of what to test
[08:16:10] <mojavelinux> I think my assumptions will lead to the source of the problem
[08:16:29] <mojavelinux> I would be rather slow to get that test setup, I think the QE guys will be much more efficient
[08:16:48] <mojavelinux> I need to call it a night
[08:18:46] <oskutka> mojavelinux: jharting got into this problem before. I believe he'll set up the test quickly.
[08:19:03] <oskutka> jharting: Could you please take a look at this issue?
[08:19:34] <sbryzak> sorry, was afk
[08:19:49] <sbryzak> mojavelinux: was your testing done with the latest weld snapshot?
[08:20:22] <jharting> oskutka: sure, please forward me dan's e-mail
[08:20:25] <sbryzak> oskutka: if you could take control of this issue it'd be much appreciated
[08:21:08] <oskutka> mojavelinux: btw: I still haven't got your email...
[08:21:36] <sbryzak> oskutka: the relevant issues are SEAMSECURITY-42, WELD-846 and GLASSFISH-15721
[08:21:37] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42
[08:21:38] <jbossbot> jira [WELD-846] Incorrect handling of cyclic dependencies between BeanDeploymentArchives [Closed (Done) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/WELD-846
[08:21:39] <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
[08:23:46] *** maschmid has joined #seam-dev
[08:27:45] *** PeteRoyle has quit IRC
[09:01:59] *** marekn has joined #seam-dev
[09:06:25] *** kpiwko has joined #seam-dev
[09:12:56] *** aslak has joined #seam-dev
[09:12:56] *** aslak has quit IRC
[09:12:56] *** aslak has joined #seam-dev
[09:15:28] <kuuyee> seam2 wiki sample error http://seamframework.org/Community/ProblemsWithExampleWikiOn210GA
[09:16:20] *** jose_freitas has joined #seam-dev
[09:28:47] <jbossbot> git [persistence] push master 55def16.. Shane Bryzak remove slf4j
[09:28:47] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/78e2973...55def16
[09:41:17] <jose_freitas> SEAMFACES-101
[09:41:19] <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
[09:46:31] <maschmid> jose_freitas: I remember filing that one, what about it?
[09:47:11] <jbossbot> git [persistence] push master 693e320.. Shane Bryzak fix compiler error
[09:47:11] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/55def16...693e320
[09:48:43] *** aslak_ has joined #seam-dev
[09:49:26] *** kpiwko has quit IRC
[09:51:12] <jose_freitas> just taking a look at it
[09:52:34] <kuuyee> seam3 has wiki sample?
[09:55:49] <kuuyee> sbryzak: wiki example will has seam3 implementation
[09:57:28] * nickarls slaps his forehead when he realizes that events dont' propagate between webclients of an application
[09:58:40] <jose_freitas> nickarls: jsf events?
[09:58:58] *** shervin_a has joined #seam-dev
[09:59:03] <nickarls> CDI
[09:59:29] <nickarls> application scoped bean firing event won't reach session scoped listeners for the clients
[09:59:48] *** shervin has joined #seam-dev
[10:00:05] <jose_freitas> ?
[10:00:09] <jose_freitas> really?
[10:00:18] <sbryzak> kuuyee: no, we won't migrate the wiki example to seam 3, unless someone volunteers to do it
[10:00:24] 
[10:01:44] <nickarls> hmm, waitaminute(tm)
[10:03:47] <nickarls> nevermind, must have been my JRebel acting up. works.
[10:04:00] <jose_freitas> :)
[10:04:02] <jose_freitas> nice
[10:04:25] <jose_freitas> one thing I was wondering though if that an event would propagate through a cluster enviroment
[10:04:45] <jose_freitas> I mean, if I fire an event on one node, and I have an observer on a different node
[10:05:00] <jose_freitas> do you think the event would reach this observer?
[10:05:24] <nickarls> I don't think events are cross-JVM, you probably need JMS for that
[10:05:57] <jose_freitas> agree
[10:16:33] *** pmuir has joined #seam-dev
[10:16:33] *** pmuir has quit IRC
[10:16:33] *** pmuir has joined #seam-dev
[10:16:38] *** sannegrinovero has joined #seam-dev
[10:16:38] *** sannegrinovero has joined #seam-dev
[10:19:40] *** shervin has quit IRC
[10:22:53] <kuuyee> sbryzak:  What plug-in mechanism to achieve the reference for wiki sample
[10:23:18] <sbryzak> kuuyee: sorry, i don't understand
[10:25:12] <nickarls> jose: back at original theory, event is contained within the same client
[10:25:51] <kuuyee> sbryzak: how implementation that wiki plug-in model
[10:26:10] <sbryzak> oh, you're asking how to implement wiki plugins?
[10:26:14] <sbryzak> i don't really know
[10:26:23] <sbryzak> Christian Bauer wrote all of that stuff
[10:26:47] <kuuyee> oh!
[10:29:31] <kuuyee> sbryzak: Christian Bauer in IRC?
[10:30:21] <sbryzak> no, he doesn't work for red hat any more
[10:33:08] <kuuyee> ok! thanks!
[10:33:43] *** msmigielski has joined #seam-dev
[10:58:01] <Diablo-D3> hrm
[10:58:09] <Diablo-D3> is there an example for using openid via seam security?
[11:00:35] *** kuuyee has quit IRC
[11:18:23] *** alesj has joined #seam-dev
[11:35:11] *** jose_freitas has quit IRC
[11:35:16] <Diablo-D3> heh there is
[11:36:43] *** wdrai has joined #seam-dev
[11:43:33] *** adamw1pl has joined #seam-dev
[11:44:08] <nickarls> hmm, MDB:s have no scope, right? So if you'd like a sessionscoped JMS-observer, you would have to register itself in a @PostConstruct or somethine?
[11:44:13] <nickarls> s/e/g
[11:45:38] <nickarls> more like inject a @SessionScoped bean into the MDB...
[11:46:06] <nickarls> no good either.
[12:11:06] *** pmuir has quit IRC
[12:33:28] *** aslak_ has quit IRC
[12:50:34] *** aslak has quit IRC
[12:50:34] *** msmigielski has quit IRC
[12:50:47] *** msmigielski has joined #seam-dev
[12:51:10] *** msmigielski has quit IRC
[12:51:15] *** aslak has joined #seam-dev
[12:52:25] <jbossbot> git [dist] push master 713be76.. Shane Bryzak SEAM-52
[12:52:26] <jbossbot> jira [SEAM-52] seam-solder-tooling missing in the distribution [Open (Unresolved) Bug, Critical, Shane Bryzak] https://issues.jboss.org/browse/SEAM-52
[12:52:26] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/d243281...713be76
[12:54:39] *** msmigielski has joined #seam-dev
[12:54:45] *** bitshuffler has joined #seam-dev
[13:16:08] *** bitshuffler_ has joined #seam-dev
[13:17:03] *** bitshuffler has quit IRC
[13:36:20] *** bitshuffler__ has joined #seam-dev
[13:39:25] *** jose_freitas has joined #seam-dev
[13:39:31] <jose_freitas> sbryzak: ping
[13:39:44] *** bitshuffler_ has quit IRC
[13:42:18] *** monkeyden has joined #seam-dev
[13:53:03] *** PeteRoyle has joined #seam-dev
[14:06:57] <sbryzak> jose_freitas: pong
[14:08:31] *** sannegrinovero has quit IRC
[14:09:15] *** sannegrinovero has joined #seam-dev
[14:09:15] *** sannegrinovero has quit IRC
[14:09:15] *** sannegrinovero has joined #seam-dev
[14:10:37] *** tsurdilo has joined #seam-dev
[14:11:15] *** lightguard_jp has joined #seam-dev
[14:12:42] <nickarls> jp: mornings
[14:17:14] <lightguard_jp> nickarls: morning
[14:17:58] <nickarls> jp: do you think a context-dump of some sort would be useful for Catch?
[14:18:18] <lightguard_jp> Yep
[14:18:20] <nickarls> iterate over the contexts and serialize the stuff and make it available
[14:18:36] <lightguard_jp> For something like the Seam 2 Debug Page
[14:18:51] <nickarls> (didn't check if there are any JIRAs for it)
[14:19:06] <lightguard_jp> You can inject the BeanManager today and get access to everything in a handler, so probably not so much access to the contexts
[14:19:12] <lightguard_jp> There are not
[14:19:22] <nickarls> no portable way of doing it.
[14:20:16] <nickarls> Not sure if BeanManagerImpl helps even, you would probably have to dig them out of request/session based on naming standards for Weld
[14:20:30] <nickarls> or reflect into the contexts.
[14:20:45] <lightguard_jp> Yeah
[14:21:17] <lightguard_jp> Feel free to add the JIRA,but we'll have to explore ideas to see if there's something we can do that's portable
[14:22:29] <nickarls> that's easy. No! ;-)
[14:25:24] *** lincolnthree has joined #seam-dev
[14:28:00] *** PeteRoyle has quit IRC
[14:31:56] <alesj> nickarls: reflection is always portable :-)
[14:32:07] *** msmigielski has quit IRC
[14:32:26] *** msmigielski has joined #seam-dev
[14:35:40] *** Obsidians has joined #seam-dev
[15:01:45] *** jbossbot has quit IRC
[15:02:02] *** jbossbot has joined #seam-dev
[15:07:22] <jose_freitas> woot! http://planet.jboss.org/post/jboss_developer_studio_4_is_now_available_for_free
[15:09:43] <nickarls> alesj: yeah, you just need to know what to reflect against and hope it doesn't change that much ;-)
[15:10:28] <nickarls> jose: eval for a limited time or?
[15:12:50] <jose_freitas> I understood that's forever
[15:12:55] <jose_freitas> free software
[15:15:20] <nickarls> just noticed the "eval" in the link
[15:16:16] *** shervin_a has quit IRC
[15:17:19] <jose_freitas> hm
[15:17:50] <jose_freitas> I still thinks that's a free software forever
[15:18:01] <jose_freitas> you have access just to the standalone version though
[15:18:53] *** oskutka has quit IRC
[15:36:25] *** balunasj has joined #seam-dev
[15:39:37] *** daniel_hinojosa has joined #seam-dev
[16:08:08] *** msmigielski has quit IRC
[16:10:24] *** marekn has left #seam-dev
[16:30:06] *** jharting has quit IRC
[16:35:14] *** bleathem has joined #seam-dev
[16:38:19] *** balunasj has quit IRC
[16:47:14] *** echelog-2 has joined #seam-dev
[16:54:47] <Diablo-D3> hrm
[16:55:15] <Diablo-D3>   <h:selectOneRadio value="#{openIdAuthenticator.providerCode}">
[16:55:15] <Diablo-D3>     <f:selectItems value="#{openIdAuthenticator.providers}" var="p" itemValue="#{p.code}" itemLabel="#{p.name}"/>
[16:55:15] <Diablo-D3>   </h:selectOneRadio>
[16:55:18] <Diablo-D3> lists only 3 providers
[16:55:20] <Diablo-D3> can I add more?
[17:04:47] <lightguard_jp> Diablo-D3: You'll have to ask Shane when he comes onlien
[17:04:51] <lightguard_jp> online*
[17:05:35] *** adamw1pl has quit IRC
[17:08:28] *** alesj has left #seam-dev
[17:16:51] <jbossbot> git [forge] push master 2b5aa4e.. Lincoln Baxter, III SEAMFORGE-49 Shrinkwrap version update to fix invalid persistence.xml generation
[17:16:53] <jbossbot> jira [SEAMFORGE-49] Persistence plugin generates invalid persistence.xml [Closed (Done) Bug, Major, Lincoln Baxter III] https://issues.jboss.org/browse/SEAMFORGE-49
[17:16:53] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/4d1da2e...2b5aa4e
[17:25:00] *** tsurdilo has quit IRC
[17:39:52] <jose_freitas> bleathem: ping
[17:42:39] <bleathem> jose_freitas: pong
[17:43:50] <jose_freitas> I've seen the faces101 yesterday, didn't have time to make sure if the problem is related directly too pretty faces though
[17:44:33] <bleathem> ok, cool
[17:44:38] <Diablo-D3> giddamnit
[17:44:41] <Diablo-D3> goddamnit
[17:44:44] <Diablo-D3> now what did I break
[17:44:52] <bleathem> if the suggested fix alleviates the problem, then it's probably the cause
[17:45:11] <bleathem> thanks for looking at it btw!
[17:45:17] <Diablo-D3> 12:41:06,529 INFO  [org.jboss.weld.Version] WELD-000900 1.1.0 (CR3)
[17:45:17] <Diablo-D3> 12:41:07,034 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///home/diablo/Workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1299437663993/deploy/DiabloPool.war_WeldBootstrapBean state=Create: java.lang.RuntimeException: Error instantiating class org.jboss.seam.servlet.ServletExtension
[17:45:40] <Diablo-D3> [long backtrace]
[17:45:47] <Diablo-D3> Caused by: java.lang.IllegalArgumentException: Invalid bundle interface org.jboss.seam.servlet.messages.ServletMessages (implementation not found)
[17:45:47] <jose_freitas> Diablo-D3: try updating the weld version
[17:46:16] <Diablo-D3> Im using whatever 3.0.0.CR1 uses
[17:46:17] <jose_freitas> and get the last bom
[17:47:22] <jose_freitas> seam-servelt is on CR3
[17:48:05] *** daniel_hinojosa has quit IRC
[17:48:36] *** tsurdilo has joined #seam-dev
[17:49:38] <jose_freitas> and weld is 1.1.0 final
[17:49:48] <jose_freitas> I'd update it too
[17:50:26] *** tsurdilo has quit IRC
[17:51:18] <bleathem> yeah, your "WELD-000900 1.1.0 (CR3)" indicates you are using an old Weld
[17:51:25] <Diablo-D3> well, to be fair
[17:51:27] <Diablo-D3> Im not using any weld
[17:51:34] <Diablo-D3> Im depending on seam to pull in the right deps
[17:51:50] <bleathem> what container are you running in?
[17:51:56] <jose_freitas> weld is the implementation of CDI
[17:52:21] <Diablo-D3> jose_freitas: yes, Im aware of what it is
[17:52:25] <Diablo-D3> bleathem: jboss as6
[17:52:36] <bleathem> AAS 6 Final?
[17:52:40] <Diablo-D3> also, whats the newest version of the bom? cr3?
[17:52:42] <Diablo-D3> bleathem: yes
[17:52:45] <jose_freitas> bleathem: final has CR3
[17:52:55] <bleathem> I think the latest bom is CR9
[17:53:07] <bleathem> huh
[17:53:09] <jose_freitas> I had to update it myself too
[17:53:13] <jose_freitas> my weld version
[17:53:23] <jose_freitas> cause Jboss Final has weld CR3
[17:53:49] <jose_freitas> sorry the message crossed
[17:54:11] <bleathem> I'm not much of an AS guy :P
[17:54:21] <bleathem> JBoss AS that is
[17:54:27] <jose_freitas> Diablo-D3: CR9 is the last bom version
[17:54:28] <bleathem> growing though!
[17:54:38] <jose_freitas> hehehe
[17:54:53] <jose_freitas> gf with new weld run smoothly now?
[17:55:32] <bleathem> so far
[17:55:43] <bleathem> some little bugs that come up, but workarounds exist
[17:55:57] <bleathem> although Shane and Dan were talking about a new big one last night in IRC
[17:56:09] <bleathem> I've been meaning to read through the logs to see what it's all about
[17:56:27] <bleathem> or I could just wait for the summary to seam-dev...
[17:57:26] *** tsurdilo has joined #seam-dev
[17:58:07] * Diablo-D3 restarts eclipse. grumble.
[18:00:17] <jose_freitas> well, have to go now
[18:00:18] <jose_freitas> bye
[18:00:28] <Diablo-D3> heh
[18:00:28] *** jose_freitas has quit IRC
[18:00:29] <Diablo-D3> guerss what
[18:00:32] <Diablo-D3> guess what
[18:00:34] <Diablo-D3> not a bug at all
[18:00:47] <Diablo-D3> at least
[18:00:56] <Diablo-D3> if there was a bug, moving the bom to CR9 fixed it
[18:01:14] <Diablo-D3> its still using weld 1.1.0 cr3 too
[18:03:34] *** daniel_hinojosa has joined #seam-dev
[18:04:22] * Diablo-D3 loves those, srsly
[18:07:08] *** maschmid has quit IRC
[18:20:27] *** tsurdilo1 has joined #seam-dev
[18:23:03] *** tsurdilo1 has quit IRC
[18:23:30] *** tsurdilo has quit IRC
[18:23:42] *** daniel_hinojosa has quit IRC
[18:39:34] *** tsurdilo has joined #seam-dev
[18:40:57] *** tsurdilo1 has joined #seam-dev
[18:40:58] *** tsurdilo has quit IRC
[18:47:46] *** jharting has joined #seam-dev
[18:48:57] <mojavelinux> the version of seam is in no way related to the version of weld
[18:49:04] <mojavelinux> the version of weld is determined by the application server
[18:49:19] <mojavelinux> so when you see weld 1.1.0.CR3, that means the application server decided to use that version when they packaged
[18:49:33] <mojavelinux> so, AS 6 final does not use weld 1.1.0.Final
[18:49:41] <mojavelinux> seam just depends on a cdi environment
[18:49:50] <mojavelinux> hope that helps
[18:49:58] <mojavelinux> we are currently coding to cdi 1.0 spec version
[18:50:12] <mojavelinux> just like if we were coding to jpa 1.0 spec version
[18:55:51] <Diablo-D3> mojavelinux: yes, but this is where seam can start dragging in requirements
[18:56:26] <mojavelinux> it shouldn't be in this case
[18:56:30] <mojavelinux> you mean dependencies?
[18:56:42] <mojavelinux> we do use weld in places like embedded testing
[18:56:56] <mojavelinux> and if you run in a servlet environment, you have to use weld-servlet.jar, which requires selecting a weld version
[18:57:03] <mojavelinux> but seam itself shouldn't be tied to it...
[18:57:11] <mojavelinux> okay, with one exception, seam-conversation
[18:57:17] <mojavelinux> but that's a vendor extension to cdi
[18:57:23] <mojavelinux> just like a hibernate extension to jpa
[18:57:41] <mojavelinux> (to clarify, the conversation is not an extension, it's the conversation manager that is a vendor extension)
[18:59:34] *** alesj has joined #seam-dev
[19:01:00] <mojavelinux> does that help?
[19:01:26] <mojavelinux> btw, I agree this is good information to include an the introductory section of the seam combined refguide
[19:01:38] <mojavelinux> is there a place for introductory, big picture chapters in github?
[19:01:46] <mojavelinux> I should probably be the one answering rather than asking, but...
[19:03:35] <lightguard_jp> mojavelinux: https://github.com/seam/dist/blob/master/docs/src/main/docbook/en-US/bundled_intro.xml
[19:03:44] <lightguard_jp> Overview: TODO
[19:03:45] <lightguard_jp> :)
[19:04:18] *** msmigielski has joined #seam-dev
[19:07:38] <mojavelinux> well cool, at least there is a spot
[19:07:43] <mojavelinux> who knew? good find
[19:19:56] *** tsurdilo has joined #seam-dev
[19:19:56] *** tsurdilo1 has quit IRC
[19:23:28] <Diablo-D3> mojavelinux: either way, the bug wasnt
[19:24:10] *** kpiwko has joined #seam-dev
[19:25:09] *** alesj has left #seam-dev
[19:25:12] *** tsurdilo has quit IRC
[19:25:46] <mojavelinux> in order to debug the security issue on glassfish, we really need security added to booking
[19:25:49] <bleathem> I think we should have a 2nd channel for #seam2 and #seam3
[19:25:53] <mojavelinux> can someone integrate that?
[19:25:55] <bleathem> (not dev, but user)
[19:25:58] <mojavelinux> when I tried, it blew up deployment
[19:26:07] <mojavelinux> probably my misunderstanding
[19:26:19] <bleathem> can you try the security example in Faces?
[19:26:27] <mojavelinux> brian, I think that is a good idea
[19:26:30] <mojavelinux> however
[19:26:34] <mojavelinux> there is one downside
[19:26:55] <mojavelinux> the migration discussions really need to happen with those users together
[19:26:56] <lightguard_jp> bleathem: Does Faces have a dep on persistence?
[19:27:03] <mojavelinux> optional
[19:27:08] <bleathem> optional, yes
[19:27:47] <bleathem> it comes in when you include security too, which is kind of annoying
[19:27:59] <bleathem> because adding Security turns on the Transaction features
[19:28:26] *** tsurdilo has joined #seam-dev
[19:29:00] <mojavelinux> if you are using linux, checkout giggle
[19:29:04] <mojavelinux> new frontend for git browsing
[19:29:15] <mojavelinux> sudo apt-get|yum install giggle
[19:29:15] <bleathem> mojavelinux, the problem is, people like me who know nothing about Seam 2 can't always tell if a problem/dsicussion is related to seam 2 or seam 3
[19:29:33] <mojavelinux> yeah
[19:30:17] <lightguard_jp> Thinking about that entityConverter
[19:30:45] <lightguard_jp> I think if I @Inject @Any EntityManager it should do the trick w/ and w/o persistence
[19:30:51] <bleathem> yeah, that would be a good one to get in for final
[19:33:10] <bleathem> mojavelinux re: giggle, would be nice if it supported java packages (instead of folder trees)
[19:33:31] <bleathem> mojavelinux re: giggle, I like the history view, but I'm partial to the dense display of gitk
[19:33:39] <mojavelinux> yeah, that's something I've requested as a github feature too
[19:37:24] <bleathem> my github experience with looking through source:
[19:38:10] <bleathem> scroll & click, scroll & clilck, (wait stop scrolling you fool - positions mouse) click, click, click
[19:39:07] <lightguard_jp> If you know the class use 't'
[19:39:13] <lightguard_jp> Try it now, I'll wait
[19:39:51] <bleathem> oh my!  That's awesome!
[19:40:13] <lightguard_jp> '?' like in google shows you the shortcuts
[19:40:21] <bleathem> how many other gems are out there
[19:40:34] <bleathem> oooh, gonna check out '?'
[19:41:01] <mojavelinux> holy crap!
[19:41:14] <mojavelinux> someone finally addressed the web viewer is the worst piece of crap interface ever problem
[19:41:17] <mojavelinux> yeah!
[19:41:22] <mojavelinux> wonder if that works on a phone
[19:41:31] <mojavelinux> because it's hell to browse github on a phone
[19:42:05] <mojavelinux> I'm going to marry github
[19:42:16] <mojavelinux> don't tell the laptop, it might get jealous
[19:42:17] <mojavelinux> hahaha
[19:42:30] <bleathem> lol!
[19:42:43] <lightguard_jp> Better not tell the wife either
[19:42:57] <lightguard_jp> You might have to move to Texas, AZ or Utah to make that legal though
[19:44:05] <mojavelinux> don't worry, my wife said that I can marry one technology
[19:44:07] <mojavelinux> hahaha
[19:44:50] *** tsurdilo has quit IRC
[19:46:54] <bleathem> mojavelinux it had better be Seam!
[19:47:20] *** daniel_hinojosa has joined #seam-dev
[19:52:17] *** sannegrinovero has quit IRC
[19:58:46] *** daniel_hinojosa has quit IRC
[20:01:49] *** cbrock has joined #seam-dev
[20:02:21] <lightguard_jp> That would imply marriage to the job, I think he already has that
[20:04:03] <nickarls> as long as he's not cheating with springframework
[20:04:53] <lightguard_jp> I think he divorced them three years ago
[20:07:45] <mojavelinux> yeah, it wasn't working out...it was too much of an arranged marriage
[20:13:30] <Diablo-D3> lincolnthree: you here?
[20:13:50] <lincolnthree> Diablo-D3: almost? fighting with classloading atm
[20:13:51] <lincolnthree> whats up
[20:15:58] <Diablo-D3> lincolnthree: prettyfaces faq #7
[20:16:03] <Diablo-D3> that class doesnt exist
[20:16:10] <Diablo-D3> or at least, I dont think it exists
[20:16:23] <lincolnthree> Diablo-D3: it probably moved. MultiPageMessages?
[20:17:01] <lincolnthree> It should be there..
[20:18:10] <Diablo-D3> lincolnthree: hrm, the blog entry that links to just says I should copy the code and put it in my project
[20:18:17] <lincolnthree> old blog
[20:18:21] <lincolnthree> it should be in the jar
[20:19:19] <Diablo-D3> chapter 5.4 in the manual also says it should be that class
[20:19:20] <Diablo-D3> oh wait
[20:19:28] <Diablo-D3> it says com.ocpsoft.pretty.faces.event.MultiPageMessagesSupport
[20:19:54] <lincolnthree> i found out whats wrong with the docs btw
[20:20:00] <lincolnthree> hudson isn't publishing them to the docserver anymore...
[20:20:04] <lincolnthree> i have to fix it
[20:20:05] <Diablo-D3> nice
[20:20:46] *** tsurdilo has joined #seam-dev
[20:23:29] <Diablo-D3> lincolnthree: yeah, its that class
[20:23:34] <Diablo-D3> so the faq needs to be fixed =P
[20:23:52] <lincolnthree> I think it has been already? just not published :(
[20:23:53] <Diablo-D3> lincolnthree: the neat part is, eclipse itself has a warning message if that class is wrong =P
[20:23:56] <lincolnthree> but glad you found it
[20:24:04] <lincolnthree> haha nice, thank you jboss tools
[20:25:17] *** lincolnthree1 has joined #seam-dev
[20:33:37] *** daniel_hinojosa has joined #seam-dev
[20:38:55] <bleathem> what's the state of requiring a web.xml file in JavaEE 6 (spec wise, not reality wise)
[20:39:09] <lightguard_jp> bleathem: For what?
[20:39:12] <bleathem> I thought the jsf impl was supposed to have a web-fragment.xml
[20:39:17] <lightguard_jp> You shouldn't need it
[20:39:18] <lincolnthree1> not required
[20:39:22] <bleathem> to configure the servlet and mapping
[20:39:34] <lincolnthree1> the appserver does that
[20:39:35] <bleathem> lincoln, do you have a reference I can point to?
[20:39:39] <mojavelinux> gotta restart folks, bbl
[20:39:39] <bleathem> is it in the spec?
[20:39:44] <lincolnthree1> not the JSF spec
[20:39:52] <lincolnthree1> it's in the EE spec though
[20:39:56] <lincolnthree1> Im pretty sure
[20:39:56] <mojavelinux> nope, it's not
[20:39:56] <bleathem> (I need the ref for a glassfish issue)
[20:39:58] <lincolnthree1> no?
[20:40:02] <mojavelinux> it's not in either afaik
[20:40:11] <nickarls> is it just a common agreement?
[20:40:13] <mojavelinux> i think what app servers are doing is forward looking
[20:40:15] <mojavelinux> yes
[20:40:17] <lincolnthree1> well either way... the AS just does it
[20:40:18] <mojavelinux> what nik said
[20:40:28] <mojavelinux> yes, and jboss as does it using a servletcontextinitializer
[20:40:38] <mojavelinux> which is an SPI for doing essentially what web-fragment.xml does
[20:40:41] <mojavelinux> except programmatically
[20:40:45] <mojavelinux> and we use it in seam servlet
[20:40:53] <mojavelinux> to register the faces servlet if it's not registered
[20:40:59] <mojavelinux> which is redundant on app servers
[20:41:03] <bleathem> ok, so I tell the Glassfish folks that it *would be nice* if it was done that way
[20:41:04] <mojavelinux> but works on tomcat 7 and jetty 8
[20:41:13] <mojavelinux> so what's the problem exactly?
[20:41:14] <bleathem> but there is no spec I can point them to
[20:41:17] <bleathem> 1 sec
[20:41:28] <bleathem> GLASSFISH-16061
[20:41:29] <jbossbot> jira [GLASSFISH-16061] could not find Factory: javax.faces.context.FacesContextFactory [Open (Unresolved) Bug, Major, rogerk] http://java.net/jira/browse/GLASSFISH-16061
[20:41:31] <mojavelinux> sorry, I know you might be repeating yourself
[20:41:41] <bleathem> (that's ok)
[20:41:48] <mojavelinux> looking
[20:42:04] <bleathem> it was initially an intermittent problem, but last night I was able to reproduce it exactly, and come up with a workaround
[20:42:12] <bleathem> so I updated the issue
[20:42:48] <bleathem> and now I just want something to point them to when I comment that I shouldn't need to configure the faces servlet.
[20:42:55] <mojavelinux> intermittent problem, hahaha, like the interceptor issue
[20:43:00] <mojavelinux> okay, so answer some questions for me
[20:43:05] <mojavelinux> 1. do you have a faces-config.xml?
[20:43:08] <bleathem> yes
[20:43:25] <bleathem> (this is with the faces security example app btw.)
[20:43:34] <mojavelinux> okay, so given that you have a faces-config.xml, glassfish is *supposed* to register Faces Servlet *if* it's not registered in web.xml (which would be an override)
[20:43:41] <mojavelinux> now, another question
[20:44:54] <mojavelinux> 2. if you debug FacesServletInitializer in Seam Faces
[20:45:09] <mojavelinux> does it detect that Faces Servlet is registered (with no entry in web.xml)?
[20:45:37] <mojavelinux> as you can see, Seam Faces is attempting to register Faces Servlet if the application server (or servlet container in actuality) doesn't
[20:45:57] <bleathem> good question... I can check that
[20:45:59] <mojavelinux> we are leveling the playing field
[20:46:47] <mojavelinux> what I'm doing is effectively the same as web-fragment.xml, except it's conditional
[20:47:05] <bleathem> it's a nice idea
[20:47:14] <mojavelinux> which, btw, is a much better way to do things than web-fragment.xml in cases where you may have duplicates
[20:47:24] <mojavelinux> however, it is less powerful than a wish it would be
[20:47:33] <mojavelinux> for instance, I wish it would allow me to remove shit
[20:47:36] <mojavelinux> or reorder it
[20:49:19] <mojavelinux> okay, i'll check in on the results after a restart
[20:49:32] *** mojavelinux has quit IRC
[20:50:10] <nickarls> who was it over here who got the "unable to determine persistence context to inject"-error with the booking sample?
[20:51:07] <lincolnthree1> BAM!!! Forge can now replace plugin versions at runtime!!!
[20:51:17] <lincolnthree1> who needs hot-swap???
[20:51:34] <lincolnthree> lincolnthree1: Dude you ROCK
[20:51:46] <lincolnthree1> lincolnthree No YOU do
[20:51:52] <lincolnthree> lincolnthree1: no...
[20:52:04] <lincolnthree1> anyway......
[20:52:08] <lincolnthree1> *cough*
[20:52:12] <nickarls> you need two credit lines!
[20:52:28] <lincolnthree1> lol. nickarls, so true
[20:53:22] <nickarls> btw, I was thinking about the jms module event bridge, will session-scoped observers work on the bridge? can it be used for cross-session communication?
[20:55:11] * bleathem pushing/pulling/building getting my work machine synched to my home machine...
[20:56:46] *** mojavelinux has joined #seam-dev
[20:57:52] * bleathem still building security
[20:59:26] <Diablo-D3> alright, Im going to bed
[20:59:27] <Diablo-D3> night all
[20:59:34] <bleathem> good afternoon!
[21:01:14] <bleathem> seam security downloads a lot of stuff to build itself
[21:03:31] <lincolnthree1> bleathem: im guessing it shades some stuff in?
[21:03:42] <lincolnthree1> I might end up using more shade to reduce the size of the forge deliverable
[21:03:53] *** Diablo-D3 has quit IRC
[21:04:18] <bleathem> it's a lot of jboss as stuff, I figured for the tests
[21:04:25] <bleathem> what is shade?
[21:04:59] <lincolnthree1> http://maven.apache.org/plugins/maven-shade-plugin/
[21:05:00] *** johnament has joined #seam-dev
[21:06:25] <johnament> no meeting yet?
[21:07:01] <bleathem> uber jar, nice!
[21:07:12] <bleathem> meeting is in 2 hours isn't it?
[21:07:22] <johnament> 6pm eastern now?
[21:07:47] <bleathem> I thought it was 3pm PDT (yes 6pm EDT)
[21:07:54] <bleathem> I could have that wrong tho
[21:08:02] <lincolnthree1> mojavelinux: ?
[21:08:16] *** lincolnthree has left #seam-dev
[21:08:21] <mojavelinux> meeting is in 1 hour
[21:08:28] <mojavelinux> we are sticking to the original time, honoring the DST
[21:08:30] <mojavelinux> in the west
[21:08:47] <johnament> so 5pm?
[21:08:54] <mojavelinux> I'm pretty sure that's what we decided on last meeting
[21:08:55] <mojavelinux> yep
[21:09:14] <bleathem> where are those minutes...!
[21:09:23] <lightguard_jp> http://people.redhat.com/~manderse/irc.freenode.org/meetings/seam-dev/2011/seam-dev.2011-03-16-21.01.html
[21:09:27] <lightguard_jp> http://www.seamframework.org/Seam3/ProjectMeetings
[21:09:33] <lightguard_jp> I liked them last week
[21:09:44] <mojavelinux> indeed
[21:09:48] <mojavelinux> thanks for adding the link
[21:09:49] <mojavelinux> hero
[21:09:58] <lightguard_jp> You can see last week's under Meetings logged with MeetBot :)
[21:10:01] <lightguard_jp> mojavelinux: np
[21:10:13] <lightguard_jp> I'll take care of this week as well once we're done.
[21:10:19] <johnament> is Seam JMS status still on the agenda?
[21:10:32] <lightguard_jp> But now would be a good time to at least send out an agenda for the meeting to the dev list
[21:10:49] *** Obsidians has quit IRC
[21:11:19] <johnament> i'm just looking at the next meeting agenda on the site.
[21:11:35] <mojavelinux> true, yes to seam jms status
[21:11:40] <mojavelinux> we have an announcement there :)
[21:11:59] <lightguard_jp> johnament: That's old, pretty sure
[21:12:05] <johnament> i've got a general CDI question.  if i have an observer method in an EJB, do transactions propogate?
[21:12:16] <johnament> if the event was fired from another EJB?
[21:12:26] <lightguard_jp> I would think they do
[21:13:25] <mojavelinux> yes
[21:14:28] <johnament> that's what I thought, maybe an integration issue? I have an MDB that fires an event into a SLSB, which fires another event into another SLSB.  in the 3rd bean, it acts like there's a new transaction instead of using the existing one.
[21:15:08] <nickarls> john: repeating question for you ;-) "btw, I was thinking about the jms module event bridge, will session-scoped observers work on the bridge? can it be used for cross-session communication?"
[21:18:37] <johnament> or was that a legit question for me?
[21:18:43] <johnament> nickarls: no, actually has nothing to do with my OSS contributions :-)
[21:20:00] <nickarls> johnament: mine was a general jms module question.
[21:20:11] <johnament> nickarls: oh ok. here's the answer then.
[21:20:49] <nickarls> since I notice that events are useless for that. application-scoped components firing event won't reach all session scoped listeners, only your own.
[21:20:52] <johnament> nickarls: currently, you would need to define a durable connection subscribing to the same queue.  it should be doable in the message builder api, but isn't yet available in the route api.
[21:21:31] <nickarls> the manual version would be to have a normal instance implement MessageListener and register in a @PostConstruct?
[21:21:56] <johnament> extend org.jboss.seam.jms.AbstractMessageListener
[21:22:02] <johnament> override handle message.
[21:22:17] *** monkeyden has quit IRC
[21:22:43] <johnament> in the post construct of your "primary" session object, create a new instance of the impl and register it via MessageBuilder.createDurable...
[21:22:46] <nickarls> OK, I'll check that out. I noticed that the current docs ended halfway for the CDI-JMS bridge ;-)
[21:22:59] * bleathem retarting IDE and appserver.  Everything got all looped up!
[21:23:01] <johnament> nickarls: the published ones?
[21:23:13] <nickarls> yes, the latest
[21:23:15] <johnament> nickarls: i just got access to the main repo yesterday, i wanted a new snapshot to be out in the field.
[21:23:27] <johnament> nickarls: so docs, hopefully this weekend on how all of it works.
[21:23:48] <nickarls> cool
[21:23:49] <johnament> nickarls: i'm going to file a route api durable subscriber as session level as a feature request right now.
[21:27:29] <bleathem> freakin' typical.  No I can't reproduce the problem
[21:27:42] <bleathem> mabye my appserver configuration was differant at home
[21:27:47] <bleathem> I'll try again tonight.
[21:27:50] *** stuartdouglas has joined #seam-dev
[21:28:13] <bleathem> I'm going to commit these logger changes to Faces though.  More convenient than debuggin.
[21:29:03] <bleathem> mojavelinux: TLDR; I'll let you know about the FacesServletInitializer tonight
[21:29:21] <johnament> nickarls: i'm going to add it to SEAMJMS-5
[21:29:24] <jbossbot> jira [SEAMJMS-5] Add/Remove routes programmatically [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMJMS-5
[21:32:52] *** koentsje has joined #seam-dev
[21:35:10] *** koentsje has quit IRC
[21:35:10] <jbossbot> git [faces] push master 10a8b5a.. Brian Leathem Added more logging to FacesServletInitializer
[21:35:11] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/c23a4e3...10a8b5a
[21:36:01] <bleathem> I've grown accustom to JBoss Logging.  It's going to end up in all my projects
[21:36:02] *** PeteRoyle has joined #seam-dev
[21:36:21] <bleathem> I love the log.infof(format, args...) methods
[21:36:29] <bleathem> String.format rocks
[21:36:47] <bleathem> and I'm not even a "C" guy!
[21:37:09] *** gmorling has joined #seam-dev
[21:37:15] <johnament> sprintf("%d[20]")
[21:37:18] <johnament> segfault
[21:38:20] *** PeteRoyle has quit IRC
[21:39:10] *** koentsje has joined #seam-dev
[21:45:36] *** PeteRoyle has joined #seam-dev
[21:47:50] *** koentsje has quit IRC
[21:53:38] *** cbrock has quit IRC
[21:53:52] *** koentsje has joined #seam-dev
[21:53:55] *** PeteRoyle has quit IRC
[22:00:36] *** PeteRoyle has joined #seam-dev
[22:05:43] <mojavelinux> meeting time!
[22:05:56] <gmorling> yippie :-)
[22:05:56] <lightguard_jp> #startmeeting
[22:06:05] <jbott> Meeting started Wed Mar 23 21:06:01 2011 UTC.  The chair is lightguard_jp. Information about MeetBot at http://wiki.debian.org/MeetBot.
[22:06:05] <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
[22:06:10] <lightguard_jp> #chair mojavelinux
[22:06:14] <jbott> Current chairs: lightguard_jp mojavelinux
[22:06:28] *** kpiwko has quit IRC
[22:06:39] <mojavelinux> #topic announcements
[22:07:14] *** kenfinnigan has joined #seam-dev
[22:08:20] <mojavelinux> #info Jordan is enjoying his new job, but it's requiring a lot of his time, so he said he can't realistically lead the JMS module in the near term
[22:09:44] <mojavelinux> #info john ament has volunteered to be the JMS module lead; he has been working with Jordan recently and also got a strong recommendation from Jordan
[22:10:28] <gmorling> He is the lead already according to http://seamframework.org/Seam3/JMSModule :-)
[22:10:48] *** daniel_hinojosa has quit IRC
[22:10:55] <mojavelinux> yep, I updated it before he even accepted ;) i was optimistic :)
[22:11:04] <gmorling> hehe
[22:11:41] <johnament> yes you were.
[22:11:54] <mojavelinux> with that said, we are looking for people interested to help john out, since module lead doesn't mean do all the work...in fact, the best thing a lead can do is build up a little army for yourself :)
[22:12:31] <gmorling> sounds interesting, what's on the agenda for Seam JMS?
[22:12:36] <mojavelinux> #info we are looking for contributors to Seam JMS
[22:12:40] <mojavelinux> #info Seam JMS should have a new release soon
[22:13:10] <mojavelinux> #link Seam JMS  http://seamframework.org/Seam3/JMSModule
[22:13:58] <mojavelinux> john, to answer a question you asked a while back, no we don't have to support MDB in Seam JMS if it's causing a road block
[22:14:11] <mojavelinux> we really just want
[22:14:18] <mojavelinux> 1) make jms easier to use and configure
[22:14:21] <mojavelinux> 2) bridge jms events
[22:14:30] <mojavelinux> mdb is more of a pain in everyone's side imho
[22:14:41] <johnament> #info the next release is expected to be 3.0.0.Beta1
[22:15:05] <mojavelinux> mdb is a means to an end, an end people would be happy to get to another way
[22:15:24] <mojavelinux> #link http://seamframework.org/Seam3/JMSModule Seam JMS  module
[22:15:33] <mojavelinux> i had the wrong syntax
[22:15:33] <johnament> #info Beta1 will come after 3.0.0.Final for the main Seam modules
[22:15:45] <mojavelinux> sounds good...since that is only days away ;)
[22:16:14] <mojavelinux> #info Seam 3.0.0.Final is schedule before the end of the month, though QE is going to push back if we don't have issues resolved
[22:17:10] <mojavelinux> we are currently facing some problems with seam security due to what appears to be another glassfish visibility issue, but we can't reproduce in a testing environment
[22:17:17] <mojavelinux> SEAMSECURITY-42 tells the saga
[22:17:19] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42
[22:17:58] <mojavelinux> #info we are currently facing some problems with seam security due to what appears to be another glassfish visibility issue, but we can't reproduce in a testing environment; see SEAMSECURITY-42
[22:17:59] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42
[22:18:04] <mojavelinux> sorry for the double post there
[22:18:33] <mojavelinux> #info snapshots of weld osgi bundles are now published to the jboss snapshots repository
[22:19:53] <mojavelinux> #link https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/weld/weld-osgi-bundle/ Weld OSGi bundle snapshots
[22:20:06] <jharting> mojavelinux: what's the target for Seam 3 Final? Is it ok to target GF 3.1 + updated Weld or are we going to hack around vanilla GF 3.1 anyway?
[22:20:19] <mojavelinux> very good question
[22:20:41] <mojavelinux> I want a Weld 1.1.1 release, period
[22:20:45] <mojavelinux> and I want it now
[22:21:02] <gmorling> the question is when this would be available in GF
[22:21:12] <mojavelinux> actually, that doesn't matter so much
[22:21:21] <lightguard_jp> A weld 1.1.1 has to be in GF 3.1.1 (hopefully they do one)
[22:21:23] <mojavelinux> what's important is that the code is fixed
[22:21:37] <mojavelinux> because it takes 2 seconds to drop it into an existing glassfish installation
[22:21:43] <lightguard_jp> And better integration code :(
[22:21:48] <mojavelinux> however, we can't link to a snapshot reasonably, because it could change any day
[22:22:05] <mojavelinux> the current snapshot works
[22:22:11] <mojavelinux> so I say, cut the damn thing
[22:22:12] <gmorling> ok. if it is that easy then its good. I know updating Hibernate Validator is nearly impossible
[22:22:25] <mojavelinux> yep, the instructions are on brian's blog
[22:22:30] <mojavelinux> but they can be repeated in one line
[22:22:44] <mojavelinux> copy weld-ogi-bundle.jar to glassfish/modules/weld-osgi-bundle.jar and restart glassfish
[22:22:47] <mojavelinux> you are now upgraded
[22:22:52] <mojavelinux> of course, that assumes no api changes
[22:22:55] <mojavelinux> atm, there are none
[22:22:58] <mojavelinux> so, it works
[22:23:09] <gmorling> I'm just wondering how many people get this by their ops
[22:23:31] <mojavelinux> if we can get a weld 1.1.1 release, then we don't have to worry about the glassfish 3.1 out of the box, we just say "upgrade" is a requirement
[22:23:46] <mojavelinux> well, the thing is, to us, it doesn't matter
[22:23:52] <mojavelinux> because glassfish 3.1 is not compliant, period
[22:23:59] <bleathem> Not many poeple are going to run Seam 3 apps in production yet... at least not those who have problematic ops
[22:24:00] <mojavelinux> so, we say, we target a compliant environment
[22:24:08] <mojavelinux> however, we can't say that, if there is no migration path
[22:24:20] <mojavelinux> and the fault is mostly in Weld
[22:24:25] <mojavelinux> which makes it doubly bad
[22:24:30] <mojavelinux> so, we need a release of Weld
[22:24:57] <gmorling> I just would like to avoid Seam being blamed although we cant do anything about the problems
[22:25:10] <kenfinnigan> Do we need to support as6 running with weld trunk?
[22:25:11] <mojavelinux> #agreed Seam 3 can target Weld 1.1.1 instead of working around problems in vanilla GlassFish 3.1 if Weld 1.1.1 is released soon
[22:25:36] <gmorling> for when is Weld 1.1.1 expected?
[22:26:00] <mojavelinux> that's the problem, I don't know, and although I've requested a release, it doesn't seem to be making any difference
[22:26:54] *** bitshuffler has joined #seam-dev
[22:27:08] <mojavelinux> we would have to then support AS 6 with Weld 1.1.1 too, but I don't anticipate any problems there
[22:27:12] <bleathem> I'll follow up with my post to weld-dev, to rattle the cage
[22:27:28] <mojavelinux> I'm hoping shane can throw some weigh around here
[22:28:01] *** bitshuffler has quit IRC
[22:28:11] <mojavelinux> Weld 1.1.1 does not currently solve all problems, though, but it is a much better situation
[22:28:28] <mojavelinux> solve all glassfish problems that is
[22:28:42] *** bitshuffler__ has quit IRC
[22:28:50] *** koentsje has quit IRC
[22:28:57] <gmorling> How bad is the problem anyways (I was not too much involved)? Is it imaginable to release Seam 3 without Weld 1.1.1 or is this a deal breaker?
[22:29:31] <bleathem> Faces will not run on Vanilla Glassfish 3.1
[22:29:42] <bleathem> Weld 1.1.1-SNAPSHOT is required
[22:29:50] <mojavelinux> I thought it did
[22:30:00] <mojavelinux> i'm pretty sure it does
[22:30:07] <bleathem> Sorry, over stated
[22:30:10] <mojavelinux> here's the situation
[22:30:14] <bleathem> anything interesting doesn't
[22:30:20] <mojavelinux> we fixed deployment problems on vanilla glassfish
[22:30:31] <mojavelinux> meaning, adding seam jars won't break your deployment
[22:30:49] <mojavelinux> however, several features in solder (and thus other features in seam) just don't work
[22:31:15] <mojavelinux> except for the security issue, all features do work (from what we can tell) with the weld snapshot
[22:31:18] <bleathem> Sorry, I forgot you made changes to the Seam jars, moreso than just the Weld fixes.
[22:31:33] <mojavelinux> yeah, we hacked around shit in Seam to make it work
[22:31:34] <bleathem> retract my statement from the record :P
[22:32:02] <mojavelinux> I want to pull out those hacks as soon as we get people off of the vanilla glassfish 3.1 (either via a weld upgrade or glassfish 3.1.1)
[22:32:26] <mojavelinux> so, it's not a show stopper, but it's not pleasant either
[22:32:35] <mojavelinux> let's put it this way
[22:32:37] <mojavelinux> booking works
[22:32:39] <mojavelinux> on glassfish
[22:32:44] <mojavelinux> vanilla glassfish
[22:32:50] <mojavelinux> that's about all we can guarnatee
[22:33:29] <mojavelinux> because the visibility issues are not really apparent until you hit them
[22:33:59] <mojavelinux> without a full review of the seam codebase for potential problems...problems mind you, that should even be problems
[22:34:07] <gmorling> hmm, ok. all in all this sounds to me that we should wait for Weld 1.1.1 Final before going Final with Seam 3. We can't really tell people to use a snapshot version to get certain things working imo
[22:34:37] <mojavelinux> right, and I think Weld 1.1.1 could easily be released before the end of the week, if someone actually commits to it
[22:34:45] <mojavelinux> so that's the message we need to take to the Weld team
[22:34:58] <gmorling> agree
[22:35:01] <mojavelinux> solid
[22:35:22] <mojavelinux> #agreed Seam 3.0.0.Final will be much better off if a Weld 1.1.1 release could happen first
[22:35:33] <stuartdouglas> AFAIK only Pete and Ales have permission to do the release process
[22:35:50] <mojavelinux> yep, i know
[22:37:21] *** cbrock has joined #seam-dev
[22:37:21] *** cbrock has quit IRC
[22:37:21] *** cbrock has joined #seam-dev
[22:37:49] <mojavelinux> btw, I apologize if I sound a little irritated about this issue...it's taken an enormous amount of time and patience to work around something that isn't even a problem in Seam
[22:38:16] <bleathem> Irritation is shared all around
[22:38:19] <kenfinnigan> Perfectly understandable
[22:38:27] *** koentsje has joined #seam-dev
[22:38:43] <mojavelinux> okay, onwards. lincolnthree1 did you want to say something about forge?
[22:39:13] *** koentsje has quit IRC
[22:39:21] <lightguard_jp> He's always talking about Forge, you may need to be more specific :)
[22:39:26] <mojavelinux> btw, I'm still waiting on a link to the jira report for which issues need to be fixed
[22:39:32] <mojavelinux> oh, he asked to have the floor I believe
[22:41:17] <kenfinnigan> mojavelinux: Shall I create the report in JIRA tonight? (if I have access)
[22:41:41] <mojavelinux> sure, it shouldn't require any special access, just a filter that you save and mark as public
[22:41:44] <mojavelinux> then anyone can link to it
[22:41:51] <kenfinnigan> Will do
[22:42:23] *** PeteRoyle has joined #seam-dev
[22:42:59] <mojavelinux> this could be a bit of an experiment with how you do a target release filter across multiple projects in jira
[22:42:59] *** PeteRoyle has quit IRC
[22:43:10] *** PeteRoyle has joined #seam-dev
[22:43:42] <mojavelinux> it may be something like status = unresolved and fix version = 3.0.0.%
[22:43:53] <gmorling> Couldn't Shane make his filter public?
[22:44:09] <kenfinnigan> Probably also contains "seam" in project name
[22:44:20] <mojavelinux> oh, yes, you can select projects in a multi-select
[22:44:35] <mojavelinux> but yes, btw, I renamed the one project that was getting stuck in the middle
[22:44:41] <mojavelinux> so now you can select Seam Distribution
[22:44:42] <kenfinnigan> Will give it a shot if Shane hasn't released his first
[22:44:45] <mojavelinux> then shift select to Seam Validation
[22:44:48] <mojavelinux> and that's all the Seam 3 projects
[22:44:59] <mojavelinux> oops, should say Seam 3 Distribution
[22:45:11] <johnament> well, except you want to exclude the modules that aren't releasing yet, right?
[22:45:15] <mojavelinux> for the fix version, you may have to click on "advanced"
[22:45:26] <mojavelinux> oh yeah, good point
[22:45:37] <mojavelinux> i'm just saying in general, FYI
[22:45:40] <mojavelinux> let me info that
[22:46:07] <mojavelinux> #info when searching in JIRA, all projects between Seam 3 Distribution and Seam Validation are the Seam 3 modules (no other projects get stuck in the middle)
[22:46:26] <kenfinnigan> Cool
[22:46:37] <mojavelinux> just makes things simpler
[22:47:00] <kenfinnigan> Is the best place to have a list of modules for final in the full distribution build?
[22:47:23] <kenfinnigan> Where I can find a list that is
[22:47:33] <mojavelinux> actually, you know what?
[22:47:44] <mojavelinux> that should be a column on http://seamframework.org/Seam3/Status
[22:48:06] <kenfinnigan> There used to be a roadmap page with ticks for that
[22:48:07] <mojavelinux> jason, can you add a column for "In stack" or something
[22:48:15] <mojavelinux> wait
[22:48:16] <kenfinnigan> But I think it was removed
[22:48:18] <mojavelinux> we discussed this already
[22:48:25] <mojavelinux> we were going to split the table into two
[22:48:31] <mojavelinux> modules in the stack
[22:48:35] <mojavelinux> modules not yet in the stack
[22:48:44] <kenfinnigan> Sounds reasonable
[22:48:44] <mojavelinux> then, it's like a promotion when you get into the stack
[22:48:48] <mojavelinux> and there was much rejoicing
[22:48:49] <mojavelinux> yeah
[22:49:08] <mojavelinux> of course, we should have this list in the distribution too, as you are suggesting ken
[22:49:10] <kenfinnigan> And a very visually intuitive way of seeing what is in the stack
[22:49:17] <mojavelinux> the web page is for the web crawlers
[22:49:21] <mojavelinux> yes
[22:49:23] <mojavelinux> and the humans
[22:49:45] <mojavelinux> hahaha
[22:49:55] <kenfinnigan> Is there a full dist readme the list could be added to?
[22:50:05] <bleathem> does this work for anyone?
[22:50:06] <bleathem> https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12314294
[22:50:16] <mojavelinux> #action split table of modules into two tables, one for modules in the stack, one for modules not in the stack http://seamframework.org/Seam3/Status
[22:50:33] <mojavelinux> dist readme should be in dist/
[22:50:55] <gmorling> One question about dependency versions
[22:51:00] <mojavelinux> what's up?
[22:51:08] <kenfinnigan> Ok, will look at adding a list to it
[22:51:28] *** daniel_hinojosa has joined #seam-dev
[22:51:35] <gmorling> to be part of the stack a module should require specific versions, right? Seam Validation is based specifically on HV 4.2 (Beta) though
[22:51:44] <gmorling> should = shouldn't
[22:52:46] <gmorling> I thinks this would be an issue at least if we try tro create a combined jar for all stock modules
[22:53:43] <mojavelinux> seam validation is a special case because it's a vendor extension of a spec exclusively
[22:53:56] <mojavelinux> all other seam modules primarily code to EE 6
[22:54:06] <kenfinnigan> I brought up a related issue with shane last night about seam-bom
[22:54:09] <mojavelinux> and have no relationship to a spec implementation
[22:54:27] <mojavelinux> well, okay, seam conversation is in the same boat
[22:54:39] <kenfinnigan> Post final, as modules have their own releases
[22:55:05] <kenfinnigan> Seam-bom will be stack bom and not what is the latest release of a module
[22:55:07] <mojavelinux> #action kenfinnigan add a list of modules in the stack release to the dist readme.txt
[22:55:28] <mojavelinux> yes, correct, seam-bom is a baseline
[22:55:35] <mojavelinux> doesn't mean you can upgrade a module in your application
[22:55:35] <kenfinnigan> Yey! I have an action!
[22:55:44] <mojavelinux> sorry, flub
[22:55:50] <mojavelinux> you can upgrade a module in your application
[22:56:05] <mojavelinux> the point is that w/ seam-bom, you get a starting point, so you don't have to worry about which version is the default
[22:56:25] <mojavelinux> or I should say recommended
[22:56:30] <mojavelinux> so let's say I'm coding up seam booking
[22:56:33] <mojavelinux> I add seam-bom
[22:56:33] <kenfinnigan> Ok. Always thought it was the latest as opposed to starting point
[22:56:42] <mojavelinux> I just say "seam-faces", "seam-security"
[22:56:46] <kenfinnigan> That makes more sense
[22:56:47] <mojavelinux> oh, but there is an update to seam-faces
[22:56:56] <mojavelinux> so now I just upgrade it with an explicit version
[22:57:01] <mojavelinux> now, the question comes in
[22:57:15] <mojavelinux> what about if seam-faces needs a newer version of seam-security, which isn't in the seam-bom
[22:57:29] <mojavelinux> so then seam-faces *temporarily* requires an explicity version of seam-security
[22:57:37] <mojavelinux> to be rectified on the next seam-bom update
[22:57:44] <mojavelinux> so the way I see it, the versions sort of float in and out
[22:57:52] <kenfinnigan> Ok. Seems logical
[22:57:56] <gmorling> I see
[22:58:08] <mojavelinux> but this is very much a "learn as we go" process
[22:58:15] <gmorling> So this shouldn't be a real problem then
[22:58:28] <mojavelinux> because there is very little in the way of reference points here
[22:58:42] <mojavelinux> right, going "versionless" is not a hard requirement
[22:58:49] <mojavelinux> think of it the other way, as a convenience
[22:59:44] <mojavelinux> #info seam-bom sets module versions as a convenience to the end developer and as a recommendation of compatible versions
[22:59:46] <lincolnthree1> sorry, im here
[22:59:50] <mojavelinux> #info ;modules and/or applications can set the version of a module explicitly
[23:00:08] <lincolnthree1> (i was here all along, just not "here")
[23:00:10] <mojavelinux> #info modules should request the update in the next seam-bom release and remove the version once it is there
[23:00:24] <mojavelinux> #info but it does not have to happen urgently
[23:01:02] *** koentsje has joined #seam-dev
[23:01:27] <kenfinnigan> So if a seam module has an explicit version for a dependency
[23:01:36] <mojavelinux> #action document the seam-bom version policy on the coding guidelines page
[23:01:48] <mojavelinux> #action document the purpose of the seam-bom in the seam module refguide <- this should be a jira
[23:01:52] <kenfinnigan> We should raise a jira on the main seam project to update it?
[23:02:04] <mojavelinux> that's correct
[23:02:09] <kenfinnigan> Cool
[23:02:20] <mojavelinux> however, we still have to feel that out...as to how urgent that really is
[23:02:35] *** koentsje has quit IRC
[23:03:35] <mojavelinux> we are going to learn some things about version matrices :)
[23:04:08] *** cbrock has quit IRC
[23:04:45] <mojavelinux> we are over time
[23:05:23] <mojavelinux> whatever you can do to help resolve issues for final, it would be most appreciated and get us back to innovating :)
[23:05:29] <gmorling> So will you keep us posted on the mailing list about the release/Weld issue?
[23:05:46] <mojavelinux> yes, that will be a decision we'll make in the coming days
[23:06:07] <mojavelinux> hopefully we get the support of the Weld team on this one
[23:06:11] * mojavelinux prays
[23:06:23] <gmorling> I'm confident :-)
[23:06:58] <mojavelinux> btw, if you are interested in scala and cdi, daniel_hinojosa has a case study you can check out
[23:07:01] <mojavelinux> pretty cool stuff https://github.com/dhinojosa/cdi-scala
[23:07:51] <mojavelinux> thanks everyone for coming and for participating. seam 3.0.0.final is the beginning of an awesome project :)
[23:07:56] <mojavelinux> I can't wait to see what happens next
[23:08:18] <mojavelinux> #endmeeting
[23:08:20] <daniel_hinojosa> mojavelinux: thank you
[23:08:23] <jbott> Meeting ended Wed Mar 23 22:08:23 2011 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[23:08:23] <jbott> Minutes:        http://people.redhat.com/~manderse/irc.freenode.org/meetings/seam-dev/2011/seam-dev.2011-03-23-21.06.html
[23:08:23] <jbott> Minutes (text): http://people.redhat.com/~manderse/irc.freenode.org/meetings/seam-dev/2011/seam-dev.2011-03-23-21.06.txt
[23:08:23] <jbott> Log:            http://people.redhat.com/~manderse/irc.freenode.org/meetings/seam-dev/2011/seam-dev.2011-03-23-21.06.log.html
[23:08:31] <mojavelinux> btw, quick post-meeting question
[23:08:51] <mojavelinux> are we in agreement that the spreadsheets functionality should be part of seam-reporting?
[23:09:09] <bleathem> as opposed to a part of something else?
[23:09:10] <mojavelinux> I think a submodule, who's with me?
[23:09:13] <mojavelinux> like
[23:09:20] <mojavelinux> org.jboss.seam.reporting.spreadsheet
[23:09:27] <mojavelinux> seam-reporting-spreadsheets
[23:09:37] <mojavelinux> seam reporting, seam reports or seam report?
[23:09:39] <bleathem> We want the functionality
[23:09:48] <bleathem> is it just a question of naming the module?
[23:09:52] <kenfinnigan> Seam reporting sounds best
[23:09:56] <mojavelinux> it's a question of scope
[23:09:56] <lightguard_jp> I'm fine having it as part of reporting
[23:10:13] <mojavelinux> yeah, I think too fine-grained and we sort of make it impossible to follow
[23:10:33] <mojavelinux> so like pdf generation would go here too
[23:10:36] <bleathem> seam reportingh
[23:10:42] <bleathem> ugh, no h
[23:10:45] <mojavelinux> excellent, motion to create seam-reporting
[23:10:50] <kenfinnigan> Agreed
[23:11:00] <bleathem> seconded!
[23:11:01] <mojavelinux> excellent...sound like we already have some working code too
[23:11:08] <mojavelinux> so something to play with very soon
[23:11:39] <lightguard_jp> Meeting list updated on the site
[23:12:02] <gmorling> mojavelinux: cool you got the JIRA/Git link set up. Do you know when this will be available for Validation?
[23:12:41] <mojavelinux> oh, I forgot about that announcement, though I did send it to the mailinglist so probably sufficient there
[23:12:45] <mojavelinux> i'm waiting on sysops
[23:12:48] <mojavelinux> vpn was down today
[23:12:59] <mojavelinux> so no news yet
[23:13:26] <mojavelinux> not added yet
[23:13:40] <gmorling> ok.
[23:13:49] *** jharting has quit IRC
[23:13:51] <mojavelinux> grr, gotta twist some arms :)
[23:14:05] <gmorling> btw. I promoted the JIRA workflow on hibernate-dev :-)
[23:14:18] <gmorling> hopefully we'll be using it there, too
[23:14:59] *** kenfinnigan has quit IRC
[23:17:06] <mojavelinux> yes, that is awesome
[23:17:12] <mojavelinux> you know that there is now one for all of jboss, right?
[23:17:16] *** koentsje has joined #seam-dev
[23:17:21] <mojavelinux> as soon as final is out, i'll switch over all the seam projects
[23:17:35] <mojavelinux> it's basically a copy of the workflow we have, with some improvements where we had bugs
[23:18:54] <gmorling> ah, I wasn't aware that there will be one unified workflow. But that's definitly good news. But Hibernate's JIRA is running on a different instance (at Atlassian), so I guess you mean the JBoss instance=
[23:20:11] <sbryzak> morning all
[23:20:38] *** cbrock has joined #seam-dev
[23:20:38] *** cbrock has quit IRC
[23:20:38] *** cbrock has joined #seam-dev
[23:20:49] <lincolnthree1> hi sbryzak
[23:22:35] <mojavelinux> yes, the jboss instance
[23:22:37] <mojavelinux> oh, good point
[23:23:11] <mojavelinux> so yes, you can copy the workflow, but I would recommend copying the on setup by jboss IT
[23:23:15] <mojavelinux> both with get the job done though :)
[23:24:32] <gmorling> well, let's see what Steve says about it, I think he is in charge of Hibernate's JIRA.
[23:36:31] <lincolnthree1> Hey mojavelinux. I have a late birthday present for you
[23:36:39] <mojavelinux> yeah?
[23:36:43] <lincolnthree1> interested? ;)
[23:36:45] <lincolnthree1> http://pastebin.com/ZAF30gwb
[23:37:03] <sbryzak> gmorling: ping
[23:37:22] <gmorling> pong?
[23:37:43] <sbryzak> hey gunnar, about the change of default profile for the validation example
[23:37:48] <mojavelinux> that's cool!
[23:37:52] <lincolnthree1> booya ;)
[23:38:05] <mojavelinux> man, just being able to command maven to configure, that is a lifesaver
[23:38:14] <sbryzak> all seam modules by default should build for jboss AS
[23:38:31] <lincolnthree1> yeah, this is stuff that people just hate to figure out
[23:38:39] <lincolnthree1> and since I'm recommending shade for all plugin authors
[23:38:43] <lincolnthree1> i needed it
[23:39:00] <mojavelinux> that's the beginning of a lot of good plugins
[23:39:05] <gmorling> Hmmm, I see. This just makes life harder for testing on Jetty
[23:39:06] <lincolnthree1> yeah. i already tested it
[23:39:11] <lincolnthree1> develop in eclipse then:
[23:39:15] <mojavelinux> definitely worth documenting as an idea
[23:39:26] <lincolnthree1> $ forge source-plugin ~/path-to-project
[23:39:27] <mojavelinux> of where to go with plugins
[23:39:42] <lincolnthree1> so you can work on a plugin locally and keep trying out new versions as you go
[23:40:02] <gmorling> Also importing the project into an IDE has to happen now using the profile as there is Jetty based test
[23:40:25] *** johnament has quit IRC
[23:42:03] <sbryzak> hmm
[23:42:54] <sbryzak> we'll have to figure out some way to work around this
[23:43:07] <sbryzak> by default, if someone builds the example and deploys to JBossAS, the deployment fails
[23:43:44] <mojavelinux> i think the policy is that the default build has to work on a compliant EE server
[23:44:02] <mojavelinux> JBoss AS is a compliant EE server, hence, what shane says is effectively accurate
[23:44:10] <mojavelinux> but the focus is not on AS, but rather EE
[23:44:13] <sbryzak> mojavelinux: in terms of libraries it must be JBAS specifically
[23:44:26] <gmorling> the problem is that the build differs for AS and GF
[23:44:55] <mojavelinux> in my mind, that's a problem with EE
[23:44:57] <mojavelinux> it shouldn't be the case
[23:45:01] <sbryzak> there's no problem including build configs for other app servers, in fact that's encouraged
[23:45:16] <gmorling> so my idea was you need a specific build for an EE server anyway, so for the ease of testing on a servlet container let the jetty profile be the default
[23:45:20] <mojavelinux> not if all these promises about EE are remotely true
[23:45:40] <gmorling> hehe. the problem is not about deployment descriptors but rather about dependencies
[23:45:56] <mojavelinux> there shouldn't be dependency differences, that's my point
[23:46:00] <sbryzak> gmorling: the problem is our users will expect the examples to run out of the box on JBAS
[23:46:01] <mojavelinux> not saying there aren't, but there shouldn't be
[23:46:12] <mojavelinux> and I think projects like seam are here to push back on this issue
[23:46:14] <mojavelinux> imo
[23:46:15] <sbryzak> in fact we've stated that's our default platform for seam 3
[23:46:30] <mojavelinux> I know that the lure of using jetty is appealing
[23:46:41] <mojavelinux> and there is good merit behind that position
[23:46:47] <mojavelinux> because that's what has sucked about EE
[23:46:53] <mojavelinux> but, our goal
[23:47:04] <mojavelinux> is to make EE more attractive than jetty
[23:47:17] <mojavelinux> and hence, we are trying to close that gap so that you won't want to use jetty by default
[23:47:34] <gmorling> I'm generally with you. But reality looks different, at least atm. :-)
[23:48:11] <gmorling> Just run the main class with embedded Jetty vs. building/deploying a WAR
[23:48:18] <mojavelinux> yes, this is our current challenge
[23:48:23] <gmorling> this really makes the difference
[23:48:25] <mojavelinux> however, there is another point to this
[23:48:39] <mojavelinux> you shouldn't be deploying the app constantly to see if it works
[23:48:44] <mojavelinux> instead, you should be using arquillian tests
[23:48:48] <mojavelinux> in fact, the rise of jetty
[23:48:59] <mojavelinux> can mostly be attributed to the lack of any decent integration testing environment for EE
[23:49:09] <mojavelinux> people test by deploying the app
[23:49:11] <mojavelinux> and praying
[23:49:11] <sbryzak> gmorling: how do you get the tests to run?
[23:49:23] <mojavelinux> so if you are using jetty:run or the main class
[23:49:33] <mojavelinux> I'm willing to wager that it's because you are testing something
[23:49:50] <gmorling> sbryzak: which one do you mean?
[23:49:51] <mojavelinux> and the message I'm attempting to get out there is that you should be using tests
[23:50:00] <mojavelinux> but again, I agree with you about the way things are now
[23:50:04] <sbryzak> example tests
[23:50:04] <mojavelinux> we are just trying to change that :)
[23:50:45] <gmorling> you can either run org.jboss.seam.validation.JettyRunner from within your IDE
[23:50:46] <sbryzak> there doesn't seem to be a surefire configuration
[23:51:06] <gmorling> or you run mvn jetty:run on the CLI
[23:51:22] <sbryzak> mvn jetty:run just seems to start the server
[23:51:35] <mojavelinux> it should deploy the app too, in place
[23:51:47] <sbryzak> yeah it does, and it works if i specify -Dservlet
[23:51:50] <gmorling> this is currently not an automated test strictly speaking. its more try it out manually in your browser
[23:51:54] <mojavelinux> btw, I do fully comprehend the appeal of jetty:run btw
[23:52:05] <sbryzak> ah, in that case it seems to work fine
[23:52:17] <mojavelinux> but I'm still challenging that while that's good, we can do better, and we can do it in a way that's compliant to EE, instead of jetty's hacked up pseudo-java ee
[23:52:43] <mojavelinux> and as I've said in the past, we should have
[23:52:49] <mojavelinux> jbossas:run
[23:52:54] <mojavelinux> but we are waiting on AS7 to get that
[23:52:57] <mojavelinux> oh, and btw
[23:53:06] <mojavelinux> forge should help close the gap in the interim, perhaps even in the long term too
[23:53:14] <mojavelinux> because again, it comes down to shitty tools for developers
[23:53:16] <gmorling> sbryzak: we need to update the example description that one now has to do mvn jetty:run -Dservlet
[23:53:22] <mojavelinux> that's why we turned to jetty
[23:53:26] <mojavelinux> because it was better than nothing
[23:53:31] <sbryzak> gmorling: no problem, i'll do that
[23:54:49] <gmorling> cool. there is readme file in the helloworld dir
[23:54:57] <sbryzak> already done :)
[23:55:17] <gmorling> also the IDE section should have a note on the profile
[23:56:02] <sbryzak> ah, down the bottom of the readme.. ok
[23:56:20] <sbryzak> we should really get it updated to use arquillian
[23:56:50] <sbryzak> i'll just update the readme for now, and we can look at it post 3.0 final
[23:56:56] <gmorling> yep, I also thought about this. At least additionally.
[23:57:00] <mojavelinux> so gmorling, i'm not disagreeing with you that you want to use jetty, i'm just trying to emphasize that developers should have to use jetty to get a good developer experience
[23:57:02] <mojavelinux> so it's a wip
[23:57:23] <mojavelinux> but arquillian is off to a hell of a start in solving it
[23:57:27] <mojavelinux> and please keep pushing
[23:58:34] <gmorling> mojavelinux: I see your point. Though I think Jetty has its purposes also without being there for annoyed developers testing JEE apps :-)
[23:59:02] <jbossbot> git [validation] push master 08cccb7.. Shane Bryzak update readme to fix jetty command line params
[23:59:02] <jbossbot> git [validation] push master 702a1bc.. Shane Bryzak add note on maven profile for testing in IDE
[23:59:03] <jbossbot> git [validation] push master URL: http://github.com/seam/validation/compare/6898be1...702a1bc
[23:59:51] <mojavelinux> my feeling about this is that a minimal environment should be the web profile; anything less needs to be supplemented to be useful; therefore, until jetty is a web profile, it's deficient in my eyes for standards-based enterprise development
[23:59:55] <sbryzak> the biggest issue is conformity





top