[00:05:26] *** lightguard_jp has joined #seam-dev
[00:29:58] *** jharting has quit IRC
[00:54:08] *** lightguard_jp has quit IRC
[00:56:14] *** tsurdilo2 has quit IRC
[00:58:22] *** lincolnthree has left #seam-dev
[01:10:04] *** aslak_ has quit IRC
[03:35:22] *** rruss has joined #seam-dev
[04:50:35] *** lightguard_jp has joined #seam-dev
[05:07:19] *** rruss has quit IRC
[06:10:18] <lightguard_jp> Anyone around?
[07:45:56] *** lightguard_jp has quit IRC
[07:50:20] *** oskutka has joined #seam-dev
[08:24:41] *** mausbull has joined #seam-dev
[09:07:51] *** jharting has joined #seam-dev
[09:28:16] *** aslak has joined #seam-dev
[09:28:16] *** aslak has quit IRC
[09:28:16] *** aslak has joined #seam-dev
[09:37:01] *** amitev has joined #seam-dev
[09:46:31] *** shervin_a has joined #seam-dev
[09:58:18] *** plenyi has joined #seam-dev
[10:15:05] *** kpiwko has joined #seam-dev
[10:29:14] *** marekn has joined #seam-dev
[11:37:12] *** marekn has quit IRC
[12:06:41] *** marekn has joined #seam-dev
[12:40:38] *** jbossbot has quit IRC
[12:42:41] *** jbossbot has joined #seam-dev
[13:49:36] *** plenyi has quit IRC
[13:53:01] *** rruss has joined #seam-dev
[13:57:02] *** rruss has quit IRC
[14:05:58] *** lincolnthree1 has joined #seam-dev
[14:15:33] *** mojavelinux has joined #seam-dev
[14:16:01] <mojavelinux> we are on for the meeting at the top of the hour (45 mins)
[14:39:53] *** tsurdilo has joined #seam-dev
[14:42:10] *** jganoff has joined #seam-dev
[14:54:09] *** oskutka has quit IRC
[14:55:36] *** oskutka has joined #seam-dev
[14:57:51] *** clerum has joined #seam-dev
[14:58:53] *** balunasj has joined #seam-dev
[15:03:11] *** lightguard_jp has joined #seam-dev
[15:03:25] *** oskutka has quit IRC
[15:04:38] <lightguard_jp> mojavelinux: I believe so
[15:04:44] <lightguard_jp> No emails saying we're not
[15:06:08] <mojavelinux> yep, we are on
[15:06:14] <mojavelinux> oh, shoot, didn't realize it was 5 past the hour
[15:06:21] <mojavelinux> okay, pressing send on an e-mail
[15:06:48] <lincolnthree1> woops, me either - too little sleep, too many monitors ;)
[15:09:12] <mojavelinux> now we have two lincolns and two monitors...geez
[15:09:29] <lightguard_jp> :)
[15:09:30] <lincolnthree1> Just one me at the moment :)
[15:09:49] <mojavelinux> first up, is anyone blocked on anything that you need to get resolved?
[15:10:18] <jganoff> other than lack of time
[15:10:23] <mojavelinux> in terms of Seam development (I can't help with mortgages)
[15:10:25] <mojavelinux> or time
[15:10:27] <jganoff> pete mentioned trying to find some help for jms - it's suffering pretty badly
[15:10:46] <lincolnthree1> I'm running into weld bugs, but not blocked because I have the liberty of putting patches in Forge (since I decide what every depenency is and dont need to worry about appservers or containers :))
[15:12:00] <mojavelinux> jganoff: jms is one of the modules I'd like to visit, but I've been addressing catch and servlet and haven't made it to jms yet
[15:12:07] <lightguard_jp> I can help with mortgages ;) Send them my way
[15:12:49] <lightguard_jp> Thank you very much Dan for the help in catch
[15:12:55] <jganoff> mojavelinux, not a problem - i have a couple changes in the pipe that i need to push back to github but overall I've had _very_ little time to work on it and that doesn't look like it's going to change in the short term :(
[15:13:02] <mojavelinux> jganoff: I see that the proposed designs made it into JIRA
[15:13:06] <mojavelinux> that should help with contributors
[15:13:13] <mojavelinux> if anyone is interested in JMS, or even if you are not
[15:13:25] <jganoff> mojavelinux, yea i set those up a while back to make sure the community was informed on what needed to be done
[15:13:27] <mojavelinux> the JMS module offers some really cool opportunities to play with the extension SPI
[15:13:39] <mojavelinux> jganoff: thank you...also helps my own poor memory :)
[15:14:05] <jganoff> mojavelinux, yea - i think i have something working for SEAMJMS-3
[15:14:06] <jbossbot> jira [SEAMJMS-3] Event Mapping Observer Method Interfaces - Egress [Open, Blocker, Unassigned] https://jira.jboss.org/browse/SEAMJMS-3
[15:14:08] <mojavelinux> in fact, lightguard_jp, the jms module would be very relevant to the work on catch (which will cover soon)
[15:14:32] <mojavelinux> jganoff: I'll clone and see if I can at least get to reviewing it
[15:14:53] <mojavelinux> btw, part of making modules consistent is reviewing each other's modules
[15:15:03] <mojavelinux> it doesn't take long, but what makes it worthwhile
[15:15:05] <mojavelinux> is that in github
[15:15:09] <mojavelinux> you can click on any commit
[15:15:12] <mojavelinux> and add line-comments
[15:15:21] <lightguard_jp> I'd like to work on JMS, gotta get catch done first though
[15:15:22] <jganoff> yea that's a powerful review tool
[15:15:31] <mojavelinux> this is useful if you have a suggestion, you need a clarification or if you just want to strike up some teamwork
[15:15:37] <mojavelinux> lightguard_jp: awesome
[15:15:48] <mojavelinux> we are all in this together :)
[15:16:06] <mojavelinux> so the line-comments make it fun...also you don't have to spam the mailinglist then if you feel tenative about your question
[15:16:15] <mojavelinux> you can make it public and targetted
[15:16:45] <mojavelinux> while it's on my mind...
[15:16:53] <mojavelinux> if you haven't heard, weld extensions will become seam solder
[15:17:04] <mojavelinux> when, I'm not sure
[15:17:29] <mojavelinux> but keep forging ahead...the refactoring won't likely be too difficult as it just involves package changes
[15:17:42] <mojavelinux> would be cool if Pete is able to use Eclipse's refactor playback to make that work
[15:17:48] <mojavelinux> never had a use for it myself
[15:18:27] <mojavelinux> okay, enough business, let's get into modules
[15:18:37] <mojavelinux> lightguard_jp: has made great progress on catch
[15:18:59] <mojavelinux> I think it's going to be a lot more central than we collectively appreciate
[15:19:13] <mojavelinux> so go ahead and give an update there
[15:19:30] <mojavelinux> lightguard_jp:
[15:19:36] <lightguard_jp> I'm getting close to being done (closer if Dan would stop coming up with cool ideas)
[15:19:52] <lightguard_jp> API is there for the most part.  Getting into impl now
[15:20:01] <lincolnthree1> lightguard_jp: when you get to the faces impl, let me know
[15:20:07] <lightguard_jp> It's drastically different from what we first came up with
[15:20:19] <lincolnthree1> lightguard_jp: interesting!
[15:20:24] <lightguard_jp> It's very similar to observers now.
[15:20:28] <lincolnthree1> I havent looked at it since then
[15:20:34] <mojavelinux> and how will that look? (leading question)
[15:21:05] <lightguard_jp> For those that are interested https://github.com/LightGuard/catch/tree/third_design
[15:21:14] <lightguard_jp> It's still WIP and doesn't build yet, but you can see what we're doing
[15:22:11] <mojavelinux> to stear the update a bit
[15:22:19] <lightguard_jp> @HandlesException MyHandlerClass { public void npeHandler(@Handles ExceptionHandlerEvent<NullPointerException> event <any other injectable objects>) { ... } }
[15:22:25] <mojavelinux> there you go
[15:22:43] <lightguard_jp> We also have the idea of Outbound and Inbound processing
[15:22:46] <mojavelinux> ah, we may be removing @HandlesException
[15:22:53] <jganoff> neat stuff
[15:23:00] <mojavelinux> MyHandlerClass { public void npeHandler(@Handles ExceptionHandlerEvent<NullPointerException> event,  injections...) { ... } }
[15:23:08] <jganoff> yea @HandlesException and @Handles is a little redundant
[15:23:08] <lightguard_jp> Basic we go through the chain twice once in once out and you can listen and handle either time.
[15:23:12] <mojavelinux> the idea is to have a handler that is as lightweight as possible
[15:23:27] <mojavelinux> implementing an interface means 1 exception == 1 class
[15:23:28] <jganoff> what if you just inject the ExceptionHandlerEvent
[15:23:30] <lightguard_jp> The HandlesException is just a marker to lessen the scanning
[15:23:32] <jganoff> and don't introduce 2 new annotations?
[15:23:43] <mojavelinux> so the observer-method strategy makes it possible to aggregate
[15:24:05] <jganoff> npeHandler(@Observes ExceptionHandlerEvent<NPE> event, ...);
[15:24:22] <mojavelinux> so we definitely went down the path of considering using observers directly
[15:24:24] <mojavelinux> way down the path
[15:24:25] <mojavelinux> :)
[15:24:32] <lightguard_jp> Can't do generic event loads with @Observes :(
[15:24:33] <jganoff> ahh, brick wall at the end?
[15:24:37] <mojavelinux> basically
[15:24:44] <mojavelinux> on two fronts, lightguard_jp mentioned one
[15:25:01] <mojavelinux> we have a generics problem in one case
[15:25:04] <mojavelinux> but the bigger issue
[15:25:10] <mojavelinux> is that we absolutely must order the observers
[15:25:18] <jganoff> ahh, gotcha.
[15:25:19] <mojavelinux> and we must have a shortcircuit capability
[15:25:25] <lightguard_jp> Lincoln has that covered, but then we still have the first problem
[15:25:28] <jganoff> akin to exception handling ;)
[15:25:29] <mojavelinux> we can make it work with some bending and twisting
[15:25:39] <mojavelinux> but it changes the semantics of the observers and that to us seems like a bad idea
[15:25:41] <lincolnthree1> Generic event loads?
[15:26:15] <mojavelinux> there are two things the catch module does to process the exception stack trace, lightguard_jp?
[15:26:37] <lincolnthree1> I think this is a perfect use-case for the event bus from forge. Since ExceptionEvents will likely inherit from a base type (which is required by the bus) you're already 1/2 of the way there
[15:26:46] <lincolnthree1> the only thing left to do is implement a FiringControl that matches your needs
[15:26:53] <lincolnthree1> And set up the right annotations.
[15:26:56] <lincolnthree1> With ordering parameters
[15:27:55] <mojavelinux> so catch does two things....it unwraps the exception stack trace, notifying handlers for each cause in the stack
[15:28:08] <mojavelinux> until at least one handler marks the exception as handled
[15:28:14] <mojavelinux> there are other flow controls as well
[15:28:18] <mojavelinux> for each cause
[15:28:40] <mojavelinux> catch notifies from general type down to specific type back to general type
[15:28:46] <mojavelinux> so, if you have an IllegalArgumentException
[15:28:49] <lightguard_jp> We find all the handler methods, order them correctly and observe the firing of exceptions.  The exception is unwrapped so we start with the inner most exception and work out.  When those are observed we fire off our own handler event through the chain starting with @Inbound and progressing through the chain.  The handler can short circuit the chain and stop if needed.  Once all the @Inbound handlers are done we run through @Outbou
[15:29:02] <lincolnthree1> FiringControl literally controls each and every observer method, if they are called at all, if it keeps firing the event to more observers, etc.
[15:29:02] <mojavelinux> sorry, there you go
[15:29:11] <mojavelinux> thanks lightguard_jp
[15:29:13] <lightguard_jp> mojavelinux: You type faster than I do :)
[15:29:16] <mojavelinux> well said
[15:29:17] <mojavelinux> hahaha
[15:29:18] <mojavelinux> sorry about that
[15:29:50] <mojavelinux> want to fill out the example of the IllegalArgumentException?
[15:30:05] <lightguard_jp> With out and in?
[15:30:48] <lightguard_jp> public void iaeHandler(@handles @Inbound @outbound EHE<IAE> event, BeanManager bm) { ... }
[15:31:17] <lightguard_jp> You could also inject messages or a NavigationHandler, etc
[15:31:49] <lightguard_jp> Basically anything the user can think of to handle an exception should be possible this way.
[15:32:10] <mojavelinux> I was hinting the handlers are notified of the exception as follows
[15:32:12] <lightguard_jp> The ExceptionHandlerEvent has flow control methods to modify the chain traversal
[15:32:20] <lincolnthree1> Example of how to use the (currently very prototype) Event Bus API: https://github.com/lincolnthree/seam-forge/blob/master/event-bus/src/test/java/org/jboss/seam/forge/bus/cdi/ObserverCaptureExtensionTest.java
[15:32:38] <lightguard_jp> So you can proceed, abort, go to the next cause, rollback, etc
[15:32:40] <mojavelinux> @Inbound Exception, then @Inbound RuntimeException, then IllegalArgumentException, then @Outbound RuntimeException, then @Outbound Exception
[15:32:54] <mojavelinux> where @Outbound is implicit when you have a @Handles method
[15:32:59] <lightguard_jp> Right
[15:33:08] <mojavelinux> the purpose of @Inbound is so you can capture all exceptions up front to do something like log it
[15:33:26] <mojavelinux> if you had an @Handles @Outbound Exception, then you might never get called
[15:33:31] <lincolnthree1> Interesting
[15:33:41] <lightguard_jp> @Handles also has a priority on it so you can put something up front as well.
[15:33:43] <mojavelinux> sort of like servlet filters
[15:34:15] <mojavelinux> yes, precedence allows you to put one handler before another, sort of like ordering of servlet filters
[15:34:28] <lightguard_jp> So you could have a LoggingHandler that is @Handles(priority=100) EHE<Exception> event, Log l that would happen first
[15:34:43] <lightguard_jp> Right, we called it precedence
[15:34:51] <lightguard_jp> Been through too many refactors already :)
[15:34:55] <mojavelinux> yep, since that's what Seam Solder (Weld Extensions) uses
[15:35:10] <mojavelinux> so the gist of all this
[15:35:12] <lightguard_jp> FWIW, we've been through three major redesigns of this thing already.
[15:35:18] <mojavelinux> aside from the fact that great progress has been made
[15:35:32] <mojavelinux> as lightguard_jp mentions, 3 major reworks
[15:35:44] <mojavelinux> is that this is absolutely capable of handling all exception concerns for any module
[15:35:45] <lightguard_jp> This appears to be the most robust, and easiest to use
[15:35:47] <mojavelinux> case in point is the rest module
[15:35:47] <aslak> lincolnthree1, is the forge event bus any different then cdi event bus?
[15:35:56] <mojavelinux> there is a lot of duplicate logic there that is now in catch
[15:36:00] <mojavelinux> so we can simplify that
[15:36:16] <mojavelinux> also, I see servlet and faces modules both leveraging this
[15:36:30] <mojavelinux> most of what the modules will do is just provide the bridge
[15:36:34] <mojavelinux> as well as some built-in handlers
[15:36:57] <lincolnthree1> aslak: yes - forge event bus is a CDI extension that allows you to fire a basic new Event(), and even though there may be 10 methods that @Observes that Event type, you control which methods are called, in what order, if processing stops after certain conditions are met
[15:37:03] <lincolnthree1> It needs a nice API
[15:37:06] <lincolnthree1> but the fundamentals are there
[15:37:48] <lightguard_jp> The bridge is pretty much as simple as providing the event for the exception.
[15:38:01] <lightguard_jp> Other modules could provide default handlers for people to use
[15:38:21] <aslak> lincolnthree1, you being the 'owner ' of the core, and no tthe caller i guess?
[15:38:25] <lincolnthree1> lightguard_jp: mojavelinux, I think it sounds pretty solid
[15:38:39] <lincolnthree1> aslak: what do you mean?
[15:38:45] <lightguard_jp> mojavelinux: It would be awesome to have the idea of the querybuilder for catch so you define the interface with some config and we'll create the handler.
[15:38:54] <aslak> lincolnthree1, "you control which methods are called", who are you?
[15:39:05] <lincolnthree1> aslak: you are the developer
[15:39:20] <aslak> lincolnthree1, sure, but the publisher, subscriber, or broker?
[15:39:26] <lincolnthree1> ahhh
[15:39:34] <lincolnthree1> the broker controls which events are called, in what order
[15:39:42] <aslak> ok
[15:39:43] <lincolnthree1> the subscriber can provide hints or configuration to the broker
[15:39:57] <lincolnthree1> the broker and the publisher are the same thing
[15:40:02] <lincolnthree1> oh no
[15:40:03] <lincolnthree1> sorry
[15:40:07] <lincolnthree1> the publisher is separate
[15:40:10] <lincolnthree1> the broker intercepts
[15:40:29] <lincolnthree1> the subscriber configures and waits to be notified
[15:41:03] <aslak> lincolnthree1, hints like?
[15:41:20] <lincolnthree1> @BusManaged(priority="12")
[15:41:34] <aslak> aa
[15:41:46] <lincolnthree1> @BusManaged(haltProcessingOnException=Exception.class)
[15:41:51] <lincolnthree1> etc...
[15:41:55] <lincolnthree1> anything you want to define
[15:42:07] <lincolnthree1> right now there are no rules, and also no API to make things nice to work with
[15:42:13] <lincolnthree1> I got the extension working and had to stop
[15:42:26] <aslak> lincolnthree1, so your using Events for more then just loose betwen plugin communication then?
[15:42:51] <lincolnthree1> Right, we need to be able to modify the event payload, determine who needs to receive that modified payload, etc, in forge
[15:43:03] <lightguard_jp> mojavelinux: Anything else you want to cover for catch.  Or anyone have questions?
[15:43:09] <lincolnthree1> So that plugins dont create an infinite loop of events when they observe things like "JavaFileChanged"
[15:43:21] <lincolnthree1> and then fire a new "JavaFileChanged" event themselves
[15:43:44] <aslak> lincolnthree1, shouldn't that be @Changed JavaFile ;)
[15:43:57] <lincolnthree1> aslak: yea yea ;)
[15:44:21] <lincolnthree1> Except there are hierarchies of events
[15:44:21] <lincolnthree1> so
[15:44:24] <lincolnthree1> that might be hard
[15:44:33] <mojavelinux> if you want to continue discussing, can you hold of for a few minutes...we'll get the meeting wrapped up
[15:44:38] <lincolnthree1> Sure
[15:44:46] <mojavelinux> I'm working on getting the servlet module pushed out
[15:44:53] <mojavelinux> I needed to do some tests
[15:45:31] <mojavelinux> then release perhaps tomorrow
[15:45:36] <mojavelinux> I did come up with one question I wanted to throw out there
[15:45:40] <aslak> lincolnthree1, yea, i was wondering the same when i was playing with the eventing between arq and a possibl eejb plugin. . my test used  @Created JavaFile or similar, but was wondering if they should be more specific.. and if they are to be more specific e.g. @Created @EJB JavaFile how to make them loose between the plugins..
[15:45:45] <mojavelinux> it was working as
[15:46:05] <mojavelinux> (@Observes @Initialized ServletContextEvent e)
[15:46:11] <mojavelinux> same w/ HttpSessionEvent and ServletRequestEvent
[15:46:25] <mojavelinux> all three events have no value other than providing the associated object
[15:46:31] <mojavelinux> ServletContext, HttpSession, ServletRequest
[15:46:37] <mojavelinux> so I'm inclined to simplify it to
[15:46:45] <mojavelinux> (@Observes @Initialized ServletContext ctx)
[15:46:56] <mojavelinux> the only time the servlet event types are relevant
[15:47:01] <mojavelinux> is for attribute change events
[15:47:21] <mojavelinux> since it has name, value and servlet object (context, session or request)
[15:47:28] <mojavelinux> hence the Event is actually meaningful
[15:47:30] <aslak> lincolnthree1, a plugin could listen to all JavaFiles, but that is probably not what he wants.. I can do something specific to some specific type of JavaFile. I can create a Test based on a EJB. with just JavaFile i'm stuck having to identify if this might be a EJB or not based on annotations that might be there somewhere..  and is the JavaFile event on the Local interface or the Remote interface or the Bean etc ?
[15:47:38] <mojavelinux> we good with (@Observes @Initialized ServletContext ctx)?
[15:47:49] <mojavelinux> lincolnthree1:
[15:47:49] <lightguard_jp> Looks fine to me
[15:47:57] <mojavelinux> cool
[15:48:18] <mojavelinux> if someone screams about it, we can always double up and just fire 2 events (though they won't fire unless there are observers of course)
[15:48:27] <mojavelinux> great
[15:48:28] <lincolnthree1> That
[15:48:30] <lincolnthree1> s fine with me
[15:48:36] <lincolnthree1> Simple enough
[15:48:41] <mojavelinux> also, we currently have
[15:48:42] <lincolnthree1> I don't like wrappers fi they can be avoided
[15:48:48] <mojavelinux> @Inject @HttpParam("name") String name;
[15:49:22] <mojavelinux> however, I want to align w/ JAX-RS
[15:49:29] <mojavelinux> so call it instead @QueryParam
[15:49:37] <mojavelinux> and then add the other parallel ones
[15:49:38] *** plenyi has joined #seam-dev
[15:49:57] <aslak> mojavelinux, is HttpParam query string or request param?
[15:49:58] <mojavelinux> I was going to reuse the jax-rs annotations, exception we have to make them qualifiers
[15:50:03] <mojavelinux> and that would throw a wrench in things
[15:50:19] <mojavelinux> httpparam is currently request.getParameter()
[15:50:27] <mojavelinux> as is @QueryParam from JAX-RS
[15:50:32] <lightguard_jp> lincolnthree1: Didn't you have something like that with Faces?
[15:50:49] <aslak> mojavelinux, yea, but QueryParam pr rest spec is QueryString no?
[15:51:06] <mojavelinux> I'll check on that
[15:51:14] <mojavelinux> if for some reason there is a difference
[15:51:15] <lincolnthree1> lightguard_jp: only for form validation
[15:51:21] <aslak> rest spec meaning filospohy.. :)
[15:51:23] <mojavelinux> then I'm inclined to make it @RequestParam
[15:51:30] <mojavelinux> I'll check
[15:51:30] <lincolnthree1> if you want @Inject @HttpParam you need to use Servlet Module as well
[15:51:39] <lincolnthree1> It should be @RequestParam
[15:51:42] <mojavelinux> nice
[15:51:43] <mojavelinux> done
[15:51:44] <lincolnthree1> because that's what it really is
[15:51:46] <mojavelinux> will be done
[15:51:48] <mojavelinux> :)
[15:51:50] <mojavelinux> excellent
[15:52:08] <lincolnthree1> QueryParams and other types of RequestParameters all aggregate into the HttpServletRequest.getParameterMap() Map
[15:52:08] <mojavelinux> okay persistence seems to be humming along
[15:52:15] <mojavelinux> mail?
[15:52:20] <lincolnthree1> clerum &
[15:52:24] <lincolnthree1> ^
[15:52:41] <clerum> I haven't had a chance this week
[15:52:44] <clerum> tought I would
[15:52:58] <clerum> but been in training class all week and it's running later than I thought
[15:53:21] <clerum> I'm just fussing with Generic config to allow alternate smtp configs
[15:53:26] <clerum> I may ditch that for now
[15:53:30] <clerum> and add it later
[15:53:36] <mojavelinux> got it
[15:53:38] <clerum> otherwise humming along
[15:53:52] <mojavelinux> good, I still owe you a response on getting you imported into the seam org
[15:53:52] <clerum> would hope to alpha next week
[15:54:00] <mojavelinux> but it's not make or break for progress
[15:54:15] <mojavelinux> just as long as I communicate when we are going to get it done
[15:54:19] <clerum> on github?
[15:54:24] <mojavelinux> yes
[15:54:30] <mojavelinux> github.com/seam/mail
[15:54:33] <clerum> I'll all associated with the seam org
[15:54:36] <clerum> I'm
[15:54:50] <clerum> I just need to cleanup my repo and then push it into there
[15:55:00] <clerum> just waiting for alpha for that
[15:55:06] <mojavelinux> got it
[15:55:07] <clerum> or just before alpha
[15:55:21] <clerum> when I think I'm close I'll ping you
[15:55:23] <mojavelinux> yep...and remember it will be a push as opposed to a fork
[15:55:25] <mojavelinux> great
[15:55:41] <clerum> yep I was going to ask about that...seemed like some projects the master was a fork
[15:55:45] <clerum> seemed backwards
[15:56:02] <mojavelinux> yep, I think when github encourages forks, they aren't referring to the case of organizations :)
[15:56:14] <mojavelinux> adopting a prototype
[15:56:40] <clerum> sounds good
[15:56:48] <mojavelinux> Devoxx is fast approaching, we are going to get a lot of daylight there. keep on pushing :)
[15:57:12] <lincolnthree1> I can't wait to share what we've got with folks there
[15:57:55] <aslak> on a side note.. 10 Nov will be a big Arquillian day.. 4 talks 'around the world' on the same day.. :D
[15:58:20] <lightguard_jp> Wow
[15:58:29] <lincolnthree1> yeah that's awesome
[15:59:02] <clerum> is the shrinkwrap-140 going to be released soon?
[15:59:18] <aslak> clerum, yea
[15:59:28] <clerum> great
[15:59:56] <aslak> clerum, was hoping to have it all done for Devoxx, but time is running short.. ShrinkWrap Alpha12 with 140, ShrinkWrap Descriptors and Arquillian Beta1
[16:02:31] <lightguard_jp> mojavelinux: Are we done?
[16:04:14] <lightguard_jp> If anyone has a better idea for http://pastebin.com/q4gc05uR please let me know
[16:04:30] <mojavelinux> all set!
[16:04:42] <mojavelinux> thanks everyone
[16:04:43] <lightguard_jp> It's adding the @Outbound annotation as a default for a handler method
[16:06:01] <mojavelinux> Nov 10 is a date that will live in infamy...hahahaha
[16:06:03] <mojavelinux> invasion day!
[16:06:24] <lightguard_jp> You should post that on the site :)
[16:06:38] *** balunasj is now known as balunasj_away
[16:10:41] <mojavelinux> yes, we should...also speaks to us having an event calendar
[16:10:45] <mojavelinux> which is on the todo list :)
[16:11:06] <aslak> we should be i nthe jboss.org one as well..
[16:11:22] <aslak> just send a mail to alex and he might put us in.. :)
[16:15:56] *** plenyi has quit IRC
[16:20:32] <lightguard_jp> Does anyone have an example of an example of testing a CDI extension with arquillian?
[16:20:37] <lincolnthree1> yeah
[16:20:42] <lincolnthree1> the forge event bus :)
[16:20:42] <lightguard_jp> Not sure the best way to get the extension file in the archive
[16:20:50] <lincolnthree1> use the weld EE container
[16:20:55] <lincolnthree1> picks it up automatically
[16:21:06] <lincolnthree1> Example of how to use the (currently very prototype) Event Bus API: https://github.com/lincolnthree/seam-forge/blob/master/event-bus/src/test/java/org/jboss/seam/forge/bus/cdi/ObserverCaptureExtensionTest.java
[16:22:47] *** shervin_a has quit IRC
[16:26:17] <lightguard_jp> Thanks lincolnthree1
[16:26:20] <lincolnthree1> np
[16:36:24] <lightguard_jp> java.lang.NoClassDefFoundError: javax/ejb/Stateless :(
[16:36:37] <lightguard_jp> at org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.Ejbs.findEjbs(Ejbs.java:38)
[16:36:41] <lightguard_jp> Not using the right one?
[16:36:44] <lightguard_jp> lincolnthree1: ^^
[16:36:52] <lincolnthree1> ah
[16:36:55] <aslak> lightguard_jp, add the ejb-api
[16:36:55] <lincolnthree1> you need the EJB apis
[16:37:06] <lightguard_jp> Okay
[16:37:11] <lincolnthree1> aslak: any chance to have that dependency removed?
[16:37:21] <lincolnthree1> aslak: if no API found, don't try to load EJB?
[16:38:09] <aslak> lincolnthree1, file a issue on it.. should be possible to dynamically register the weld services
[16:38:17] <lincolnthree1> k
[16:38:25] <lincolnthree1> lightguard_jp: could i have your stack trace?
[16:40:06] <lightguard_jp> http://pastebin.com/yWGBmYFJ
[16:40:15] <lincolnthree1> ty!
[16:42:50] <lincolnthree1> https://jira.jboss.org/browse/ARQ-328
[16:42:51] <jbossbot> jira [ARQ-328] EJB-API dependencies in Weld EE container should be optional (causes failures on boot) [Open, Major, Unassigned] https://jira.jboss.org/browse/ARQ-328
[16:44:12] <mojavelinux> yeah, that was getting in my way too
[16:44:21] <mojavelinux> so it will be nice to have that as optional
[16:45:46] <lightguard_jp> Gah, playing the missing jar game now
[16:45:59] <aslak> none reads docs eh..
[16:46:03] <aslak> :)
[16:46:48] <lincolnthree1> its an extra step that trips people up :) even if it is in the docs :(
[16:47:58] <mojavelinux> yeah, it's just one of those things like...okay, I have to add a JAR file that I don't need to use
[16:48:06] <mojavelinux> hmmm, so it's def an improvement
[16:48:25] *** balunasj_away has left #seam-dev
[16:49:43] <aslak> fro mbeta1 and on, you can optionally define deps in arq.xml (needed for classloading with multi containers), in the same line, creating arq profile poms you use use in maven or arq.xml should be doable..
[16:50:49] <aslak> then all you have to do is depend on org.jboss.arquillian.profile:weld-ee-embedded-1.1 and it should pull in what is needed
[16:50:56] <mojavelinux> that's a cool feature :)
[16:51:15] <mojavelinux> though, weld is designed in such a way that it shouldn't register ejb services if they aren't available, such as in servlet containers
[16:51:27] <mojavelinux> so the fact that you want to test it w/o the services there is a relevant use case
[16:51:36] <aslak> mojavelinux, it's not weld that does it.. it's the TestContainer that weld use for test
[16:51:50] <aslak> it's the registration of the MockEjbService etc
[16:52:06] <mojavelinux> right, I understand, but I'm saying if you are using weld embedded to emulate the target environment, then you don't want ejbservices in the embedded either
[16:52:17] <mojavelinux> if you are targeting a servlet container
[16:52:28] <mojavelinux> aligning the behavior, so to speak
[16:52:42] <aslak> true.. but it was probably not 'designed' with a target env in mind
[16:53:29] <aslak> i think it only expose them so if in any case you would want to inject them it will, so should be possible to do based on what's on runtime
[17:37:41] *** clerum has left #seam-dev
[17:54:35] *** aslak has quit IRC
[18:10:17] *** aslak has joined #seam-dev
[18:10:17] *** aslak has quit IRC
[18:10:17] *** aslak has joined #seam-dev
[18:11:27] *** mausbull has quit IRC
[18:22:47] *** shervin_a has joined #seam-dev
[18:29:13] *** varunss1 has joined #seam-dev
[18:31:09] *** varunss1 has left #seam-dev
[19:00:57] *** rruss has joined #seam-dev
[19:07:49] *** marekn has left #seam-dev
[19:21:06] *** jganoff has quit IRC
[20:01:09] *** kpiwko has quit IRC
[20:08:01] *** shervin_a has quit IRC
[20:28:56] *** rruss has quit IRC
[20:37:35] *** aslak has quit IRC
[21:07:23] *** jharting has quit IRC
[21:10:31] <stuartdouglas> has anyone looked at JBSEAM-4722
[21:10:32] <jbossbot> jira [JBSEAM-4722] Build seam2.5 [Open, Optional, Unassigned] https://jira.jboss.org/browse/JBSEAM-4722
[21:10:39] <stuartdouglas> I think we should do it
[21:10:49] <stuartdouglas> as it will make the migration process to seam 3 easier
[21:11:21] <stuartdouglas> as you could upgrade to seam 2.5 first to upgrade all your deps, and sort out any issues that occur
[21:11:31] <stuartdouglas> before you take the plunge and move to CDI
[21:12:08] *** aslak has joined #seam-dev
[21:12:08] *** aslak has quit IRC
[21:12:08] *** aslak has joined #seam-dev
[21:17:30] <mojavelinux> yeah, I feel we need to give them something because there's no question we've got people hanging in limbo as we carve out Seam 3
[21:21:13] <stuartdouglas> do you think we will be able to do this officially?
[21:21:33] <stuartdouglas> or will someone need to fork seam 2
[21:21:48] *** aslak has quit IRC
[21:22:03] <stuartdouglas> because this version of seam would also be a good starting point for the seam 2 bridge
[21:25:41] *** aslak has joined #seam-dev
[21:25:42] *** aslak has quit IRC
[21:25:42] *** aslak has joined #seam-dev
[21:31:34] <mojavelinux> hmmm
[21:32:01] <mojavelinux> I'm not sure who can say we can do it officially, if it was done officially it would likely be up to Marek
[22:22:26] <mojavelinux> stuartdouglas: I have a question for you
[22:22:31] <mojavelinux> if you have a minute
[22:23:23] <mojavelinux> I ran into what seems to an issue that it appears extensions go deep enough to address
[22:26:22] *** stuartwdouglas has joined #seam-dev
[22:26:32] <stuartwdouglas> mojavelinux: You had a question?
[22:26:50] <mojavelinux> yes, so I had this idea on several occations
[22:26:56] <mojavelinux> to reuse an existing annotation as a qualifier
[22:27:00] <mojavelinux> and it sounds like a great idea
[22:27:06] <mojavelinux> until you need an annotation attribute
[22:27:10] <mojavelinux> then, you are screwed
[22:27:23] <mojavelinux> because there doesn't seem to be anyway to add @NonBinding to an attribute if it isn't compiled in
[22:27:53] <stuartwdouglas> I must admit I don't really like the idea
[22:28:14] <mojavelinux> shouldn't it be possible though?
[22:28:20] <stuartwdouglas> It should be
[22:28:35] <mojavelinux> I'll give you two use cases
[22:28:35] <stuartwdouglas> but that would need a change to the SPI
[22:28:38] <mojavelinux> the first is in our own module
[22:29:03] <mojavelinux> @TransactionAttribute
[22:29:08] <mojavelinux> now, I know we ruled it out for other reasons
[22:29:19] <mojavelinux> namely that it would put our interceptor on ejbs
[22:29:23] <mojavelinux> the second use case
[22:29:34] <mojavelinux> was that I was going to reuse the JAX-RS annotations for injection points
[22:29:41] <mojavelinux> but because they all take a value
[22:29:43] <mojavelinux> I can't
[22:29:47] <stuartwdouglas> hmm, that is a good point
[22:30:00] <mojavelinux> for example
[22:30:00] <stuartwdouglas> all you can really do at this point is file a CDI issue
[22:30:09] <mojavelinux> @Inject @QueryParam("foo") String foo;
[22:30:26] <mojavelinux> got it, that's just what I was checking, that you didn't have some trick up your sleeve ;)
[22:30:30] <mojavelinux> hehehe
[22:30:42] <stuartwdouglas> no, you could probably do it in a non portable way
[22:30:44] <mojavelinux> figured if there was anyone who knew what dark magic was possible, it would be you
[22:31:01] <stuartwdouglas> or do a fakereplace style trick and instrument the reflection API
[22:31:15] <lightguard_jp> I'll remember the bring candles and virgins next time I have a question for Stuart.
[22:31:15] <stuartwdouglas> to make weld think that the annotation has @NonBinding on it :-)
[22:31:31] <mojavelinux> yeah, true that...what's funny is that while it's possible to replace an annotated type
[22:31:36] <mojavelinux> and all of it's fields and methods, etc
[22:31:50] <mojavelinux> the Annotation type itself is like a hard nut
[22:31:53] <mojavelinux> no crackin' it open
[22:32:34] <mojavelinux> I tried a couple of times to find a way to wrap it, but it seems to be a real problem in java itself
[22:32:34] <stuartwdouglas> any idea on the timeframe for the 1.1 revision?
[22:33:11] <mojavelinux> my guess, though just a guess, its that it's contingent on this whole JCP turnover right now
[22:33:28] <mojavelinux> because from what I understand, everything is frozen until that is resolved, which should be < 2 weeks
[22:34:01] <mojavelinux> so I figure by Dec we should finally be ready to get some dates for 1.1 estimated
[22:34:19] <mojavelinux> stuartdouglas:
[22:34:27] <mojavelinux> I also had one other question, sorry, I know I said it was only one
[22:34:31] <stuartwdouglas> thats ok
[22:34:53] <mojavelinux> I'm really concerned that extensions are not ordered and there doesn't appear to be a way to do it
[22:35:06] <mojavelinux> the reason I say that is because certain extensions, such as XML
[22:35:15] <mojavelinux> fundamentally change the type
[22:35:15] <stuartwdouglas> I have thought about this as well
[22:35:19] <mojavelinux> and if that doesn't happen first
[22:35:29] <mojavelinux> then other extensions just aren't going to do what we want them to do
[22:35:37] <stuartwdouglas> actually xml does not change anything, it veto's then adds
[22:35:46] <mojavelinux> this idea dawn on me when I tried an idea that I totally thought was going to work
[22:35:48] <stuartwdouglas> the other extensions should observe ProcessAnnotatedType
[22:36:05] <stuartwdouglas> and they will get the type that has been added by seam-xml
[22:36:08] <mojavelinux> I wanted to find types that have @Path
[22:36:14] <mojavelinux> and add @RequestScoped
[22:36:17] <mojavelinux> if a scope is not there
[22:36:29] <mojavelinux> and it works, except that the JAX-RS extensions are coming first
[22:36:30] <lincolnthree1> that would also be nice for @FacesValidator
[22:36:34] <mojavelinux> :(
[22:36:45] <stuartwdouglas> This one we can address in weldx I think
[22:37:07] <stuartwdouglas> we could build an ordered extension mechanism in there
[22:37:19] <stuartwdouglas> however it would only work if everyone used the weldx version
[22:37:26] <stuartwdouglas> rather than the native CDI version
[22:37:54] <stuartwdouglas> we could also do tricks to speed up scanning
[22:38:14] <stuartwdouglas> so your extension could say to weldx 'I am only interested in types that have @Path'
[22:38:18] <mojavelinux> I think for Seam 3 it would be fine since all modules are def going to use weldx
[22:38:35] <stuartwdouglas> and weldx scans the AnnotatedType and only passes it to the extensions that need it
[22:38:47] <stuartwdouglas> rather than every extension scanning every single class
[22:38:51] <mojavelinux> exactly
[22:39:00] <mojavelinux> I tweeted something to that effect
[22:39:01] <mojavelinux> of having
[22:39:09] <mojavelinux> ProcessAnnotatedType<@Path>
[22:39:15] <mojavelinux> obviously a fake expression
[22:39:18] <mojavelinux> but often that's what I want to do
[22:39:23] <stuartwdouglas> which is massivly slow at the moment as every call to getAnnotatedMethods etc
[22:39:37] <stuartwdouglas> defensivly copies a new HashSet
[22:39:45] <stuartwdouglas> which is slow to iterate over anyway
[22:39:50] <mojavelinux> yep, I've also wanted to know
[22:40:06] <mojavelinux> if I could just be notified if any method on a class has an annotation
[22:40:11] <mojavelinux> so the check on type is quick
[22:40:15] <mojavelinux> this might be what you are talking about
[22:40:23] <mojavelinux> but rolling through the methods seems painful
[22:40:23] <stuartwdouglas> that is exactly what I am talking about
[22:40:26] <mojavelinux> we have to do this in catch
[22:40:27] <mojavelinux> ah
[22:40:41] <mojavelinux> yeah, I suspected quickly that this was going to be a potential bottleneck...so good
[22:40:48] <mojavelinux> glad you are thinking about that, amen!
[22:40:50] <stuartwdouglas> although the scanning process could be sped up massivly with some minor tweaks in weld
[22:41:14] <mojavelinux> probably running the Seam modules w/ the profiler is very interesting for weld
[22:41:17] <stuartwdouglas> basically using an ImmutableArraySet for the methods/fields
[22:41:25] <stuartwdouglas> so no defnesive copying and fast iteration
[22:41:40] <mojavelinux> right, exactly, immutability is the best thing to move to if you are doing a lot of copying
[22:42:41] <stuartwdouglas> It's something that I have wanted to do for a while, however I have been waiting on David Allens memory stuff
[22:42:58] <stuartwdouglas> as it is sort of releated
[22:43:43] <mojavelinux> is there a JIRA for the process annotated type w/ a specific annotation?
[22:45:16] <stuartwdouglas> no
[22:45:34] <stuartwdouglas> it should probably be a spec issue
[22:45:46] <stuartwdouglas> but we may be able to address it in weldx first
[22:45:52] <stuartwdouglas> provided Pete agrees
[22:46:08] <stuartwdouglas> mojavelinux: also I have a question for you
[22:46:17] <mojavelinux> what's up
[22:46:29] <stuartwdouglas> in seam 2 we proxied @PersistenceContext injection into seam components
[22:46:41] <stuartwdouglas> to enable el in queries
[22:47:02] <stuartwdouglas> afaik this is the only seam 2 persistence feature that I have not implemented yet
[22:47:20] <stuartwdouglas> and I am not really sure if it is worth doing
[22:47:24] <stuartwdouglas> wdyt?
[22:47:49] <stuartwdouglas> It will involve another extension that scans every field
[22:48:01] <stuartwdouglas> looking for @PersistenceContext
[22:48:09] <mojavelinux> understood
[22:49:00] <stuartwdouglas> If I have time I am going to cut another seam-persistence alpha this weekend
[22:49:05] <stuartwdouglas> really it should probably be a beta
[22:49:21] <stuartwdouglas> but I think I will wait for weldx to change to seam solder
[22:49:43] <mojavelinux> I'd say we can leave it out...I don't know that there is a ton of benefit of using that over setParameter()
[22:50:00] <stuartwdouglas> That is what I wanted you to say :-)
[22:50:02] <lightguard_jp> Don't want to break the flow of the conversation too much.  The only thing I'm missing (I think) is matching up the invocation of the handler with the @Outbound or @Inbound.
[22:50:04] <mojavelinux> and one could argue it goes against our more type-safe advocacy
[22:50:26] <mojavelinux> awesome news on the seam-persistence, super happy to see that rolling along
[22:51:03] <mojavelinux> because that is really the biggest missing piece in non-ejb environments (or if you aren't using ejb)
[22:51:04] <mojavelinux> big hole
[22:51:27] <stuartwdouglas> I decided to leave REQUIRES_NEW support out for now
[22:51:28] <mojavelinux> I'd say you could go beta
[22:51:35] <stuartwdouglas> and put it in 3.1
[22:51:54] <mojavelinux> I'd try to get to looking it over tomorrow, I think I had one or two minor comments
[22:51:59] <mojavelinux> might even be obsolete by now
[22:52:03] <mojavelinux> the comments
[22:52:38] <stuartwdouglas> I still need to document seam managed hibernate session as well
[22:52:39] <mojavelinux> yeah, we can leave it out, though that will be important to have in 3.1 at least
[22:52:43] <stuartwdouglas> and a bit of other stuff
[22:52:51] <stuartwdouglas> should be able to do that this weekend though
[22:53:15] <mojavelinux> fantastic...I'm really excited to be able to showcase the persistence at devoxx, no doubt it will be a critical piece of our presentation
[22:53:25] <mojavelinux> speaking of which, still gotta get that together :(
[22:53:28] <mojavelinux> freakin' slides
[22:56:33] <mojavelinux> this is good
[22:56:34] <mojavelinux>  String fruitName = expressions.evaluateValueExpression("#{fruitBowl.fruitName}");
[22:56:34] <mojavelinux>       Apple fruit = expressions.evaluateMethodExpression("#{fruitBown.getFruit}");
[22:56:35] <mojavelinux> howeer
[22:56:42] <mojavelinux> however, I noticed in the rest module
[22:56:46] <mojavelinux> Jozef has an interpolator
[22:57:34] <stuartwdouglas> I must admit I have not looked at the rest module yet
[22:57:48] <mojavelinux> https://github.com/seam/rest/blob/master/impl/src/main/java/org/jboss/seam/rest/util/ExpressionLanguageInterpolator.java
[22:57:53] <mojavelinux> seems like that should be in weldx too
[22:58:03] <mojavelinux> in fact, I think there is a much better impl in seam i18n that lincoln worked on
[22:58:53] <mojavelinux> ah, in fact
[22:59:02] <mojavelinux> jozef's version even injects Expressions from weld x
[22:59:07] <mojavelinux> but then disabled because I guess it wasn't working
[22:59:25] <mojavelinux> i'll make sure this is an issue...I think whereever we have Expressions, we should have Interpolator
[22:59:32] <mojavelinux> I had originally proposed having a Seam EL module
[22:59:38] <stuartwdouglas> can you file a JIRA?
[22:59:41] <mojavelinux> but I guess we are just mashing this up into weldx
[22:59:43] <mojavelinux> yep
[22:59:46] <mojavelinux> doing it now
[23:03:24] *** arbi has joined #seam-dev
[23:04:36] <arbi> if you invoke a method on a JavaBean (POJO) (that is not tx-aware like with Spring AOP or Seam's @Transactional) from a running tx in a SLSB, is it true that the tx will not propagate to the JavaBean method?  I'm guessing it waits or terminates...
[23:04:59] <arbi> i could not find anything on this in JSR220
[23:05:47] <stuartwdouglas> it will propagate
[23:05:55] <arbi> in EE 5 or 6?
[23:06:05] <stuartwdouglas> there are no interceptors in the way to stop it propegating
[23:06:14] <arbi> hmm ok
[23:06:40] <arbi> ok thx for the fdbk
[23:08:10] <stuartwdouglas> just tried to migrate a bzr repo to git at work
[23:08:25] <stuartwdouglas> and it looks like some deleted files have magically re-appeared in the repo :-(
[23:12:38] <lightguard_jp> Any clues for my question above?
[23:14:30] <mojavelinux> WELDX-185
[23:14:31] <jbossbot> jira [WELDX-185] Implement an interpolator for strings containing expressions [Open, Major, Unassigned] https://jira.jboss.org/browse/WELDX-185
[23:14:33] <mojavelinux> oh, sorry
[23:15:06] <mojavelinux> right, when you invoke the POJO, it's no different than instantiating an object and invoking a method
[23:15:10] <mojavelinux> w/ regard to how the tx works
[23:15:29] <mojavelinux> you only have propagation rules when you are dealing w/ components that themselves have a transaction shield around them
[23:15:31] <mojavelinux> like ejbs ;)
[23:18:10] <stuartwdouglas> lightguard_jp: Was that the question you were referring to or the one above about @Inbound @Outbound ?
[23:19:41] <lightguard_jp> @Inbound and @outbound
[23:20:16] <lightguard_jp> Those are qualifiers, but we're invoking the methods ourselves (not observers).  I need to match them up.
[23:20:30] <lightguard_jp> I could just check for the annotation
[23:20:38] <lightguard_jp> That may be the easiest way
[23:21:05] <stuartwdouglas> There is some stuff in weldx that may help you
[23:21:52] <lightguard_jp> Specific places to look?
[23:22:02] <lightguard_jp> The reflection stuff?
[23:22:58] <stuartwdouglas> I am thinking of org.jboss.weld.extensions.reflection.annotated.InjectableMethod<X>
[23:23:15] <stuartwdouglas> it makes it easy to call methods where some of the parameters are injected
[23:23:33] <lightguard_jp> Right, I saw that, and I'm planing on using it.
[23:23:54] <lightguard_jp> I guess the parameter redefiner will be needed for the qualifiers as well?
[23:24:30] <stuartwdouglas> I think so, I have not really used it though
[23:28:21] <lightguard_jp> Okay
[23:28:27] <mojavelinux> heading out
[23:29:02] <lightguard_jp> Okay
[23:29:07] <lightguard_jp> mojavelinux: Enjoy dinner
[23:29:48] <arbi> i don't think it will propagate actually, it will behave like @NOT_SUPPORTED (suspend tx, keep it active, and resume tx when JavaBean method completes)
[23:30:10] <arbi> so the JavaBean method like effectively run outside of a tx
[23:30:54] <stuartwdouglas> arbi: and what black magic stops the transaction?
[23:31:10] <arbi> i don't know but here's another opinion: http://community.jboss.org/thread/158508
[23:31:20] <arbi> need to run to team mtg, bye
[23:41:57] *** tsurdilo has quit IRC
[23:42:20] *** tsurdilo has joined #seam-dev





top