[00:12:52] <mojavelinux> clerum: I updated the mail module page http://seamframework.org/Seam3/MailModule
[00:13:03] <mojavelinux> so now there are three pages to reference, Servlet, Mail and Catch
[00:13:11] <mojavelinux> Faces is a little special
[00:15:19] <lincolnthree> Damn right it is!
[00:16:21] <lightguard_jp> Has GF 3.1 been fixed for solder?
[00:16:37] <lincolnthree> lightguard_jp: I feel like you ask that question every day.
[00:17:30] <lightguard_jp> Not every day
[00:17:34] <lightguard_jp> Once a week maybe
[00:17:43] <lincolnthree> i wish i knew
[00:17:44] <lightguard_jp> Little important that it is fixed
[00:17:51] <lincolnthree> yeah only slightly
[00:18:39] <mojavelinux> hahaha
[00:18:53] <mojavelinux> yeah, it's crucial that it's fixed...actually
[00:18:59] <mojavelinux> it's pretty simple to answer
[00:19:08] <mojavelinux> if we can run the tests w/ embedded glassfish
[00:19:29] <mojavelinux> or at least configure one test to run on some glassfish mode
[00:19:45] <mojavelinux> to put it simpler, the test should be able to tell us
[00:19:51] <mojavelinux> I honestly haven't tried
[00:22:45] <lightguard_jp> I tried, a little while ago, many failed, I think because they timed out on the deploy
[00:25:52] *** maxandersen has quit IRC
[00:26:57] *** rruss has quit IRC
[00:32:35] <clerum> mojavelinux: thanks
[01:10:05] *** bleathem has quit IRC
[01:34:05] *** lightguard_jp has quit IRC
[03:32:33] *** aslak has quit IRC
[04:04:10] *** rruss has joined #seam-dev
[04:06:45] *** rruss has quit IRC
[04:08:54] <jbossbot> git [security] push master 90df834.. Shane Bryzak SEAMSECURITY-20
[04:08:55] <jbossbot> jira [SEAMSECURITY-20] Security won't run on stock Glassfish 3.0.1 [Open, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-20
[04:08:56] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/252de20...90df834
[04:25:54] *** lightguard_jp has joined #seam-dev
[05:22:45] *** lightguard_jp has quit IRC
[06:01:33] *** tsurdilo has quit IRC
[06:26:43] *** lincolnthree has left #seam-dev
[06:28:12] *** rruss has joined #seam-dev
[07:42:04] *** oskutka has joined #seam-dev
[08:21:01] *** kpiwko has joined #seam-dev
[09:08:08] *** jharting has joined #seam-dev
[09:14:29] *** maxandersen has joined #seam-dev
[10:06:09] *** shervin_a has joined #seam-dev
[10:06:24] *** marekn has joined #seam-dev
[10:24:00] *** mbg has quit IRC
[12:32:37] *** maxandersen is now known as maxandersen_lunc
[13:02:10] *** aslak has joined #seam-dev
[13:02:11] *** aslak has quit IRC
[13:02:11] *** aslak has joined #seam-dev
[13:11:17] *** pmuir has joined #seam-dev
[13:44:21] *** maxandersen_lunc is now known as maxandersen
[13:51:51] *** rruss has quit IRC
[14:29:07] *** shervin_a has quit IRC
[14:31:07] *** shervin_a has joined #seam-dev
[14:33:48] *** emmanuel has joined #seam-dev
[14:36:20] *** aslak has quit IRC
[14:36:52] *** aslak has joined #seam-dev
[14:42:15] *** aslak has quit IRC
[14:42:52] *** aslak has joined #seam-dev
[14:44:55] *** kpiwko1 has joined #seam-dev
[14:46:18] *** kpiwko has quit IRC
[14:59:17] *** aslak has quit IRC
[14:59:52] *** aslak has joined #seam-dev
[15:01:50] *** aslak has quit IRC
[15:02:22] *** aslak has joined #seam-dev
[15:13:11] *** kpiwko1 has quit IRC
[15:15:38] *** rruss has joined #seam-dev
[15:20:17] *** kpiwko has joined #seam-dev
[15:27:07] *** pmuir has quit IRC
[15:36:04] *** marekn has left #seam-dev
[15:36:04] *** mbg has joined #seam-dev
[15:45:04] *** tsurdilo has joined #seam-dev
[15:47:43] *** oskutka has quit IRC
[15:48:42] *** tsurdilo has quit IRC
[15:49:05] *** tsurdilo has joined #seam-dev
[15:49:51] *** pmuir has joined #seam-dev
[15:52:10] *** oskutka has joined #seam-dev
[16:06:42] *** oskutka has quit IRC
[16:25:55] *** emmanuel has quit IRC
[16:37:29] *** bleathem has joined #seam-dev
[16:45:53] *** jharting has quit IRC
[16:53:19] *** epbernard has joined #seam-dev
[16:53:20] *** epbernard is now known as emmanuel
[16:53:26] *** emmanuel has quit IRC
[17:23:04] *** jharting has joined #seam-dev
[17:29:02] *** shervin_a has quit IRC
[17:42:30] *** sbryzak has quit IRC
[17:44:19] *** sbryzak has joined #seam-dev
[17:50:38] *** kpiwko has quit IRC
[18:03:54] *** maxandersen has quit IRC
[18:05:07] *** maxandersen has joined #seam-dev
[18:09:33] *** maxandersen has quit IRC
[18:56:26] *** rruss has quit IRC
[19:06:31] *** marekn has joined #seam-dev
[19:06:50] *** marekn has left #seam-dev
[19:52:03] *** pmuir has left #seam-dev
[20:20:11] *** jharting has quit IRC
[20:23:31] *** lightguard_jp has joined #seam-dev
[20:29:41] *** lightguard_jp has quit IRC
[20:32:36] *** bleathem has quit IRC
[20:41:47] *** lightguard_jp has joined #seam-dev
[21:00:33] *** balunasj has joined #seam-dev
[21:26:52] *** balunasj has quit IRC
[22:00:00] <jbossbot> git [solder] push master dac76e8.. Dan Allen SOLDER-9
[22:00:01] <jbossbot> jira [SOLDER-9] JTA should not be a required dep but Getting Started chapter says it is [Open, Major, Dan Allen] https://issues.jboss.org/browse/SOLDER-9
[22:00:01] <jbossbot> git [solder] push master 8f847fc.. Dan Allen Merge branch 'master' of github.com:seam/solder
[22:00:01] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/434d6e6...8f847fc
[22:09:34] *** lightguard_jp has quit IRC
[22:20:14] <mojavelinux> we are really stuck doing anything on solder until the api/impl split is committed
[22:20:37] <stuartdouglas> we could just merge what is there
[22:20:41] <mojavelinux> so I'm going to apply that now, with some follow-up tweeks
[22:20:45] <mojavelinux> yep, about to say that
[22:20:57] <stuartdouglas> I'm about to close the performance issue
[22:21:08] <mojavelinux> are you working from the split? or the non-split?
[22:21:18] <stuartdouglas> non-split, but the changes are in weld
[22:21:20] <stuartdouglas> not solder
[22:21:23] <mojavelinux> ah
[22:21:29] <stuartdouglas> not sure if I can get it into this release though
[22:21:44] <stuartdouglas> Pete made a change last night that helps alot
[22:21:47] <mojavelinux> so can I muck with the solder repo master?
[22:21:58] <stuartdouglas> sure
[22:22:14] <mojavelinux> k, I'm going to begin merging in your pull request(s)
[22:22:15] <stuartdouglas> isn't get mean't to be smart enought to handle something like that anyway :-)
[22:22:22] <stuartdouglas> ^git
[22:23:09] <mojavelinux> yeah, but at this point I'm trying to have least resistance :) I don't want to create an issue I don't already have
[22:27:14] <jbossbot> git [persistence] push master c72d31a.. Lincoln Baxter, III weldx needs to have deps excluded for 1.0.0.Beta1
[22:27:14] <jbossbot> git [persistence] push master 0cf7b94.. Lincoln Baxter, III removed generated files
[22:27:14] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/1c833fe...0cf7b94
[22:32:48] <stuartdouglas> I think the performance issue is done, but my last fix will miss AS6 final
[22:35:31] <jbossbot> git [solder] push master 3b01b9c.. Dan Allen Merge branch 'SOLDER-20'
[22:35:32] <jbossbot> jira [SOLDER-20] Extract API into separate module [Open, Major, Stuart Douglas] https://issues.jboss.org/browse/SOLDER-20
[22:35:32] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/8f847fc...3b01b9c
[22:36:39] *** tsurdilo has quit IRC
[22:38:59] <stuartdouglas> solder now makes a negligible difference to startup time
[22:39:16] <stuartdouglas> previously it went from 16s without solder to 1m with
[22:39:23] <stuartdouglas> now it goes from 16s to 17s
[22:43:10] <stuartdouglas> mojavelinux: It probably would have been better to merge the other pull requests for solder before the api/impl split
[22:43:18] <stuartdouglas> it will be interesting to see how git handles it
[22:43:39] <mojavelinux> fantastic! (to the performance change)
[22:43:52] <mojavelinux> that will make mike brock esp happy
[22:44:31] <mojavelinux> shit, oh well, I'll make it work...I could always revert the push...looking into a failure atm
[22:45:36] <stuartdouglas> the latest performance fix won't make it into the CR release
[22:45:47] <stuartdouglas> so startup is around 22s
[22:45:55] <stuartdouglas> which is still much better than 1m
[22:46:10] <stuartdouglas> and for a normal number of beans, probably unnoticeable
[22:51:13] <mojavelinux> right, these numbers are for huge deployments, right
[22:51:21] <stuartdouglas> 10,000 beans
[22:51:48] <mojavelinux> incredible
[22:52:11] <mojavelinux> really makes you feel much better about the CDI programming model...a model with power without cost
[22:52:17] <mojavelinux> is something to feel good about
[22:52:28] <stuartdouglas> half that time is class loading to
[22:53:02] <stuartdouglas> in as7 I think I am going to try and get a secondary thread to start loading the required classes as early as possible
[22:55:46] <stuartdouglas> are we going to get SOLDER-1 done?
[22:55:48] <jbossbot> jira [SOLDER-1] ELResolver assumes flat deployment structure [Open, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-1
[22:56:05] <stuartdouglas> I can't really see any good way to do it
[23:01:42] <mojavelinux> pete says it's a cdi issue
[23:01:50] <mojavelinux> and that we need to convert it into a cdi issue to close it
[23:02:05] <mojavelinux> because there is absolutely nothing we can do about it right now that I can see
[23:03:14] <stuartdouglas> soounds good
[23:03:51] <mojavelinux> yeah, parallelizing the class loading is definitely the way to go
[23:04:12] <mojavelinux> there is no question that AS7 has a great opportunity to do some revolutionary things with app servers, glad to see thinking outside the box on this kind of stuff
[23:04:21] <stuartdouglas> I think there may be other bits that can be parallelised as well
[23:04:33] <mojavelinux> really, to compete with jetty/tomcat, all we have to realize is that what developers care about is speed
[23:04:39] <mojavelinux> no speed, no interest
[23:04:44] <stuartdouglas> thats it
[23:05:22] <mojavelinux> sadly, it's the world we live in today, but it's also an opportunity to win them over so to speak
[23:29:22] <sbryzak> morning guys
[23:29:37] <sbryzak> mojavelinux stuartdouglas: anything i can do to help with the Solder release?
[23:30:04] <mojavelinux> good morning shane
[23:30:14] <mojavelinux> good question, let me think about it for a minute
[23:31:47] *** rruss has joined #seam-dev
[23:32:20] <mojavelinux> I'm about to commit a build change that should give us a foundation that won't change from under us...meaning I've got the migration to
[23:32:23] <mojavelinux> 1. api/impl split
[23:32:26] <mojavelinux> 2. version 3
[23:32:39] <mojavelinux> 3. use Seam parent, + some cleanups of the build to sync with other modules
[23:32:57] <mojavelinux> then, I would suggest that you can tackle the removal of slf4j
[23:33:10] <mojavelinux> since that is currently unscheduled and should be fairly straightforward
[23:33:16] <mojavelinux> as to what to do
[23:34:15] <sbryzak> sure thing
[23:34:23] <mojavelinux> I've got the combined jar configuration working
[23:34:25] <sbryzak> i'll wait till you commit your stuff first ;)
[23:34:34] <mojavelinux> so it creates seam-solder.jar from seam-solder-impl.jar + seam-solder-api.jar
[23:34:37] <mojavelinux> but I have to tell you
[23:34:44] <mojavelinux> maven is so dumb, or at least, the shade plugin is
[23:34:58] <mojavelinux> I would  put the plugin config in the impl/pom.xml
[23:35:03] <mojavelinux> however, when creating a shaded jar
[23:35:03] <sbryzak> i find maven extremely frustrating
[23:35:11] <mojavelinux> you only have one option, you can add to the name of the artifactId
[23:35:15] <mojavelinux> so, it can be called
[23:35:24] <mojavelinux> seam-solder-3.0.0.Beta1-shaded.jar
[23:35:27] <mojavelinux> but it can't be called
[23:35:34] <mojavelinux> seam-solder-3.0.0.Beta1.jar
[23:35:43] <mojavelinux> for that, you need a separate module, i.e., combined/pom.xml
[23:35:48] <mojavelinux> braindead
[23:35:56] <mojavelinux> so, that's why we have another folder
[23:35:57] <mojavelinux> :)
[23:36:14] <mojavelinux> I'll add that to the comments...that way, if someone figures out how to make it work, they can have at it
[23:36:20] <sbryzak> they design their modules for very narrow-scoped use cases
[23:36:20] <mojavelinux> more power to them
[23:36:24] <mojavelinux> very
[23:36:52] <mojavelinux> I have a suggestion for how to handle this jboss-logging dependency
[23:37:05] <mojavelinux> I suggested that we make it compiled scope, since it really is a dependency
[23:37:14] <mojavelinux> we are just setting it as provided becauase we know jboss as happens to leak it
[23:37:28] <mojavelinux> I could add another shaded jar
[23:37:35] <mojavelinux> that has it marked as provided
[23:37:46] <sbryzak> is it ok to use jboss-logging in other app servers?
[23:37:50] <mojavelinux> yep
[23:37:54] <mojavelinux> it's really really a basic jar
[23:38:04] <mojavelinux> it does dep on javasisst to generate the proxies
[23:38:09] <sbryzak> np, so i guess it just delegates to the underlying logging api
[23:38:14] <mojavelinux> which, should probably also be a dependency
[23:38:16] <mojavelinux> yep
[23:38:22] <mojavelinux> in fact, it's really just one java class
[23:38:50] <sbryzak> if it's only one class, couldn't we have just included that in Solder?
[23:38:59] <sbryzak> since most of the other modules use Solder anyway
[23:39:06] <sbryzak> it would mean one less dependency
[23:39:57] <mojavelinux> http://anonsvn.jboss.org/repos/common/jboss-logging/trunk/src/main/java/org/jboss/logging/
[23:40:05] <mojavelinux> by one class, I mean it routes out all the calls
[23:40:20] <mojavelinux> it does a bunch of other stuff, but that's mostly about preparing the message
[23:40:36] <sbryzak> ah i see, so there's a bit more to it ;)
[23:40:51] <mojavelinux> yeah
[23:41:01] <mojavelinux> it is a delegate to all the popular providers
[23:41:27] <sbryzak> no problem, once your commit is in i'll start working on removing slf4j
[23:41:34] <sbryzak> what's the issue in JIRA?
[23:42:03] <mojavelinux> but really this dependency thing comes back to something we have to start addressing more clearly
[23:42:11] <mojavelinux> it's correct for us to mark a java ee api as provided
[23:42:25] <mojavelinux> because we assume the runtime provides that and we have no business pulling in that dependency
[23:42:30] <mojavelinux> however, just because jboss as provides something
[23:42:36] <mojavelinux> doesn't not mean we should mark it as provided
[23:42:54] <mojavelinux> that is something the user is going to have to sort out
[23:43:03] <mojavelinux> and by default we should put it as a dependency
[23:43:07] <sbryzak> i think we decided that our target container was jboss-as
[23:43:12] <mojavelinux> now, like I said, we could go half way and provide an extra jbossas jar
[23:43:46] <sbryzak> so by default we should configure our dependencies for that environment
[23:43:47] <mojavelinux> i think for solder we have to be careful there if the goal is to really get people to use it as a foundation...otherwise, we never really reach out
[23:43:57] <mojavelinux> I think are target environemnt is compliant ee 6
[23:44:13] <sbryzak> for stuff like jboss-logging, i think we should mark it as optional
[23:44:24] <mojavelinux> optional and provided are the same thing, essentially
[23:44:44] <mojavelinux> the problem is, people go to use solder on something like glassfish, and it blows up because jboss-logging isn't there
[23:44:56] <mojavelinux> and when they see a failed dependency on jboss-logging
[23:44:56] <sbryzak> i guess if you deploy an app that packages jboss-logging to jboss-as, you get a classloader error?
[23:45:02] <mojavelinux> they assume they can't use solder and they go away
[23:45:18] <mojavelinux> I'm really not sure what happens when it gets deployed to jboss-as
[23:45:22] <mojavelinux> but I could try it out
[23:45:32] <sbryzak> we need to determine that first
[23:45:34] <mojavelinux> btw SOLDER-35
[23:45:36] <jbossbot> jira [SOLDER-35] Remove slf4j usage from weldx [Open, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-35
[23:45:59] <mojavelinux> all I need to do is run these tests in integration mode w/ jboss-logging marked as compile scope





top