[00:10:12] *** rruss has joined #seam-dev
[00:12:57] <jbossbot> git [solder] push master 473a809.. Dan Allen fix reference to Weld Extensions
[00:12:57] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/3665aee...473a809
[00:30:34] *** mbg has joined #seam-dev
[00:30:34] *** mbg has quit IRC
[00:30:34] *** mbg has joined #seam-dev
[00:31:45] *** mbg has quit IRC
[00:51:45] *** rruss has quit IRC
[02:05:20] *** aslak_ has joined #seam-dev
[02:05:30] *** aslak_ has quit IRC
[02:29:21] *** aslak has quit IRC
[02:53:55] *** mbg has joined #seam-dev
[03:19:13] *** rruss has joined #seam-dev
[03:50:16] *** lincolnthree1 has joined #seam-dev
[03:58:14] *** lincolnthree has quit IRC
[04:30:54] *** lightguard_jp has joined #seam-dev
[04:48:54] *** rruss has quit IRC
[06:18:16] *** rruss has joined #seam-dev
[06:49:24] *** bleathem_ has joined #seam-dev
[06:49:41] <bleathem_> Howdy
[06:49:52] <lightguard_jp> Hey
[06:50:06] <bleathem_> Hey Jason
[06:50:18] <bleathem_> I'm not so familiar with Weld extensions...
[06:50:36] <bleathem_> How can I get the BeanAware functionality in my class without extending it?
[06:50:43] <bleathem_> I'm already extending another class.
[06:51:05] <bleathem_> (This is for the Faces Exception handler for Seam Catch)
[06:51:15] <lightguard_jp> Ouch
[06:51:22] <lightguard_jp> You can't just inject the bean manager?
[06:51:48] <jbossbot> git [catch] push master 6debb12.. Dan Allen test for ignoring decorators and interceptors
[06:51:48] <jbossbot> git [catch] push master 9b1d82f.. LightGuard Fixes SEAMCATCH-21
[06:51:49] <jbossbot> jira [SEAMCATCH-21] Add isMarkedHandled() to CaughtException [Resolved, Minor, Jason Porter] https://jira.jboss.org/browse/SEAMCATCH-21
[06:51:49] <jbossbot> git [catch] push master 2ae53b7.. LightGuard Fixes SEAMCATCH-22
[06:51:49] <jbossbot> jira [SEAMCATCH-22] Name improvements for flow directives [Resolved, Major, Jason Porter] https://jira.jboss.org/browse/SEAMCATCH-22
[06:51:49] <jbossbot> git [catch] push master 18fc443.. LightGuard Fixes SEAMCATCH-19
[06:51:50] <jbossbot> jira [SEAMCATCH-19] Provide a way to rethrow a different exception [Resolved, Minor, Jason Porter] https://jira.jboss.org/browse/SEAMCATCH-19
[06:51:50] <jbossbot> git [catch] push master fee8f40.. LightGuard Implements SEAMCATCH-23
[06:51:50] <jbossbot> jira [SEAMCATCH-23] Handlers without qualifiers should be notified even if ExceptionToCatch has qualifiers [Reopened, Major, Jason Porter] https://jira.jboss.org/browse/SEAMCATCH-23
[06:51:50] <jbossbot> git [catch] push master 46df7b8.. LightGuard Files to test interceptors and decorators aren't picked up.
[06:51:51] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/ef45566...46df7b8
[06:51:57] <bleathem_> whoa.
[06:52:04] <bleathem_> someons busy :P
[06:52:16] <lightguard_jp> Eh, a little bit today and yesterday
[06:52:37] <bleathem_> I could try injecting it.
[06:52:56] <bleathem_> Feels funny injecting into the ExceptionHandler wrapper for some reason
[06:53:08] <bleathem_> Would it be CDI managed?
[06:53:25] <lightguard_jp> Should be
[06:53:34] <bleathem_> doesn't have a no args constructor
[06:53:38] <lightguard_jp> Won't know until you try :)
[06:53:44] <bleathem_> that is a requirement isn't it?
[06:53:50] <lightguard_jp> You could create one
[06:54:08] <bleathem_> Yeah, but JSF sets the parent via the constructor call
[06:54:26] <lightguard_jp> Hrm
[06:55:24] <bleathem_> I'm pretty sure there's a programmatic way to get the bean manager
[06:55:32] <bleathem_> i think I saw it in Seam Faces somewhere.
[06:55:33] <lightguard_jp> You need the bean manager to fire the event?
[06:55:42] <lightguard_jp> JNDI lookup
[06:55:46] <lightguard_jp> Or through the facescontext
[06:55:46] *** mojavelinux has joined #seam-dev
[06:55:49] <bleathem_> Following Dan's suggestion of making sure Seam Catch is present
[06:55:53] <lightguard_jp> There's the guy to ask
[06:56:04] <bleathem_> Ah, hey Dan!
[06:56:57] <bleathem_> mojavelinux: ping
[06:57:24] <lightguard_jp> Lol, he's looking something up
[06:57:32] <lightguard_jp> Ah
[06:57:34] <lightguard_jp> Hm
[06:57:55] <bleathem_> BeanManagerAccessor.getBeanManager();
[06:57:56] <lightguard_jp> Try looking it up via the facescontext
[06:58:03] <lightguard_jp> There you go
[06:58:06] <lightguard_jp> Not the best, but it'll work
[06:58:13] <lightguard_jp> Should also be in the FacesContext somewhere.
[06:58:53] <bleathem_> Curious why it's not the best.
[06:58:54] <bleathem_> ?
[07:01:25] <mojavelinux> so you need the BeanManager but you aren't using Seam Faces (or are outside of it somehow?)
[07:01:34] <mojavelinux> I should say, what is the context
[07:02:06] <lightguard_jp> He's taking a stab at the Catch integration with Faces
[07:02:33] <bleathem_> I'm extending ExceptionHandlerWrapper, and so I can't inject the beanManager, but want to look it up.
[07:02:41] <mojavelinux> ah, gotcha
[07:02:46] <bleathem_> so far I figured I could use BeanManagerAccessor.getBeanManager();
[07:03:10] <mojavelinux> yes, that works...it will likely pull it from the servlet context, which is where it gets stored at the start of the app
[07:03:23] <mojavelinux> the faces module stores it there, as does the servlet module as does solder ;)
[07:03:28] <mojavelinux> we need some consolidation :)
[07:03:40] <bleathem_> then it's sure to find it there!
[07:03:41] <mojavelinux> hehehe, but no matter, because now you are sure it's there :)
[07:03:55] <mojavelinux> it's stored under an attribute w/ the same name as the BeanManager class name
[07:04:08] <mojavelinux> though the accessor abstracts it away
[07:04:20] <bleathem_> abstraction is good!
[07:04:29] <mojavelinux> consults other providers if for some reason it can't be found, though the servlet context provider is the highest priority I'm pretty sure
[07:04:44] <mojavelinux> the reason is, in cdi 1.1, it should be there by spec
[07:04:47] <mojavelinux> rules
[07:04:54] <mojavelinux> which is much better than only JNDI
[07:05:07] <mojavelinux> I think with those two, it's nice coverage...though something for SE applications would be nice too
[07:05:36] <lightguard_jp> bleathem_: Here's Pete's note on that class:
[07:05:37] <lightguard_jp> **WARNING** This class is NOT a clever way to get the BeanManager, and should be avoided at all costs. If you need a handle to the BeanManager you should probably register an Extension instead of using this class; have you tried using @Inject?
[07:05:51] <lightguard_jp> :)
[07:05:58] <bleathem_> yikes, strong warning!
[07:06:15] <bleathem_> Well, it'll get this going - proof of principle
[07:06:26] <bleathem_> refinement can be added later
[07:07:50] <bleathem_> I'm doing all this Faces/Catch integration in Faces impl.  Should I be doing anything in Faces API?
[07:08:08] <mojavelinux> you'll see SeamApplicationWrapper provides injection by overriding createValidator, etc
[07:08:28] <mojavelinux> nope, you only need the faces api when you get into declarative handling
[07:08:36] <bleathem_> ok
[07:08:39] <mojavelinux> oh, we should have a @FacesRequest qualifier
[07:08:40] <mojavelinux> for the exception
[07:08:45] <mojavelinux> so handlers know it's coming from JSF
[07:08:52] <mojavelinux> or can filter the handler that way
[07:09:09] <bleathem_> ok.  I'll put that in the api
[07:09:26] <lightguard_jp> Yep
[07:09:32] <bleathem_> this is fun'
[07:09:34] <mojavelinux> put it in org.jboss.seam.faces.FacesRequest
[07:09:51] <mojavelinux> I'm still thinking whether we need *Request at the end of it
[07:10:20] <bleathem_> Why Request? (over somtehing else)
[07:10:23] <mojavelinux> like we could have qualifiers (when considering all modules) like @Faces, @Rest, @Web (which is a catch all)
[07:10:28] *** oskutka has joined #seam-dev
[07:10:36] <bleathem_> Not @FacesException?
[07:10:39] <mojavelinux> so for instance, if I want a handler to deal with a REST failure
[07:10:42] <mojavelinux> then I have
[07:11:02] <mojavelinux> void catchAllRestFailures(@Handles @Rest CaughtException<Throwable> caught) {}
[07:11:04] <lightguard_jp> @Faces makes more sense
[07:11:10] <lightguard_jp> Especially for JSF
[07:11:21] <lightguard_jp> because it may not simply be a request (yes, technically it is though)
[07:11:28] <mojavelinux> we have that already then
[07:11:42] <lightguard_jp> Fair enough, just reuse it.
[07:12:00] <mojavelinux> yep...I think I might change the servlet module once again from @WebRequest to just @Web
[07:13:06] <bleathem_> right - we don't need the *Exception, because the qualifier isn't restrcited to being used with exception handling.
[07:13:21] <bleathem_> catchin' on... bit by bit
[07:16:06] <mojavelinux> yep, the whole essence of cdi, and hence seam 3
[07:16:14] <mojavelinux> is a fluent conversation with your code
[07:16:18] <mojavelinux> and this is a lot of fun
[07:16:31] <mojavelinux> sometimes tough, because you wrestle over how to make that work
[07:16:37] <mojavelinux> but when you nail it, you just love reading it
[07:16:57] <mojavelinux> :)
[07:19:39] <bleathem_> Faces maven dependency on Catch should be of scope provided right?
[07:19:59] <bleathem_> So that it doesn't pull it in automatically?
[07:20:09] <mojavelinux> that's absolutely correct
[07:28:05] <bleathem_> lightguard_jp is ceam catch not yet in the jboss maven repo?
[07:28:11] <bleathem_> ^seam catch
[07:28:38] <lightguard_jp> Should be
[07:28:54] <lightguard_jp> https://repository.jboss.org/nexus/content/groups/public/org/jboss/seam/catch/
[07:29:08] <lightguard_jp> Alpha1 and Alpha2 are there
[07:30:11] <bleathem_> oic, the artifact is seam-catch-{api,impl}
[07:30:24] <lightguard_jp> Yeah
[07:30:32] <bleathem_> the smfwk.org page says it's just seam-catch
[07:30:36] <lightguard_jp> I think at some point we'll do a shaded jar that's just seam-catch
[07:30:42] <bleathem_> Maven artifact: org.jboss.seam.catch:seam-catch
[07:30:46] <lightguard_jp> Which page?
[07:30:54] <bleathem_> http://seamframework.org/Seam3/CatchModule
[07:31:28] <mojavelinux> I already have the shaded pom.xml magic ready to create seam-catch.jar...let's do it in Alpha3
[07:31:34] <mojavelinux> all we need to decide is what to call the folder
[07:31:41] <mojavelinux> in servlet, I called it "combined"
[07:31:52] <mojavelinux> i'm open to suggestions
[07:31:58] <mojavelinux> see http://github.com/seam/servlet
[07:32:20] <lightguard_jp> fixed
[07:32:36] <lightguard_jp> It's another folder??
[07:33:05] <lightguard_jp> Once again, thank you maven for being brain dead
[07:33:26] <mojavelinux> hahaha
[07:33:29] <lightguard_jp> I'd harvest organs, but I've seen it's insides, there's nothing worth taking that hasn't already been harvested
[07:33:33] <mojavelinux> yeah, I tried to figure out if I could put this in dist/
[07:33:55] <mojavelinux> if someone figures it out, i'm all ears
[07:34:07] <mojavelinux> for now, I put the prototype in combined/pom.xml :)
[07:34:23] <lightguard_jp> Want to use Gradle?.
[07:35:34] <bleathem_> Seam3 has already got me using eclipse, jboss as, and git
[07:35:43] <bleathem_> at least I'm familiar with maven!
[07:37:54] <bleathem_> mojavelinux: you used beanManager.getBeans(...) to determine if Seam Catch is on the classpath, or is that done with the @Requires("...") ?
[07:37:57] <bleathem_> from https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/seam/servlet/filter/CatchExceptionFilter.java
[07:39:32] <mojavelinux> well, it's tricky :)
[07:39:39] <bleathem_> go figure :P
[07:39:44] <lightguard_jp> Why did you switch to eclipse for this?
[07:39:46] <mojavelinux> it's tricky because a filter isn't technically a bean, or it isn't in all environments
[07:39:52] <bleathem_> for fun
[07:39:56] <mojavelinux> so I have this sort of half in/half out approach to things in servlet
[07:40:00] <bleathem_> and to deploy to JBoss AS
[07:40:05] <mojavelinux> and in this case, I'm basicallly disabling the bean if it works
[07:40:12] <mojavelinux> if that doesn't work, I have a secondary check, which you see
[07:40:25] <mojavelinux> it's sort of hacky because servlet is just sort of like wild west
[07:40:55] <bleathem_> So exception handler wrappers are kind of similar in that they aren't managed by CDI
[07:40:58] <mojavelinux> so yes, @Requires vetos the bean if the CatchExtension isn't present
[07:41:02] <mojavelinux> but that may not disable the filter
[07:41:08] <mojavelinux> yep
[07:41:37] <bleathem_> so I want to use the bean manager to tell me if seam catch is present, and only delegate exceptions if it is present
[07:41:53] <lincolnthree1> Why not just use Class.forName() ?
[07:42:02] <lincolnthree1> That will tell you if it's there.
[07:42:16] <lincolnthree1> ClassDefNotFoundException == not present.
[07:42:20] <mojavelinux> actually, I really try to stay away from that type of check...
[07:42:29] <mojavelinux> better to leave that lower level or else we get into all sorts of osgi trouble
[07:42:36] <mojavelinux> like for instead if Seam became an osgi service
[07:42:45] <mojavelinux> better is to allow cdi to tell you if something is there or not
[07:42:48] <lincolnthree1> true I suppose
[07:42:51] <mojavelinux> so checking for the bean is safer
[07:43:02] <mojavelinux> basically, if bean is there, class must be there too
[07:43:09] <lincolnthree1> How do you check for the bean without a type? ;) Unless you're using the API all the time
[07:44:11] <mojavelinux> hehehe, an indirection
[07:44:31] <mojavelinux> you use @Requires("") on the type
[07:44:37] <mojavelinux> then check for the bean that has @Requires ;)
[07:44:39] <mojavelinux> woot
[07:44:41] <lincolnthree1> Ah
[07:44:53] <mojavelinux> nice little pattern I think
[07:44:58] <mojavelinux> pushes all type checking into one place
[07:45:08] <mojavelinux> I should say class checking
[07:45:15] <bleathem_> Will that work with JSF exception handlers?
[07:45:35] <bleathem_> they aren't CDI managed, so whtat will the @Requires do?
[07:45:59] <mojavelinux> what I'm saying in a general sense
[07:46:03] <mojavelinux> is that you could create a dummy class
[07:46:08] <mojavelinux> that has @Requires("")
[07:46:17] <mojavelinux> then check for the dummy class as a bean w/ the bean manager
[07:46:18] <bleathem_> Ah, ok
[07:46:36] <mojavelinux> though, it would be best if you can figure out whether you can shift that to a class you are actually using
[07:46:44] <mojavelinux> so you don't have dead weight in the code base :)
[07:47:09] <mojavelinux> the other point I should make is this
[07:47:26] <mojavelinux> when working at the boundary of cdi, you should try to think about how to shift the execution context into the managed environment
[07:47:38] <mojavelinux> I do this a lot in the servlet module...though I'm mostly using observers
[07:48:07] <mojavelinux> basically, get me inside a managed bean...so the nastiness of not having injection can be relegated to a single place
[07:48:16] <bleathem_> makes sense, but in this case, the exception wrapper isn't doing much
[07:48:29] <mojavelinux> well, that's true...and you just have to send an event
[07:48:57] <mojavelinux> that's the easiest way to interact w/ cdi from outside
[07:49:00] <mojavelinux> you event in
[07:49:07] <mojavelinux> and in this case ,you are sending the event to catch
[07:49:16] <mojavelinux> so it's even simpler problem to deal with
[07:49:40] <mojavelinux> but what I would do is just annotated the ExceptionHandlerWrapper then w/ @Requires
[07:49:50] <mojavelinux> and check for itself
[07:50:00] <mojavelinux> you aren't using it as a bean, so it's harmless
[07:50:37] <mojavelinux> basically, these fringe situations are about tricks
[07:50:49] <mojavelinux> we are doing tricks so that the end developer doesn't have to worry about this stuff
[07:51:01] <mojavelinux> integration isn't always pretty...the effect of integration is
[07:59:04] <lightguard_jp> Not sure I'm liking the way the focus is going in http://www.seamframework.org/Seam3/CatchModuleOverview :)
[07:59:11] <lightguard_jp> Less would be better
[07:59:26] <lightguard_jp> But by the time Alpha3 is done we should be pretty stable.
[08:02:40] *** mbg has quit IRC
[08:04:59] <bleathem_> beanManager.fireEvent(new ExceptionToCatch(t), @Faces);
[08:05:06] <bleathem_> how do I get the @Faces in there?
[08:05:18] <bleathem_> is it annotationliteral<> ?
[08:05:24] <lightguard_jp> You could also Inject an event
[08:05:33] <bleathem_> cant inject :(
[08:05:35] <lightguard_jp> Use the FacesLiteral
[08:05:37] <lightguard_jp> Ah
[08:05:47] <lightguard_jp> Should be a FacesLiteral.INSTANCE
[08:05:49] <bleathem_> oh, there already is a leteral
[08:05:50] <lightguard_jp> If not, then create one
[08:05:51] <bleathem_> got it.
[08:07:23] *** bleathem_ has quit IRC
[08:07:27] *** bleathem__ has joined #seam-dev
[08:11:56] <bleathem__> ok done.  just have to test it.  but these things always work the first time right?
[08:12:13] <lightguard_jp> Sure they do :)
[08:12:17] <bleathem__> testing tomorrow. now sleep.
[08:16:36] <bleathem__> shoot
[08:16:57] <bleathem__> I just commited to my git master branch, instead of my feature branch
[08:17:25] <lightguard_jp> find the sha hash of that commit
[08:17:34] <lightguard_jp> git checkout feature_branch
[08:17:40] <lightguard_jp> git cherry-pick sha hash
[08:17:47] <lightguard_jp> git checkout master
[08:18:15] <lightguard_jp> git reset --hard HEAD~1 (or how many ever commits you made)
[08:18:45] <lincolnthree1> git reset --hard HEAD^1
[08:18:49] <lincolnthree1> goodnight all
[08:18:57] <bleathem__> g'night!
[08:19:01] <lightguard_jp> lincolnthree1: later
[08:19:26] <bleathem__> lightguard_jp: thx, i'll try that
[08:19:38] *** lincolnthree1 has quit IRC
[08:23:32] <bleathem__> ok, that worked, thanks
[08:23:48] <bleathem__> easier then the recipe I found goolging
[08:24:00] <bleathem__> now github won't let me push
[08:24:28] <bleathem__> 'By default, updating the current branch in a non-bare repository is denied'
[08:24:39] <bleathem__> any idea what that's about?
[08:26:28] <bleathem__> apparently I have to convert my remote repository to bare repository ( There is no working copy in the bare repository)
[08:26:41] <bleathem__> i have no idea how github got a working copy.
[08:33:14] <lightguard_jp> Can you force a push?
[08:33:17] <lightguard_jp> git push --force
[08:34:01] <bleathem__> just tried that.  same error
[08:34:17] <bleathem__> somehow I got a checkout of one of my branches on github
[08:34:30] <bleathem__> must have been from an earlier --force :P
[08:34:31] <lightguard_jp> Odd
[08:34:36] <lightguard_jp> Could be
[08:34:52] <bleathem__> there are recipes to correct, but all seem to require shell access to the repo
[08:34:59] <lightguard_jp> Well, you could blow away your github fork, recreate it and then push again
[08:35:21] <bleathem__> it would re-create all my branches?
[08:35:45] <bleathem__> sounds scary
[08:36:47] <bleathem__> oh nvermind
[08:36:50] <bleathem__> dammit
[08:37:07] <bleathem__> this was a git clone of a loacl folder, which itself was a clone from github
[08:40:55] <bleathem__> ok, pushed to github. now my hard drive won't crash
[08:41:05] <bleathem__> for if I didn't push, it surey would have crashed
[08:41:18] <bleathem__> g'night all
[08:41:36] *** bleathem__ has quit IRC
[08:43:03] <lightguard_jp> bed time for me as well.
[08:43:44] *** lightguard_jp has quit IRC
[08:55:51] *** marekn has joined #seam-dev
[09:08:39] *** mojavelinux has quit IRC
[09:16:35] *** emmanuel has joined #seam-dev
[09:41:44] *** rruss has quit IRC
[09:56:31] *** emmanuel has quit IRC
[10:01:04] *** emmanuel has joined #seam-dev
[10:04:41] *** jharting has joined #seam-dev
[10:11:01] *** kpiwko has joined #seam-dev
[11:19:37] *** amitev has quit IRC
[11:38:10] *** aslak has joined #seam-dev
[12:06:01] *** emmanuel has quit IRC
[12:23:41] *** epbernard has joined #seam-dev
[12:23:41] *** epbernard is now known as emmanuel
[12:34:01] *** amitev has joined #seam-dev
[13:53:08] *** aslak has quit IRC
[13:53:42] *** aslak has joined #seam-dev
[14:00:29] *** balunasj has joined #seam-dev
[14:10:37] *** rruss has joined #seam-dev
[14:18:28] *** aslak has quit IRC
[14:19:13] *** aslak has joined #seam-dev
[15:01:01] *** rruss has quit IRC
[15:10:02] *** lincolnthree has joined #seam-dev
[15:14:07] *** tsurdilo has joined #seam-dev
[15:29:29] <jbossbot> git [forge] push master 9e17187.. Lincoln Baxter, III Refactoring for Enum and Annotation support
[15:29:29] <jbossbot> git [forge] push master ee1c212.. Lincoln Baxter, III Oops
[15:29:29] <jbossbot> git [forge] push master 91015e2.. Lincoln Baxter, III horrible generics in the JavaParser API - not sure about this...
[15:29:30] <jbossbot> git [forge] push master e2ac9ec.. Lincoln Baxter, III Merge branches 'generics' and 'master'
[15:29:30] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/4402937...e2ac9ec
[15:37:03] *** lightguard_jp has joined #seam-dev
[15:45:28] *** adamw1pl has joined #seam-dev
[15:55:44] *** mbg has joined #seam-dev
[15:55:45] *** mbg has quit IRC
[15:55:45] *** mbg has joined #seam-dev
[15:56:59] <lightguard_jp> Meeting?
[15:57:22] <lincolnthree> Yep, we'll see how much is on the agenda, but yes.
[15:57:48] <lincolnthree> I doubt if 3am Dan will make it ;) But we'll see.
[15:58:14] <lightguard_jp> lol
[15:58:23] *** oskutka has quit IRC
[16:04:11] <lincolnthree> Good morning everyone.
[16:04:27] <lincolnthree> Let's go ahead and get started. I think this will probably be short today.
[16:04:53] <lincolnthree> Does anyone have any topics before I mention a few things briefly?
[16:05:14] *** mojavelinux has joined #seam-dev
[16:05:25] <mojavelinux> hello everyone
[16:05:31] <lincolnthree> Here's the man, mojavelinux, I just asked if anyone had topics before we ramble.
[16:05:45] <lincolnthree> I have two items.
[16:06:02] <mojavelinux> yes, I've woken from the dead...good late night hack session w/ lightguard_jp and bleathem ;)
[16:06:14] <mojavelinux> and lincoln
[16:06:20] <lincolnthree> yes?
[16:06:37] <lightguard_jp> :)
[16:06:40] <mojavelinux> we were writing catch integrations, reminded me of when we hacked together the arquillian containers at JUDCon
[16:06:47] <mojavelinux> okay, so on to topics
[16:06:57] <lincolnthree> Lol. You mean when I was hacking JDT and you were hacking Arquillian containers? ;)
[16:07:08] <mojavelinux> hehe
[16:07:21] <lincolnthree> Ok, so I didn't hear any topics.
[16:07:27] <lincolnthree> Dan if you have anything, go ahead.
[16:07:45] <mojavelinux> I have some minor conventions to sort out, so I'll ask those shortly
[16:07:55] <lincolnthree> Ok, I'll just give my part then.
[16:08:02] <mojavelinux> go for it
[16:08:05] *** marekn has quit IRC
[16:08:15] <lincolnthree> #1. SeamForge is at the point where we really need people to start prototyping some plugins.
[16:08:44] <lincolnthree> So if you're curious at all, or have some bold idea, now is the time to do it and still be able to change things easily if they are hard or "broken."
[16:09:05] <lincolnthree> In the end, we need a plugin for each seam module (or one for all, depending onhow it's done.)
[16:09:16] <lincolnthree> Actually one single project with Seam3 module support wouldn't be a bad idea.
[16:09:21] <lincolnthree> Keep things simpler from a user's perspective.
[16:09:24] <lincolnthree> One thing to "get"
[16:09:44] <mojavelinux> should the plugins be in the module? or we aren't ready to decide yet
[16:09:51] <lincolnthree> So please fork: http://github.com/seam/forge and play around.
[16:10:00] <lincolnthree> We haven't had that discussion yet.
[16:10:04] <mojavelinux> so for now?
[16:10:06] <mojavelinux> in the fork
[16:10:09] <lincolnthree> right
[16:10:11] <mojavelinux> got it
[16:10:11] <lincolnthree> for now do it in a fork
[16:10:24] <lincolnthree> https://github.com/arquillian/seam-forge/
[16:10:25] <lincolnthree> for example
[16:10:27] <mojavelinux> I was also thinking perhaps we can create a page of possible plugins, a brainstorm page
[16:10:37] <lincolnthree> http://seamframework.org/Documentation/SeamForge#H-PotentialPluginsBrainstorming
[16:10:40] <mojavelinux> that way, if I think of something but don't have time to do it now, I can perhaps inspire another
[16:10:45] <mojavelinux> ah!
[16:10:55] <lincolnthree> It could probably be put in a more visible space.
[16:11:28] <lincolnthree> So, to give an example of a Seam Module plugin, just at a basic level:
[16:11:31] <lincolnthree> SeamCatch
[16:11:58] <lincolnthree> Would pretty much just need to add itself to the POM, but if there were a Plugin that knew how to add an exception handler.
[16:12:00] <lincolnthree> That would be sweet.
[16:12:01] <lincolnthree> Like:
[16:12:05] <lincolnthree> "install seam-catch"
[16:12:38] <lincolnthree> new-exception-handler --named ~.handlers.HandleViewExpired
[16:13:16] <lincolnthree> And boom, you have a catch handler pre-annotated and set up for you.
[16:13:21] <lincolnthree> Just fill in the blanks.
[16:13:21] <lightguard_jp> Cool
[16:13:23] <mojavelinux> indeed
[16:13:48] <lincolnthree> Ok, so that's #1.
[16:13:59] <lincolnthree> #2 is just a bit of info on how to get access to do releases and upload docs.
[16:14:10] <lincolnthree> lightguard_jp has asked and I realized I didn't know.
[16:14:11] <mojavelinux> ah, that was one of my to discuss items too
[16:14:17] <lightguard_jp> www.seamframework.org is down
[16:14:22] <mojavelinux> yeah, I noticed
[16:14:32] <lincolnthree> blast!
[16:14:35] <lincolnthree> But yes.
[16:14:52] <lincolnthree> In order to gain access to release your module:
[16:14:56] <mojavelinux> I was thinking another key plugin for #1 would be a jboss as plugin
[16:15:11] <mojavelinux> to start, stop, remove deployments, show deployments
[16:15:17] <lincolnthree> You need to request the "Release Technician" role by emailing help at jboss dot org
[16:15:23] <mojavelinux> believe it or not, I keep an ant script to do all that
[16:15:30] <lincolnthree> mojavelinux: yep, it's on the list :) that would be a sweet plugin
[16:15:53] <mojavelinux> as for #2
[16:15:59] <lincolnthree> In addition to the release technician role, which enables you to release to the nexus repo
[16:16:08] <mojavelinux> all the information is on the module release page
[16:16:14] <lincolnthree> Link?
[16:16:45] <mojavelinux> perhaps not in such a clear way...I'm thinking we should split the page out for "how to get permissions to things"
[16:16:56] <mojavelinux> then the module guide can link to that, but it's cleaner
[16:16:57] <lincolnthree> You also need to request permission to upload docs to sourceforge, which takes another (or the same) email to help at jboss dot org - they'll need your public SSH key
[16:17:08] <mojavelinux> yep, again, on module release page
[16:17:08] <lincolnthree> mojavelinux: agreed
[16:17:27] <lincolnthree> That's all I had, and now my coffee is cold :(
[16:17:31] <mojavelinux> but I acknowledge that the page is a bit too busy
[16:17:43] <lincolnthree> We need some nice buttons for people to click and get the part they want.
[16:17:48] <lincolnthree> images* rather
[16:17:58] <lincolnthree> It can all be on the same page in a flow
[16:18:05] <lightguard_jp> Okay, sounds like I just need to give them my public ssh key then.
[16:18:05] <lincolnthree> but we need some kind of visual index
[16:18:15] <lightguard_jp> I can release just not the docs nor source forge update.
[16:18:54] <mojavelinux> I'm not sure what the ruling is on access to the docs
[16:19:27] <mojavelinux> red hat may say that they can't give out permissions...but actually they may I just have to check
[16:19:56] <mojavelinux> but, regardless, a better way would be to have a bot that handles this part of the release, then we don't need permissions beyond releasing to nexus
[16:20:05] <mojavelinux> one triggers the other...I get tired of doing it manually anyway
[16:20:29] <mojavelinux> or even hudson should be able to detect a new tag and release from that
[16:20:32] <lightguard_jp> That would be very nice
[16:20:40] <mojavelinux> seriously
[16:20:48] <lightguard_jp> +1 for push button hudson release
[16:21:11] <lincolnthree> I agree
[16:21:17] <lincolnthree> Hudson doing this for us would be the best option
[16:21:21] <lincolnthree> Then you just tag and forget.
[16:21:25] <mojavelinux> exactly
[16:21:46] <lincolnthree> Maybe you should have to notify hudson somehow, because tagging can be done accidentally as well
[16:21:52] <mojavelinux> another major issue right now is that you have to update about 8 pages after a release
[16:21:58] <lincolnthree> Yeeeahh
[16:22:06] <mojavelinux> I spent a couple hours updating all the pages because they were way out of date
[16:22:14] <lightguard_jp> Releasing right now is very manual, and takes a lot of time
[16:22:19] <mojavelinux> the problem we face is that other people think we don't have modules released
[16:22:25] <mojavelinux> because they see a list of 3
[16:22:29] <mojavelinux> on some page like documentation
[16:22:38] <mojavelinux> which is now fixed...but it was only showing 3 modules
[16:23:17] <mojavelinux> I don't see why we have documentation on a separate page from downloads
[16:23:24] <mojavelinux> really it should be "module name"
[16:23:27] <mojavelinux> all the links you need
[16:23:29] <mojavelinux> in one row
[16:25:05] <mojavelinux> and then limit the number of links we have even on that page...like we don't need to link to every possible combination of maven artifact
[16:26:09] <lightguard_jp> We should have a press link or something for articles and things like http://jaxenter.com/seam-catch-more-than-simply-logic-in-your-catch-block.1-32969.html
[16:26:29] <mojavelinux> we actually do, but again, totally hidden
[16:26:34] <mojavelinux> how about this
[16:27:03] <mojavelinux> let's get together a page of requirements (or google doc or something), then we can carry out those changes perhaps by splitting it up
[16:27:16] <lightguard_jp> Works for me
[16:27:22] <mojavelinux> like we talked already about the module release guide being too long
[16:27:30] <mojavelinux> cool...i'll kick that off, AI
[16:27:45] <mojavelinux> couple quick questions and comments about conventions
[16:27:54] <lincolnthree> Ah, we'd also briefly talked about a Forge seam release plugin
[16:28:04] <mojavelinux> first, it seems that module leads are using docs/ instead of docs/reference for the reference guide
[16:28:07] <mojavelinux> is that what you prefer?
[16:28:09] <lincolnthree> I still think that would be a nice driver instead of that horrible maven release plugin
[16:28:33] <lightguard_jp> I copied my structure from faces :P
[16:28:38] <lincolnthree> mojavelinux: I've been using /reference/ because there's a chance of having more than one type of documentation.
[16:29:27] <mojavelinux> can we vote, reference/ or no reference?...cause it makes it easier if we are consistent
[16:29:39] <lincolnthree> no preference
[16:29:44] <lincolnthree> ah ah
[16:29:45] <mojavelinux> I should say: reference/ subdirectory or not?
[16:29:47] <lincolnthree> that's a pun
[16:29:48] <lightguard_jp> I'm not passionate either way.
[16:30:07] <mojavelinux> damn...I was hoping for some strong opinions
[16:30:21] <lincolnthree> I said NO PREFERENCE!!
[16:30:26] <lincolnthree> Is that better?
[16:30:30] <mojavelinux> hahaha, damn you
[16:30:45] <lightguard_jp> lol
[16:30:59] <lightguard_jp> Put it out on the mailing list so we get more than just us three
[16:31:05] <mojavelinux> true
[16:31:08] <mojavelinux> okay, another issue
[16:31:21] <mojavelinux> I want to create a combined API + Impl Jar as part of the module build
[16:31:38] <mojavelinux> in maven, this has to be done with another sub-folder, unless someone comes up with some wizardry
[16:31:48] <mojavelinux> I named the folder combined/
[16:31:53] <mojavelinux> does that make sense?
[16:31:58] <mojavelinux> any better names?
[16:32:08] <mojavelinux> uber is misleading since it doesn't include dependencies
[16:32:09] <lincolnthree> it really could be a part of dist
[16:32:24] <lincolnthree> well, maybe
[16:32:28] <lincolnthree> depends on the maven magic
[16:32:30] <mojavelinux> yeah, I was going to try that, but I wasn't sure if Maven could handle it
[16:32:53] <mojavelinux> I'll try it, if it doesn't work, we'll just stick with combined/ for the moment
[16:32:59] <mojavelinux> go ahead and make that part of the next release
[16:33:02] <mojavelinux> for your module
[16:33:10] <mojavelinux> get the source from github.com/seam/servlet
[16:33:24] <mojavelinux> because I agree it's nice to give people seam-catch.jar or seam-faces.jar
[16:33:38] <mojavelinux> and have -api and -impl for those that prefer it
[16:33:42] <lincolnthree> right, which also needs you need to rename the non-api sub-module, yes?
[16:33:42] <lincolnthree> yeah
[16:33:49] <mojavelinux> we already have :)
[16:33:55] <mojavelinux> faces just hasn't yet
[16:34:13] <mojavelinux> and faces must have a dist on the next release ;)
[16:34:21] <lincolnthree> yes it must
[16:34:23] *** pmuir has joined #seam-dev
[16:34:23] *** pmuir has quit IRC
[16:34:23] *** pmuir has joined #seam-dev
[16:34:32] <mojavelinux> it just looks out of a alignment atm...and it already works, I tried it
[16:34:34] <mojavelinux> so it's just doing it
[16:34:41] <lincolnthree> ok awesome
[16:34:50] <mojavelinux> in fact, we can go back and do a dist for the current release, though we need a new release anyway
[16:35:14] <mojavelinux> ah, another thing for the website
[16:35:20] <mojavelinux> we need instructions for how people hack the source code
[16:35:25] <mojavelinux> people don't know how to fork in git
[16:35:28] <mojavelinux> they need to be told
[16:35:38] <mojavelinux> this is just a matter of pointing to the git help pages
[16:35:48] <mojavelinux> so nothing hard, but we should have the pointer
[16:35:55] <mojavelinux> i'll add that to the requirements
[16:36:04] <mojavelinux> the other big issue
[16:36:11] <mojavelinux> is that we are going to have to coordinate the switch to solder
[16:36:18] <mojavelinux> because we can't have some modules on weldx and some on solder
[16:36:23] <mojavelinux> of course, we need a release of solder first ;)
[16:36:31] <mojavelinux> I did publish a snapshot of docs at least
[16:36:37] <mojavelinux> http://docs.jboss.org/seam/3/solder
[16:37:21] <mojavelinux> so basically, we need all modules to do a release in the coming weeks...lincoln & I can drive releases for module leads that don't have time
[16:37:23] <mojavelinux> we just have to do it
[16:37:49] <mojavelinux> we should bump the seam-bom # too, to make sure we have all versions in there
[16:38:20] <lightguard_jp> mojavelinux: Seems like we may have someone in #seam asking about servlet
[16:38:51] <mojavelinux> tell him i'll be in 15 min...don't want to delay meeting
[16:39:02] <lincolnthree> mojavelinux: let's set aside some time to work together on that
[16:39:14] <mojavelinux> btw, Servlet 3.0.0.Alpha2 and Catch 3.0.0.Alpha2 were released this week
[16:39:29] *** jharting has quit IRC
[16:40:06] <pmuir> hi everyone, sorry for missing the meeting
[16:40:12] <mojavelinux> and there was progress on getting solder to run on GlassFish 3.1...got that info from jason
[16:40:43] <lincolnthree> good morning pmuir :)
[16:40:56] <mojavelinux> no problem, sometimes we just end up talk to ourselves anyway :)
[16:41:11] <pmuir> all ok?
[16:41:20] <mojavelinux> (I should do a roll call at the beginning, so I know who else might respond :))
[16:41:28] <mojavelinux> the big thing that you'll be concerned with pete
[16:41:31] <mojavelinux> that we just discussed
[16:41:32] <lightguard_jp> Yeah, hopefully the changes to GF will be in sometime next week in a promoted build
[16:41:43] <mojavelinux> is that we are going to need a coordinate shift to solder
[16:41:51] <mojavelinux> w/ an update to the seam-bom at the same time to bring everything in line
[16:41:56] <mojavelinux> all modules are going to need a release
[16:41:59] <pmuir> sounds good
[16:42:03] <pmuir> is sbryzak around?
[16:42:34] <mojavelinux> not sure, but I'll e-mail the list after this just to make sure i'm including everyone that needs to be involved
[16:42:56] <mojavelinux> progress is going great on seam this week, though in general
[16:43:10] <mojavelinux> lots of participation, including bleathem hacking on faces ;)
[16:43:15] <mojavelinux> and cody working on mail
[16:43:20] <lightguard_jp> pmuir: Haven't heard anything from him.
[16:43:26] <mojavelinux> and of course lightguard_jp :)
[16:43:31] <pmuir> ok great
[16:43:34] <mojavelinux> the other big issue
[16:43:39] <mojavelinux> is this jboss logging thing
[16:43:41] <mojavelinux> shane is stuck
[16:44:07] <lincolnthree> bleathem: do you have a fork that I should be pulling changes from?
[16:44:08] <mojavelinux> basically, the type safe logger is giving him issues, I think because of the system property that jboss logging uses
[16:44:12] <mojavelinux> to enable the proxies
[16:44:12] <lincolnthree> for faces
[16:44:20] <mojavelinux> I have it working on my end, but he still seems to have an issue
[16:44:32] <mojavelinux> I'm not sure if you are on the thread, I'll add you
[16:45:49] <mojavelinux> any for anyone reading, if you have a spare hour, and you don't feel like hacking
[16:45:57] <mojavelinux> remember this...a blog entry on a single feature
[16:45:59] <mojavelinux> some tidbit
[16:46:07] <mojavelinux> is a great way to keep news about seam just rolling out
[16:46:14] <mojavelinux> it doesn't always have to be a module release announcement
[16:46:29] <mojavelinux> an easy way to come up with stuff is to do what I call counter blog posts
[16:46:43] <mojavelinux> you see a blog post about how to do something in JSF or Servlet or EJB
[16:46:49] <mojavelinux> and we happen to have a simpler way
[16:46:59] <mojavelinux> just post how you could solve it with a Seam feature
[16:48:33] <mojavelinux> okay, I've been dominating, anyone have anything they want to mention/discuss/ask
[16:49:01] <lightguard_jp> I post up the link, but the interview for Catch with jaxenter.com is up.
[16:49:02] <lincolnthree> I'm done, but again, please start forking / playing with Forge
[16:49:18] <mojavelinux> great!!!
[16:49:21] <lightguard_jp> Catch Alpha3 next week
[16:49:28] <lightguard_jp> Beta by the end of the month
[16:49:33] <mojavelinux> Servlet Alpha3 next week, and hopefully Faces Beta2
[16:49:55] <mojavelinux> super...Catch is turning out to be a hallmark module :)
[16:49:56] <lightguard_jp> I haven't heard anything from anyone save Dan.  Hopefully with bleathem doing the integration there will be more feedback.
[16:50:20] <mojavelinux> I'll be helping him along, in fact last night I did my own version that I'll post
[16:51:13] <lightguard_jp> Of an integration for JSF?
[16:51:26] <mojavelinux> yes
[16:52:14] <mojavelinux> okay, keep hacking away on modules and forge plugins...I look forward to reading announcements ;)
[16:53:12] <mojavelinux> now back to the regularly scheduled hacking ;)
[16:56:28] <jbossbot> git [faces] push master 7e71d6c.. Lincoln Baxter, III ArrayIndexOutOfBoundsException fix
[16:56:28] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/07e5cc9...7e71d6c
[16:56:55] <mojavelinux> I think lincoln had that push planned :)
[16:56:56] <mojavelinux> hehehe
[16:56:59] <lightguard_jp> mojavelinux: Come on in to #seam, GTobi has a question about injecting into Servlet Filters, which if I read right shouldn't need to be done any more, just use eventing.
[16:57:05] <bleathem> lincolnthree: nothing to pull yet, I didn't get to testing it last night
[16:57:07] <lightguard_jp> lol
[16:58:51] <lightguard_jp> lincolnthree: thought about converts for seam render?
[16:59:10] <lincolnthree> lightguard_jp: yeah, that's why I want a Seam Convert module
[16:59:12] *** rruss has joined #seam-dev
[16:59:17] <lightguard_jp> I was thinking we need something global so you don't have to reimplement it every time for a new object.
[16:59:19] *** rruss has quit IRC
[16:59:25] <lincolnthree> exactly
[16:59:29] <mojavelinux> we need a convert module (or at least logic somewhere)
[16:59:32] <lincolnthree> By default it just uses .toString()
[16:59:41] <lincolnthree> Perhaps Weld Extensions is a good place for Convert
[17:00:00] <bleathem> but my branch is here: https://github.com/bleathem/faces/tree/SeamCatch
[17:00:05] <lightguard_jp> How are you going to go back to the object?
[17:02:47] <lightguard_jp> :( in.r.2 down too
[17:03:30] <lightguard_jp> sorry, not down just really slow
[17:03:38] <lincolnthree> Ah, well right now there is no inbound conversion :)
[17:03:47] <lincolnthree> Aside from the basic EL type coercion
[17:04:33] <lightguard_jp> Well, that may actually be enough.
[17:04:36] <lightguard_jp> Maybe
[17:04:55] <lincolnthree> It's not unfortunately.
[17:05:07] <lincolnthree> EL only knows how to convert simple types like String, int, etc...
[17:05:20] <lincolnthree> So if you bind to an object in a backing bean, you'll get rubbish
[17:05:23] <lincolnthree> or an exception
[17:05:50] *** pmuir has quit IRC
[17:06:13] <lightguard_jp> doh
[17:06:52] <lincolnthree> I mean, if you have like, "private Customer cust"
[17:06:56] <lincolnthree> With some random constructor
[17:07:03] <lincolnthree> EL isn't going to be able to know what to do with that
[17:07:14] <lincolnthree> So that's where you need to ask EL for the expected type
[17:07:20] <lincolnthree> Do the conversion manually
[17:07:22] <lincolnthree> then set the value
[17:07:39] <lincolnthree> That's the proper space for converters, which is something we could do in Solder
[17:08:03] <lincolnthree> Converters are relatively low-level, so it almost fits
[17:08:14] <lincolnthree> I'm just not sure if that would be bloat or not
[17:08:23] <lincolnthree> And if it should really go into a simple extension module.
[17:08:41] <lincolnthree> Actually, mojavelinux, is there precedent for utility-style modules? Just a simple maven project?
[17:09:05] <mojavelinux> so here's how I see this...
[17:09:29] <mojavelinux> what about a submodule of solder?
[17:09:36] <mojavelinux> we can still call it something like seam-convert
[17:09:41] <mojavelinux> but solder owns all utilities
[17:09:47] <mojavelinux> or common pieces
[17:09:50] <mojavelinux> make sense?
[17:09:52] <lincolnthree> i dunno. then you pull in solder and you get everything
[17:09:59] <lincolnthree> I'm not sure I like that, unless they aren't linked
[17:10:00] <mojavelinux> nope, not saying that
[17:10:02] <lincolnthree> ah ok
[17:10:05] <mojavelinux> I'm just saying that's were it's organized
[17:10:05] <lincolnthree> yeah that wouldn't be bad
[17:10:19] <lincolnthree> saves us from even more releases
[17:10:23] <mojavelinux> exactly
[17:10:47] <lincolnthree> and that would be a place where the /reference/ /convertsion-reference/ etc folders might come in handy
[17:10:58] <mojavelinux> here's the thing with convert
[17:11:06] <mojavelinux> it's always been a closed set in seam
[17:11:13] <mojavelinux> a big mistake IMO in seam 2
[17:11:24] <mojavelinux> we are already going down that path
[17:11:31] <mojavelinux> with a closed set of conversions in seam config
[17:11:39] *** balunasj has quit IRC
[17:11:45] <mojavelinux> let's factor this out...I talked to Marjin from Wicket about this
[17:11:51] <mojavelinux> he said they have a nice convert API in trunk
[17:11:58] <mojavelinux> so perhaps something to look at for reference
[17:12:12] <mojavelinux> who's with me in saying that conversion should be a spec just like Bean Validation?
[17:12:23] <mojavelinux> I mean, if validation is so important, central and cross-cutting, isn't conversion too?
[17:13:09] <lightguard_jp> Makes sense to me.
[17:13:15] <lightguard_jp> lincolnthree: start a JSR :)
[17:13:29] <mojavelinux> and there is a JSR even for currency
[17:13:33] <lincolnthree> yeah
[17:13:34] <mojavelinux> so come on, there has to be a JSR for this
[17:13:45] <mojavelinux> I would actually talked to emmanuel about this...first, see if he's thought about it
[17:14:07] <mojavelinux> if not, okay, but if so, hey, maybe it's closer to happening already
[17:15:47] <emmanuel> conversion of what
[17:15:48] <emmanuel> ?
[17:15:52] <emmanuel> units?
[17:16:28] <lightguard_jp> Bean conversion like JSF converters
[17:16:52] <emmanuel> what's wrong with JSF converters?
[17:16:58] <mojavelinux> basically, a common API for doing type conversion
[17:17:09] <mojavelinux> that could be used across the board...and in cases when you aren't dealing with a UI
[17:17:16] <mojavelinux> for instance, the XML configuration of Beans
[17:17:20] <mojavelinux> has it's own conversion rules
[17:17:25] <mojavelinux> JAX-RS has it's own conversion rules
[17:17:38] <emmanuel> The issue is that every format and its brother use different encoding schemes
[17:17:42] <lincolnthree> Has anyone taken a look at what JAX-RS 2.0 is proposing?
[17:17:49] <lincolnthree> It sounds like a play out of the groovy-handbook
[17:17:50] <mojavelinux> JSF is another (though the first)...also we have the same thing at injection points, when you want to do something like @RequestParam
[17:18:41] *** adamw1pl has quit IRC
[17:20:15] <emmanuel> mojavelinux: yes but why would a request param encode say a number the same way a number is encoded in a file or in Hibernate Search?
[17:20:41] <emmanuel> in a way you'd need specific converters for every single format
[17:21:00] <emmanuel> the factoring is not as strong as validation
[17:21:12] <emmanuel> esp since conversion is only useful at the system boundaries
[17:21:18] <emmanuel> file, socket etc
[17:22:02] <mojavelinux> hmm, I understand the encoding issue...though once you get past that...you still have a situation where you have a meaning in a string
[17:22:08] <mojavelinux> and it needs to become an object
[17:22:10] <mojavelinux> such as a date
[17:22:12] <mojavelinux> or an enum
[17:22:30] <mojavelinux> i'd say this is primarily about the string to object conversion
[17:22:47] <mojavelinux> or one could say a representation of the object
[17:22:50] <lincolnthree> yes
[17:23:03] <mojavelinux> that can be moved between systems...string being the universal format
[17:23:54] <mojavelinux> but I see what you are saying in that it may not be so clear cut...and that okay, we are going to do some research within seam on this then...cause we need it anyway as a utility
[17:24:01] <mojavelinux> and we'll see where we get
[17:28:54] <clerum> so module into eclipse
[17:28:58] <clerum> git clone
[17:29:05] <clerum> then import it as a maven project?
[17:29:24] <clerum> the top level and all the components
[17:29:41] <mojavelinux> I always import as different projects
[17:29:42] <mojavelinux> with m2eclipse
[17:29:48] <mojavelinux> in fact, I only import api and impl
[17:29:54] <mojavelinux> the rest is just noise
[17:29:57] <mojavelinux> in eclipse
[17:30:09] <clerum> right I skip the dist and docs
[17:30:14] <lincolnthree> i usually import everything
[17:30:22] <mojavelinux> I'm too afraid :)
[17:30:23] <lincolnthree> and close what i don't need at the time
[17:30:28] <lincolnthree> yeah it breaks sometimes
[17:30:45] <mojavelinux> also, I recommend unchecking resolve in workspace projects in the Maven tab of properties
[17:30:56] <mojavelinux> well, maybe, depends on what you have open
[17:31:03] <mojavelinux> it just gets confusing because if you depend on a module
[17:31:07] <mojavelinux> and that module is open
[17:31:18] <mojavelinux> then it uses the open version rather than the version in the pom
[17:31:26] <mojavelinux> though it makes real-time changes simpler
[17:31:43] <mojavelinux> there should be an option to *only* link them if it's a snapshot dependency
[17:31:49] <mojavelinux> but there is no such option
[17:31:52] <mojavelinux> alas
[17:31:57] *** mojavelinux has quit IRC
[17:33:21] <clerum> ok central must be down or something
[17:33:47] <clerum> why would I get that
[17:33:47] <clerum> 1) javax.mail:mail:jar:1.4.3
[17:33:47] <clerum> can't be found
[17:38:39] <lincolnthree> clerum: there's no 1.4.3 in central
[17:38:46] <lincolnthree> 1.4.1
[17:38:51] <lincolnthree> http://mvnrepository.com/artifact/javax.mail/mail
[17:39:11] <clerum> odd that that has worked up to now
[17:39:20] <clerum> must be coming off java.net
[17:39:24] <clerum> which is now done
[17:39:25] <clerum> down
[17:41:17] <lincolnthree> that could explain it
[17:43:48] <clerum> using the mail api in my seam 2 project..should help to flush out the missing bits and pieces
[17:44:07] <clerum> and seperate out the api and impls better
[17:51:27] *** mojavelinux has joined #seam-dev
[17:51:47] *** rruss has joined #seam-dev
[17:55:40] <mojavelinux> here's my prototype of the jsf catch integration
[17:55:40] <mojavelinux> https://gist.github.com/734963
[17:56:00] <mojavelinux> I was just curious about playing around with it
[17:56:06] <mojavelinux> and I ended up getting it working :)
[17:56:15] <mojavelinux> I don't currently add the @Faces qualifier
[17:56:24] <mojavelinux> also, we should add the @ViewId qualifier as well
[17:56:39] <mojavelinux> ah, and very important
[17:56:54] <mojavelinux> we need to have a qualifier to indicate that it's an ajax or non-ajax request
[17:57:38] <lincolnthree> mojavelinux: that looks perfect
[17:57:45] <mojavelinux> :)
[17:57:56] <lincolnthree> only thing i might do out of pure paranoia
[17:58:02] 
[17:58:06] <lincolnthree> if that's ever null..
[17:58:12] <lincolnthree> it shouldn't be, but we all know JSF
[17:58:38] <mojavelinux> actually, I'm sure it won't be, required by spec...though dig this
[17:58:45] 
[17:58:49] <mojavelinux> the exception handler is called even when there are no exceptions to catch
[17:58:58] <lincolnthree> yeh
[17:59:00] <mojavelinux> the jsf exception handling is just insane
[17:59:07] <lincolnthree> thats because it queues exceptions until the end of the phase
[17:59:10] <mojavelinux> thank goodness we have catch
[17:59:11] <lincolnthree> it doesn't handle them right away
[17:59:20] <lincolnthree> it's kind of crazy
[17:59:26] <mojavelinux> no, i mean it calls handle() and there's nothing to handle
[17:59:28] <lincolnthree> i have no idea why you'd want to do it like that
[17:59:32] <lincolnthree> i know
[17:59:36] <lincolnthree> so it has to check the queue each time
[17:59:38] <lincolnthree> it's odd
[18:00:10] <mojavelinux> very
[18:00:23] <lincolnthree> also, your CatchExceptionHandlerFactory has a bug I think
[18:00:31] <lincolnthree> oh nm
[18:00:34] <mojavelinux> I'm not a fan of the BeanManagerAccessor
[18:00:38] <lincolnthree> read the boolean backwards
[18:00:41] <mojavelinux> I don't like the IllegalArgumentException
[18:00:51] <mojavelinux> it should just return null
[18:01:09] <lincolnthree> No, actually
[18:01:12] <lincolnthree> Even better
[18:01:20] <mojavelinux> and isBeanManagerAvailable is a huge waste
[18:01:21] <lincolnthree> I think this is a place where we DO want a checked exception
[18:01:24] <mojavelinux> because it searches for it again
[18:01:41] <mojavelinux> okay, let me restate
[18:01:44] <lincolnthree> Because it *is* technically possible to get nothing back, but null is just as bad as Illegal*Exception
[18:01:49] <mojavelinux> if you are going to have a checked exception
[18:02:04] <mojavelinux> which I want to submit my vote against, but I'll get over it
[18:02:08] <mojavelinux> the exception type should be
[18:02:12] <mojavelinux> BeanManagerNotAvailable
[18:02:15] <lincolnthree> Yes
[18:02:16] <lincolnthree> Agreed
[18:02:17] <mojavelinux> because if I wrap a big block
[18:02:23] <lincolnthree> But here's why I think we do need a checked exception
[18:02:31] <mojavelinux> I have no idea that the reason I'm getting an exception is because the bean manager isn't found
[18:02:37] <mojavelinux> so I have to create a separate try/catch
[18:02:43] <lincolnthree> The BeanManager is used in so many cases where you really need to know if it's there or not
[18:02:49] <mojavelinux> okay, fair enough
[18:02:53] <lincolnthree> it is something that can and should be recovered from
[18:02:54] <mojavelinux> so it's a failure scenario
[18:02:56] <lincolnthree> most of the time
[18:02:57] <lincolnthree> right
[18:03:03] <mojavelinux> but we need an exception just for that
[18:03:05] <lincolnthree> yes
[18:03:07] <mojavelinux> let's put it in that package
[18:03:17] <mojavelinux> I'll add an issue to solder
[18:03:27] <mojavelinux> and isBeanManagerAvailable is a waste
[18:03:32] <mojavelinux> it's doing the lookup again
[18:03:36] <lincolnthree> i was just about to do that :-p go ahead
[18:03:42] <lincolnthree> yeah, agreed
[18:03:46] <lincolnthree> blow it away
[18:03:58] <lightguard_jp> try / catch is wrong, should have been a save point object, where you pass in state and then call it again if it fails.  My $0.02.
[18:04:15] <lincolnthree> im lost
[18:04:28] <lightguard_jp> I went off on a tangent
[18:04:35] <lincolnthree> oh
[18:04:40] <lincolnthree> you're talking about java as a lang
[18:04:41] <lincolnthree> got it
[18:04:45] <lightguard_jp> Yep
[18:04:51] <lincolnthree> that's an interesting idea
[18:05:09] <lincolnthree> would completely change the way the lang is used
[18:05:13] <lincolnthree> more like scala
[18:05:16] <lightguard_jp> Yep
[18:05:19] <lincolnthree> but with extra code to make it work
[18:05:26] <lincolnthree> da
[18:05:27] <lincolnthree> n
[18:05:28] <lincolnthree> mojavelinux:
[18:05:31] <lightguard_jp> Very easily doable w/ CDI
[18:05:38] <lincolnthree> i think you should change the name of your "catchUnavailable" var
[18:05:51] <lincolnthree> it's confusing I think
[18:05:58] <lincolnthree> if(catchUnavailable)
[18:06:02] <lincolnthree> if(!available)
[18:06:10] <lincolnthree> just a thought
[18:06:24] <lincolnthree> i can see why you did it this way, im on the fence
[18:07:12] <mojavelinux> I really don't care, i just don't want to do the check if it's already done
[18:07:18] <lincolnthree> haha
[18:07:22] <lincolnthree> whatever works
[18:07:26] <lincolnthree> im ocd
[18:07:31] <lincolnthree> i should have called it OCDSoft.com
[18:07:45] <lincolnthree> that's why I can't get anything done
[18:08:04] <lightguard_jp> haha
[18:08:11] <mojavelinux> jason, I was thinking
[18:08:20] <mojavelinux> so JSF has this context map that has info about the exception
[18:08:42] <mojavelinux> I suppose we could support passing a context map to ExceptionToCatch()
[18:08:48] <mojavelinux> then make it available in CaughtException
[18:09:00] <mojavelinux> on the fence about it...cause in general it's a bad practice
[18:09:05] <mojavelinux> though the other thing I was thinking about is
[18:09:10] <mojavelinux> when we forward to an error page
[18:09:11] <lightguard_jp> What's in it?
[18:09:18] <mojavelinux> we should have access to the CaughtException
[18:09:41] <mojavelinux> for one, the context map has the view id that was the source of the exception
[18:09:57] <mojavelinux> which is actually useful info...though it could be retrieved another way if we think about it long enough :)
[18:10:11] <lincolnthree> yeah
[18:10:11] <mojavelinux> just as Seam 2 had EL variables for the exception, catch should too
[18:10:14] <lightguard_jp> I'd prefer to make it availabe via cdi
[18:10:22] <lincolnthree> FacesContext.getCurrentInstance().getViewRoot().getViewID();
[18:10:29] <mojavelinux> right, we could allow it to be injected
[18:10:31] <mojavelinux> the map
[18:10:38] <mojavelinux> lincoln, once you are in the error page
[18:10:40] <mojavelinux> that doesn't work
[18:10:41] <lightguard_jp> Yeah
[18:10:46] <mojavelinux> cause the error page is the viewId then
[18:10:53] <mojavelinux> you need original page
[18:11:11] <lightguard_jp> Not sure how the producer would work for it (dependent scopped for sure)
[18:11:17] <mojavelinux> yep
[18:11:30] <lightguard_jp> Maybe that's all it is
[18:11:49] <lightguard_jp> It lives in the factory that way it should have the info when you need it.
[18:12:07] <lightguard_jp> This is one of those places where Seam2's outjection was helpful
[18:12:30] <lightguard_jp> Unless I'm missing something with producers
[18:12:38] *** lincolnthree1 has joined #seam-dev
[18:12:49] <lightguard_jp> I have this object now, I want it a little later, outject it now.
[18:13:15] *** lincolnthree1 has left #seam-dev
[18:13:41] <lightguard_jp> lincolnthree: I just looked at converters in wicket.  The actual converter isn't much different than JSF
[18:13:48] <lightguard_jp> https://cwiki.apache.org/WICKET/using-custom-converters.html
[18:17:11] <lincolnthree> the framework around it  im not a fan of
[18:17:16] <lincolnthree> but yes
[18:17:27] <lincolnthree> all a converter needs to do is go from String <--> Object
[18:17:39] <lincolnthree> how it's registered and located is where Seam / Solder come in
[18:17:50] <lincolnthree> And how you request a given converter.
[18:18:03] <lincolnthree> Or request that a conversion take place.
[18:18:27] <lightguard_jp> Makes sense
[18:18:33] <jbossbot> git [faces] push master ea575b8.. Lincoln Baxter, III fix for NPE w/persistence
[18:18:33] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/7e71d6c...ea575b8
[18:18:40] <lightguard_jp> CDI is a much better way to do it in the first place
[18:18:44] <lincolnthree> *nods*
[18:19:02] <mojavelinux> https://issues.jboss.org/browse/SOLDER-50
[18:19:04] <jbossbot> jira [SOLDER-50] Throw a specialized exception when BeanManagerAware cannot resolve BeanManager [Open, Minor, Lincoln Baxter III] https://issues.jboss.org/browse/SOLDER-50
[18:19:06] <mojavelinux> I assigned it to you
[18:19:26] <lincolnthree> k, im not sure i have perms on that repo, but i'll do it now
[18:23:23] <bleathem> lightguard_jp should I not be compiling against alpha2?
[18:23:51] <lightguard_jp> No you should, because that's what's released, but Alpha3 will contain some API changes and renames, just FYI
[18:24:09] <bleathem> ok.  I love API changes!
[18:24:19] <bleathem> <insert ALR's sarcasm character>
[18:24:39] <jbossbot> git [catch] push master 61723fe.. LightGuard Implements SEAMCATCH-23
[18:24:41] <jbossbot> jira [SEAMCATCH-23] Handlers without qualifiers should be notified even if ExceptionToCatch has qualifiers [Resolved, Major, Jason Porter] https://issues.jboss.org/browse/SEAMCATCH-23
[18:24:41] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/46df7b8...61723fe
[18:24:53] <mojavelinux> bleathem: link to your branch your prototype is on in the JIRA
[18:24:57] <lightguard_jp> Now if you have the latest ;) you'll see what should be the changes in Alpha3
[18:25:01] <mojavelinux> that's sort of the convetion I"ve been following
[18:25:10] <lightguard_jp> There's one more addition, but it shouldn't affect you.
[18:25:13] <mojavelinux> sorry, I haven't pulled since yesterday ;)
[18:25:25] <bleathem> my bransch is in my fork
[18:25:35] <lightguard_jp> hehe
[18:25:37] <bleathem> ^branch
[18:25:51] <lightguard_jp> The last feature for Alpha3 is going to be stack filtering
[18:26:10] <lightguard_jp> Or we could even blow away the stack and create our own with simple the wrapped exceptions.
[18:26:32] <lincolnthree> while we are talking about BeanManagerAware
[18:26:39] <lincolnthree> how do we feel about the package name
[18:26:43] <lincolnthree> i'd like to change it to:
[18:26:48] <lincolnthree> org.jboss.seam.solder.cdi
[18:26:52] <lincolnthree> or something like that
[18:27:12] <lincolnthree> though I see we also have .resourceLoader.*
[18:27:36] <bleathem> id used org.jboss.seam.eception
[18:27:43] <bleathem> ^exxeption
[18:27:47] <bleathem> ^exception
[18:27:47] <lincolnthree> ...
[18:27:51] <lincolnthree> there we go
[18:27:51] <lincolnthree> hehe
[18:27:56] <bleathem> but it was more of a placeholder
[18:28:00] <lightguard_jp> What is it now?
[18:28:13] <bleathem> oops, wrong conversation, sorry
[18:28:21] <lincolnthree> org.jboss.seam.solder.beanManager
[18:28:28] <lincolnthree> i guess it's fine
[18:29:05] <lightguard_jp> beanManager is the package name?
[18:29:17] <lightguard_jp> Is it just that one class?
[18:29:29] <lincolnthree> package name
[18:32:44] <lightguard_jp> I guess it's okay.  Hopefully it has more classes than just this one.
[18:32:51] <lincolnthree> yes
[18:35:17] *** kpiwko has quit IRC
[18:36:17] <mojavelinux> I hate the package name
[18:36:27] <lincolnthree> it stays for now
[18:36:33] <mojavelinux> oh well
[18:36:35] <lincolnthree> i just made the changes. sending pull request now
[18:36:37] <lightguard_jp> Is seam security portable to different AS or only JBoss?
[18:36:43] <mojavelinux> portable
[18:36:50] <lightguard_jp> I guess the real qusetion: Is picketlink portable
[18:36:54] <mojavelinux> yes
[18:36:58] <lightguard_jp> sweet
[18:37:16] <lincolnthree> https://github.com/seam/solder/pull/5
[18:37:16] <mojavelinux> picketlink is basically the same as what seam 2 security was (well, different, but same in spirit)
[18:37:17] <lightguard_jp> definitely have to think about it more with seam3 than we did in seam2
[18:38:44] <mojavelinux> okay, gotta run, be back later
[19:32:13] *** jbossbot has quit IRC
[20:03:48] <lightguard_jp> lincolnthree: Are you there?
[20:03:54] <lincolnthree> lightguard_jp: I am
[20:04:12] <lightguard_jp> got a little time to brain storm the stack filtering with me?
[20:05:08] <lincolnthree> sure
[20:06:08] <lightguard_jp> Here's my initial thought: two objects 1) a filter which will take a throwable, a string (or regex, or package) to strip from the stack elements 2) a formatter for displaying the stack elements.
[20:06:35] <lincolnthree> question
[20:06:42] <lincolnthree> where do you envision the stack filter being applied?
[20:06:43] <lightguard_jp> I thought since we have all the wrapped exceptions (causes) we could just show those, but often you want more info than that.
[20:06:44] <lincolnthree> In what context?
[20:06:53] <lightguard_jp> logging
[20:07:09] <lightguard_jp> or showing a stack trace in general
[20:08:10] <lincolnthree> Do you think there are enough integration points for the filter?
[20:08:18] <lincolnthree> Like loggers, etc.
[20:08:47] <lincolnthree> One problem with Exceptions is that the stack trace is not reassignable because the methods are 'final'
[20:08:48] <lightguard_jp> *shrug*
[20:09:04] <lightguard_jp> true
[20:09:18] <lincolnthree> I'm only asking these questions because I think they are important before the other stuff :)
[20:10:28] <lightguard_jp> I'm not thinking of reasigning the stack elements though
[20:10:58] <lincolnthree> I'm looking for a use-case example to wrap my head around.
[20:11:23] <lincolnthree> When would you filter a stack trace message? As a utility when writing an exception logger?
[20:11:39] <lincolnthree> Anything else?
[20:11:51] <lightguard_jp> seeing what really happened w/o having to go through all the classes you don't care about
[20:12:03] <lightguard_jp> probably not
[20:12:14] <lightguard_jp> It's a developer utility more than anything.
[20:12:15] <lincolnthree> Seeing what happened in what context?
[20:12:23] <lightguard_jp> You don't show stack traces to users
[20:12:28] <lightguard_jp> Or you shouldn't :)
[20:12:36] <lincolnthree> How will developers use this?
[20:13:05] <lightguard_jp> I got this exception and the trace has five nested exceptions and is 130 lines long in my log
[20:13:21] <lightguard_jp> Probably 1/3 of that are internal classes or proxies that I don't care about.
[20:13:31] <lightguard_jp> I want to see what really happened and where it affects my code.
[20:13:57] <lightguard_jp> Or you can never really see the root cause because it's buried too far.
[20:14:13] <lightguard_jp> Of course a logger in Catch will solve that by logging the root exception first
[20:14:31] <lightguard_jp> But you could still trim it down by not showing other classes / packages you don't care about.
[20:15:54] <lincolnthree> So this would have to be implemented specifically by the developer to filter out stack trace messages.
[20:16:08] <lincolnthree> In whatever context they want.
[20:16:19] <lightguard_jp> Correct
[20:16:42] <lightguard_jp> There's really no way to do it globally.
[20:16:45] <lincolnthree> Right.
[20:16:46] <lincolnthree> Ok.
[20:17:06] <lincolnthree> So ... 1) a filter which will take a throwable, a string (or regex, or package) to strip from the stack elements 2) a formatter for displaying the stack elements.
[20:17:59] <lightguard_jp> I should say multiple strings (regexes or packages)
[20:18:15] <lightguard_jp> optionally a formatter and this object will give back a string that you can log
[20:18:55] <lightguard_jp> So the formatter is there if you want to change the default display of the stack trace.
[20:19:08] <lightguard_jp> say change the indentation
[20:19:17] <lightguard_jp> Still not 100% sure on the formatter though
[20:19:38] <lincolnthree> formatter good idea
[20:19:52] <lightguard_jp> Just have to have the right amount of options on it
[20:20:10] <lincolnthree> public interface StackTraceFilter
[20:20:10] <lincolnthree> {
[20:20:10] <lincolnthree>    String filter(Throwable e);
[20:20:10] <lincolnthree> }
[20:20:13] <lincolnthree> Simple enough
[20:20:25] <lincolnthree> public interface StackTraceFormatter
[20:20:25] <lincolnthree> {
[20:20:25] <lincolnthree>    String format(Throwable e);
[20:20:25] <lincolnthree> }
[20:20:27] <lightguard_jp> Filter what though?
[20:20:37] <lincolnthree> actually wait
[20:20:42] <lightguard_jp> brb, bio
[20:21:37] <lincolnthree> Hello
[20:21:42] <lincolnthree> You can setStackTrace() now
[20:22:38] *** jbossbot has joined #seam-dev
[20:22:44] <bleathem> mojavelinux: "if (catchEvent.isHandled())" nice.  Didn't know you could do that.
[20:23:02] <lincolnthree> So there are a few options.
[20:23:03] <bleathem> it does alleviate the need for having a catchall logging catch
[20:23:08] <lincolnthree> ExceptionFilter
[20:23:11] <lincolnthree> StackTraceFilter
[20:23:15] <lincolnthree> StackElementFilter
[20:23:42] <lincolnthree> StackTraceElement has a lot of information in it
[20:24:12] <lightguard_jp> back
[20:24:39] <lightguard_jp> bleathem: Kind of
[20:24:54] <lincolnthree> http://pastebin.com/hAFTWTD4
[20:25:03] <lightguard_jp> bleathem: Ah, I see what you mean.  Yes
[20:25:06] <lincolnthree> The Filter can return the same exception with the updated stack trace
[20:25:21] <lincolnthree> but the Formatter needs to return a String, since the StackTraceElements themselves just contain data.
[20:25:44] <lincolnthree> Not formatted strings.
[20:27:00] <lightguard_jp> true
[20:27:00] *** aslak has quit IRC
[20:27:51] *** aslak has joined #seam-dev
[20:28:13] <lincolnthree> A StackTraceFilter could actually be globally applied via Catch
[20:28:28] <lincolnthree> You simply run the filter on the Exceptions as Catch processes them.
[20:28:39] <lincolnthree> If they match the filter constraints, then perform the filter and move along.
[20:28:46] <lincolnthree> That would be a global update to logging.
[20:28:52] <lincolnthree> For any message that goes through Catch
[20:29:00] <lightguard_jp> Hm, interesting
[20:29:15] <lightguard_jp> We could creat our own subclass of stack trace elemen
[20:29:18] <lightguard_jp> t
[20:29:19] <lincolnthree> You cant
[20:29:25] <lincolnthree> It's final
[20:29:32] <lightguard_jp> Or not
[20:29:36] <lightguard_jp> bah
[20:29:41] <lincolnthree> But
[20:29:47] <lightguard_jp> Still need a formatter then
[20:30:01] <lincolnthree> Yeah
[20:30:15] <lincolnthree> But what you can do is override printStackTrace() in Throwable
[20:30:20] <lincolnthree> which would mean wrapping the exception
[20:30:24] <lincolnthree> which sort of defeats the purpose
[20:30:45] <lightguard_jp> Yep
[20:30:49] <lincolnthree> And could damage other things.
[20:30:56] <lincolnthree> "would" damage other things
[20:31:04] <lightguard_jp> More than likely
[20:31:10] <lincolnthree> But the filter at least is very possible and practical
[20:31:19] <lincolnthree> However, any time you remove strack trace information you are taking a risk
[20:31:28] <lincolnthree> So that needs to be made clear to developers using this.
[20:31:33] <lincolnthree> It probably should not be used in Production
[20:31:41] <lincolnthree> and an on/off switch would be nice.
[20:31:53] <lightguard_jp> Why would it be risky if you remove info about classes they don't care about to a log?
[20:31:53] <lincolnthree> Damn the JCP rejecting the Java projectStage concept
[20:32:17] <lincolnthree> Because then you'd still have to match up information between logs.
[20:32:25] <lightguard_jp> Setting the StackTraceElement[] probably isn't a good idea
[20:32:27] <lincolnthree> And you never completely don't care.
[20:32:41] <lincolnthree> Because there's always the chance the problem isn't your fault.
[20:32:52] <lincolnthree> And that's when you need the rest of the trace.
[20:32:53] <lightguard_jp> Eh, not sure I completely agree with that 100%
[20:33:19] <lincolnthree> There will always be cases where trace filters can remove something important.
[20:33:21] <lightguard_jp> Sure though, this would be something they'd know *could* be dangerous
[20:33:23] <lincolnthree> No matter what you filter out
[20:33:40] <lincolnthree> Why isn't setting StackTraceElement a good idea?
[20:34:13] <lightguard_jp> Exactly what you're saying
[20:34:37] <lightguard_jp> If you just hand back a filtered string they can still get the full stack trace and print that else where if they really wanted to, or something.
[20:35:01] <lincolnthree> I do see value in this, though.
[20:35:14] <lincolnthree> A run-time switch for example. Perhaps with the option to log full traces elsewhere.
[20:35:34] <lincolnthree> On the handler for example
[20:35:41] <lincolnthree> @Handles @Filtered Exception e
[20:35:42] <lincolnthree> or
[20:35:48] <lincolnthree> @Handles Exception e
[20:36:21] <lincolnthree> @Handles @Filtered(MyFilter.class) Exception e
[20:37:38] <lightguard_jp> Hm
[20:37:45] <lightguard_jp> That may work well.
[20:39:05] <lightguard_jp> Then we could have an abstract method for filtering a StackTraceElement and a formatter
[20:39:20] <lightguard_jp> We'll give you the STE, and you decide if you want it printed
[20:39:51] <lightguard_jp> That way you know if you're in a production environment and want everything printed or not (if there is a printing / logging, etc)
[20:40:25] <lincolnthree> MyFilter.class could be responsible for the production check, or we could provide a system for that.
[20:40:34] <lightguard_jp> Right.
[20:40:47] <lincolnthree> I think we need that in Solder
[20:40:59] <lincolnthree> A common "Is Production or not" check
[20:41:18] <lincolnthree> It really belongs in Java
[20:41:32] <lincolnthree> But as far as Seam Modules go, solder is the next most common ground
[20:43:16] <lightguard_jp> public abstract CatchExceptionFilter {
[20:43:17] <lightguard_jp>     abstract boolean displayStackTraceElement(STE element);
[20:43:17] <lightguard_jp>     CatchExceptionFormatter getFormatter();
[20:43:17] <lightguard_jp>     public final String filter(Throwable e);
[20:43:17] <lightguard_jp> }
[20:43:29] <lightguard_jp> true
[20:43:50] <lincolnthree> I think that Filter and Formatter should be separate concerns
[20:44:37] <lightguard_jp> If we're going to return a string though, we need it in the class that generates the string.
[20:44:46] <lightguard_jp> We could inject it and just have a default one
[20:44:57] <lightguard_jp> You can create your own if you want to override.
[20:45:15] <lincolnthree> public interface StackTraceElementFilter
[20:45:15] <lincolnthree> {
[20:45:15] <lincolnthree>    boolean accept(Throwable e, StackTraceElement t);
[20:45:15] <lincolnthree> }
[20:45:25] <lincolnthree> We do the filtering, you just pass the filters.
[20:46:08] <lincolnthree> As far as Formatting goes, I think I'd probably just have an @Inject StackTraceFormatter formatter;
[20:46:20] <lincolnthree> But I do think it needs to be separate.
[20:46:35] <lightguard_jp> Would a generic filter make more sense?
[20:46:40] <lincolnthree> generic filter?
[20:47:06] <lightguard_jp> public interface StackTraceElementFilter<T extends Throwable> then you don't need to pass the exception.
[20:47:17] <lincolnthree> having the exception can be useful
[20:47:27] <lincolnthree> what if you only want to filter on Exceptions that wrap a certain kind of exception?
[20:47:28] <lightguard_jp> I suppose there could be info on the exception though that you might want
[20:47:49] <lightguard_jp> Possible
[20:47:56] <lincolnthree> and likely imo
[20:47:58] <lightguard_jp> In catch though you get the inner most exception first
[20:48:12] <lincolnthree> if that's an exception that is @Handled
[20:48:24] <lincolnthree> wait how do you mean
[20:48:26] <lightguard_jp> True, if you used this outside Catch
[20:48:43] <lincolnthree> You're saying that Catch never gives you a wrapped exception?
[20:49:03] <lightguard_jp> Catch unwraps the exception all the way down and the first exception that's sent to the handlers is the furthest nested exception
[20:49:12] <lightguard_jp> Nope.
[20:49:50] <lightguard_jp> You can still get the causes info though
[20:49:52] <lincolnthree> So if my DAO throws a NoSuchObjectException
[20:50:06] <lincolnthree> you're saying that I won't see the root cause of that is an NPE at a lower level?
[20:50:17] <lightguard_jp> No, you'll see the NPE first
[20:50:18] <lincolnthree> if I @Handles NoSuchObjectException ?
[20:50:37] <lincolnthree> So you handle all exceptions in the chain?
[20:50:48] <lightguard_jp> You won't be notified if that's your handler until we process the NoSuchObjectException
[20:50:52] <lightguard_jp> Yep
[20:51:02] <lincolnthree> Now I'm confused.
[20:51:26] <lincolnthree> I have one single handler defined in my app
[20:51:32] <lincolnthree> @Handles NoSuchObjectException e
[20:51:40] <lincolnthree> I have not defined any handler for NPE
[20:51:46] <lightguard_jp> Okay let's say you have this new EJBException(new NoSuchObjectException(new NullPointerException)))
[20:51:50] <lincolnthree> Ok
[20:51:59] <lightguard_jp> Catch will first look for a handler for the NPE
[20:52:02] <lightguard_jp> Then for the NSOE
[20:52:06] <lightguard_jp> Then the EJBE
[20:52:09] <lincolnthree> Right. That makes sense.
[20:52:14] <lincolnthree> Sort of...
[20:52:20] <lincolnthree> I mean.
[20:52:38] <lincolnthree> That could start to cause issues where top-level exceptions are not handled.
[20:52:56] <lincolnthree> Would it not make sense to start at the top?
[20:53:10] <lincolnthree> I guess it depends on the scenario.
[20:54:20] <lightguard_jp> the only way it would happen that the top level isn't handled is if a handler marks the exception as handled, aborts, or throws an exception
[20:54:40] <lincolnthree> Right
[20:54:59] <lincolnthree> Which may well happen if you have a @Handles RuntimeException e
[20:55:05] <lincolnthree> and also a @Handles NSOE e
[20:55:11] <lightguard_jp> If you write it that way, sure.
[20:55:16] <lincolnthree> Alright.
[20:55:18] <lincolnthree> Well anyway.
[20:55:37] <lincolnthree> I think having the Exception instance is important
[20:56:01] <lincolnthree> Because you still may want to filter on a nested exception
[20:56:09] <lincolnthree> If you don't care, don't use it.
[20:56:17] <lincolnthree> But if you want it, it'll be a pain in the ass if it's not there
[20:56:34] <lincolnthree> Trust me, I wrote an ExceptionHandler for RESTEasy and omitted this
[20:56:39] <lincolnthree> I immediately regretted it
[20:56:47] <lightguard_jp> Okay
[20:59:13] <lightguard_jp> Only one filter per system. Is there a problem with that?
[20:59:22] <lightguard_jp> Either the default one or your own.
[20:59:51] <lincolnthree> I think that it might be nice to declare a filter either globally or on the handler itself
[21:00:13] <lincolnthree> Where the specific filter would override the global one
[21:00:24] <lincolnthree> or condense
[21:00:29] <lincolnthree> depending on a flag perhaps
[21:01:00] <lincolnthree> @Filtered(value=MyFilter.class, compositeDefault=true)
[21:01:12] <lincolnthree> or just @Filtered(MyFilter.class) which would not composite
[21:01:29] <lightguard_jp> composite what though?
[21:01:34] <lightguard_jp> And override where?
[21:02:00] <lincolnthree> public void handler(@Handles @Filtered(value=MyFilter.class, compositeDefault=true) EJBException e)
[21:02:31] <lincolnthree> if compositeDefault is set to true, then the global filter would also be applied in addition to the local one
[21:02:42] <lincolnthree> im sure the name could be improved
[21:02:47] <lincolnthree> but that's the concept im trying to convey
[21:02:54] <lightguard_jp> hm
[21:02:54] <mojavelinux> I think that the real focus of the filtering is the formatter aspect
[21:03:13] <mojavelinux> and for that, I'm thinking something along the lines of being able to filter patterns out
[21:03:14] <lincolnthree> mojavelinux: I disagree, there's no way to globally apply a formatter to an Exception
[21:03:24] <mojavelinux> like root package names or symbols in the class
[21:03:30] <lincolnthree> *that* could be done
[21:03:36] <mojavelinux> sure there is
[21:03:48] <mojavelinux> if the app is providing the filter implementation
[21:03:56] <mojavelinux> then you know what you want to cut out
[21:04:09] <lincolnthree> Ok, I think we're mis-communicating
[21:04:12] <mojavelinux> what catch is providing is the applier
[21:04:26] <mojavelinux> the interface and the application of the filter to the stacktrace to get the result
[21:04:30] <mojavelinux> or the printer
[21:04:39] <mojavelinux> right now, you have two very coarse options
[21:04:43] <mojavelinux> printStackTrace, which sucks
[21:04:52] <lincolnthree> When I hear formatter, I think "formatStackTrace"
[21:04:55] <mojavelinux> and getStackTrace, which then requires a lot of work to get back to a print
[21:05:09] <mojavelinux> yes, exactly
[21:05:15] <mojavelinux> so I'm saying that you want to do two things
[21:05:16] <lincolnthree> That's not something you can do globally.
[21:05:21] <mojavelinux> you want to pare down the stack
[21:05:29] <lincolnthree> It has to be explicitly invoked by the developer where the stack trace is logged
[21:05:31] <mojavelinux> and then you want to be able to print it (or export it in some way)
[21:05:35] <mojavelinux> yes, of course
[21:05:40] <lincolnthree> I'm talking about something else
[21:05:51] <mojavelinux> I don't think we need to be messing with the exceptions
[21:05:52] <mojavelinux> globally
[21:06:08] <mojavelinux> this is really about printing or summary reporting in general
[21:06:15] <lincolnthree> I think there's more value to be gained.
[21:06:43] <mojavelinux> I read the back log
[21:06:56] <mojavelinux> but why do you care about the stacktrace other than when you are printing it?
[21:06:59] <lincolnthree> In providing a built-in StackTraceElementFilter, and a built in StackTraceElementFormatter
[21:07:19] <lincolnthree> Because it could be printed in any number of different ways.
[21:07:24] <lincolnthree> If it's re-thrown and un-caught
[21:07:26] <lincolnthree> if it's logged
[21:07:32] <lincolnthree> if it's displayed on a page
[21:07:42] <mojavelinux> yeah, so I don't get how that's different than what I'm saying
[21:07:42] <lincolnthree> You can handle all of that in one central place.
[21:07:49] <lincolnthree> At the Handler itself
[21:08:08] <mojavelinux> why not just have a nice API
[21:08:23] <lincolnthree> Why not both?
[21:08:42] <lincolnthree> Although
[21:08:46] <lincolnthree> I would concede one opint
[21:08:47] <lincolnthree> point
[21:08:48] <mojavelinux> sure, I see what you are saying...have a declarative way of passing it through the filter
[21:09:00] <mojavelinux> yeah, okay, that would be secondary in the implementation of this feature
[21:09:03] <lincolnthree> You can just @Inject ExceptionFormatter API and do that stuff in the handler itself
[21:09:06] <mojavelinux> right
[21:09:07] <lincolnthree> so yeah
[21:09:10] <mojavelinux> that's where we need to start
[21:09:13] <lincolnthree> sure
[21:09:19] <lincolnthree> then I agree
[21:09:25] <mojavelinux> it should really be ExceptionTransformer or something
[21:09:28] <lincolnthree> right
[21:09:49] <mojavelinux> then have the "export as" idea from shirnkwrap
[21:10:00] <mojavelinux> which takes a formatter
[21:10:13] <mojavelinux> something like
[21:10:21] <lincolnthree> But I still think that filtering entire StackTraceElements from the trace entirely can be useful.
[21:10:35] <mojavelinux> right, sure, for something downstream to not have to worry about it
[21:10:58] <lincolnthree> First you apply the filters
[21:11:00] <mojavelinux> that's again a transformer...you are taking the exception and creating a new view of it
[21:11:02] <lincolnthree> then you apply the formatters
[21:11:07] <lincolnthree> yes
[21:11:22] <mojavelinux> I mean, if you think about it
[21:11:33] <mojavelinux> the way that exceptions are displayed...it's like someone came up with a way
[21:11:41] <mojavelinux> and no one ever thought maybe there would be a different way
[21:11:52] <mojavelinux> for a decade we've used one formatter
[21:11:56] <mojavelinux> that's just crazy
[21:12:37] <mojavelinux> I think it would be really cool...and this would of course be a development feature
[21:12:43] <mojavelinux> to actually show the lines of code that failed
[21:13:00] <mojavelinux> now that would be game changing...how many times have you tried to find line 89 to see what it does?
[21:13:00] <lightguard_jp> That would be cool
[21:13:19] <mojavelinux> you could either do it with a jad-like tool
[21:13:38] <mojavelinux> or you could have a way to link the source in...not sure how that would work
[21:13:52] <lightguard_jp> I don't think there's a way we could do within the program though
[21:14:00] <mojavelinux> why not?
[21:14:04] <lightguard_jp> You'd have to link it up with the source code.
[21:14:17] <mojavelinux> not necessarily, the bytecode has most of the info you need to recreate it
[21:14:18] <mojavelinux> or
[21:14:23] <mojavelinux> we could have a way to link the source code in
[21:14:24] <lightguard_jp> jad-like tool probably won't work right.
[21:14:37] <mojavelinux> yeah, getting the source would be a better approach
[21:14:40] <lightguard_jp> But you don't have the exact code that was written
[21:14:55] <lightguard_jp> And byte code strips comments too
[21:15:03] <mojavelinux> yeah, true
[21:15:23] <mojavelinux> so one thing is that you could show the signature of the method you are in
[21:15:23] <lightguard_jp> And non-runtime retained annotations
[21:15:35] <mojavelinux> a lot of that info is not used in the current stacktrace
[21:15:49] <mojavelinux> but for the source display, we simply have to link in the source
[21:16:25] <lightguard_jp> Everything in StackTraceElement save hashCode and equals is used when you dump the stack trace
[21:17:20] <lightguard_jp> But we could go a little further and print the method sig
[21:17:23] <mojavelinux> doh!
[21:17:39] <mojavelinux> why doesn't it have a reference to the actual method
[21:17:42] <mojavelinux> that's lame
[21:17:44] <lightguard_jp> :)
[21:17:50] <mojavelinux> the name is not enough to find it
[21:17:54] <lightguard_jp> Yep, I thought the same thing when I looked at the javadocs
[21:18:03] <lightguard_jp> Oh, you're right
[21:19:16] <mojavelinux> so here's what we would need...at least to start
[21:19:31] <mojavelinux> assume that the .java file is on the classpath
[21:19:34] <mojavelinux> or at least look for it
[21:19:48] <mojavelinux> then print 5 lines on either side or something of the line reported
[21:19:58] <mojavelinux> that's a start and we can see what people come up with otherwise
[21:20:05] <mojavelinux> of course, you won't have all the source, but you should have your own source
[21:20:14] <mojavelinux> which is a good chance that's where the problem is happening
[21:20:17] <mojavelinux> or so you hope
[21:21:03] <mojavelinux> and with Mr. Lincoln's code in forge
[21:21:12] <mojavelinux> we could actually find the method and print that
[21:21:23] <mojavelinux> parse up the java file and figure out what method you are in at that line
[21:21:39] <mojavelinux> just some ideas
[21:21:44] <mojavelinux> I'm just saying, if we want to change the game
[21:21:49] <lincolnthree> well you could always use javap to convert the .class file into a source file, or a basic one
[21:22:08] <mojavelinux> yeah, we were saying that, but w/ so much source available now, it's just easier to go to the real thing
[21:22:15] <lincolnthree> then you could parse that with forge, if the source file isnt available
[21:22:17] <lincolnthree> ah
[21:22:18] <jbossbot> git [mail] push master 60ff43a.. Cody Lerum sync changes with internal project...
[21:22:18] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/db94362...60ff43a
[21:22:23] <lincolnthree> but if it's in a deployed app
[21:22:36] *** emmanuel has quit IRC
[21:22:41] <lincolnthree> chances are that you might not have access to the source at runtime
[21:22:54] <mojavelinux> in development you can ensure it is
[21:23:01] <mojavelinux> obviously it won't be in production, but this isn't for production
[21:23:21] <mojavelinux> I'm saying in development you bundle the source in the war
[21:23:44] <lightguard_jp> it would still be a lookup
[21:23:57] <lightguard_jp> if it's there
[21:24:05] <lightguard_jp> then do this
[21:24:12] <mojavelinux> sure, you have to do getResource()
[21:24:24] <lightguard_jp> yep
[21:27:26] <mojavelinux> also, while we are discussing exception filtering, we should discuss exception mapping too
[21:27:34] <clerum> so I basically have an impl of seam mail for that is outside of cdi so it works with seam 2
[21:28:10] <clerum> guessing I should just throw it up on my personal github and link it to the module page?
[21:28:17] <mojavelinux> interesting...because essentially the focus is on the mail api, not so much on cdi
[21:28:21] <clerum> in case people on seam 2 want to use it
[21:28:28] <clerum> right
[21:28:35] <clerum> very little of it is really cdi
[21:28:38] <mojavelinux> sure...if we need to we can move it into seam-mail as a submodule
[21:28:51] <clerum> k
[21:29:15] <mojavelinux> first we need to see where seam mail is in terms of a release though
[21:29:23] <clerum> I just need to use it in my seam 2 project now and I'm using the api now. helping to flush some other things out
[21:29:24] <clerum> yep
[21:29:53] <clerum> really I'm held up on using the generic beans to provide alternate session configs
[21:30:34] <mojavelinux> yep, I got stuck there too
[21:30:40] <mojavelinux> to be honest, I don't understand generic beans yet
[21:30:47] <mojavelinux> I think the solder docs need a second example
[21:30:49] <clerum> and my time is unfortuatnly very limited right now
[21:30:51] <mojavelinux> perhaps mail can be that example
[21:31:04] <mojavelinux> I get about two beans in, then I'm lost
[21:31:05] <mojavelinux> :)
[21:31:14] <clerum> yeah I'll take another look at it and see if pmuir can point me in the right direction
[21:31:16] <mojavelinux> is it that generic beans are not working correctly?
[21:31:26] <mojavelinux> or you are having trouble understanding them (like me)
[21:31:37] <clerum> I just can't get the configuration of them right...because I don't understand it well enough
[21:31:53] <mojavelinux> yep, okay, so I might jump in with you on this so I can learn from pete too
[21:32:02] <clerum> sounds good
[21:32:07] <mojavelinux> and I'll use it as an opportunity to improve the docs
[21:32:34] <stuartdouglas> I still have some more changes to go into generic beans in the next release
[21:32:46] <stuartdouglas> that should make them a (little) bit easier to understand
[21:32:56] <clerum> for solder?
[21:33:00] <stuartdouglas> yes
[21:33:39] <stuartdouglas> also there are lots of examples in the tests in solder
[21:33:42] <stuartdouglas> if that helps
[21:33:53] <clerum> ok...anyway that part is deeper in the guts of mail. I'm going to try and get the api locked down more and clean up the javadocs on it
[21:34:02] <clerum> then I'll circle back around
[21:34:07] <clerum> in a week or so
[21:34:20] <clerum> I'll check the example tests too
[21:34:43] <mojavelinux> ah, good call, didn't think about the tests
[21:35:06] <mojavelinux> stuart I noticed another major issue as we started to use the service handler for declarative exception mapping
[21:35:16] <mojavelinux> you can't provide an annotation in the api
[21:35:22] <mojavelinux> because it has a reference to the impl class
[21:35:32] <mojavelinux> @ServiceHandler(MyServiceHandler.class)
[21:35:43] <mojavelinux> so then you have to move the impl into the api
[21:35:55] <mojavelinux> and that brings a whole slew of other stuff with it typically
[21:35:59] <mojavelinux> can we switch to a string?
[21:36:06] <mojavelinux> or perhaps some other approach?
[21:36:10] <mojavelinux> interface?
[21:36:47] <mojavelinux> actually, interface would be sufficient, or some other binding approach
[21:37:37] <stuartdouglas> I think string would probably be the best approach here
[21:38:29] <mojavelinux> yeah, at least to start. also, it would be nice if it could be on a stereotype
[21:38:33] <mojavelinux> not just a metaannotation
[21:38:44] <mojavelinux> for instance, an idea we had in Seam Catch
[21:39:15] <mojavelinux> was being able to group @HandlesExceptions and @ExceptionResponseService (service handler annotation) into an annotation called @ExceptionResponses
[21:39:32] <mojavelinux> catch now supports stereotype checking, so we just have to do the same lookup in PAT
[21:39:39] <mojavelinux> in service handler extension
[21:40:57] <mojavelinux> I feel like all I'm doing is filing JIRA requests today :) but that's good, lots of improvements
[21:41:20] <stuartdouglas> actually making @ServiceHandler a meta-annotation could be the way to go
[21:41:33] *** tsurdilo has quit IRC
[21:41:47] <stuartdouglas> so then you annotate both the interface and the handler with the annotated annotation
[21:41:55] <stuartdouglas> in a similar way to how interceptor bindings work
[21:42:27] <mojavelinux> indeed, I was thinking that, but wasn't sure if there was a reason you didn't choose binding already, so I didn't suggest it
[21:42:37] <mojavelinux> how about I make the issue report generic to solve the issue of less coupling
[21:42:41] <mojavelinux> then we can run with the best solution
[21:42:48] <stuartdouglas> the current apprach is simpler, and easier to understand
[21:43:05] <stuartdouglas> with the meta annotation approach it is not immediatly clear what is going on
[21:43:57] <stuartdouglas> SOLDER-50
[21:43:59] <jbossbot> jira [SOLDER-50] Throw a specialized exception when BeanManagerAware cannot resolve BeanManager [Coding In Progress, Minor, Lincoln Baxter III] https://issues.jboss.org/browse/SOLDER-50
[21:44:16] <stuartdouglas> I don't think that the bean manager not being availible is something that is recoverable
[21:44:28] <lincolnthree> it is in faces
[21:44:56] <lincolnthree> although, to some extent, I see your point
[21:45:07] <lincolnthree> it depends on the nature of the extension
[21:45:16] <lincolnthree> More correct might be to say
[21:45:16] <stuartdouglas> this should only happen in a new environment that does not have a BeanManagerAccessor yet
[21:45:37] <lincolnthree> It's something that should probably fail gracefully instead of failing hard.
[21:45:39] <stuartdouglas> e.g. in an EE environment it should always be available from JNDI
[21:45:39] <mojavelinux> I argued that it should just return null, but I'd be happy with something I can actually catch
[21:46:51] <lincolnthree> It's something that you actually need to think about.
[21:46:53] <mojavelinux> the Catch integration in seam faces is sort of an example of it being recoverable (though null would work too)
[21:47:00] <lincolnthree> "Is the bean manager going to be avaiable here?"
[21:47:07] <mojavelinux> because if it's not available, then it just allows jsf to handle exceptions as normal
[21:47:23] <mojavelinux> but then again, if you are using seam faces and cdi isn't available, it likely would have fallen apart before then :)
[21:47:29] <stuartdouglas> but it should always be available
[21:47:49] <stuartdouglas> the solution is to write a new BeanManagerProvider, not catch the exception
[21:47:58] <lincolnthree> i suppose I agree
[21:48:03] <lincolnthree> :)
[21:48:04] <lincolnthree> darn
[21:48:08] <mojavelinux> actually, this is an area where seam is still sitting on the fence
[21:48:25] <mojavelinux> because in a lot of places we are tenative as to whether cdi is available...not saying we should, I'm just observing
[21:48:43] <stuartdouglas> where?
[21:48:48] <mojavelinux> there are many areas that are attempting to degrade gracefully
[21:48:52] <mojavelinux> in the faces and servlet modules
[21:49:26] <mojavelinux> I'm still trying to decide what to do in the servlet module
[21:49:36] <mojavelinux> as to whether I even need BeanManagerAware
[21:49:47] <mojavelinux> I inherited the code, so I didn't start down that path
[21:49:52] <mojavelinux> I'm the one backing it out
[21:50:03] <mojavelinux> what it does is use @Inject in a filter/servlet/listener
[21:50:07] <mojavelinux> @Inject BeanManager
[21:50:12] <mojavelinux> and if that didn't resolve
[21:50:13] <stuartdouglas> with servlet, the servlet context may start before or after CDI
[21:50:19] <mojavelinux> it turns around and tries to look it up
[21:50:19] <stuartdouglas> it is unspecified
[21:50:38] <stuartdouglas> with weld-servlet the servlet context comes up first
[21:50:43] <mojavelinux> nope, it's okay
[21:50:48] <stuartdouglas> with jbossas6 other way around
[21:50:48] <mojavelinux> because @Inject must work into a listener
[21:51:01] <mojavelinux> so far it's proved to work for me in all cases
[21:51:18] <mojavelinux> @Inject is required to work into a listener, so cdi must be loaded first
[21:51:33] <mojavelinux> that's just implied, it's not a super well defined rule
[21:51:37] <stuartdouglas> but not in weld servlet
[21:51:46] <stuartdouglas> cause it is bootstrapped by a listener
[21:51:56] <stuartdouglas> I also have something of an announcement to make, although I think most of you already know
[21:52:01] <mojavelinux> hehehe
[21:52:14] <stuartdouglas> As of next year I will be working for jboss on as7, doing weld and ejb integration
[21:52:33] <lincolnthree> congratulations stuartdouglas!
[21:52:36] <mojavelinux> FANTASTIC!! congratulations!! whooooooooooooooooooooooooooooooooooooooooooooooooooooooo
[21:52:48] <lincolnthree> Glad to hear it finally happened!!!! Long overdue :) Mr. 1 man army
[21:52:49] <lightguard_jp> :)
[21:52:51] <lightguard_jp> YAY!!
[21:53:04] <lincolnthree> With you on AS7, I'm confident it won't suck!
[21:53:13] <mojavelinux> as 7 is going to rock for so many reasons
[21:53:14] <mojavelinux> hahha
[21:53:17] <mojavelinux> I was thinking too
[21:53:29] <mojavelinux> it's actually perfect because you can pursue fake replace at the right level
[21:53:29] <stuartdouglas> thanks guys :-)
[21:53:52] <stuartdouglas> yes, I have not looked at fakereplace in ages
[21:54:04] <mojavelinux> I should also take the opportunity to thank you for saving seam 3 as well :)
[21:54:36] <stuartdouglas> I would not go that far
[21:54:39] <mojavelinux> stellar work
[21:54:54] <lincolnthree> No, stuartdouglas, it's really true.
[21:55:15] <mojavelinux> there were some defining moments, you greased the wheels
[21:55:17] <lincolnthree> You and the rest of the community guys that refused to let us give up :)
[21:55:21] <lincolnthree> At critical moments.
[21:55:39] <lincolnthree> Coming through with persistence in particular, and weldx, were the two brightest moments I think.
[21:55:48] <lincolnthree> In addition to being there to answer questions from everybody (mostly me I think.)
[21:56:15] <lincolnthree> And that really goes for everybody here, too.
[21:56:25] <mojavelinux> um, how about seam config :)
[21:56:28] <mojavelinux> major
[21:56:28] <lincolnthree> Oh duh.
[21:56:29] <lincolnthree> Hah!
[21:56:36] <lincolnthree> I knew I missed something.
[21:58:19] <lightguard_jp> haha
[21:59:20] <mojavelinux> but yeah, we can get seam servlet module loading after weld servlet thanks to relative ordering
[21:59:30] <mojavelinux> something I meant to add but forgot
[21:59:43] *** epbernard has joined #seam-dev
[21:59:43] *** epbernard is now known as emmanuel
[21:59:56] <mojavelinux> if the user puts the listener in their web.xml, that will come first anyway
[22:00:06] <mojavelinux> since seam servlet uses web-fragment.xml
[22:00:23] <mojavelinux> if weld used web-fragment.xml, then we need to come after that...I'll add it in for future proofing
[22:00:35] <lightguard_jp> https://blogs.apache.org/foundation/entry/the_asf_resigns_from_the
[22:00:45] <lightguard_jp> If people haven't seen it
[22:00:59] <mojavelinux> yeah, lincoln and I were just discussing offline
[22:01:25] <stuartdouglas> I doubt it will change oracles position
[22:01:48] <lincolnthree> It won't.
[22:01:53] <lincolnthree> Oracle does the arm bending.
[22:03:18] <mbg> stuartdouglas: I'm skimming through the log, so this is a bit late, but:  this is excellent news, welcome onboard!
[22:03:37] <stuartdouglas> thanks mbg
[22:04:50] <mojavelinux> btw, if you are interested we are putting together a new logo color scheme for Seam 3 modules
[22:04:52] <mojavelinux> https://issues.jboss.org/browse/DESIGN-152
[22:04:53] <jbossbot> jira [DESIGN-152] Seam 3 Module Logos [Coding In Progress, Major, James Cobb] https://issues.jboss.org/browse/DESIGN-152
[22:05:29] <mojavelinux> the last link is the candidate for approval
[22:05:56] <mojavelinux> if anyone has any thoughts, feel free to weigh in...though probably best in IRC so we don't confuse the poor designers
[22:05:59] <mojavelinux> :)
[22:10:19] <lightguard_jp> Which link?
[22:11:34] <lightguard_jp> https://issues.jboss.org/secure/attachment/12339493/seam_typeweight_r5v1.gif ?
[22:12:52] <mojavelinux> correct
[22:13:00] <mojavelinux> yeah, jira is lame about attachments
[22:13:10] <mojavelinux> doesn't seem to put them in any sort of logical order (maybe it's alpha)
[22:14:35] <lightguard_jp> Looks like it's alpha
[22:20:47] <mojavelinux> stuartdouglas: I have one other question about service handlers
[22:20:58] <mojavelinux> is it possible to have two service handlers process the same method?
[22:21:00] <stuartdouglas> yes?
[22:21:45] <mojavelinux> btw, I really like the idea of using the binding annotations for service handlers...that makes them just like interceptor bindings, so that should be easier for people to understand in the long run
[22:22:20] <stuartdouglas> can you file a jira for that?
[22:22:40] <mojavelinux> I just did SOLDER-51
[22:22:42] <jbossbot> jira [SOLDER-51] Decouple service handler annotation from implementation class [Open, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-51
[22:23:24] <stuartdouglas> cool
[22:24:29] <lincolnthree> and mojavelinux said, "boom"
[22:24:36] <lincolnthree> "i just did"
[22:25:03] <mojavelinux> next we need jboss bot to start filing issues for us
[22:25:17] <lincolnthree> jbossbot: do my bidding
[22:25:17] <mojavelinux> make the machines do the work
[22:25:28] <mojavelinux> then jboss bot needs to implement the feature
[22:25:32] <mojavelinux> based on what we said
[22:25:33] <mojavelinux> hahaha
[22:25:36] <lightguard_jp> Hm
[22:25:43] <lightguard_jp> Is that Skynet starting to form?
[22:26:25] <mojavelinux> @author jbossbot
[22:26:57] <mojavelinux> if Pete rejects jbossbot's, at least it won't feel sad
[22:27:05] <mojavelinux> jbossbot's issue that is
[22:30:23] *** balunasj has joined #seam-dev
[22:41:22] <stuartdouglas> I'm off to work
[22:41:32] <stuartdouglas> 10 days to go :-)
[22:41:43] <lightguard_jp> hehe
[22:41:48] <lightguard_jp> Counting down huh?
[22:42:18] <stuartdouglas> yes, the timing worked out pretty well as my last day is actually the christmas party
[22:42:25] <lincolnthree> Hah! nice. Good luck :)
[22:42:27] <lightguard_jp> lol
[22:45:09] <mojavelinux> ending on a high note with some egg nog
[22:46:06] <lightguard_jp> yum, broccolli cheese soup, just need it in a bread bowl now.
[22:46:25] <lincolnthree> I ended with my boss' boss threatening to fire me after I told them I was quitting -- then basically being like, "whatever" and walking out of his office.
[22:47:12] <lightguard_jp> lol
[22:47:49] <lincolnthree> Yeah - true story. ha ha
[22:48:08] <lincolnthree> Gotta get ready to head out of here for a bit. Swimming tonight finally
[22:48:09] <lightguard_jp> The ending was?
[22:48:16] <lincolnthree> Yea
[22:49:48] *** tsurdilo has joined #seam-dev
[22:49:56] <lightguard_jp> lincolnthree: Were you fired or not?
[22:50:03] <lincolnthree> Oh, no.
[22:50:04] <lincolnthree> Lol
[22:50:10] <lincolnthree> He was just mad that he just promoted me.
[22:50:20] <lincolnthree> It was his own fault that I told him I wanted to leave and he promoted me.
[22:50:34] <lightguard_jp> yep
[22:50:38] <lincolnthree> "Rate your opinion of X as a long term career:"
[22:50:40] <lincolnthree> 1 out of 10
[22:50:42] <lincolnthree> I mean, cmon.
[22:50:46] <lincolnthree> that's a pretty clear indication
[22:50:58] <lincolnthree> And I even told him directly.
[22:51:03] <lincolnthree> "I don't see a place for me here."
[22:51:10] <lincolnthree> It's all funny looking back.
[22:51:13] <lightguard_jp> We're software people "long term" typically means 5 years
[22:51:24] <lincolnthree> haha
[22:51:34] <bleathem> 5 years is a long time
[22:51:56] <bleathem> it's wehn the stagnation starts to set in if at the wrong place
[22:52:03] <lincolnthree> Yes... and it set in hard.
[22:53:58] <lightguard_jp> lincolnthree: enjoy your swim
[22:54:11] <lincolnthree> thanks, cya later dudes
[22:54:35] <bleathem> cya





top