[00:02:14] <jbossbot> git [security] push master e367f9a.. Shane Bryzak remove external module from build
[00:02:15] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/3978ff0...e367f9a
[00:02:52] <lightguard_jp> stuartdouglas: ping
[00:03:08] *** tsurdilo has joined #seam-dev
[00:03:21] <lincolnthree> pong PONG pong Pong POnG ponG pong
[00:03:42] <lightguard_jp> You're not Stuart
[00:03:50] <lincolnthree> doh
[00:04:00] <lincolnthree> can't fool you
[00:04:33] <lightguard_jp> stuartdouglas: When you get a moment, any reason why http://pastebin.com/VA4VG272 won't work?
[00:07:39] *** lincolnthree has left #seam-dev
[00:09:31] *** maxandersen has quit IRC
[00:12:02] <jbossbot> git [security] push master 93363e4.. Shane Bryzak updated seam-persistence version
[00:12:02] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/e367f9a...93363e4
[00:17:08] *** balunasj has joined #seam-dev
[00:17:40] <sbryzak> stuartdouglas: ping
[00:18:39] <jbossbot> git [security] push master 5346a69.. Shane Bryzak update seam-persistence version for idmconsole example
[00:18:39] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/93363e4...5346a69
[00:19:46] *** balunasj has quit IRC
[00:21:49] <jbossbot> git [security] push master e64d12f.. Shane Bryzak updated seam-xml version for idmconsole example
[00:21:49] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/5346a69...e64d12f
[00:42:11] <sbryzak> any maven gurus that can explain why maven hates me so much?
[00:45:16] *** lightguard_jp has quit IRC
[01:14:25] <jbossbot> git [catch] push master 07dbe5d.. Dan Allen streamline example...
[01:14:25] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/ea0bcc6...07dbe5d
[01:15:13] <jbossbot> git [catch] push master 1447cfe.. Dan Allen skip test phase for api
[01:15:13] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/07dbe5d...1447cfe
[01:55:07] *** clerum has quit IRC
[01:57:16] *** tsurdilo has quit IRC
[02:20:55] <jbossbot> git [security] push master 5c7625a.. Shane Bryzak update artifact id
[02:20:55] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/e64d12f...5c7625a
[03:24:02] <jbossbot> git [security] push master e0b2d5d.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.Alpha1
[03:24:02] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/5c7625a...e0b2d5d
[03:24:18] <jbossbot> git [security] push master 3a1a117.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[03:24:19] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/e0b2d5d...3a1a117
[04:07:50] *** Administrator has joined #seam-dev
[04:08:12] *** Administrator is now known as Guest45362
[04:08:39] *** Guest45362 is now known as stan8688
[04:30:05] *** stan8688 has quit IRC
[06:54:02] <stuartdouglas> sbryzak: you pinged?
[07:46:22] <sbryzak> stuartdouglas: yes, but i can't remember what for
[08:05:09] *** Nik is now known as nickarls
[08:07:46] *** mbg has quit IRC
[08:22:32] *** oskutka has joined #seam-dev
[08:45:27] *** kpiwko has joined #seam-dev
[08:48:16] *** marekn has joined #seam-dev
[09:04:00] *** maxandersen has joined #seam-dev
[09:06:10] *** maxandersen has left #seam-dev
[09:14:07] *** amitev has joined #seam-dev
[09:20:52] *** jharting has joined #seam-dev
[09:24:49] *** kpiwko has quit IRC
[09:27:30] *** kpiwko has joined #seam-dev
[09:53:29] *** adamw1pl has joined #seam-dev
[10:11:23] *** emmanuel has joined #seam-dev
[10:34:02] <stuartdouglas> is there a meeting tonight?
[10:46:07] <nickarls> is it just me or are the seam-sec archives on SF b0rken?
[10:49:51] <nickarls> didn't find anything in the docs but is there some best practices for view-level (f:metaData preRenderView-listener redirect?) approach for protecting complete views?
[11:59:01] *** pmuir has joined #seam-dev
[11:59:01] *** pmuir has quit IRC
[11:59:01] *** pmuir has joined #seam-dev
[12:02:31] <stuartdouglas> pmuir: Is there a seam meeting tonight?
[12:02:54] <stuartdouglas> and if so, is there anything worth staying up to 1am for?
[12:06:15] <pmuir> stuartdouglas: no meeting tonight
[12:17:49] *** emmanuel has quit IRC
[13:48:27] *** shervin_a has joined #seam-dev
[14:05:07] *** rruss has joined #seam-dev
[14:12:54] *** balunasj has joined #seam-dev
[14:12:54] *** balunasj has joined #seam-dev
[14:25:11] <jbossbot> git [build] push master 6200902.. Pete Muir Add solder
[14:25:11] <jbossbot> git [build] push master URL: http://github.com/seam/build/compare/f370d33...6200902
[14:33:09] *** balunasj has quit IRC
[14:35:49] *** balunasj has joined #seam-dev
[14:36:17] *** balunasj has quit IRC
[14:57:53] *** emmanuel has joined #seam-dev
[15:00:23] *** shervin_a has quit IRC
[15:16:52] *** adamw1pl has left #seam-dev
[15:24:13] *** rruss has quit IRC
[15:59:49] *** balunasj has joined #seam-dev
[16:00:03] *** balunasj is now known as balunasj_mtg
[16:04:55] *** mojavelinux has joined #seam-dev
[16:05:17] <mojavelinux> good morning all
[16:07:11] *** lincolnthree has joined #seam-dev
[16:09:47] *** mbg has joined #seam-dev
[16:09:56] *** mbg has left #seam-dev
[16:10:38] <mojavelinux> just want to touch base real quick, since things seem to be really moving along nicely
[16:11:10] <mojavelinux> shane, good job on the release of Seam Security! that's a big step forward for Seam 3
[16:11:21] <lincolnthree> *applause!!!!!*
[16:11:51] <mojavelinux> also, stuart nice job getting persistence into beta, another cornerstone of Seam 3
[16:12:23] <mojavelinux> I pushed out Seam Servlet yesterday and have an announcement in draft that I'll push out shortly
[16:13:03] <mojavelinux> I saw on twitter someone said "wow, there is a lot going on with Seam 3". the individual module releases give us this advantage that the news feed is continous
[16:13:14] <lincolnthree> :)
[16:14:15] *** tsurdilo has joined #seam-dev
[16:14:24] <mojavelinux> in terms of announcements, the switch over the Seam Solder is now official, so we need to iron out when we can do a release so the Seam modules can switch over
[16:14:53] <mojavelinux> today I need to catch up the solder repo with the latest commits in weld extensions, in case you notice that it's a bit behind
[16:15:34] <lincolnthree> have we frozen that repo yet?
[16:16:30] <mojavelinux> not yet...as soon as we are caught up, that's probably a good move to make. I'll follow up then...AI
[16:16:57] <mojavelinux> Jason has been hard at work on catch and the next step is to put the catch integration into servlet, jax-rs and faces
[16:17:16] <mojavelinux> we are going to start with servlet and do an alpha tomorrow
[16:17:43] <lincolnthree> let me know when you get to faces and I'll give you some cycles
[16:17:46] <mojavelinux> but the idea is that modules should not have to introduce any exception handling infrastructure...simply forward uncaught exceptions to catch
[16:17:51] <mojavelinux> it's pretty cool stuff
[16:18:24] <lincolnthree> they'll need to do it in a way that's not hard-linked though
[16:18:44] <lincolnthree> if people don't want to use catch, for example
[16:19:36] <lincolnthree> not that I have any reason why they wouldn't
[16:20:01] <mojavelinux> we are thinking that there will be a dependency on catch, but if you don't write any handlers, then nothing happens
[16:20:09] *** mbg has joined #seam-dev
[16:20:35] <lincolnthree> well, I don't think you even need a compile-or @Inject dependency really
[16:20:35] <mojavelinux> so you don't get forced to use it, but we can consider how to make it an optional dependency...ah
[16:20:37] <mojavelinux> I know
[16:20:42] <mojavelinux> we just use @Requires from Solder
[16:20:45] <lincolnthree> like what stuart has done with persistence in faces
[16:20:50] <mojavelinux> yep
[16:22:08] *** clerum has joined #seam-dev
[16:23:59] <mojavelinux> while adding the servlet release information to sfwk.org pages, I realized that there were several pages out of date with the latest releases
[16:24:28] <mojavelinux> I concluded that there are way too many pages to update; I'm going to think about how we can cut down on the # of updates necessary
[16:24:48] <mojavelinux> when we do get to a reasonable #, we need to make sure they are kept up to date, which means checking when you release your module
[16:25:02] <mojavelinux> it's better to have no information then wrong information
[16:25:48] <mojavelinux> but again, part of that is my fault for having the info spread out across too many pages...I'll work with lincoln to get some order there :)
[16:26:14] <lincolnthree> it would be nice if we had a templating system in sfwk ;)
[16:28:16] <mojavelinux> sigh
[16:28:28] <mojavelinux> actually
[16:28:37] <lincolnthree> seam-render anyone? ;) eh eh?
[16:28:52] <mojavelinux> we sort of do have something that would make this simpler, the problem is we have to hack it up
[16:29:01] <mojavelinux> sfwk.org supports wiki macros
[16:29:05] <lincolnthree> ahhh
[16:29:31] <mojavelinux> so there could be a macro for a dependency at least...instead of typing these long repo urls
[16:31:31] *** pmuir has quit IRC
[16:31:44] <mojavelinux> I have one other item to discuss, -impl vs no -impl suffix
[16:31:51] <lincolnthree> go for it
[16:32:12] <mojavelinux> originally we were dropping the -impl suffix on the impl jar...to make it simpler for developers to add to their pom
[16:32:36] <mojavelinux> however, that really isn't quite the right thing to do and breaks down when we have multiple impls
[16:32:51] <mojavelinux> so, instead, I think we should add a shaded jar that is api+impl, and drop the suffix on that jar
[16:33:11] <mojavelinux> we just need someone to hack together the plugin fragment :)
[16:33:46] <lincolnthree> what are the reasons for needing a new plugin?
[16:33:53] <mojavelinux> we can reference weld-servlet as a model...perhaps lincoln, jason or stuart since you guys have been releasing frequently
[16:34:07] <mojavelinux> we don't need a plugin, we just need to use the plugin...so we need to snippet to steal
[16:34:17] <lincolnthree> oh, i've got one
[16:34:40] <lincolnthree> however, it requires another module be added to the project
[16:34:44] <mojavelinux> if you want to try it on faces, go for it...then we can copy...and if you see anything that can be moved into a parent pom, even better
[16:34:59] <mojavelinux> can you put it in dist?
[16:35:12] <lincolnthree> not sure, that's possible
[16:35:27] <lincolnthree> im not sure I'll have time to look at it for a while
[16:35:28] *** marekn has quit IRC
[16:35:33] <lincolnthree> but I can try to squeeze it in
[16:35:50] <lincolnthree> I'll put it on the list :)
[16:36:09] *** pmuir has joined #seam-dev
[16:36:15] <mojavelinux> hehehe
[16:36:28] <mojavelinux> I much prefer taking things off the list myself these days :)
[16:37:37] <mojavelinux> in other news, we've got the design team working on a new logo color that's going to be used for the Seam 3 icon...you may have noticed the orange logos show up
[16:37:47] <mojavelinux> those were taking from the Seam state of the union talk slides
[16:38:01] <mojavelinux> and is a design proposal for James to draw from
[16:38:08] <mojavelinux> here are the possibilities
[16:38:26] <mojavelinux> https://jira.jboss.org/browse/DESIGN-152
[16:38:27] <jbossbot> jira [DESIGN-152] Seam 3 Module Logos [Coding In Progress, Major, James Cobb] https://jira.jboss.org/browse/DESIGN-152
[16:39:00] <mojavelinux> personally, I like the last one...the idea is to have something that is brighter, that makes a bold statement that Seam 3 is here
[16:39:43] <lincolnthree> Yeah, I prefer the last one as well
[16:39:45] <lincolnthree> we don't want dull colors
[16:39:46] <mojavelinux> oh, I didn't realize james uploaded a second set
[16:39:55] <mojavelinux> hmm, now I think the second word is too bold
[16:39:59] <mojavelinux> we need something half way in between
[16:40:15] <lincolnthree> I like the first set better
[16:40:33] <mojavelinux> well, it wouldn't be a set, we have to pick one
[16:40:48] <lincolnthree> Right, but in general
[16:40:56] <lincolnthree> i like the first set better in entirety than his second set
[16:41:13] <lincolnthree> nothing in the second set is better than anything in the first set imo ;)
[16:41:20] <mojavelinux> go ahead and comment if you like...I think we do want the second word thinner, as that is the style we are going for
[16:41:33] <lincolnthree> I do have a few items to mention before we finish
[16:41:44] <mojavelinux> okay, go on
[16:41:59] <lincolnthree> Ok, first: SeamForge doesn't currently build on windows
[16:42:09] <lincolnthree> I'm in the process of sorting that out
[16:42:17] <lincolnthree> so as soon as it does, I will be broadcasting the heck out of it
[16:42:20] <lincolnthree> trying to get people to try it out
[16:42:32] <mojavelinux> good
[16:42:45] <lincolnthree> after that, we really need time spend on plugins, so we can get feedback on the APIs developers will be using
[16:42:57] <lincolnthree> and so we can get started on the actual functionality that will be aiding end users
[16:43:10] <mojavelinux> for those that didn't hear, seam forge made a big splash at devoxx and motivation to really push it forward...roo also drew a croud, so even more motivation
[16:43:22] <lincolnthree> so if anyone is interested in writing a plugin for their module, the time is soon
[16:43:37] <mojavelinux> excellent...I think about it almost daily
[16:43:44] <mojavelinux> every time I have to type something :)
[16:44:04] <lincolnthree> Second - for those of you who don't know
[16:44:46] <lincolnthree> During Devoxx, I started working on a lightweight composite templating module (as an alternative to velocity or another tool)
[16:44:57] <lincolnthree> mojavelinux: and I had some fun hacking on it on the flight home
[16:45:09] <lincolnthree> http://github.com/lincolnthree/seam-render
[16:45:14] <lincolnthree> if anyone would like to check it out
[16:45:16] <mojavelinux> lincoln coded, I commented :)
[16:45:22] <lincolnthree> it's extremely fast
[16:45:38] <lincolnthree> a 4000 line template compiles in 3-5 seconds, and renders in (drum roll)
[16:45:44] <lincolnthree> 0.000 seconds
[16:45:48] <mojavelinux> I was thinking while working on Seam Servlet how nice that would be to use if you were coding up a basic servlet
[16:45:54] <mojavelinux> anything but JSP :)
[16:46:16] <mojavelinux> and important point to make about it is that it's very much in the style of Facelets, drawing on the popularity of Facelets
[16:46:26] <lincolnthree> but without the coupling to JSF
[16:46:27] <mojavelinux> except unlike Facelets, it isn't hard coded like hell into JSF :)
[16:46:31] <lincolnthree> :0D
[16:46:33] <lincolnthree> :-D
[16:46:39] <lincolnthree> So, in combination with seam-render
[16:46:48] <lincolnthree> I am also working on seam-mvc (really need a better name for it)
[16:46:57] <mojavelinux> I also like the idea of seam render for mail templating
[16:47:11] <mojavelinux> because currently clerum has been using velocity
[16:47:19] <lincolnthree> yes, I'll be working on that as soon as I can get a few minutes to take a look at what clerum has got going in mail
[16:47:21] <mojavelinux> max points out that the problem w/ velocity is that the error reporting sucks
[16:47:37] <mojavelinux> I still owe clerum an import of mail into the seam git repo
[16:47:38] <lincolnthree> http://github.com/lincolnthree/seam-mvc
[16:47:39] <mojavelinux> :)
[16:47:58] <lincolnthree> seam MVC is super-prototype stage right now, render is actually usable
[16:48:04] <mojavelinux> so check this out...w/ seam servlet
[16:48:09] <mojavelinux> you can make a servlet like this...
[16:49:25] <mojavelinux> public class SimplerServlet {
[16:49:25] <mojavelinux>    public void handleRequest(@Observes @Initialized HttpServletRequestContext ctx) {
[16:49:25] <mojavelinux>       ctx.getResponse.getWriter().write("<html><body>hello</body></html>");
[16:49:25] <mojavelinux>       ctx.getResponse.flushBuffer();
[16:49:25] <mojavelinux>    }
[16:49:26] <mojavelinux> }
[16:49:30] <mojavelinux> :)
[16:49:44] <mojavelinux> add a template dispatch to that, and voila
[16:49:49] <mojavelinux> so we need some sort of renderer API
[16:50:04] <lincolnthree> @Inject TemplateCompiler compiler;
[16:50:12] <mojavelinux> oops, I forgot a path :)
[16:50:12] <lincolnthree> compiler.render(InputStream template);
[16:50:27] <mojavelinux> @Observes @Path("hello") @Initialized HttpServletRequestContext ctx
[16:50:33] <lincolnthree> CompiledView = compiler.render(InputStream template);
[16:50:44] <mojavelinux> I didn't do anything really to enable that, other than fill out the event bridge :)
[16:51:26] <lincolnthree> So my thinking behind seam MVC is this
[16:51:30] <mojavelinux> also provides a very lightweight filter mechanism
[16:51:35] <lincolnthree> JSF does a lot of stuff right
[16:51:35] <mojavelinux> you just commit the response in the observer
[16:51:44] <lincolnthree> JSF also does a lot of stuff wrong
[16:51:56] <lincolnthree> And JSF also does way more than it should
[16:52:39] <lincolnthree> in this ecosystem we have CDI (don't need JSF beans), JSR303 (don't need JSFs validations), seam-render (don't need facelets)
[16:53:03] <lincolnthree> add in something like PrettyFaces, plus seam-persistence, and other seam modules
[16:53:07] <mojavelinux> and I'd really like to add to that list seam-convert (or some standard)
[16:53:09] <lincolnthree> you have a pick-and-choose web-framework
[16:53:13] <lincolnthree> yeah agreed
[16:53:25] <mojavelinux> we need to centralize our conversions in Seam anyway
[16:54:46] <mojavelinux> cool stuff indeed!
[16:54:57] *** kpiwko has quit IRC
[16:55:35] <mojavelinux> okay, last chance for any comments or topics, then we'll wrap up
[16:55:46] <lincolnthree> raise your hand if you are here ;)
[16:57:12] <mojavelinux> hehehe, well, to those of you reading the archive, hello and goodbye :)
[16:57:33] <lincolnthree> peace out
[16:59:51] *** pmuir has quit IRC
[17:04:55] *** jharting has quit IRC
[17:08:46] *** tsurdilo1 has joined #seam-dev
[17:12:05] *** tsurdilo has quit IRC
[18:05:01] *** lightguard_jp has joined #seam-dev
[18:11:52] *** kpiwko has joined #seam-dev
[18:14:34] *** oskutka has quit IRC
[18:27:44] <lightguard_jp> Who can comment on http://java.net/jira/browse/GLASSFISH-14808 for me?
[18:28:23] <lightguard_jp> It looks like Siva is correct that there is no beans.xml in weldx, so how is this working in JBoss AS?
[18:34:39] <mojavelinux> classic misunderstanding of CDI, which I myself had until I studied weldx
[18:34:50] <mojavelinux> beans.xml is primarily for application developers
[18:35:04] <mojavelinux> the preferred way of registering beans in a core extension, especially one as low level as weldx
[18:35:12] <mojavelinux> is to use addAnnotatedType
[18:35:16] <mojavelinux> in an extension
[18:35:30] <mojavelinux> see for instance
[18:35:41] <mojavelinux> oh, and you don't need beans.xml to load extensions
[18:35:47] <lightguard_jp> Okay, then this is a problem with the GF integration
[18:35:48] <mojavelinux> as those are loaded by interface (no scanning required)
[18:36:21] <lightguard_jp> Would one of you mind commenting on that issue (you probably have more sway being a Weld dev than I do)?
[18:36:35] <mojavelinux> see https://github.com/seam/solder/raw/master/impl/src/main/java/org/jboss/seam/solder/el/ELExtension.java
[18:42:19] <lightguard_jp> Where is this in the spec?
[18:42:32] <lightguard_jp> I'm looking, can't find it
[18:44:54] <lightguard_jp> I guess the actual test would be to see if those lifecycle methods are being invoked in weldx
[18:46:35] <lightguard_jp> mojavelinux: When will solder have a release?
[18:48:42] <mojavelinux> just a second, publishing an blog entry...requires way too much concentration
[18:48:45] <mojavelinux> stupid jboss.org editor :(
[18:50:35] <lightguard_jp> Write in markdown, convert to HTML using pandoc paste HTML
[18:50:54] <lightguard_jp> Sorry, insert "clean up HTML" after pandoc.
[18:52:27] *** emmanuel has quit IRC
[19:03:54] <mojavelinux> http://community.jboss.org/people/dan.j.allen/blog/2010/12/02/seam-servlet-alpha-1-brings-servlet-lifecycle-events-to-cdi
[19:04:08] <mojavelinux> so that's what I do, write in markdown (well, I just type text)
[19:04:19] <mojavelinux> it takes me an hour to convert that into HTML in the blog entry
[19:04:30] <mojavelinux> because you have to know about all the weird rendering glitches
[19:04:32] <lightguard_jp> There's already been 11 views, lol
[19:04:38] <mojavelinux> such as the fact that all paragraphs get mashed together
[19:04:44] <lightguard_jp> eck
[19:04:51] <mojavelinux> stupid, stupid stupid styles
[19:04:54] <mojavelinux> ignorant styles
[19:04:57] <lightguard_jp> I didn't seem to have much problem when I pasted mine in.
[19:05:12] <mojavelinux> that's because I'm OCD about it
[19:05:23] <lightguard_jp> Probably
[19:05:25] <mojavelinux> I absolutely refuse to have empty paragraph tags for spacers between paragraphs
[19:05:28] <mojavelinux> so I add styles to fix it
[19:05:29] <lightguard_jp> I blame Manning for that
[19:05:50] <mojavelinux> and it mangles the crap out of XML
[19:06:01] <mojavelinux> so you have to go fix all that
[19:06:06] <mojavelinux> so annoying
[19:06:20] <mojavelinux> then, when you find a typo or need a paragraph break...that's like a 3 minute process
[19:06:36] <mojavelinux> crazy...anyway, it's done
[19:07:19] <lightguard_jp> I added in handling exceptions async via JMS in the response
[19:07:25] <lightguard_jp> Thought that would be a very cool thing to mention
[19:07:33] <lightguard_jp> jaxevent response*
[19:07:56] <mojavelinux> awesome
[19:10:23] <lightguard_jp> Sent
[19:10:47] <mojavelinux> faces needs a distribution
[19:10:49] <mojavelinux> looks out of place
[19:11:18] <mojavelinux> it's really not that hard now that we have other examples to cheat off of
[19:11:49] <lincolnthree> mojavelinux: yep, that's one thing i never got around to
[19:12:36] <lightguard_jp> Is there a weldx beta2 available or are we waiting for solder for that?
[19:12:40] <mojavelinux> I can help you when we get the next faces release out...thanks to those that have come before us, it doesn't take much effort (well, unless Maven is being a pain)
[19:12:47] <mojavelinux> solder
[19:13:49] <mojavelinux> as to when there will be a Solder release...I need to catch up on the commits today, make sure tests are working and ping pete
[19:14:00] <mojavelinux> then, we will get a roadmap...but hopefully < 1 week
[19:14:14] <mojavelinux> still need me to comment on that GF issue?
[19:14:59] <lightguard_jp> I'm going to try the newest (b31) promoted build and see what happens
[19:15:06] <lightguard_jp> Chances are it's still broken though
[19:16:05] <mojavelinux> spec section 11.5
[19:16:26] <mojavelinux> An extension is a service provider of the service
[19:16:27] <mojavelinux> javax.enterprise.inject.spi.Extension declared in META-INF/services.
[19:16:27] <mojavelinux>   public interface Extension {}
[19:16:45] <mojavelinux> doesn't specifically say it doesn't have to be in a bean archive, but doesn't say it is required (assume the behavior of ServiceLoader which is global)
[19:16:50] <lightguard_jp> But it doesn't say anything about it needing or not needing a beans.xml
[19:17:08] <mojavelinux> adds a given AnnotatedType to the set of types which will be scanned during bean discovery.
[19:17:08] <mojavelinux> addAnnotatedType()
[19:17:39] <mojavelinux> right, but in that area it says it is a standard service loader pattern
[19:17:42] <mojavelinux> so see ServiceLoader
[19:18:49] <mojavelinux> Service providers can be installed in an implementation of the Java platform in the form of extensions, that is, jar files placed into any of the usual extension directories.
[19:19:00] <mojavelinux> A service provider is identified by placing a provider-configuration file in the resource directory META-INF/services. The file's name is the fully-qualified binary name of the service's type.
[19:19:50] <mojavelinux> hahaha, I love this comment in the ServiceLoader javadoc
[19:19:54] <mojavelinux> " If the class path of a class loader that is used for provider loading includes remote network URLs then those URLs will be dereferenced in the process of searching for provider-configuration files.
[19:19:54] <mojavelinux> This activity is normal, although it may cause puzzling entries to be created in web-server logs. If a web server is not configured correctly, however, then this activity may cause the provider-loading algorithm to fail spuriously."
[19:19:55] <mojavelinux> hahaha
[19:20:14] <mojavelinux> yes, perfect
[19:20:20] <mojavelinux> fail spuriously
[19:20:47] *** cpopetz_ has quit IRC
[19:24:31] <lightguard_jp> Nope, still broken WELD-001408 Unsatisfied dependencies for type [ResourceLoaderManager] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.weld.extensions.resourceLoader.ResourceProducer.resourceLoaderManager]
[19:24:36] <lightguard_jp> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [ResourceLoaderManager] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.weld.extensions.resourceLoader.ResourceProducer.resourceLoaderManager]
[19:25:21] <lincolnthree> are you running this in an arquillian test or on the server ?
[19:25:31] <lightguard_jp> Nope, on the server
[19:25:37] <lightguard_jp> It's my jaxrs example
[19:27:44] <lightguard_jp> But the lifecycle methods are being called
[19:32:45] <mojavelinux> RC1?
[19:32:53] <mojavelinux> don't know how we could be getting different results
[19:32:57] <mojavelinux> how are you deploying?
[19:33:32] <lightguard_jp> RC1 of what?
[19:33:47] <lightguard_jp> This is Glassfish 3.1, latest promoted build
[19:33:57] <lightguard_jp> I'm using asadmin deploy <war file>
[19:36:33] <lightguard_jp> Gah, they're using the old verion of JIRA on java.net, JBoss uses the new one *sigh*
[19:36:44] <lightguard_jp> Oh well, at least it's not their old bug tracker
[19:38:30] *** balunasj_mtg has quit IRC
[19:43:37] <lightguard_jp> I added a comment
[19:43:42] <lightguard_jp> Very frustrating
[19:43:49] <lightguard_jp> Must have tests for GF :(
[19:48:45] <lightguard_jp> mojavelinux: jaxrs example w/ seam config, you got that working?
[19:49:09] <mojavelinux> ah, I see...I'm saying that I've got it working on JBoss AS
[19:49:11] <mojavelinux> I haven't tried GF
[19:49:16] <mojavelinux> I don't think it's going to work
[19:49:26] <lightguard_jp> That's fine, I just need those changes in the repo
[19:49:49] <lightguard_jp> at this point in time, until weldx / solder works on glassfish 3.1 it doesn't matter
[19:51:24] <mojavelinux> I have to redo the solder import...it was just screwed up
[19:51:32] <mojavelinux> missing commits somewhere in the middle...I must have branched from the wrong point
[19:51:56] <mojavelinux> right, I mean the issue w/ GF is that there is no use trying to run anything on it until we can run the solder tests on it
[19:52:04] <mojavelinux> because that's where the problem is
[19:52:21] <mojavelinux> so basically, start there (of course, wait for my commit to get solder up to speed)
[19:54:52] <mojavelinux> eclipse refactoring doesn't rename services files
[19:54:57] <mojavelinux> it fixes the class references in them
[19:55:03] <mojavelinux> but the file itself still uses the old classname
[19:56:28] <mojavelinux> panel, I have a question?
[19:56:43] <mojavelinux> wait, that's a statement, I know I have a question
[19:56:45] <mojavelinux> can you answer
[19:56:46] <mojavelinux> ?
[19:57:02] <mojavelinux> we need to name web-fragment.xml files consistently
[19:57:09] <mojavelinux> right now, so we need a convention
[19:57:15] <mojavelinux> which of the three do you prefer?
[19:57:19] <mojavelinux> a. SeamServlet
[19:57:23] <mojavelinux> b. seam_servlet
[19:57:31] <mojavelinux> c. org_jboss_seam_servlet
[19:57:34] <mojavelinux> d. seamservlet
[19:57:37] <mojavelinux> ?
[19:58:32] <lightguard_jp> So a/b/c/d/?-web-fragement.xml ?
[19:58:41] <lightguard_jp> Or the name of the servlet in the file?
[20:00:10] <mojavelinux> basically the id
[20:00:15] <mojavelinux> <name>SeamServlet</name>
[20:00:28] <mojavelinux> this is for other apps to reference for ordering purposes
[20:03:32] <lightguard_jp> Ah, okay
[20:03:52] <lightguard_jp> I'm fine with a, though the namespacing of c is nice as well
[20:04:18] <lightguard_jp> Maybe go with c for less possibility of name clashes
[20:11:09] <mojavelinux> though it's very unlikely that there will be another project called Seam Servlet...we could even fight it legally mostly likely (though I despise that word fight in the context of OSS)
[20:11:17] <mojavelinux> projects have been going in the direct of a
[20:11:32] <mojavelinux> for instance, PrimeFaces uses PrimeFaces and PrettyFaces uses PrettyFaces :)
[20:13:10] <lightguard_jp> I hate the Seam2 Application Framework
[20:13:15] <lightguard_jp> I wish it had never been pushed
[20:13:33] <lightguard_jp> Same with SeamTest
[20:13:58] <lightguard_jp> The two biggest issues (both of them currently in #seam) I've seen with Seam2 and people asking for help.
[20:16:55] <lightguard_jp> </rant>
[20:18:47] <lincolnthree> InvalidMarkupException: You never started ranting.
[20:19:29] *** marekn has joined #seam-dev
[20:19:31] <lightguard_jp> I never said what you should parse it with either :P
[20:19:56] <mojavelinux> hehehe, someone just asked about that framework on the twitter feed today
[20:20:04] <mojavelinux> I said it needs to be redesigned
[20:20:13] <mojavelinux> I think what it really should be is just some generic daos
[20:20:13] <lightguard_jp> Which SAF?
[20:20:16] <mojavelinux> yep
[20:20:20] <lightguard_jp> Yeah
[20:20:31] <mojavelinux> we need to review what Andy Gibson has done
[20:20:42] <lightguard_jp> It should have a huge warning that says ONLY USE THIS FOR BASIC CRUD
[20:20:54] <mojavelinux> Pete didn't seem to be in love with it, but i'd be interested to check it out and see if I see value
[20:21:16] <lightguard_jp> Was that the query building stuff?
[20:21:22] <mojavelinux> right, with SAF you end up doing more to make it work then you would to just do what you were doing in the first place
[20:21:29] <lightguard_jp> Yep
[20:21:30] <mojavelinux> let me get a link
[20:21:45] <lightguard_jp> And everyone tries to make it do things it was never supposed to do
[20:21:57] <lightguard_jp> Like the Query object
[20:22:10] <lightguard_jp> Home isn't so much a problem but query blows
[20:22:44] <mojavelinux> we really need to court Andy to Seam
[20:22:52] <mojavelinux> he has great ideas and is clearly thinking a lot about CDI and EE 6
[20:23:36] <lightguard_jp> http://www.andygibson.net/blog/ ?
[20:25:25] <mojavelinux> http://www.andygibson.net/files/datavalve/docs/html/index.html
[20:26:03] <mojavelinux> "As a long time Seam user, Seam provides most of this with the EntityQuery that can be used to run queries using JPA but it isn't perfect. I extended the Seam EntityQuery and blogged about it and it still remains a popular article today when people are looking for info on JSF and pagination. However this solution only works in Seam projects but the same functionality is needed in Wicket, Spring, JSP and even Swing and co
[20:26:08] <lightguard_jp> http://www.andygibson.net/blog/article/injecting-string-resource-services-with-cdi/ is good, Solder has better though :)
[20:27:55] <mojavelinux> yeah, when we see blog posts like this, it is a great opportunity to do what I call a counter post
[20:28:04] <mojavelinux> that's like, here's how you accomplish the same using our framework
[20:28:23] <mojavelinux> great for promoting features and giving people a reason to consider switching over
[20:29:03] <lightguard_jp> Though it's not really "our framework vs theirs" It's all CDI, is more "here's an alternative, oh, and some other really cool stuff you get too"
[20:33:17] *** balunasj has joined #seam-dev
[20:33:23] *** balunasj has quit IRC
[20:34:58] *** rruss has joined #seam-dev
[20:38:03] <mojavelinux> right, exactly, but we also want to make people feel like they have some off the shelf solutions so they don't have to reimplement everything from scratch
[20:38:07] <mojavelinux> but yes, an alternative, an option
[20:38:12] <mojavelinux> okay, solder is now totally up to date
[20:38:17] <mojavelinux> I had to redo the import...it was screwed up
[20:38:22] <mojavelinux> https://github.com/seam/solder
[20:39:51] <mojavelinux> seam solder should probably be 3.0.x
[20:39:57] <mojavelinux> 3.0.0.Beta1
[20:46:02] <lightguard_jp> Yeah
[20:53:31] <mojavelinux> okay, so let's go with SeamFaces, SeamServlet, SeamSolder for the web-fragment.xml
[20:56:06] <lightguard_jp> mojavelinux: In your blog, don't you need to tell the EM to join the transaction you just started?
[20:56:45] <mojavelinux> yes...actually, I could just make it @Stateless
[20:56:47] <mojavelinux> that would work too
[20:57:23] <lightguard_jp> But that's not what you're demonstrating :)
[20:57:33] <lightguard_jp> Sure you could do it as an EJB, but you don't have to this way
[20:58:52] <mojavelinux> I'm thinking we should have ids for our conventions
[20:59:01] <mojavelinux> each rule has some number to refer to
[20:59:09] <mojavelinux> that way, we can say, follow convention 0023
[20:59:17] <mojavelinux> S23
[21:00:00] <lincolnthree> organization is good
[21:01:35] <mojavelinux> hm, I like aliases better
[21:01:46] <mojavelinux> I came up with s-apiscope and s-webfragname as examples
[21:01:53] <mojavelinux> http://seamframework.org/Seam3/DevelopmentGuidelines
[21:02:04] <lincolnthree> that works
[21:07:15] <stuartdouglas> morning all
[21:12:28] <lincolnthree> hey stuartdouglas :)
[21:13:40] <lightguard_jp> stuartdouglas: Morning
[21:17:58] <lightguard_jp> mojavelinux: Are your catch jaxrs example changes in github?
[21:18:16] *** balunasj has joined #seam-dev
[21:22:35] *** kpiwko has quit IRC
[21:25:48] <stuartdouglas> lightguard_jp: Did you fix your problem yesterday?
[21:26:35] <lightguard_jp> I think mojavelinux fixed it, but hasn't shared it yet
[21:28:17] <stuartdouglas> I have release seam xml beta1, I just need to do up the release announcement
[21:28:27] <lightguard_jp> Awesome
[21:29:50] <lightguard_jp> stuartdouglas: What's been fixed / changed?  I don't see a beta1 in JIRA
[21:32:16] <stuartdouglas> minor doc stuff, nothing to major
[21:32:29] <lightguard_jp> Ah
[21:32:29] <stuartdouglas> It should have been called beta a while ago
[21:32:38] <lightguard_jp> Yeah, it's been pretty stable for a while now
[21:32:52] <stuartdouglas> also I got the example to run on jbossas
[21:33:08] <lightguard_jp> The Catch jaxrs example?
[21:33:42] <lightguard_jp> stuartdouglas: What did you do?
[21:35:29] <stuartdouglas> no, the pricess-rescue example from seam-xml
[21:35:34] <lightguard_jp> Ah
[21:35:45] <stuartdouglas> up till now it only had a jetty profile
[21:38:45] *** balunasj has quit IRC
[21:44:09] <lightguard_jp> WELD-001308 Unable to resolve any beans for Types: [java.util.List<org.jboss.seam.exception.control.example.jaxrs.handler.RestExceptionResponse>]; Bindings: [ at org dot jboss.seam.exception.control.example.jaxrs.handler.RestRequest()] seems like an old message (Bindings instead of Qualifiers)
[21:46:14] <stuartdouglas> can you post the code you are using to produce the list?
[21:46:36] <lightguard_jp> http://pastebin.com/VA4VG272
[21:46:48] <lightguard_jp> I may have found something
[21:47:37] <stuartdouglas> what about ExceptionResponseMappings ?
[21:47:47] <stuartdouglas> also, are you getting seam-xml messages in the logs?
[21:47:55] <lightguard_jp> Yes
[21:48:04] <lightguard_jp> ExceptionResponsMappings I made a change
[21:48:09] <lightguard_jp> going to try it.
[21:48:38] <lightguard_jp> The list wouldn't take a subclass of ExceptionResponse, which RestExceptionResponse is
[21:49:30] <mojavelinux> the latest catch changes I pushed to github
[21:49:43] <mojavelinux> I pushed directly into master, which in hindsight perhaps I should have been on a branch...but I wanted to get you moving
[21:49:59] <lightguard_jp> You should delete the other branches
[21:50:36] <lightguard_jp> Hm, latest change says Oct 22
[21:53:03] <mojavelinux> https://github.com/seam/catch
[21:53:15] <mojavelinux> https://github.com/seam/catch/commits/master/
[21:53:30] <mojavelinux> I should have said I pushed directly into upstream
[21:53:33] <lightguard_jp> Oh, you pushed directly into the official repo?
[21:53:34] <mojavelinux> not my master
[21:53:36] <mojavelinux> yes
[21:53:45] <lightguard_jp> Hm, didn't get any logs here
[21:55:23] <mojavelinux> there
[21:55:29] <mojavelinux> I didn't have my upstream setup for catch
[21:55:39] <mojavelinux> now my master is inline with the real master
[21:55:43] <lightguard_jp> Okay
[21:55:43] <mojavelinux> and I can work on it ;)
[21:55:54] <mojavelinux> we should have instructions for this I realize on seamframework.org
[21:55:57] <mojavelinux> about how to setup an upstream
[21:56:01] <mojavelinux> and pull and push from it
[21:57:01] <mojavelinux> now I see why you weren't getting it to work :)
[21:57:04] <mojavelinux> try it out now
[21:57:07] <mojavelinux> gotta run to lunch
[22:00:06] <stuartdouglas> lightguard_jp: It is not working because you can't inject List<ExceptionResponce> into List<RestExceptionResponse>
[22:00:37] <lightguard_jp> Yeah, so I tried List<? extends ExceptionResponse> and it blew up too
[22:00:59] <lightguard_jp> java.lang.RuntimeException: Cannot convert ? extends org.jboss.seam.exception.control.ExceptionResponse into a java.lang.Class
[22:01:16] <lightguard_jp> I need to use a <T extends ExceptionResponse> ?
[22:02:00] <stuartdouglas> I think you need to inject List<ExceptionResponse>
[22:07:10] <lightguard_jp> Okay, going to have to find some docs then about how to do the config.  I don't actually need the ExceptionResponseMapper class
[22:07:21] <lightguard_jp> But I need to have the config produce a list.
[22:09:14] <lightguard_jp> Can I just do a <Produces>qualifier value value value</Produces> ?
[22:09:30] <lightguard_jp> I guess that should be <qualifier> <value>...
[22:09:51] <stuartdouglas> at the moment it won't work, as there is no way of specifying the type parameter
[22:09:53] <stuartdouglas> for the list
[22:10:04] <stuartdouglas> there is an open issue
[22:10:11] <stuartdouglas> I will add that next release
[22:11:24] <lightguard_jp> Currently, there isn't a way to do this then? Without some Java code defining the producer?
[22:12:18] <stuartdouglas> you just have to inject List<ExceptionResponse> rather than List<RestExceptionResponse>
[22:14:57] <lightguard_jp> Okay, I'll give it a shot
[22:20:33] <lightguard_jp> Still no love
[22:20:35] <lightguard_jp> NPE that time
[22:22:00] <lightguard_jp> http://pastebin.com/nnu20D2G
[22:24:22] <stuartdouglas> That looks like a bug
[22:24:32] <stuartdouglas> can you file a JIRA?
[22:24:39] <stuartdouglas> I'll fix it this weekend
[22:25:37] <lightguard_jp> Okay, which is the bug? The injection?
[22:26:51] <stuartdouglas> the npe, just attache the info in the pastbin
[22:27:04] <lightguard_jp> okay
[22:30:55] <lightguard_jp> https://jira.jboss.org/browse/SEAMXML-23
[22:30:55] <jbossbot> jira [SEAMXML-23] NPE with injection [Open, Major, Unassigned] https://jira.jboss.org/browse/SEAMXML-23
[22:32:59] <stuartdouglas> what package is RestExceptionResponce in?
[22:34:09] <lightguard_jp> org.jboss.seam.exception.control.example.jaxrs.handler
[22:35:26] *** marekn has left #seam-dev
[22:36:56] <lightguard_jp> stuartdouglas: Beta1 was the one you just released?
[22:37:49] <stuartdouglas> yes
[22:38:06] <stuartdouglas> I am going to do the release announcement tonight
[22:38:29] <stuartdouglas> I think I know what is causing the problem, and I think the underlying problem may be a weldx/solder issue
[22:38:45] <lightguard_jp> You don't think anything in there would have fixed this bug, do you?
[22:39:05] <stuartdouglas> no, I don't think it likes having a getter with no setter
[22:39:23] <stuartdouglas> as it then assumes the property is read only
[22:39:28] <lightguard_jp> Ah
[22:39:32] <lightguard_jp> I can try that then
[22:39:33] <stuartdouglas> but I will need to investigate further
[22:39:50] <stuartdouglas> I have to go to work
[22:40:41] <lightguard_jp> Hm
[22:40:48] <lightguard_jp> It has both getter and setter though
[22:40:55] <lightguard_jp> ExceptionResponseMappings
[22:40:57] <lightguard_jp> does
[22:41:03] <stuartdouglas> in RestExceptionResponse
[22:41:25] <lightguard_jp> Oh.  I asked Dan about that the other day and he thought it would be okay
[22:41:34] <lightguard_jp> I try again w/ both getter and setters
[22:41:51] <stuartdouglas> It would have been with a previous version
[22:42:15] <stuartdouglas> but then I moved to weldx's PropertyQuery, rather than using my home grown one from seam xml
[22:42:21] <stuartdouglas> cause re-use is good right?
[22:42:30] <stuartdouglas> and I think that is what caused it
[22:43:11] <stuartdouglas> I'll have to modify Property somewhat, another one for this weekend
[22:44:12] <stuartdouglas> later
[22:51:59] <lightguard_jp> stuartdouglas: Yep, having both the getter and setter worked
[23:06:36] *** lincolnthree has left #seam-dev
[23:50:22] <jbossbot> git [catch] push master 6a23fc0.. LightGuard Merge branch 'master' of github.com:seam/catch...
[23:50:22] <jbossbot> git [catch] push master 8059bdd.. LightGuard All handlers are working correctly now in the example...
[23:50:22] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/1447cfe...8059bdd
[23:56:17] *** rruss has quit IRC





top