[00:00:01] <mojavelinux> now, if you bring spring into the picture, okay, that's a different story
[00:00:07] <mojavelinux> you are on a different path then
[00:00:23] <sbryzak> we have so many modules in seam now, that we unfortunately have to enforce certain restrictions
[00:00:39] <sbryzak> if each module did their own thing then the user experience would suffer
[00:01:02] <mojavelinux> yes, though without my point, one could argue for every module to build in jetty by default
[00:01:21] <mojavelinux> which, clearly, is not in the spirit of the goal of this project, which is to be based on the web profile
[00:01:22] <gmorling> agreed on uniformity
[00:01:29] *** daniel_hinojosa has quit IRC
[00:01:30] <mojavelinux> as the default target
[00:01:51] <sbryzak> bleathem: ping
[00:01:54] <gmorling> mojavelinux: there are modules which can't run on Jetty per definition as they need full EE stuff
[00:01:58] <mojavelinux> now, if you take jetty and make it a web profile, then you can use jetty:run out of the box :)
[00:02:01] <gmorling> e.g. JMS
[00:02:18] <gmorling> hehe. Well, if that's going to happen ...
[00:02:42] <gmorling> sbryzak: is it really
[00:02:43] <gmorling> mvn clean package jboss:hard-deploy
[00:02:45] <gmorling> $JBOSS_HOME/bin/run.sh
[00:02:46] <gmorling> ?
[00:02:49] <mojavelinux> I don't see any reason why the jetty project would refuse to go in that direction (okay, maybe cut out EJB, but who the hell cares)
[00:03:09] <sbryzak> gmorling: yep that works
[00:03:09] <mojavelinux> web profile - EJB == web profile :)
[00:03:15] *** msmigielski has quit IRC
[00:03:49] <mojavelinux> or I should say
[00:03:53] <sbryzak> so... the order of the day now is glassfish rants
[00:03:54] <gmorling> how does jboss:hard-deploy know where my installation is? Does it also jus $JBOSS_HOME?
[00:03:55] <mojavelinux> web profile - EJB + Seam == web profile
[00:04:04] <mojavelinux> yeah
[00:04:07] <gmorling> jus=use
[00:04:14] *** bleathem has quit IRC
[00:04:16] <sbryzak> gmorling: yes, it uses $JBOSS_HOME
[00:04:24] <gmorling> cool, got to try that out.
[00:04:46] <mojavelinux> btw, JMS isn't in the web profile, so technically that module requires extra power to run, however
[00:04:48] <sbryzak> mojavelinux: i think i found another GF bug last night
[00:05:01] <mojavelinux> jboss was strongly opposed to the decision to take jms out of the web profile
[00:05:06] <mojavelinux> really?!
[00:05:12] <mojavelinux> what is it?
[00:05:16] <sbryzak> mojavelinux: quite a serious one
[00:05:21] <mojavelinux> uh oh
[00:05:21] <sbryzak> i need to double check it
[00:05:26] *** daniel_hinojosa has joined #seam-dev
[00:05:27] <sbryzak> and honestly, i need a test
[00:05:31] <sbryzak> but my arq skills are noob
[00:05:39] <gmorling> Ok, to sum this up, everything is fine with the example for now, and for post 3.0 Final we'll add arquillian/selenium based automated tests
[00:05:54] <sbryzak> gmorling: sounds good :)
[00:06:10] <sbryzak> we could polish the test a little more however...
[00:06:19] <sbryzak> i'd like to see validation errors handled gracefully
[00:06:38] <sbryzak> maybe we can use the catch module for that
[00:06:55] <gmorling> that sounds interesting
[00:07:05] <gmorling> you mean like displaying some nice error page?
[00:07:25] <sbryzak> yes
[00:07:44] <sbryzak> i really like that we're using method validation in the example
[00:08:02] <sbryzak> though we should make a note of it on the actual test web page
[00:08:08] <sbryzak> so that people realize how cool it is
[00:08:11] <mojavelinux> yes, and to answer your question gunnar, we can add seam-validation to booking if you want to patch it in
[00:08:17] <mojavelinux> the idea of booking has very much become
[00:08:22] <mojavelinux> throw in everything and see if it runs ;)
[00:08:23] <mojavelinux> hahaha
[00:08:27] <sbryzak> definitely, i would love to see it in the booking example
[00:08:28] <mojavelinux> poor mans integration testing
[00:08:46] <sbryzak> mojavelinux: so, this GF bug...
[00:08:50] <mojavelinux> yep
[00:09:00] <sbryzak> it's with the security-simple example
[00:09:20] <sbryzak> one sec while i generate the stack trace
[00:09:40] <sbryzak> oh, actually i found 2 bugs
[00:09:43] <lightguard_jp> Time to go home, later all
[00:09:45] <sbryzak> the first one is that @Requires doesn't work
[00:09:52] <sbryzak> night jason
[00:10:13] <gmorling> sbryzak: ok, I'll look into this one. Maybe I can get this done before 3.0 Final.
[00:10:14] <gmorling> mojavelinux: cool, just need to have closer look at the booking example :-)
[00:10:27] <gmorling> so, that's it for me, too. see you later
[00:10:44] <sbryzak> cya gunnar
[00:10:49] <sbryzak> mojavelinux: http://pastebin.com/s8MAqugA
[00:11:19] *** gmorling has left #seam-dev
[00:11:22] <sbryzak> it's throwing an exception about an interceptor being specified twice
[00:11:31] <sbryzak> however, it's only specified once
[00:11:56] <mojavelinux> I just want to say, I love glassfish logging
[00:12:10] <mojavelinux> i also like traffic jams, bad food and cleaning toilets
[00:12:32] <mojavelinux> can they make it a little harder to read the logs?
[00:12:38] <sbryzak> inside security-simple.war/WEB-INF/lib/seam-security.jar/META-INF/beans.xml
[00:13:07] <sbryzak> that's the only place the interceptor is specified
[00:13:20] <sbryzak> so we need a test that reproduces it
[00:13:31] *** wdrai1 has joined #seam-dev
[00:13:36] <sbryzak> the actual interceptor class is in security-simple.war/WEB-INF/lib/seam-persistence.jar
[00:13:55] <sbryzak> so the test should create a war that bundles two jar libraries
[00:14:04] <sbryzak> one of which contains an interceptor
[00:14:12] *** lightguard_jp has quit IRC
[00:14:14] <sbryzak> and the other one enables it
[00:14:30] *** wdrai has quit IRC
[00:14:57] <sbryzak> is that straightforward to set up in arquillian?
[00:15:15] <mojavelinux> yep, could get this done when I write the test to figure out why interceptors are not being enabled each time
[00:15:42] <mojavelinux> but wait, where is it being enabled?
[00:15:43] <sbryzak> also, with the @Requires bug pete said that it's a GF problem
[00:15:51] <sbryzak> it's happening before WELD is starting
[00:16:00] <sbryzak> the interceptor you mean?
[00:16:02] <mojavelinux> what @Requires bug?
[00:16:11] <sbryzak> @Requires doesn't work in GF
[00:16:19] <mojavelinux> in glassfish 3.1?
[00:16:20] <sbryzak> it's not actually a bug with @Requires itself
[00:16:32] <mojavelinux> it works in my tests
[00:16:38] <mojavelinux> it doesn't work in glassfish 3.0.1
[00:16:53] <mojavelinux> ah, wait
[00:17:01] <mojavelinux> there is a case it doesn't work in vanilla glassfish 3.1
[00:17:07] <mojavelinux> but stuart fixed that in weld HEAD
[00:17:08] <sbryzak> GF is throwing a class not found exception
[00:17:15] <sbryzak> i think i'm running vanilla 3.1
[00:17:24] <mojavelinux> yep, fixed in snapshot I'm willing to bet
[00:17:25] <sbryzak> btw we need a page on sfwk.org
[00:17:33] <sbryzak> with a link on the left hand menu
[00:17:37] <sbryzak> 'Running in Glassfish'
[00:17:41] <sbryzak> or something like that
[00:17:50] <mojavelinux> https://github.com/weld/core/commit/a349d2c410d2a4f6182af22fd7bdf5aff94649b5
[00:17:51] <jbossbot> git [core] a349d2c.. Stuart Douglas Prevent NoClassDefFound exceptions from killing the deployment
[00:17:56] <sbryzak> with all known issues, so we have a definitive list
[00:18:23] <sbryzak> hmm
[00:18:43] <sbryzak> so that means even though it throws an exception, the deployment still works?
[00:18:45] <mojavelinux> @Requires should be flawless with weld snapshot
[00:18:55] <stuartdouglas> that GF one is a problem in the GF integration code
[00:19:01] <mojavelinux> it's completely broken with glassfish 3.0.1
[00:19:10] <mojavelinux> and it's partially broken with vanilla glassfish 3.1
[00:19:16] <mojavelinux> oh, really?
[00:19:33] <mojavelinux> @Requires does work in some cases on glassfish 3.1
[00:19:43] <mojavelinux> there is something specific about this case then that makes it break
[00:19:50] <mojavelinux> because the @Requires tests pass on glassfish 3.1
[00:20:00] <mojavelinux> tells me we need another test
[00:20:09] <mojavelinux> or another scenario
[00:20:17] <mojavelinux> which @Requires usage is this?
[00:20:20] <sbryzak> well, in this example it's because we bundle seam-international
[00:20:37] <mojavelinux> ah, this is the joda time
[00:20:39] <sbryzak> which has a @Requires on the package-info for all the classes that require joda
[00:20:40] <sbryzak> yes
[00:20:53] <mojavelinux> interesting
[00:21:05] <mojavelinux> cool, that should definitely be made into a solder test
[00:21:09] <mojavelinux> that particular use case
[00:21:14] <mojavelinux> so that the CoreTest fails
[00:21:17] <sbryzak> i'm just testing it again
[00:21:28] <mojavelinux> actually, I don't like that CoreTest is testing all of these things in one test
[00:21:32] <mojavelinux> I wish there were seperate tests
[00:21:37] <mojavelinux> perhaps a jira
[00:21:37] <stuartdouglas> The issue is that GF's BeanDeploymentArchive implementation is loading classes before weld starts
[00:21:47] <stuartdouglas> and when it hits a NCDFE it blows up
[00:21:52] <sbryzak> what we really need is a compatibility suite
[00:22:03] <mojavelinux> I thought that was only a glassfish 3.0.1 thing, sucks to hear it's still a problem
[00:22:22] <stuartdouglas> in some cases this will still work, as just loading a class is not enough to cause a NCDFE in all curcumstances
[00:22:23] <mojavelinux> I call that the "over eager scanner" problem :)
[00:22:24] <sbryzak> stuartdouglas: that would make sense
[00:22:44] <mojavelinux> as always, thanks for the insight stuart :)
[00:22:53] <stuartdouglas> as the class loading is lazy, it can be postponed until you call get(Declared)Methods/Fields, or even until you call the method
[00:22:55] <mojavelinux> we would be talking out of our asses without you
[00:23:15] <sbryzak> ok, here's the exception : http://pastebin.com/wkGmnTpX
[00:23:36] <sbryzak> and i can confirm, the deployment doesn't work
[00:23:44] <sbryzak> this is on vanilla GF
[00:23:54] <stuartdouglas> BeanDeploymentArchiveImpl.handleEntry() is trying to load the class
[00:24:01] <stuartdouglas> it should wait till weld asks to load it
[00:24:25] <sbryzak> stuartdouglas: do you know if there is a GLASSFISH jira for this?
[00:24:43] <stuartdouglas> I only saw this yesterday, so I have not looked
[00:25:13] <sbryzak> mojavelinux: i'm of the opinion that this shouldn't hold up the release
[00:25:15] <stuartdouglas> considering how long the bean visibility one has sat there I am not sure it will help :-(
[00:25:36] <stuartdouglas> especially considering the bean visibility one is a one line fix
[00:25:41] <sbryzak> what we need to do though is clearly document all the issues, with links to jira
[00:25:56] <sbryzak> stuartdouglas: that doesn't sound very hopeful
[00:26:05] <mojavelinux> oh, I see the problem with the solder test
[00:26:13] <mojavelinux> it verifies that the @Requires check works
[00:26:18] <sbryzak> although looking at the GF jiras, i sense an overwhelming amount of bureaucracy
[00:26:23] <mojavelinux> what it doesn't confirm is that the bean can reference a class not present at runtime
[00:26:49] <mojavelinux> there is one solution to this problem Shane Bryzak, sbryzak
[00:26:53] <mojavelinux> we can tweet the crap out of it
[00:26:57] <mojavelinux> that actually seems to move oracle
[00:27:04] <mojavelinux> they don't seem to like bad press ;)
[00:27:05] <mojavelinux> go figure
[00:27:06] <sbryzak> i think that's what we have to do
[00:27:16] <mojavelinux> we have about 30 seam developers on twitter
[00:27:17] <sbryzak> i'd like to involve siva first though
[00:27:22] <mojavelinux> yeah, do that
[00:27:27] <sbryzak> but all of these issues are unacceptable
[00:27:27] <stuartdouglas> I would submit a patch, but considering I work on a competing app server, it is probably not the best idea :-)
[00:27:29] <mojavelinux> then we can make noise on your command :) hahha
[00:27:43] <mojavelinux> actually stuart, I think that would be a good move for jboss
[00:27:50] <mojavelinux> because it would prove that we have the *freedom* to do that
[00:27:51] <sbryzak> as far as i'm concerned, seam is a set of compliant extensions
[00:28:01] <sbryzak> the GF issues are just that, issues in GF
[00:28:04] <mojavelinux> which oracle is currently getting a bad reputation for their oppression of their developers in open source
[00:28:44] <mojavelinux> hell, i'll submit the patch if you want
[00:28:44] <sbryzak> stuartdouglas: i tend to agree, if it's done in a way so you distance yourself from the issue
[00:29:03] <sbryzak> more like pointing the finger at some code and saying 'here's where the problem seems to be'
[00:29:13] <mojavelinux> besides, pete has submitted many patches to glassfish in the past
[00:29:22] <sbryzak> true
[00:29:45] <mojavelinux> I want to defeat them through openness :)
[00:30:01] <sbryzak> we should collaborate with them to get these issues fixed
[00:30:04] <sbryzak> it helps both of us
[00:30:17] <mojavelinux> basically, we take the high road
[00:30:18] <sbryzak> that's why i think a compatibility suite is a good idea
[00:30:24] <sbryzak> to cover stuff the tck has missed
[00:30:38] <sbryzak> i'm even tempted to create a new seam compatibility module
[00:30:44] <sbryzak> which purely contains tests
[00:30:57] <sbryzak> mojavelinux: what do you think
[00:32:17] <mojavelinux> I think it's a good idea, and it's sort of the guerilla approach i've taken with the solder compat package
[00:32:29] <sbryzak> right, let's do it then
[00:32:31] <sbryzak> i'll get it set up
[00:32:36] <mojavelinux> excellent!
[00:32:40] <sbryzak> mojavelinux: could you please create a new page on sfwk.org
[00:32:48] <sbryzak> with a link in the left hand menu
[00:32:56] <mojavelinux> sure, I'll likely adopt the blog layout
[00:33:01] <mojavelinux> the blog entry layout
[00:33:02] <sbryzak> sounds good
[00:33:03] <mojavelinux> that i used
[00:33:24] <mojavelinux> I think we should call it compatibility
[00:33:35] <mojavelinux> because we could have issues with other environments we need to reference
[00:33:37] <mojavelinux> that page that is
[00:33:47] <sbryzak> ok, but on that page have a big section heading for GF
[00:34:08] <mojavelinux> yep
[00:34:16] <sbryzak> any compatibility tests we have in solder we'll move to the new compatibility module
[00:34:23] <mojavelinux> and of course, we can prominently link to it as "Having GlassFish issues?" sort of thing
[00:34:27] <mojavelinux> yes, move them
[00:34:36] <mojavelinux> also, that allows us to not have to worry about breaking the solder build
[00:34:43] <mojavelinux> while we lay down some tests
[00:34:51] <sbryzak> agreed, it shouldn't be solder's concern to test this stuff
[00:34:52] <mojavelinux> also, we can upgrade to arquillian alpha5 in that module
[00:34:58] <mojavelinux> which will make it easier to use glassfish adapter
[00:34:59] <sbryzak> also agreed
[00:35:04] <mojavelinux> and jsfunit
[00:35:10] <sbryzak> right, first i need coffee
[00:35:11] <mojavelinux> easier to use jsfunit
[00:35:13] <mojavelinux> k
[00:35:33] <mojavelinux> we def need a compatibility test for this @Requires problem
[00:35:35] <mojavelinux> test goes like this
[00:35:48] <mojavelinux> @Requires on package-info.java references class on classpath
[00:35:59] <mojavelinux> inject class into bean in package
[00:36:07] <mojavelinux> do not include injected class in shrinkwrap archive
[00:36:15] <mojavelinux> make sure deployment succeeds
[00:36:54] <mojavelinux> also, use required class in field, as return value of method and perhaps even have a case where a required class is a super class of a class in the bean archive
[00:36:55] *** wdrai1 has quit IRC
[00:37:00] <mojavelinux> all combinations of linking to the required class
[00:37:02] <stuartdouglas> Another test you need is class A extends B
[00:37:07] <stuartdouglas> where B is not present
[00:37:12] <mojavelinux> yep, just cited that last
[00:37:32] <mojavelinux> though I think that is probably a good test to have even for solder
[00:37:42] <mojavelinux> i'll add a jira
[00:39:04] *** jganoff has joined #seam-dev
[00:41:00] *** wdrai has joined #seam-dev
[00:42:59] <mojavelinux> SOLDER-93
[00:43:01] <jbossbot> jira [SOLDER-93] Add more thorough tests for @Requires [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-93
[00:43:10] <jganoff> lazy!
[00:44:54] <mojavelinux> btw, funny to see codi struggle with glassfish too
[00:45:17] <mojavelinux> well, not funny, it's sad, more that at least it's not just us
[00:45:21] <sbryzak> it's ridiculous
[00:45:29] <jganoff> ^^
[00:45:34] <sbryzak> it says to me that no-one is using GF for serious JavaEE development
[00:45:39] <mojavelinux> actually, highlighting that they are having problems helps our position in a way
[00:46:17] <mojavelinux> not that my goal is really to bash GF, that isn't it at all, but I don't think we should have to be taking on all this heat, it's really unfair to us
[00:46:38] <mojavelinux> but such is the current state of affairs
[00:46:40] <sbryzak> up until now we have been taking the heat
[00:47:09] <sbryzak> assuming the onus is on us to make all the workarounds for GF deficiencies
[00:47:24] <sbryzak> but this latest set of issues is insurmountable, there is no workaround
[00:47:37] <mojavelinux> yep, it's gotten to the point where we are out of tricks
[00:47:41] <sbryzak> so we have to put our foot down
[00:47:45] <mojavelinux> or at least tricks we can afford to buy
[00:48:47] <sbryzak> mojavelinux: do we have a url for the new compatibility page yet?
[00:49:14] <sbryzak> i'm guessing it will be sfwk.org/Seam3/Compatibility ?
[00:52:13] <sbryzak> https://github.com/seam/compatibility
[00:52:24] *** jganoff has quit IRC
[00:52:27] <sbryzak> empty so far, i'll start adding to it
[00:56:44] <mojavelinux> voila http://seamframework.org/Seam3/Compatibility
[00:57:06] <sbryzak> perfect
[00:57:07] <mojavelinux> it's mostly just  copy at this point, we can refine it
[00:57:24] <sbryzak> that's fine
[01:00:14] <jbossbot> git [forge] push master 7bec3fb.. Lincoln Baxter, III Remove unnecessary println() on exit
[01:00:14] <jbossbot> git [forge] push master fd68b38.. Lincoln Baxter, III Added prototype XML parser solution. Ability to abort facet installation requests. Improved plugin installation semantics
[01:00:14] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/3e179e7...fd68b38
[01:06:11] <sbryzak> mojavelinux: is the overzealous class scanner issue the one that breaks @Requires ?
[01:06:21] <mojavelinux> yes, it's back
[01:06:32] <mojavelinux> in 3.0.1 it was much worse
[01:06:37] <sbryzak> we need to remove the 'fixed in GlassFish 3.1' note
[01:06:43] <mojavelinux> in 3.0.1, if you had any class on the classpath that referenced one that wasn't, you were dead
[01:06:53] <mojavelinux> in 3.1, it seems that the error occurs for bean candidates
[01:07:16] <mojavelinux> yep, i'll add what I just said
[01:07:21] <sbryzak> k
[01:07:38] <sbryzak> so, for the compatibility suite i'm not sure how to get started
[01:07:46] <sbryzak> i wonder if the QE guys would be best to set this up
[01:09:08] *** kenfinnigan has joined #seam-dev
[01:13:59] <mojavelinux> clarified
[01:15:51] <sbryzak> thanks
[01:18:52] <jbossbot> git [solder] push master 7b4dfcd.. Dan Allen add logmanager version to fix build
[01:18:53] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/c0b1bd5...7b4dfcd
[01:19:27] <sbryzak> mojavelinux: i'll chat to ondrej today about the compatibility suite
[01:19:33] <mojavelinux> great
[01:19:34] <sbryzak> i know that jozef was working on some tests
[01:19:48] <sbryzak> so i'll get them to put all of that stuff in the new module
[01:19:49] <mojavelinux> yeah, he has some tests in the rest module that could get moved there
[01:19:54] <mojavelinux> awesome
[01:20:09] <sbryzak> it will make it much simpler if all of this is in one place
[01:20:16] <sbryzak> just one single set of tests then to test for compatibility
[01:20:52] <sbryzak> could you add a comment to your in.relation.to blog pointing to the new sfwk.org page?
[01:21:06] *** PeteRoyle has quit IRC
[01:21:15] <sbryzak> maybe add a note that we've discovered new issues, and we're currently researching them
[01:24:29] <mojavelinux> doe
[01:24:31] <mojavelinux> done
[01:24:41] <sbryzak> cool
[01:24:53] <sbryzak> i've gotta spend the day writing documentation
[01:24:55] <mojavelinux> we really need a test for that interceptor bug, so perhaps you can mention that to Ondrej and Jozef
[01:25:06] <sbryzak> sure thing
[01:25:07] <mojavelinux> I can pull up the description
[01:25:51] <sbryzak> we should also add instructions to the compatibility page about how to upgrade weld in GF
[01:27:35] <mojavelinux> interceptor goes in jar; class to intercept is in web app; see if that works consistently...interceptor will set a flag on the bean or something; then, if that works every time; then it may be that the problem is with an interceptor steoreotype (interceptor binding on an interceptor binding); you can see it in the seam faces module ConversationBoundaryInterceptor; so worth having two tests
[01:28:25] <sbryzak> i'll raise a jira for it
[01:28:49] <mojavelinux> gotta head out to dinner shortly
[01:29:16] <sbryzak> np, we'll get this sorted out yet ;)
[01:31:30] *** gastaldi has joined #seam-dev
[01:32:06] <gastaldi> hey all
[01:32:34] <kenfinnigan> How's this for 3.0.0.Final issues filter: https://issues.jboss.org/sr/jira.issueviews:searchrequest-printable/12314295/SearchRequest-12314295.html?tempMax=100
[01:32:38] <sbryzak> gastaldi: hey
[01:33:23] <sbryzak> kenfinnigan: can't see your filter
[01:33:30] <sbryzak> "The saved filter you are trying to view no longer exists or you do not have access rights to view it."
[01:33:35] <kenfinnigan> damn it
[01:34:03] <sbryzak> i use this query: project in (SEAM,SEAMCATCH,SOLDER,SEAMXML,SEAMPERSIST,SEAMINTL,SEAMFACES,SEAMREMOTING,SEAMSERVLET,SEAMREST,SEAMVALIDATE,SEAMWICKET,SEAMSECURITY) AND issuetype in standardIssueTypes() AND status = Open and fixVersion="3.0.0.Final" ORDER BY key ASC
[01:35:15] <kenfinnigan> I used: project in (SEAM, SEAMCATCH, SEAMXML, SEAMFACES, SEAMWICKET, SEAMFORGE, SEAMINTL, SEAMJMS, SEAMPERSIST, SEAMREMOTING, SEAMREST, SEAMSECURITY, SEAMSERVLET, SOLDER) AND resolution = Unresolved AND fixVersion <= "3.0.0.Final"
[01:35:22] <kenfinnigan> how do I make it public?
[01:35:29] <kenfinnigan> can't seem to find where that is set
[01:35:46] <sbryzak> there's a "Rename or Share" link
[01:35:49] <sbryzak> i think you can use that
[01:36:13] <kenfinnigan> I clicked that but it seems to only give me the option to rename and add a description
[01:36:30] <sbryzak> hmm, one sec
[01:37:50] <kenfinnigan> looks like I don't have permissions to share filters
[01:38:11] <gastaldi> Can anyone access twitter ?
[01:38:53] <sbryzak> gastaldi: seems to be working
[01:39:05] <sbryzak> kenfinnigan: try this - https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12314291
[01:39:34] <kenfinnigan> yeah I can see that
[01:39:44] <sbryzak> cool
[01:40:20] <kenfinnigan> not sure if mojavelinux mentioned it, but an outcome from today's meeting was to share the link to the filter so that everyone could access the details, as opposed to mailing a snapshot
[01:40:27] <kenfinnigan> is it worth emailing the link to the filter?
[01:40:46] <sbryzak> yeah i'll do that for the next update
[01:40:57] <kenfinnigan> thanks
[01:42:36] <gastaldi> sbryzak: It could be better if this filter is placed on seam 3 front page
[01:42:56] <gastaldi> So whoever enters the site, will find all the issues left for the final release
[01:43:05] <sbryzak> gastaldi: the filter will only be relevant for 3 more days
[01:49:07] <sbryzak> mojavelinux: i don't know if the "Missing typed logger and message bundle implementation classes" issue belongs in the list
[01:49:33] 
[01:49:52] <sbryzak> gastaldi: is that an event class?
[01:49:55] <gastaldi> yes
[01:50:19] <sbryzak> stuartdouglas: ^^^
[01:51:36] <stuartdouglas> it should be part of the api
[01:51:37] 
[01:51:57] <gastaldi> stupid eclipse did not indexed it
[01:52:07] <gastaldi> yeah
[01:52:10] <gastaldi> sorry about that
[01:53:03] 
[01:53:04] <jbossbot> jira [SEAMPERSIST-40] Replace SeamManaged annotation in documentation [Open (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMPERSIST-40
[01:53:25] <gastaldi> Will create a pull request soon
[01:54:17] *** wdrai has left #seam-dev
[01:56:40] *** jose_freitas has joined #seam-dev
[01:56:54] <gastaldi> done
[01:57:18] <gastaldi> https://github.com/seam/persistence/pull/5
[01:58:01] <gastaldi> one step closer to 3.0.0.Final  ! :D
[02:07:42] *** kuuyee has joined #seam-dev
[02:09:21] *** gastaldi has quit IRC
[02:10:21] *** gastaldi has joined #seam-dev
[02:11:03] *** jose_freitas has quit IRC
[02:11:51] *** PeteRoyle has joined #seam-dev
[02:14:14] <kenfinnigan> sbryzak: an action on me from the team meeting was to add the list of modules in the distribution into the readme
[02:14:22] <kenfinnigan> have submitted https://github.com/seam/dist/pull/4 for it
[02:14:44] <sbryzak> kenfinnigan: awesome, thank you
[02:14:54] <kenfinnigan> hopefully I got the list right!
[02:15:15] <jbossbot> git [dist] push master 61b3e16.. Ken Finnigan Provide list of Seam Modules within distribution in the Readme
[02:15:15] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/713be76...61b3e16
[02:15:51] *** aslak has quit IRC
[02:17:41] <sbryzak> looks good to me
[02:18:57] <kenfinnigan> cool
[02:20:45] <gastaldi> Would be a problem if I resolve https://issues.jboss.org/browse/SEAMXML-38 ??
[02:20:46] <jbossbot> jira [SEAMXML-38] Older CDI version specified explicitly [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMXML-38
[02:21:04] <jbossbot> git [international] push master d07919c.. Ken Finnigan SEAMINTL-36 Remove reference to specific Solder version in API
[02:21:05] <jbossbot> jira [SEAMINTL-36] Solder version hardcoded in the API module [Open (Unresolved) Bug, Minor, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-36
[02:21:06] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/c4affd2...d07919c
[02:24:05] *** koentsje has quit IRC
[02:26:48] <gastaldi> SEAMXML-38 done also
[02:26:49] <jbossbot> jira [SEAMXML-38] Older CDI version specified explicitly [Pull Request Sent (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMXML-38
[02:28:46] <gastaldi> Man, GIT surely helped patching projects !
[02:34:17] *** tsurdilo has quit IRC
[02:39:26] <jbossbot> git [international] push master 7ffc747.. Ken Finnigan Update to seam-bom CR9
[02:39:27] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/d07919c...7ffc747
[02:41:10] *** tsurdilo has joined #seam-dev
[02:43:05] <gastaldi> wow, lots of pull requests pending on seam config
[02:43:34] *** johnament has joined #seam-dev
[02:43:51] <gastaldi> seam persistence also
[02:44:12] <gastaldi> hey johnament !
[02:44:21] <johnament> hey
[02:44:33] <johnament> seam bow-and-arrow
[02:44:38] <gastaldi> lol
[02:45:46] <gastaldi> I see that everyone is working hard on this release
[02:47:42] <johnament> definitely
[02:48:08] <kenfinnigan> hey johnament
[02:48:15] <johnament> hey kenfinnigan
[02:48:20] <johnament> i saw you reopened that issue
[02:48:28] <kenfinnigan> yeah, working on it tonight
[02:48:43] <kenfinnigan> have you tried running the example in i18n at all?
[02:49:37] <johnament> kenfinnigan: I ran both my own sample app and nickarls' sample, once i created foo.properties, it worked.
[02:49:50] <johnament> but no, not the provided example
[02:49:55] <kenfinnigan> ok
[02:51:02] 
[02:51:34] <sbryzak> hmm, i didn't think of that
[02:51:49] <johnament> 1/3 of the master list is solder :/
[02:52:00] <johnament> which means we could all run into compatibility issues.
[02:54:15] <gastaldi> Wonder when will my pull requests be merged :P
[02:55:01] <sbryzak> the filter is fixed
[02:55:05] <sbryzak> gastaldi: which pull requests?
[02:55:42] <gastaldi> https://github.com/seam/persistence/pull/5 and  https://github.com/seam/config/pull/5
[02:57:40] <gastaldi> merging that will leave up to 60 issues left
[02:57:45] <gastaldi> :)
[02:57:53] <sbryzak> working on it, one minute
[02:57:57] <gastaldi> nop
[03:00:47] *** bleathem has joined #seam-dev
[03:01:23] <jbossbot> git [persistence] push master 19fe4bb.. George Gastaldi SEAMPERSIST-40: Changed docs and javadocs
[03:01:24] <jbossbot> jira [SEAMPERSIST-40] Replace SeamManaged annotation in documentation [Pull Request Sent (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMPERSIST-40
[03:01:25] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/693e320...19fe4bb
[03:01:47] <johnament> i thought solder was merging api and impl? or was that rejected?
[03:01:51] <gastaldi> great
[03:04:14] <sbryzak> johnament: not that i'm aware of
[03:04:30] <gastaldi> sbryzak: thanks
[03:05:36] <gastaldi> Now only 61 to go !
[03:06:05] <sbryzak> we're on a roll :)
[03:07:17] <johnament> how should i know if someone's working on one that's not assigned?
[03:07:43] <gastaldi> good question
[03:09:40] <gastaldi> maybe the permissions could be changed so that all people who work on Seam modules could assign the issue to himself
[03:10:20] <gastaldi> Like: I have privileges on Seam JCR, but contributed to Seam Persistence, so I could assign an issue to myself
[03:16:12] <bleathem> SEAMFACES-100
[03:16:13] <jbossbot> jira [SEAMFACES-100] Reformat the source code to use the new code format rules [Open (Unresolved) Task, Major, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-100
[03:16:46] <bleathem> Are right Eclipse, this is between you and me!  Let's not let it get ugly, ok?
[03:17:07] * bleathem would have been better if I didn't mis-type that
[03:18:07] *** PeteRoyle has quit IRC
[03:18:30] *** PeteRoyle has joined #seam-dev
[03:19:24] <sbryzak> if you want to work on issues for other modules, ask the module lead to add you as a developer
[03:22:13] <bleathem> How do you get eclipse of a "Building workspace" loop?
[03:22:14] <jbossbot> git [international] push master 3ab39f3.. Ken Finnigan SEAMINTL-35 Remove System.out and replace with logger
[03:22:15] 
[03:22:15] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/7ffc747...3ab39f3
[03:23:36] <bleathem> ^How do you get Eclipse out of a loop "Building workspace" loop
[03:23:44] <bleathem> it just keeps building over and over again
[03:23:57] <stuartdouglas> I fixed it by switching to Intellij
[03:24:36] <bleathem> lol
[03:24:50] <bleathem> I don't have this problem in Netbeas either
[03:24:51] <PeteRoyle> uninstall eclipse, blow on it, and reinstall
[03:25:06] <bleathem> I just want to use the code formatting part of it
[03:25:21] <sbryzak> bleathem: i couldn't get the faces security example working properly
[03:25:31] <bleathem> no?  what went wrong?
[03:25:41] <sbryzak> the secured page doesn't seem to be... secured
[03:26:02] <bleathem> It show you the message that you should never see that page?
[03:26:11] <sbryzak> one sec
[03:26:18] <bleathem> works in Glassfish 3.1, baybe it's an AS 6 compatibility issue :P
[03:26:26] <sbryzak> ah, you didn't test in JBAS?
[03:26:28] <bleathem> I'll give it a try in AS 6 myself shortly
[03:26:34] <bleathem> not yet
[03:26:46] <johnament> stuartdouglas: would you mind adding me to solder in jira?
[03:26:57] <bleathem> I added the example last minute last night
[03:27:38] <stuartdouglas> johnament: whats your user name
[03:28:35] <johnament> stuartdouglas: meetoblivion
[03:28:44] <sbryzak> bleathem: when i click on the first link, it goes to the item.jsf page
[03:28:56] <sbryzak> and displays a message 'A page where you will be asked to login'
[03:29:06] <stuartdouglas> done
[03:29:07] <bleathem> yeah, that's not working then
[03:29:34] <bleathem> I'll take a look
[03:32:21] <johnament> stuartdouglas: tks.  pull requests are a coming.
[03:32:35] <johnament> git doesn't like when pull requests aren't merged.
[03:32:48] <bleathem> rebase first
[03:32:57] <bleathem> keeps the commit history clean
[03:33:07] <bleathem> git pull --rebase
[03:35:20] <bleathem> confirmed, doesn't work on AS 6
[03:35:24] <bleathem> now to find out why
[03:36:31] <bleathem> I love the portability of Java EE - write once, run anywhere!
[03:37:46] <gastaldi> lol
[03:39:30] <bleathem> where is the AS 6 logging configuration?
[03:40:33] *** gastaldi has quit IRC
[03:40:51] <sbryzak> server/default/deploy/jboss-logging.xml
[03:41:20] <bleathem> ty
[03:43:41] <johnament> its like shane just read my mind
[03:44:37] <kenfinnigan> Am I crazy, or should it be possible to inject an @ApplicationScoped bean into a @RequestScoped one?
[03:45:06] <kenfinnigan> SEAMINTL-33 is driving me crazy, and has been for a week!
[03:45:07] <jbossbot> jira [SEAMINTL-33] Injections null when Bundles.get(String) is called [Reopened (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-33
[03:45:12] <sbryzak> kenfinnigan: of course you can
[03:45:19] <kenfinnigan> ok, so not crazy
[03:45:22] <kenfinnigan> just frustrated
[03:46:17] <sbryzak> kenfinnigan: what's the problem?
[03:46:37] <kenfinnigan> I have an arquillian test that sometimes works and sometimes doesn't
[03:46:54] <kenfinnigan> nickarls has raised the problem with some example apps too
[03:47:08] <sbryzak> which test?
[03:47:14] <kenfinnigan> basically a NPE in the Request scoped bean when it tries to access the app scoped one
[03:47:30] <johnament> kenfinnigan: and yet, i still have not been able to reproduce it.
[03:47:34] <sbryzak> is this in AS6?
[03:47:44] <kenfinnigan> org.jboss.seam.international.test.status.BundlesTest
[03:47:45] <kenfinnigan> yes
[03:48:09] <kenfinnigan> the code in git at the moment will work. as I have removed @RequestScoped and @Named from the Bundles class
[03:48:16] <kenfinnigan> trying to add it back in now
[03:48:34] <sbryzak> ah, let me know when it's back in and i'll take a look
[03:48:34] <kenfinnigan> but then the test result becomes especiialy non-deterministic
[03:49:27] <jbossbot> git [international] push master a29f3f0.. Ken Finnigan SEAMINTL-33
[03:49:28] <jbossbot> jira [SEAMINTL-33] Injections null when Bundles.get(String) is called [Reopened (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-33
[03:49:28] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/3ab39f3...a29f3f0
[03:49:32] <kenfinnigan> now back in
[03:50:04] <johnament> mojavelinux: its funny, i was looking for that exact functionality recently.
[03:50:27] <sbryzak> how do i reproduce? just run mvn clean test?
[03:50:33] <kenfinnigan> yes
[03:50:58] <kenfinnigan> might work the first time, but then a subsequent run and it should fail
[03:51:26] <sbryzak> success 3 times in a row so far
[03:51:34] <johnament> :-)
[03:52:32] <johnament> back down to 59
[03:52:33] <bleathem> AS 6 is picking up the annotations, delegating to Security, getting the repsonse, as I see this log message:
[03:52:44] <bleathem> DEBUG [org.jboss.seam.faces.view.config.SecurityPhaseListener] Access denied - not logged in
[03:52:59] <bleathem> It must just be the jsf navigation that's not kicking in
[03:53:02] <kenfinnigan> damn it!
[03:53:03] <sbryzak> kenfinnigan: no failures yet after 10 times
[03:53:13] <sbryzak> kenfinnigan: can you still reproduce?
[03:53:29] <bleathem> phewf, that should at least be easy to fix - didn't want to dive back into all that annotation processing again tonight!
[03:53:34] <sbryzak> bleathem: that sounds like an easy fix
[03:53:43] <kenfinnigan> yes
[03:54:01] <sbryzak> kenfinnigan: what's your environment?
[03:54:10] <kenfinnigan> windows, eclipse
[03:54:25] <kenfinnigan> running the default profile, which I think is weld ee embedded for tests
[03:54:41] <kenfinnigan> mvn 3.0.2
[03:54:45] <sbryzak> you're running the tests in eclipse?
[03:54:53] <kenfinnigan> that and command line
[03:55:06] <sbryzak> does it fail from the command line?
[03:55:08] <kenfinnigan> eclipse seems to succeed first time, mvn on command line always fails
[03:55:26] <sbryzak> try mvn -U clean test
[03:55:34] <kenfinnigan> ok
[03:55:53] <kenfinnigan> what's the -U for?
[03:56:03] <sbryzak> force updates
[03:56:10] <sbryzak> it will take a bit longer
[03:56:12] <kenfinnigan> still fails
[03:56:54] <sbryzak> hmm, intriguing
[03:56:59] <sbryzak> which version of java?
[03:57:29] <kenfinnigan> 1.6.0_20
[03:57:40] <sbryzak> same as mine
[03:57:45] <sbryzak> and i'm using the same maven
[03:57:48] <kenfinnigan> 64 bit o/s, but 34 bit jdk
[03:57:57] <sbryzak> only difference is OS, i'm running linux
[03:58:02] <kenfinnigan> weird
[03:58:10] <kenfinnigan> nickarls also has the same problem
[03:58:15] <kenfinnigan> not sure what env he is using
[03:58:21] <kenfinnigan> but I know he was deploying to AS6
[03:58:37] <sbryzak> back in a few minutes
[03:58:57] *** gastaldi has joined #seam-dev
[04:00:06] <bleathem> doh, it is working!
[04:00:34] <johnament> so it works on linux (shane and i) but not on windows (ken, maybe nicklas?)
[04:00:40] <bleathem> sbryzak, you are seeing what you are supposed to see: perhaps a sign of bad wording choice on my part...
[04:00:54] <bleathem> item.xhtml contains: A page showing the item, you will never be allowed to see it.
[04:01:03] <bleathem> login.xhtml contains: A page where you will be asked to login
[04:01:21] <bleathem> so, "working as designed" as IBM always says to me
[04:01:25] <kenfinnigan> nickarls: are you about?
[04:03:30] <sbryzak> bleathem: when i click the protected link, the url displays item.jsf and the message says "A page where you will be asked to login"
[04:03:42] <bleathem> that's correct
[04:03:45] <gastaldi> is there an IRC channel related to jboss jobs ?
[04:03:54] <sbryzak> ah, so it is working then?
[04:03:57] <bleathem> I didn't put a faces-redirect=true in the rewrite rule
[04:04:09] <bleathem> yeah, if it wasn't yo'd see: A page showing the item, you will never be allowed to see it.
[04:04:11] <sbryzak> ah, that makes sense then
[04:04:21] <bleathem> bad wording on my part
[04:04:32] <bleathem> I should have at least put an input box, so it looked like a log in page!
[04:04:37] <sbryzak> we should add a login form to that example so the user can log in and see the protected page
[04:04:46] <bleathem> agreed.
[04:04:57] <bleathem> it was very much last minute, last night - I was exhausted
[04:05:27] <bleathem> What't the simples authentication to configure?
[04:05:28] <sbryzak> no problem, it's a good start :)
[04:05:33] <bleathem> ^simplest
[04:05:45] <bleathem> file based I imagine...
[04:05:46] <sbryzak> bleathem: look at the simple example in the security module
[04:05:52] <bleathem> ok, will do!
[04:05:59] <johnament> down to 58
[04:06:07] <bleathem> I want to knock of seamfaces-100 first tho
[04:12:12] 
[04:12:28] <jbossbot> git [faces] push master 07c8e28.. Brian Leathem Added debug log statements to SecurityPhaseListener
[04:12:29] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/10a8b5a...07c8e28
[04:13:34] <bleathem> gastaldi that's why I'm using eclipse for that!  Netbeans doesn't support multi file formatting.
[04:13:49] <gastaldi> any luck on SEAMFACES-112 ?
[04:13:50] <jbossbot> jira [SEAMFACES-112] Store the requested view id and view params when redirecting a user to log in [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-112
[04:14:16] <gastaldi> +1 to Eclipse ! :)
[04:14:47] <bleathem> puts the score at about 1372 to 1 - at least it's no longer a shutout!
[04:15:06] 
[04:15:15] <johnament> stuartdouglas: what do you think about DelegatingResourceLoader being singleton, to be within scope of other resource loaders within a single app? SOLDER-2
[04:15:16] <jbossbot> jira [SOLDER-2] Rework ServletContextResourceLoader to not rely on static for registration [Open (Unresolved) Bug, Blocker, Unassigned] https://issues.jboss.org/browse/SOLDER-2
[04:15:53] <stuartdouglas> ServletContextResourceLoader is broken in most cases anyway
[04:16:17] <stuartdouglas> as weld starts before the servlet context is created
[04:17:12] <stuartdouglas> in some cases you can change the order
[04:17:23] <stuartdouglas> so that the servlet context starts first
[04:17:29] <stuartdouglas> (e.g. weld-servlet)
[04:17:57] <stuartdouglas> but then when the SC is created weld is not initalized, so the only place you can stash the ServletContext reference is a static
[04:18:52] <gastaldi> egg and chicken problem ?
[04:18:55] <stuartdouglas> and this is the main reason why seam-config can't read beans.xml from WEB-INF in a portable way
[04:18:59] <stuartdouglas> pretty much
[04:27:54] <johnament> grrr yeah.
[04:29:18] *** gastaldi has quit IRC
[04:31:23] <bleathem> reformatted the java code, and everything still builds.  w00t!
[04:31:23] *** johnament has quit IRC
[04:32:31] <jbossbot> git [faces] push master c5afc14.. Brian Leathem SEAMFACES-100 Reformat the source code to use the new code format rules
[04:32:33] <jbossbot> jira [SEAMFACES-100] Reformat the source code to use the new code format rules [Open (Unresolved) Task, Major, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-100
[04:32:33] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/07c8e28...c5afc14
[04:32:50] <bleathem> Let us take a moment to mark the passing of the old formatting style in Seam Faces
[04:33:07] <bleathem> Those aligned braces sure will be missed
[04:33:16] <bleathem> well, not really
[04:35:33] <jbossbot> git [faces] push master a91e750.. Brian Leathem SEAMFACES-100 Reformat the source code to use the new code format rules - missed one
[04:35:34] <jbossbot> jira [SEAMFACES-100] Reformat the source code to use the new code format rules [Resolved (Done) Task, Major, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-100
[04:35:34] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/c5afc14...a91e750
[04:36:30] <kenfinnigan> sbryzak: should I continue trying to resolve seamintl-33, as it is really sending me round the twist!
[04:36:45] <kenfinnigan> given it works on yours
[04:37:38] <sbryzak> hmm
[04:37:50] <kenfinnigan> just checked hudson
[04:37:52] <sbryzak> i'd like to know more about nik's environment
[04:37:56] <kenfinnigan> even it passed with the current code!
[04:37:57] <bleathem> I want to configure the Netbeans code formatter.  Anyone have a link to what the formatting rules are?
[04:38:05] <bleathem> I know Dan and Jason have it moemorized...
[04:38:09] <sbryzak> see if we can find some commonality
[04:38:20] <sbryzak> kenfinnigan: remove the fix version for now
[04:38:25] <sbryzak> but leave the issue open
[04:38:32] <kenfinnigan> bleathem: should be in dist module
[04:38:42] <kenfinnigan> sbryzak: will do
[04:39:17] <bleathem> kenfinnigan there is a README there, thx!
[04:39:21] <kenfinnigan> bleathem: sorry on two counts
[04:39:29] <kenfinnigan> formatters are in build
[04:39:37] <kenfinnigan> but there only appears to be ones for eclipse and idea
[04:39:48] <bleathem> it's ok, I knew what you meant
[04:39:53] <kenfinnigan> lol
[04:39:54] <bleathem> I didn't see the readme before
[04:40:00] <bleathem> I'm building the Netbeans one now
[04:40:06] <kenfinnigan> cool
[04:40:09] <bleathem> First step in converting y'all!
[04:41:18] <jbossbot> git [international] push master fbf594c.. Ken Finnigan SEAMINTL-33
[04:41:19] <jbossbot> jira [SEAMINTL-33] Injections null when Bundles.get(String) is called [Reopened (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-33
[04:41:20] <jbossbot> git [international] push master URL: http://github.com/seam/international/compare/a29f3f0...fbf594c
[04:44:32] <bleathem> Hmm, Netbeans doesn't have an option to export just the formatting rules
[04:44:43] <bleathem> and the only option I needed to change was the line length.
[04:44:55] <bleathem> Probably not worth  messing around with
[04:45:20] <bleathem> The new Seam style is so closely aligned with the default
[04:45:41] *** kenfinnigan has quit IRC
[05:19:31] <bleathem> well, I did it anyways.  I exported the netbeans config to a zip file, and removed everything except the bit that sets the line length
[05:21:41] <bleathem> pull request on build
[05:22:19] <bleathem> mojavelinux: pull request on build
[05:35:05] <jbossbot> git [faces] push master 23e2210.. joserodolfofreitas Added documentation for InputElement
[05:35:05] <jbossbot> git [faces] push master 18318b4.. Brian Leathem Some wording changes
[05:35:05] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/a91e750...18318b4
[05:37:26] *** tsurdilo has quit IRC
[05:43:32] *** Diablo-D3 has joined #seam-dev
[05:45:55] <bleathem> sbryzak, how do I get the user in my @Secure method?  Do I inject an parameter in the method?
[05:46:17] <sbryzak> you can inject the Identity into the method parameters, or as a bean field
[05:46:28] <bleathem> thx
[05:47:59] <bleathem> here goes nothing
[05:54:37] <bleathem> this isn't going to work on glassfish is it...
[06:03:48] <Diablo-D3> http://www.zdnet.com/blog/btl/red-hat-nearing-1-billion-in-revenue-not-bad-for-free-software/46445
[06:03:59] <jbossbot> git [dist] push master 4a35ac3.. Shane Bryzak remove JMS module from module list
[06:03:59] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/61b3e16...4a35ac3
[06:04:14] <Diablo-D3> I dont care if the url is zdnet, I can finally tell all the anti-FOSS assholes who say FOSS cant make money to go shove it up their ass
[06:04:38] <bleathem> org.jboss.seam.security.AuthenticationException: Authenticator must return a valid authentication status
[06:04:55] <sbryzak> bleathem: pastebin your authenticator?
[06:05:04] <bleathem> this is on glassfish
[06:05:06] <mojavelinux> you guys are freakin'  hilarious...don't know why I even pay for cable
[06:05:11] <bleathem> is theis the problem you were talking abou tlater?
[06:05:21] <mojavelinux> oh yeah, so I can have internet and read this channel :)
[06:05:25] <bleathem> pastie incoming
[06:05:31] <bleathem> lol mojavelinux
[06:06:00] <bleathem> http://pastie.org/1706968
[06:06:07] <bleathem> ^sbryzak
[06:06:16] <sbryzak> looking now
[06:06:36] <sbryzak> authenticate() must set a status
[06:06:44] <bleathem> I copy/pasted it from the simple security example
[06:06:51] <bleathem> I don't actually know what I'm doing :P
[06:07:04] <sbryzak> so thanks for finding a bug in the security example ;)
[06:07:18] <bleathem> lol - way to look on the bright side!
[06:07:47] <sbryzak> pastie doesn't let me edit
[06:07:56] <bleathem> does pastebin?
[06:08:01] <sbryzak> i think so
[06:08:34] <mojavelinux> gist is really the best
[06:08:35] <sbryzak> it has a 'create new version of this paste' link
[06:08:40] <mojavelinux> a gist you can actually checkout with git
[06:08:42] <mojavelinux> :)
[06:08:50] <bleathem> http://pastebin.com/taJKEcx4
[06:08:50] <mojavelinux> gist.github.com
[06:09:05] <sbryzak> this should work: http://pastie.org/1706972
[06:09:15] <mojavelinux> ah, with pastie
[06:09:20] <mojavelinux> you can click "Paste again" to edit
[06:09:29] <bleathem> https://gist.github.com/884607
[06:09:32] <mojavelinux> not exactly intuitive, especially if you weren't the one that pasted originally
[06:09:57] <mojavelinux> it's sort of like getting an e-mail and to reply you click "send e-mail again"
[06:10:01] <jbossbot> git [security] push master 3f972c8.. Shane Bryzak ensure status is set
[06:10:01] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/7c53dcf...3f972c8
[06:10:13] <sbryzak> mojavelinux: agreed :)
[06:10:27] <mojavelinux> omg, I almost fell on the floor
[06:10:37] <bleathem> pastie is gist like jedit is to eclipse
[06:10:53] <bleathem> forgot a to in there
[06:12:13] <mojavelinux> sort of like cvs is to git like crawling is to flying
[06:12:33] <bleathem> flying first class
[06:12:42] <mojavelinux> my last joke was better -> "send e-mail again"
[06:13:43] <bleathem> sbryzak, do you have a new pastie for me?
[06:14:01] <sbryzak> yeah, i pasted it about 10 lines up
[06:14:07] <bleathem> lol
[06:14:15] <bleathem> too busy reading mojavelinux's jokes!
[06:16:37] <bleathem> weird
[06:16:56] <bleathem> the viewId for the page I'm viewing is wrong
[06:18:18] <bleathem> something is wrong here
[06:18:48] <Diablo-D3> ye gods, Ive somehow spread my problems to the rest of the channel
[06:18:49] <mojavelinux> i've got a good feature for jboss tools
[06:18:51] <mojavelinux> you create an interceptor
[06:19:02] <mojavelinux> then you get a code completion to create an AroundInvoke method
[06:21:34] <bleathem> securing pages is easier when you don't let people log in
[06:24:12] <bleathem> sbryzak, I don't think my @Secures method is getting invoked
[06:24:43] <bleathem> http://pastie.org/1706996
[06:25:01] <bleathem> none of my messages are showing up in the output
[06:25:21] <sbryzak> check it in and i'll take a look
[06:32:59] <mojavelinux> haha!
[06:33:00] <mojavelinux> yes!
[06:33:07] <mojavelinux> I proved the interceptor problem with an arquillian test
[06:33:17] <sbryzak> mojavelinux: awesome
[06:33:18] <mojavelinux> hmm, only problem is, you have to run it manually until you see it fail
[06:33:34] <mojavelinux> but literally, I have this test doing basic interceptor enablement
[06:33:35] <sbryzak> you mean it doesn't fail first time?
[06:33:39] <mojavelinux> and the fifth time, it just failed
[06:33:46] <mojavelinux> then two times it worked
[06:33:49] <mojavelinux> then failed again
[06:33:52] <mojavelinux> wow
[06:33:57] <sbryzak> is this in GF?
[06:34:01] <mojavelinux> unreal...I'm going to see how I can get this to repeat
[06:34:02] <mojavelinux> yep
[06:34:10] <sbryzak> wow, nicely done
[06:34:12] <mojavelinux> I'll run it 20 times if I can configure it as such
[06:34:40] <mojavelinux> ah!
[06:34:42] <mojavelinux> a test suite
[06:35:22] <sbryzak> this is exactly what we need, something solid before we start blaming GF
[06:40:49] <mojavelinux> wow, I ran it once
[06:40:53] <mojavelinux> 9 failures, 1 success
[06:41:00] <mojavelinux> ran it again, 7 failures, 3 success
[06:41:08] <mojavelinux> ran it again, 1 failure, 9 success
[06:41:11] <sbryzak> i'm a bit concerned about the randomness
[06:41:12] <mojavelinux> cool
[06:42:07] <mojavelinux> it hasn't hit 10 in a row, so it seems like 10 is enough
[06:42:10] <sbryzak> are you going to add this to the compatibility module?
[06:42:14] <mojavelinux> actually, I should be like an engineer and double it
[06:42:19] <mojavelinux> yep
[06:42:24] <sbryzak> or a german engineer, and quadruple it
[06:42:50] <bleathem> git is cool, but you can really screw a clone up something fierce
[06:43:35] <bleathem> git is a really big gun with few warnings about pointing it at your face
[06:47:16] <mojavelinux> but the nice part is, if you shoot yourself, you can still reverse the process and put the bullet back in the gun
[06:47:32] <bleathem> yeah because you are working on a clone
[06:47:49] <mojavelinux> even with upstream
[06:47:58] <bleathem> mojavelinux, problem with applying security on postback, until invoke application, the current viewId is "wrong"
[06:48:15] <mojavelinux> you have full control over the history, though then you can erase it and that's like shooting off your nuts
[06:49:13] <mojavelinux> ah
[06:49:24] <mojavelinux> you are correct my dear watson
[06:49:46] <mojavelinux> you need two security checks then
[06:49:51] <bleathem> yeah
[06:50:16] <bleathem> or, *always* check security before render response
[06:50:32] <mojavelinux> actually, we could look at it as three options
[06:50:34] <mojavelinux> there is initial
[06:50:37] <mojavelinux> there is postback
[06:50:42] <mojavelinux> and then there is forward
[06:50:51] <mojavelinux> because this is sort of like an internal forward in jsp
[06:51:07] <bleathem> but every page navigation is a forward
[06:51:16] <mojavelinux> yep, so the security is being applied on navigation
[06:51:52] <mojavelinux> could you argue that you wouldn't want security at that point?
[06:52:09] <bleathem>  no, I think we always want security at that point
[06:52:37] <bleathem> one can optionally apply security earlier, to save cycles, but it should always be applied pre render
[06:53:14] <bleathem> no, that's not right either, because we want to guard against side-effects
[06:53:50] <mojavelinux> okay, so we have two options
[06:54:01] <mojavelinux> either we see three security points
[06:54:11] <mojavelinux> initial, navigate, postback
[06:54:20] <mojavelinux> or, there are two options for a postback
[06:54:24] <mojavelinux> like
[06:54:39] <mojavelinux> initial = RESTORE_VIEW, postback = { INVOKE_APPLICATION, RENDER_RESPONSE }
[06:54:51] <mojavelinux> btw, you don't have to check security if the viewRoot doesn't change
[06:54:56] <bleathem> right
[06:55:04] <mojavelinux> because in that case, you would have already done it in INVOKE_APPLICATION
[06:55:10] <mojavelinux> though I suppose state could change
[06:55:14] <mojavelinux> and then you should check again
[06:55:15] <bleathem> true
[06:55:21] <mojavelinux> like if you disable view permission to an object
[06:55:22] <bleathem> you could have selected a different item
[06:55:24] <mojavelinux> then you can't render it
[06:55:46] <mojavelinux> it would be sort of a dumb user interface if that happened, but it is a security check
[06:55:59] <bleathem> no one writes dumb user interfaces!
[06:56:31] <bleathem> I think we should just always apply security pre render
[06:56:46] <bleathem> in addition to the configurable earlier check
[06:56:52] <mojavelinux> hmmm
[06:57:42] <bleathem> You wouldn't secure a view unless you didn't want it to not render when security is violated
[06:57:52] <bleathem> that is a garbage sentence
[06:58:15] <Diablo-D3> hey guys
[06:58:18] <mojavelinux> i'm not questing the default
[06:58:20] <Diablo-D3> what could cause something like
[06:58:21] <mojavelinux> i'm just questing the control
[06:58:25] <Diablo-D3> 01:55:54,002 ERROR [org.jboss.seam.security.IdentityImpl] Login failed: java.lang.RuntimeException: java.lang.NullPointerException
[06:58:25] <Diablo-D3> 	at org.jboss.seam.security.IdentityImpl.authenticate(IdentityImpl.java:324) [:3.0.0.CR3]
[06:58:41] <mojavelinux> that's SEAMSECURITY-42
[06:58:43] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42
[06:59:34] <bleathem> so "navigate" is the control of whether or not you want to apply security pre render?
[06:59:52] <Diablo-D3> Im not on glassfish, btw
[07:00:10] <mojavelinux> it's still the same issue though
[07:00:15] <mojavelinux> Messages bean is not found
[07:00:20] <Diablo-D3> hrm
[07:00:25] <mojavelinux> likely because seam-international.jar is not present
[07:00:40] <Diablo-D3> hrm
[07:00:41] <mojavelinux> if it is present, interesting that this isn't just a GF issue
[07:00:41] <bleathem> nitial = {RESTORE_VIEW | NVOKE_APPLICATION | RENDER_RESPONSE}, postback = {RESTORE_VIEW | NVOKE_APPLICATION | RENDER_RESPONSE}, navigate = {YES|NO}
[07:00:49] <Diablo-D3> I dont think its present
[07:01:05] <Diablo-D3> maven is putting seam-security-external, seam-servlet, and seam-solder into my war
[07:01:09] <mojavelinux> what's the annotation again?
[07:01:09] <bleathem> initial = {RESTORE_VIEW | INVOKE_APPLICATION | RENDER_RESPONSE}, postback = {RESTORE_VIEW | INVOKE_APPLICATION | RENDER_RESPONSE}, navigate = {YES|NO}
[07:01:23] <mojavelinux> that was for brian
[07:02:28] <bleathem> oh
[07:02:30] <bleathem> ok
[07:02:31] <bleathem> hold on
[07:02:38] <bleathem> RestrictAtView
[07:02:43] <Diablo-D3> I have seam-bom in my dependency management, and seam-security and seam-security-external in the deps
[07:03:04] <Diablo-D3> so if I need international, shouldnt it be pulling it in?
[07:03:20] <mojavelinux> RestrictAsPhase
[07:03:39] <mojavelinux> that's a good question, why no transitive on seam-international
[07:03:45] <mojavelinux> RestrictATPhase
[07:03:49] <mojavelinux> RestrictAtPhase
[07:03:51] <mojavelinux> yeah!
[07:03:52] <bleathem> yes, sorry
[07:04:23] <mojavelinux> RestrictAtPhase(duringInitial = {}, duringPostback = {}, onNavigation = true)
[07:04:25] <mojavelinux> would that work?
[07:04:28] <sbryzak> Diablo-D3: that might be my mistake, you can explicitly declare it as a dependency for the time being
[07:05:44] <bleathem> yes
[07:05:48] <bleathem> default is true
[07:05:51] <bleathem> wait
[07:06:05] <mojavelinux> though, if you have multiple options, onNavigation really isn't needed
[07:06:17] <bleathem> does the onNavigation apply to the view you are navigating from, or when you are navigating to that view
[07:06:20] <Diablo-D3> whats the groupid for that
[07:06:23] <mojavelinux> oh, yes it would be
[07:06:29] <mojavelinux> because here is the proposed logic
[07:06:48] <sbryzak> Diablo-D3: org.jboss.seam.international:seam-international
[07:07:50] <bleathem> sbryzak: String id = identity.getUser().getId(); gives an NPE (identity is not null).  Is there some better way to get the username?
[07:08:22] <sbryzak> that should give it to you
[07:08:33] <mojavelinux> @RestrictAtPhase(onPostback = INVOKE_APPLICATION, onNavigate = true) would check the security again if a navigation occurs on a postback
[07:08:36] <sbryzak> is the user authenticated?
[07:08:54] <bleathem> right, not yet!
[07:08:57] * bleathem facepalm
[07:09:06] <mojavelinux> @RestrictAtPhase(onPostback = { INVOKE_APPLICATION, RENDER_RESPONSE }, onNavigate = true) would check the security again even if no navigation occurs
[07:09:09] <sbryzak> if they're not authenticated, there's no user
[07:09:12] <Diablo-D3> grr, somethings being dumb
[07:10:14] <mojavelinux> hmm, I guess we could have another phase actually
[07:10:22] <Diablo-D3> oh
[07:10:23] <mojavelinux> NAVIGATE
[07:10:25] <Diablo-D3> goddamnit eclipse
[07:10:26] <mojavelinux> so like this
[07:10:29] <Diablo-D3> I think its screwing me
[07:10:55] * bleathem following along mojavelinux
[07:11:28] <Diablo-D3> without the explicit international dep
[07:11:29] <mojavelinux> @RestrictAtPhase(onPostback = { INVOKE_APPLICATION, HANDLE_NAVIGATION, RENDER_RESPONSE }
[07:11:31] <Diablo-D3> mvn clean package
[07:11:39] <Diablo-D3> ls -al target/DiabloPool/WEB-INF/lib/
[07:11:51] <Diablo-D3> so it IS in there
[07:11:53] <Diablo-D3> when mvn builds it
[07:12:25] <mojavelinux> handle navigation is sort of a pseudo phase
[07:12:32] <bleathem> ok, but the HANDLE_NAVIGATION makes sense for the view you are navigating to, so it's indepenent of the other two, wehre they apply to the view you are navigating from
[07:12:34] <mojavelinux> it's whenever a navigation takes place
[07:12:39] <Diablo-D3> but if I use the servers tab in eclipse, and press the arrow for my project, it only shows four jars
[07:12:48] <bleathem> I think we can simplify
[07:12:52] <mojavelinux> oh yeah
[07:12:54] *** stuartdouglas has quit IRC
[07:13:07] <mojavelinux> yeah, this is where seam 2 messed up too btw
[07:13:07] <bleathem> wehn we navigate to a new view, look at that view, and see if it's configured for pre_render
[07:13:19] <bleathem> if so, apply security
[07:13:24] <bleathem> if not, move on
[07:13:29] <mojavelinux> wait, I think i've got it
[07:13:33] <mojavelinux> close to what you said
[07:13:43] <mojavelinux> navigating to a view is really another type of request for a view
[07:13:48] <mojavelinux> because it's like an initial request
[07:13:51] <bleathem> yes
[07:13:53] <mojavelinux> which is tied to the end of a postback
[07:13:57] <mojavelinux> so, perhaps
[07:13:59] <mojavelinux> we have
[07:14:09] <mojavelinux> onInitial, onPostback, onNavigate
[07:14:16] <mojavelinux> where navigate is navigation to that view during a postback
[07:14:43] *** stuartdouglas has joined #seam-dev
[07:14:57] <Diablo-D3> Goddamnit.
[07:14:57] <mojavelinux> or
[07:15:00] <Diablo-D3> ls -al ~/Workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1299437663993/deploy/DiabloPool.war/WEB-INF/lib/
[07:15:08] <mojavelinux> we can consider navigation to a view as an initial request for that view
[07:15:25] <mojavelinux> i'm torn a bit between simplicity and control
[07:15:35] <bleathem> i have a gut feeling towards keeping it simpler, but ...
[07:15:40] <bleathem> you took the words out of my mouth
[07:15:52] <Diablo-D3> you mean between osx and linux.
[07:15:53] * Diablo-D3 snickers
[07:16:15] <Diablo-D3> btw, I wonder if Im just coding this wrong
[07:16:25] <bleathem> what would be a use case for securing a page on initial request, but not on navigation to
[07:16:31] <sbryzak> stuartdouglas: could you please bump any solder issues that we can't fix for 3.0.0.Final
[07:16:35] <bleathem> or vice versa
[07:16:48] <Diablo-D3> Im trying to figure out which parts of the openid-rp example I need to get auth from openid
[07:16:54] <bleathem> if we keep it simple, we can make it more complex if needed - but we can't go the other way
[07:17:05] <bleathem> once it's out there, we should probably keep supporting it
[07:17:18] <Diablo-D3> I dont think whats in Login.xhtml is enough
[07:17:30] <Diablo-D3> plus the stuff for beans.xml
[07:17:44] <bleathem> Can we keep this feature as beta when we release, warn poeple the API might change in this area?
[07:18:18] <mojavelinux> so the reasoning for the control is multi-faceted
[07:18:52] <mojavelinux> 1. to not apply security excessively (wasting cycles)
[07:19:06] <mojavelinux> 2. to not apply security at the wrong time (annoying the developer designing the app)
[07:19:44] <mojavelinux> 3. to not get in the way of the developer because they can't stop security from being applied in a case (sort of like #2)
[07:19:45] <Diablo-D3> hey bleathem, mojavelinux
[07:19:48] <Diablo-D3> can one of you do me a favor?
[07:19:58] <Diablo-D3> deploy the openid-rp example and try to login with it
[07:20:21] <bleathem> right, those are good reasons
[07:20:37] <sbryzak> Diablo-D3: what's the problem?
[07:20:45] <Diablo-D3> I wanna know if it actually works.
[07:20:51] <sbryzak> it does
[07:20:56] <sbryzak> did you put the entries in your hosts file?
[07:21:14] <Diablo-D3> sbryzak: WHICH parts of the example do I need to copy
[07:21:19] <jbossbot> git [faces] push master fc52b04.. Brian Leathem Introduced simple authentication to the security example
[07:21:19] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/18318b4...fc52b04
[07:22:01] *** stuartdouglas has quit IRC
[07:22:06] <bleathem> sbryzak: Authentication is in the faces/security example app, but there is Faces integration issue to be worked out
[07:22:07] <sbryzak> there's not much to it really
[07:22:12] <bleathem> it will still work
[07:22:15] <sbryzak> you basically need to copy the three classes that are there
[07:22:20] <sbryzak> and modify them for your application
[07:22:20] <mojavelinux> I think if we stick to a two-prong approach, that's best
[07:22:27] <Diablo-D3> because I copied whats in beans.xml, seam-beans.xml, and login.xhtml
[07:22:37] <mojavelinux> we have two types of request, we just want to know when to apply security depending on request type
[07:22:37] <Diablo-D3> the login page displays, it gives me a list of openid providers
[07:22:43] <bleathem> mojavelinux, I'm burnt out form this week, and I'm sure I would think better on this with a fresh head
[07:22:51] <bleathem> can we pick up on this in the morning?
[07:22:55] <mojavelinux> sure
[07:22:57] <Diablo-D3> sbryzak: so THAT part works
[07:22:58] <sbryzak> Diablo-D3: you need Configuration, OpenIdRelyingPartyCustomizer and OpenIdRelyingPartySpiImpl
[07:23:00] *** daniel_hinojosa has quit IRC
[07:23:05] <mojavelinux> might want to see what lincoln has to say
[07:23:11] <Diablo-D3> sbryzak: what do those classes do? I cant see anywhere those are plugged in
[07:23:11] <bleathem> good call
[07:23:13] <mojavelinux> maybe an e-mail would be best
[07:23:30] <bleathem> Ill send one out first thing in the morning
[07:23:44] <sbryzak> the Configuration class is required by the openid api
[07:24:12] <sbryzak> OpenIdRelyingPartyCustomizer has an event observer which configures the OpenIdRelyingPartyConfigurationApi
[07:24:36] <sbryzak> you don't need that class exactly, but you do need an event observer somewhere in your app that configures the domain name, port, etc
[07:25:34] <sbryzak> and then OpenIdRelyingPartySpiImpl is required for the authentication process to complete, and to redirect the user depending on whether login was successful or not
[07:25:35] <bleathem> I'm sure this will be less muddled for me after a nights sleep.
[07:25:35] <bleathem> just too long a week
[07:25:35] <bleathem> I hope we don't do a Seam 3 release every week, I won't make it to 35!
[07:25:38] <bleathem> k, night all!
[07:25:49] <sbryzak> night Brian
[07:26:25] <Diablo-D3> night bleathem
[07:26:29] *** stuartdouglas has joined #seam-dev
[07:26:37] <Diablo-D3> sbryzak: okay, I see that file, and it does a unch of rp.setFoos
[07:26:58] <Diablo-D3> sbryzak: how do I set these in a way that makes sense
[07:27:02] *** bleathem has quit IRC
[07:27:21] <sbryzak> what do you mean?
[07:28:01] <Diablo-D3> well, why do I need to set them at all?
[07:28:03] *** jharting has joined #seam-dev
[07:28:09] <Diablo-D3> who consumes that information
[07:28:40] <sbryzak> because when you send your user to google to authenticate, google needs to redirect them back to your app somehow
[07:29:01] <Diablo-D3> so why isnt it just a url I fill in?
[07:29:36] <sbryzak> it effectively is
[07:29:44] <sbryzak> hostname, port and protocol does specify a url
[07:31:16] <Diablo-D3> so, basically, if I want to deploy this app on other people's machines, I need some way in my app to configure how my app is accessed from the outside world?
[07:31:22] <Diablo-D3> theres no way to query the container for this?
[07:34:35] <sbryzak> yes
[07:35:04] <sbryzak> the container doesn't necessarily know
[07:38:14] <jbossbot> git [compatibility] push master 31c71bf.. Dan Allen add test for interceptor enablement...
[07:38:14] <jbossbot> git [compatibility] push master URL: http://github.com/seam/compatibility/compare/bcb40a9...31c71bf
[07:38:22] <mojavelinux> voila
[07:38:23] <mojavelinux> test is live
[07:38:42] <sbryzak> cool
[07:38:44] <sbryzak> how do i run it?
[07:38:57] <mojavelinux> ah, hmm
[07:39:05] <mojavelinux> I need to upgrade to arquillian 1.0.0.Alpha5
[07:39:07] <mojavelinux> let me do that
[07:44:51] <Diablo-D3> sbryzak: okay, so, is there an accepted way for webapps to configure themselves?
[07:45:01] *** mgencur has joined #seam-dev
[07:45:04] <sbryzak> i recommend using seam-config
[07:48:26] <nickarls> sbryzak: windows 7 64bit on a 1.6.0_23 64bit
[07:48:59] <nickarls> SEAMINTL-33 is sooo strange
[07:49:05] <jbossbot> jira [SEAMINTL-33] Injections null when Bundles.get(String) is called [Reopened (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-33
[07:49:06] <sbryzak> nickarls: hmm, i wonder if it's to do with windows then
[07:49:17] <sbryzak> how can we rid the world of this evil
[07:49:23] <jbossbot> git [compatibility] push master 13ad007.. Dan Allen upgrade to Arquillian 1.0.0.Alpha5
[07:49:23] <jbossbot> git [compatibility] push master URL: http://github.com/seam/compatibility/compare/31c71bf...13ad007
[07:49:24] <mojavelinux> cool!!!
[07:49:33] <mojavelinux> we are now on arquillian 1.0.0.Alpha5 for compat tests
[07:49:42] <mojavelinux> that means the world can actually run them now on glassfish
[07:49:42] <mojavelinux> yeah
[07:49:51] <sbryzak> mojavelinux: nice, are the instructions? :)
[07:49:52] <mojavelinux> mvn clean install -Ditest-container=glassfish-remote
[07:49:54] <nickarls> the strangest think is that I couldn't make it fail on weld trunk arq-tests
[07:49:59] <sbryzak> trying it now
[07:50:05] <nickarls> but it fails in an AS with updated Weld
[07:50:10] <mojavelinux> if you want, just add a readme.md
[07:50:17] <mojavelinux> basically, the property is itest-container
[07:50:23] <mojavelinux> and the possible values are
[07:50:24] <sbryzak> there is a readme.md, i'll update it
[07:50:30] <mojavelinux> jbossas-managed, jbossas-remote and glassfish-remote
[07:50:43] <mojavelinux> I think that is a better scheme that solder should adopt
[07:50:43] <nickarls> the bug smells like Weld but it's so core that it would have been found by now if it was just weld
[07:50:48] <mojavelinux> we need a standard for seam anyway
[07:50:54] <mojavelinux> I'll note that in the seam master plan
[07:50:57] <nickarls> and like I said, it works as an arq-test on win
[07:51:18] * Diablo-D3 wonders why all app servers just cant be perfect
[07:51:32] <mojavelinux> that's the goal for AS 7
[07:51:39] <Diablo-D3> heheheheh
[07:51:39] <mojavelinux> and the path to get there is Arquillian
[07:51:45] <Diablo-D3> I cant wait for AS 7, actually
[07:51:50] <mojavelinux> an endless battery of, as brian puts it, "real tests"
[07:51:54] <mojavelinux> real, for real
[07:52:02] <mojavelinux> not this fake mock crap
[07:52:02] <nickarls> the famous "this-time-we'll-get-it-right-rewrite"
[07:52:03] <Diablo-D3> tests, the bane of programmers everywhere
[07:52:19] <nickarls> like AS6 was. And 5, and 4... ;-)
[07:52:23] <mojavelinux> the great part about arquillian is that
[07:52:26] <Diablo-D3> mojavelinux: well, one of the sins of a programmer is not actually going out and writing shit with your shit
[07:52:30] <mojavelinux> when someone uses it in a way we didn't think of
[07:52:38] <mojavelinux> we can duplicate that scenario almost exactly in the test suite
[07:52:42] <mojavelinux> that is just amazing
[07:53:01] <mojavelinux> to me, that is how you close the gap
[07:53:06] <nickarls> "please attach your zipped AS to the JIRA"
[07:53:25] <mojavelinux> actually, we have visions for attaching your arquillian test
[07:53:32] <mojavelinux> and we are sort of doing that now, in some jiras
[07:53:39] <mojavelinux> I actually have written out whole tests
[07:53:47] <Diablo-D3> sbryzak: btw, I think the openid-rp readme needs to be bigger
[07:53:50] <mojavelinux> a pull request would be better, but sometimes easier to just put the code there
[07:53:55] <Diablo-D3> sbryzak: it should cover the stuff I asked you
[07:54:05] <mojavelinux> pull request ;)
[07:54:15] <sbryzak> Diablo-D3: that stuff should actually be in the documentation
[07:54:23] <Diablo-D3> sbryzak: that too
[07:54:29] <sbryzak> unfortunately the guy who wrote the openid stuff is too busy to write it
[07:54:37] <Diablo-D3> the readme would be great if it just said "read this this this and this in the javadocs"
[07:54:58] <Diablo-D3> sbryzak: btw, what I dont get is, why isnt some of this xml in seam-beans.xml
[07:55:15] <sbryzak> which xml?
[07:55:24] <Diablo-D3> rp.setFoo and shti
[07:55:34] <sbryzak> that's not xml, it's java ;p
[07:55:48] <Diablo-D3> no I mean
[07:55:53] <Diablo-D3> why isnt it already xml
[07:55:58] <sbryzak> it should be configured in xml if that's what you mean
[07:56:02] <sbryzak> i didn't write the example though
[07:56:03] <Diablo-D3> yeah
[07:56:09] <nickarls> mojavelinux: when you have lots of spare time, write a JIRA-form where you upload the requested files and it assembles an arq-test and runs it automagically. then it marks it "non-reproducable" automatically if it passes ;-)
[07:56:18] * Diablo-D3 thinks seam should be as dev friendly as possible
[07:56:28] <Diablo-D3> last thing we need is to sink back into the pit known as pre-6 javaee
[07:56:58] <sbryzak> mojavelinux: do i need to have glassfish running?
[07:57:09] <mojavelinux> oh, yes
[07:57:12] <mojavelinux> we don't have a managed version yet
[07:57:16] <mojavelinux> just do
[07:57:20] <mojavelinux> asadmin start-domain domain1
[07:57:41] <mojavelinux> we need a glassfish issue report for this interceptor problem
[07:58:28] <mojavelinux> this experience is really proving my point that arquillian is a learning environment
[07:58:40] <mojavelinux> of course, we don't like what we are learning :)
[07:58:40] <jbossbot> git [compatibility] push master f255d07.. Shane Bryzak update readme
[07:58:40] <jbossbot> git [compatibility] push master URL: http://github.com/seam/compatibility/compare/13ad007...f255d07
[07:59:07] <mojavelinux> shane, I looked at john's pull requests for solder
[07:59:09] <sbryzak> mojavelinux: https://github.com/seam/compatibility/blob/master/readme.md
[07:59:10] <mojavelinux> they look good
[07:59:12] <mojavelinux> you can merge them in
[07:59:13] <sbryzak> see if that looks ok
[07:59:44] <mojavelinux> yep, might want to just add how you start the jboss server (for completeness) but otherwise that is correct
[08:00:12] <mojavelinux> you should easily be able to take that interceptor test
[08:00:15] <sbryzak> ok, ran it and got 9 errors in shouldInterceptBeanMethod
[08:00:16] <mojavelinux> and try out your interceptor problem
[08:00:32] <mojavelinux> yep, that's consistent with my results
[08:00:36] <sbryzak> great
[08:00:46] <sbryzak> this is fantastic, great job
[08:00:53] <mojavelinux> and this is happening also on my gf server running weld snapshot
[08:01:06] <mojavelinux> two things important to know
[08:01:10] <mojavelinux> to add to WEB-INF
[08:01:11] <mojavelinux> it's now
[08:01:15] <mojavelinux> addAsWebInfResource
[08:01:32] <mojavelinux> and to add to the web root (though you probably don't need to) is asAsWebResource
[08:01:45] <mojavelinux> also, methods are mostly addAs instead of just add
[08:01:48] <mojavelinux> this is for shrinkwrap
[08:01:58] <mojavelinux> also, in alpha5, the jndi.properties file is not longer needed
[08:01:58] <sbryzak> heh i just tweeted about it
[08:01:59] <mojavelinux> *if*
[08:02:07] <mojavelinux> I can figure out the new configuration syntax ;)
[08:02:11] <mojavelinux> which is not documented
[08:02:13] <mojavelinux> hehehe
[08:02:27] <sbryzak> sowing seeds
[08:02:28] <mojavelinux> so i'll ask aslak about it tomorrow and we'll update it
[08:02:30] <mojavelinux> to be cleaner
[08:02:56] <mojavelinux> if we can get one jsfunit test running in here
[08:03:07] <mojavelinux> then that will open the door for testing other things with ease
[08:03:10] <sbryzak> the QE guys will be coming online shortly
[08:03:13] <mojavelinux> super
[08:03:21] <mojavelinux> this is a much cleaner environment for them to test
[08:03:22] <mojavelinux> oh, and btw
[08:03:39] <mojavelinux> we should *definitely* stop running the tests in integration-test phase
[08:03:48] <mojavelinux> that breaks using it in the IDE
[08:03:55] <mojavelinux> pretty easy to fix that
[08:04:19] <sbryzak> that's something that everyone needs to know, could you post about it to seam-dev?
[08:04:50] <mojavelinux> ah, that's easy to fix
[08:04:52] <mojavelinux> fix coming
[08:05:19] <sbryzak> do any other modules do that?
[08:06:26] *** PeteRoyle has quit IRC
[08:09:48] *** bleathem has joined #seam-dev
[08:09:56] <bleathem> mojavelinux ping
[08:10:23] <jbossbot> git [compatibility] push master c4fc440.. Dan Allen run tests at normal phase; update readme
[08:10:24] <jbossbot> git [compatibility] push master URL: http://github.com/seam/compatibility/compare/f255d07...c4fc440
[08:10:58] <mojavelinux> after seam final we need to have a discussion about arquillian tests
[08:11:02] <mojavelinux> so I'm saving the discussion until then
[08:11:10] <bleathem> ok, I'm back
[08:11:11] <mojavelinux> the way that solder tests are run I don't like at all
[08:11:29] <bleathem> here's what I'm thinking
[08:11:35] <mojavelinux> I'm okay with a handful of tests that run against solder in JAR form
[08:11:42] <mojavelinux> but the whole test suite should not be run that way
[08:11:55] <bleathem> if you apply restrictions to a page, your saying you want security applied
[08:12:10] <bleathem> initial and postback allow you to contorl when security gets applied
[08:12:17] <bleathem> but it *does* get applied
[08:12:31] <bleathem> the onNavigate case, their is no choice of when it gets applie
[08:12:36] <bleathem> there is only one chance
[08:12:46] <bleathem> but it *should* get applied
[08:12:58] <bleathem> because that's why the security was configured on that view
[08:13:17] <bleathem> so I don't think we need configuration option
[08:14:06] <bleathem> tldr; the view is secured or not, their is only a question of timing
[08:14:13] <mojavelinux> right
[08:15:15] <mojavelinux> i think you've got it nailed down
[08:15:16] <mojavelinux> and you are right
[08:15:25] <bleathem> ok cool
[08:15:26] <mojavelinux> the important part is that we secure pages as you navigate to them
[08:15:32] <mojavelinux> which would be render response
[08:15:45] <mojavelinux> which you've now got covered
[08:16:55] <mojavelinux> so i'm just thinking, to keep it simple
[08:17:16] <mojavelinux> @RestrictAtPhase should take a list of phases for "duringInitial" and "duringPostback"
[08:17:18] <mojavelinux> and the default is
[08:17:46] <mojavelinux> RESTORE_VIEW, RENDER_RESPONSE for initial
[08:17:59] <mojavelinux> and RESTORE_VIEW, INVOKE_APPLICATION and RENDER_RESPONSE for postback
[08:18:03] <mojavelinux> is that reasonable?
[08:18:19] <bleathem> for the default?
[08:18:31] <mojavelinux> yeah, or whatever the defaults you think
[08:18:56] <mojavelinux> but what we are doing is giving them the option to apply the security at different phases
[08:19:11] <bleathem> right
[08:19:22] <mojavelinux> and more fine grained
[08:19:28] <mojavelinux> and they can apply the security themselves
[08:19:32] <mojavelinux> aha!
[08:19:47] <mojavelinux> the API should let them apply the security restrictions for the current view Id
[08:19:56] <mojavelinux> so you can say something like
[08:20:10] <mojavelinux> viewConfig.enforceViewRestrictions()
[08:20:28] <mojavelinux> that way, if you want to apply the securtiy (or check it) at an arbitrary place, you can
[08:20:33] <mojavelinux> you could even have a
[08:20:40] <mojavelinux> viewConfig.checkViewRestrictions()
[08:20:48] <mojavelinux> and then that would tell you what the result is
[08:20:50] <mojavelinux> rather than enforce it
[08:20:52] <bleathem> i like that programmatic invocation
[08:20:52] <mojavelinux> that's pretty cool
[08:21:04] <bleathem> so to summarize the intent:
[08:21:12] <bleathem> as you said earlier, there are 3 ways you can arrive at a view:
[08:21:18] <bleathem> 1) , initial request
[08:21:20] <mojavelinux> no, we are saying just two now
[08:21:24] <bleathem> 2) , postback request
[08:21:28] <bleathem> 3) , or navigation to
[08:21:34] <mojavelinux> just 2
[08:21:40] <mojavelinux> keep it simpler
[08:21:41] <bleathem> only 1 and 2 have an option to control timing
[08:21:51] <bleathem> 3) has only one phase where it can happen
[08:21:55] <bleathem> so it always happens
[08:21:57] <mojavelinux> let's drop 3
[08:22:08] <mojavelinux> for post-navigate, see #2
[08:22:21] <mojavelinux> so let's say I navigate to /results.xhtml
[08:22:36] <mojavelinux> during render response, I check if postback
[08:22:58] <mojavelinux> if postback, enforce if duringPostback has RENDER_RESPONSE
[08:23:02] <bleathem> postback should be checked after restore
[08:23:24] <mojavelinux> so what I'm saying is, forget about the navigate for a second
[08:23:25] <bleathem> in most cases I would think
[08:23:29] <mojavelinux> because we are going to keep it simpler
[08:23:33] <bleathem> ok
[08:23:42] <mojavelinux> you consider what view you are in currently
[08:23:48] <mojavelinux> you consider what view id you are on
[08:23:54] <mojavelinux> and you consider if this is initial or postback
[08:24:02] <mojavelinux> with that information, find the rule in the view config and apply it
[08:24:15] <bleathem> but that's the problem
[08:24:26] <mojavelinux> how come?
[08:24:42] <bleathem> if I want to restrict who can change state, I want postback to occur before invoke application (after restore)
[08:25:02] <bleathem> but wehn I navigate to a page, if I treat that as post back, we are already past the secure points
[08:25:05] <bleathem> and access is granted
[08:25:14] <mojavelinux> ah, but think about it another way
[08:25:23] <mojavelinux> let's say you want to secure like /item.xhtml
[08:25:32] <mojavelinux> the application navigates
[08:25:39] <mojavelinux> now we are in render response
[08:25:45] <mojavelinux> and view id is /item.xhtml
[08:25:55] <mojavelinux> (we are in before render response)
[08:26:07] <mojavelinux> we look at the view config
[08:26:13] <mojavelinux> and we see the restrictions for /item.xhtml
[08:26:19] <mojavelinux> and we enforce them
[08:26:21] <mojavelinux> if
[08:26:27] <mojavelinux> duringPostback contains RENDER_RESPONSE
[08:26:45] <mojavelinux> nevermind that at the beginning of the postback, the view id was /search.xhtml
[08:26:45] <bleathem> so duringPostback is multi-valued?
[08:26:57] <mojavelinux> right, I'm saying they are both multi-valued
[08:27:13] <mojavelinux> duringPostback = INVOKE_APPLICATION, RENDER_RESPONSE
[08:27:24] <bleathem> so you are saying we will never be able to post back to a page, if we weren't allowed to navigate to it in the first place
[08:28:18] <mojavelinux> in a sense
[08:28:32] <mojavelinux> though what I'm really saying is that the enforcement follows the navigation
[08:28:48] <mojavelinux> so the enforcement during invoke application will be on the view id to which I posted
[08:28:59] <mojavelinux> the enforcement during render response may be on a different view id
[08:29:31] <bleathem> right
[08:30:02] <mojavelinux> but if I do an intial request for a view, then I'm looking at duringInitial = RENDER_RESPONSE
[08:31:02] <mojavelinux> if I do a postback then navigate to a view, them i'm looking at duringPostback = INVOKE_APPLICATION for the postback view, and duringPostback = RENDER_RESPONSE for the target view
[08:31:11] <mojavelinux> to put it more clearly
[08:31:31] <mojavelinux> if you an arrive at a view id via an initial request or from a navigation after a postback
[08:31:34] <mojavelinux> then you need
[08:31:39] <bleathem> it feels annoying to have to specify the two values for postback
[08:31:59] <mojavelinux> @RestrictAtPhase(duringInitial = { RENDER_RESPONSE }, duringPostback = { RENDER_RESPONSE })
[08:32:37] <mojavelinux> okay, so perhaps
[08:32:48] <mojavelinux> we should just drop the initial and postback distinction
[08:32:50] <mojavelinux> and just say
[08:32:59] <bleathem> and to restrict postback to that same view, you add After_Restore to the duringPostback
[08:33:07] <mojavelinux> @RestrictAtPhase({RESTORE_VIEW, RENDER_RESPONSE})
[08:33:22] <mojavelinux> that makes more sense actually
[08:33:23] <bleathem> that seems good
[08:33:29] <mojavelinux> and the default is
[08:33:44] <mojavelinux> {RESTORE_VIEW, INVOKE_APPLICATION, RENDER_RESPONSE}
[08:34:01] <mojavelinux> the use case here, is if you only want to restrict the render response phase
[08:34:04] <mojavelinux> then you can just do
[08:34:09] <bleathem> the reason why we seperated out the initial request though, was that the viewparams weren't parsed yet
[08:34:10] <mojavelinux> @RestrictAtPhase(RENDER_RESPONSE)
[08:34:54] <bleathem> this shouldn't be so complicated
[08:35:07] <mojavelinux> well, we are trying to make it simpler :)
[08:35:16] <mojavelinux> actually
[08:35:17] <mojavelinux> I would say
[08:35:20] <mojavelinux> the default should be
[08:35:40] <mojavelinux> @RestrictAtPhase({INVOKE_APPLICATION, RENDER_RESPONSE})
[08:35:44] <bleathem> yes
[08:35:45] <mojavelinux> and RESTORE_VIEW is a special case
[08:35:51] <mojavelinux> for things like admin pages
[08:35:52] <bleathem> that makes sense
[08:36:21] <bleathem> that's simple
[08:36:49] <mojavelinux> now one more thing to ask, don't let it throw us off track though
[08:37:05] <mojavelinux> do you think you will want some restrictions to be applied at one point, and others at another point?
[08:37:22] <bleathem> yes, was just thinking about that, when you mentioned the admin pages
[08:38:15] <mojavelinux> I think there is a simple solution
[08:38:20] <mojavelinux> super simple
[08:38:26] <mojavelinux> that's a separate mapping
[08:38:39] <mojavelinux> and chances are, you will be mapping it w/ a different glob anyway
[08:38:43] <mojavelinux> for instance
[08:39:06] <mojavelinux> @Admin
[08:39:06] <mojavelinux> @RestrictAtPhase(RESTORE_VIEW)
[08:39:06] <mojavelinux> @ViewMapping("/admin/*")
[08:39:07] <mojavelinux> then
[08:39:28] <mojavelinux> @Owner
[08:39:28] <mojavelinux> @ViewMapping("/admin/document.xhtml")
[08:39:37] <mojavelinux> and you can have
[08:39:47] <bleathem> use case: RESTORE_VIEW I could see a role restriction, and RENDER_RESPONSE/INVOKE_APPLICATION could be object value based
[08:39:57] <mojavelinux> yep
[08:40:28] <mojavelinux> and in those two examples I gave
[08:40:33] <mojavelinux> the mapping can be the same
[08:40:34] <bleathem> ok with that, I don't think we need to worry at all about seperating out the initial/postback timings
[08:40:43] <mojavelinux> yeah, same here
[08:41:24] <mojavelinux> in fact, what I would say is this
[08:41:30] <mojavelinux> this is the simple approach we throw out there
[08:41:35] <mojavelinux> and if we get feedback, okay then
[08:41:44] <mojavelinux> but you can hardly argue that this is not a good start
[08:41:51] <mojavelinux> this is a good start
[08:41:59] <bleathem> so when I look up the the security annotations, we climb the specificity tree, looking for the first match to our phase
[08:42:12] <mojavelinux> allowing a glob to occur twice might change your internal indexing
[08:42:15] <mojavelinux> but it should be allowed
[08:42:16] <bleathem> better than what we had this morning!
[08:42:20] *** kpiwko has joined #seam-dev
[08:42:37] <mojavelinux> yep
[08:42:41] <bleathem> what do you mean by allowing a glob to occur twice
[08:42:43] <mojavelinux> btw, do you have a utility for glob matching
[08:42:49] <mojavelinux> because that would be really useful as an API
[08:42:49] <bleathem> in the example you gave
[08:42:57] <bleathem> if I visit
[08:43:05] <bleathem>  /admin/document.xhtml"
[08:43:23] <bleathem> then during the restore view, I will see only the @Admin restriction
[08:43:28] <mojavelinux> assume my first example was also /admin/document.xhtml
[08:43:40] <bleathem> then during the other two phases, I see only @Owner
[08:43:52] <mojavelinux> correct
[08:44:11] <mojavelinux> the point of the first one is, you can't even look at this page at all
[08:44:18] <mojavelinux> the second one is, well, this is a contextual restriction
[08:44:28] <mojavelinux> might be rule-based
[08:44:31] <bleathem> if you added "/*" @noone
[08:44:51] <bleathem> I wouldn't see that either (for visiting the /admin/document.xhtml page)
[08:45:10] <mojavelinux> actually, it would be
[08:45:38] <mojavelinux> @BanAll
[08:45:38] <mojavelinux> @RestrictAtPhase(RESTORE_VIEW)
[08:45:38] <mojavelinux> @ViewMapping("/*")
[08:45:44] <mojavelinux> that blocks off the whole application
[08:46:03] <bleathem> that implies we know @BanAll has higher precedence than @Owner
[08:46:11] <bleathem> consider if it were the other way around
[08:46:15] <mojavelinux> ah, no
[08:46:27] <bleathem> you could argue to ignore the @BanAll because of the @Owner at the root level
[08:46:29] <mojavelinux> you try security checks until you have tried them all
[08:46:36] <bleathem> ah ok
[08:46:43] <mojavelinux> I think you shouldn't have precedence, you just apply anything that matches
[08:46:45] <mojavelinux> the order
[08:46:48] <mojavelinux> is when you get specific
[08:46:56] <mojavelinux> so /admin/document goes before /*
[08:47:27] <bleathem> I have to make sure we are applying all security restrictions from patterns that match
[08:47:38] <bleathem> I'm pretty sure it's not
[08:47:48] <bleathem> but your right, it should apply them all
[08:48:04] <bleathem> all the ones that apply to the current phase anyway
[08:48:18] <bleathem> I'm going to need a new data structure for this
[08:48:25] *** oskutka has joined #seam-dev
[08:48:27] <bleathem> very doable though
[08:49:18] <bleathem> this feature is going to need a lot of hammering
[08:49:26] <mojavelinux> and if people say, "but I want a special case for a certain page that has different security"
[08:49:30] <mojavelinux> then we say, okay
[08:50:00] <mojavelinux> we add @ViewPattern(value = "/admin/*", excludes = {"/admin/specialcase.xhtml"})
[08:50:02] <mojavelinux> voila
[08:50:19] <bleathem> nice
[08:52:00] <bleathem> ok, I'll code this up tomorrow.  I need to summarize this in a jira though, before I forget the details!
[08:52:54] <nickarls> AS6 EOL:d
[08:55:42] <bleathem> what about:
[08:55:45] <bleathem> @Owner
[08:55:49] <bleathem> @ViewMapping("/admin/document.xhtml")
[08:55:53] <bleathem> and
[08:56:09] <bleathem> @SuperUser
[08:56:13] <bleathem> @RestrictAtPhase(RESTORE_VIEW)
[08:56:18] <bleathem> @ViewMapping("/admin/*")
[08:56:25] <bleathem> no sorry
[08:56:34] <bleathem> that last @viewPattern should be:
[08:56:40] <bleathem> @ViewMapping("/admin/document.xhtml")
[08:57:03] <nickarls> where does that go?
[08:57:03] <bleathem> so you have to configs for the same pattern, that apply at differant phases
[08:57:12] <nickarls> in the view?
[08:57:13] <bleathem> in the @ViewConfig
[08:57:14] <mojavelinux> that's allowed
[08:57:47] * nickarls hasn't been following the discussion, where do you place @ViewConfig
[08:57:54] <bleathem> what if it looke like:
[08:57:56] <mojavelinux> SEAMFACES-33
[08:58:02] <jbossbot> jira [SEAMFACES-33] Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting configuration [Resolved (Done) Feature Request, Blocker, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-33
[08:58:23] <bleathem> @RestrictAtPhase(RESTORE_VIEW, @Admin)
[08:58:35] <bleathem> @RestrictAtPhase(Render_RESPONSE, @Owner)
[08:58:48] <bleathem> no, that feels unnatural
[08:59:20] <bleathem> I don't know if I like having two enums that correspond to the exact same view though
[08:59:30] <bleathem> if we end up using them to handle navigation
[09:00:49] <mojavelinux> I think it's okay because you can't navigate to a glob
[09:00:55] <mojavelinux> so some enums won't be navigatable
[09:01:04] <bleathem> true
[09:01:24] <mojavelinux> and you could name them like
[09:01:25] <bleathem> but two enums that are navigatable coressponding to the same view seems bad
[09:01:26] <mojavelinux> ADMIN_GLOB
[09:01:32] <bleathem> unless you flag one as unnavigable
[09:01:34] <mojavelinux> DOCUMENT_VIEW
[09:01:45] <bleathem> let me pastie something
[09:02:17] <mojavelinux> but remember, this might be an edge case anyway
[09:02:35] <mojavelinux> wait
[09:05:12] <bleathem> check this out
[09:05:15] <mojavelinux> k
[09:05:22] <bleathem> this is the multivalued thing that I thought was bad:
[09:05:24] <bleathem> http://pastie.org/1707255
[09:05:27] <bleathem> but what if we allowed:
[09:05:33] <bleathem> http://pastie.org/1707257
[09:05:47] <bleathem> So the phase goes in the security restriction itself.
[09:06:25] <bleathem> Make @RestrictAtView a qualifier for other annotations, where the phase can be configured, per restriction
[09:06:40] <bleathem> I say give me all the restrictions for this view, that martch this phase
[09:06:47] <mojavelinux> you are brilliant
[09:06:49] <bleathem> where their is a default phase
[09:07:10] <mojavelinux> that's much better
[09:07:35] <bleathem> only problem is a bit of a disconnect with the SecurityBindingType qualifier that's in Security
[09:07:50] <bleathem> which has no notion of JSF phases
[09:08:06] <mojavelinux> that's okay though, because the security annotation is your own
[09:08:09] <mojavelinux> you can define it how you want
[09:08:18] <mojavelinux> and I would say, if you have an existing annotation
[09:08:21] <mojavelinux> check this out
[09:08:29] <mojavelinux> so let's say some dude gives me a jar with @Admin
[09:08:38] <mojavelinux> and I want to do @Admin(RESTORE_VIEW)
[09:08:45] <mojavelinux> then I create a stereotype annotated with @Admin
[09:08:46] <mojavelinux> like
[09:09:13] <mojavelinux> @Admin
[09:09:13] <mojavelinux> @Stereotype
[09:09:13] <mojavelinux> public @interface AdminRestriction { PhaseId value(); }
[09:09:17] <mojavelinux> then I can do
[09:09:24] <mojavelinux> @AdminRestriction(RESTORE_VIEW)
[09:09:28] <mojavelinux> voila!
[09:09:30] <bleathem> nice
[09:09:38] <mojavelinux> but if i'm on the cheap
[09:09:42] <mojavelinux> and doing my own annotations
[09:09:54] <mojavelinux> then I can just hard-wire it right into my security binding annotation
[09:10:10] <mojavelinux> and
[09:10:17] <mojavelinux> you could still support @RestrictAtPhase
[09:10:21] <mojavelinux> for the super cheap
[09:10:36] <bleathem> right
[09:10:42] <mojavelinux> which is all defaulted anyway, so then this is a less than normal use case
[09:11:00] <mojavelinux> this is definitely the right way to go me thinks
[09:11:16] <bleathem> yes, the ViewConfig is simplifying
[09:11:45] <mojavelinux> so if you want fine-grained control, you have to add the PhaseId to your security annotation
[09:12:01] <mojavelinux> and your security annotation can be a stereotype
[09:12:27] <mojavelinux> I would not look for the PhaseId any higher then on the annotation directly used on the enum
[09:12:50] <mojavelinux> but seam security should take it from there to give you the actual restriction
[09:12:58] *** PeteRoyle has joined #seam-dev
[09:13:01] <mojavelinux> seam security doesn't need to care that you have a value on your security annotation
[09:13:21] <mojavelinux> so this logic boils down to
[09:13:26] <mojavelinux> look for @RestrictAtPhase
[09:13:44] <bleathem> we can give it a name @Admin(restrictAtPhase=RESTORE_VIEW)
[09:13:45] <mojavelinux> if that is absent, look to see if the value of the security annotation has a PhaseId
[09:13:53] <mojavelinux> yes
[09:13:56] <mojavelinux> do that
[09:14:00] <bleathem> can annotations implement interfaces?
[09:14:06] <mojavelinux> yes
[09:14:18] <mojavelinux> because that's how annotation literals work
[09:14:18] <bleathem> so we can define a RestrictAtPahse interfaace
[09:14:19] <mojavelinux> :)
[09:14:24] <mojavelinux> yes
[09:14:30] <mojavelinux> and, btw, that is an array
[09:14:40] <bleathem> right
[09:14:47] <mojavelinux> this is awesome
[09:14:50] <mojavelinux> this is good thinking
[09:14:57] <mojavelinux> the reason this was a great exercise
[09:15:20] <mojavelinux> is that you have now officially gone through the cdi-way of innovation
[09:15:27] <bleathem> so I create an annotation that implements the RestrictAtView interface, which gives me the restrictAtPhase attribute
[09:15:42] <bleathem> nice, what way is that?
[09:16:14] <mojavelinux> just to keep bending java until you realize you can put things where you didn't think you could originally
[09:16:38] <bleathem> lol - you were right when you called this a DSL
[09:16:55] <mojavelinux> rats
[09:17:01] <bleathem> I think a groovy DSL to programmitcally configre the ViewSotre could be looked at down the road
[09:17:04] <mojavelinux> no implement interface on annotation, I was thinking enum
[09:17:08] <mojavelinux> we'll, a convention is fine
[09:17:11] <bleathem> sure
[09:17:19] <mojavelinux> groovy dsl, absolutely
[09:17:27] <mojavelinux> that's why I was saying the api is important
[09:17:35] <bleathem> tis
[09:17:49] *** marekn has joined #seam-dev
[09:18:03] <mojavelinux> this is solid
[09:18:07] <bleathem> I think this is a good point to stop, we've got something clean and achievable
[09:18:23] <mojavelinux> yeah, because I'm going to start typing zzzzzzzz
[09:18:24] <mojavelinux> zzzzzzzzzzz
[09:18:28] <mojavelinux> nose on keyboard
[09:18:34] <bleathem> is that your nose on the keyboard?!
[09:18:40] <bleathem> man you're a fast typer
[09:18:42] <Diablo-D3> hah
[09:19:03] <mojavelinux> funny, I always think I type slow
[09:19:09] <bleathem> ok, van pool is going to be here in 5 hours
[09:19:13] <mojavelinux> but then, that's because I can't type as fast as crap comes out of my skull
[09:19:23] <mojavelinux> okay, good night!
[09:19:27] <bleathem> that doesn't give me much time for too many of those "z"s
[09:19:33] <mojavelinux> quick, to bed!
[09:19:33] <bleathem> cya
[09:19:38] *** bleathem has quit IRC
[09:43:20] *** aslak has joined #seam-dev
[09:43:20] *** aslak has quit IRC
[09:43:20] *** aslak has joined #seam-dev
[09:48:49] *** PeteRoyle has quit IRC
[09:58:03] *** PeteRoyle has joined #seam-dev
[10:01:41] *** aslak has quit IRC
[10:02:35] *** aslak has joined #seam-dev
[10:02:35] <Diablo-D3> I think I like the looks of seam.config
[10:04:14] *** mgencur has quit IRC
[10:07:31] *** mgencur has joined #seam-dev
[10:10:30] *** PeteRoyle has quit IRC
[10:11:53] *** sannegrinovero has joined #seam-dev
[10:29:16] *** shervin_a has joined #seam-dev
[10:36:19] *** amitev has joined #seam-dev
[10:50:36] *** alesj has joined #seam-dev
[10:51:31] <jbossbot> git [remoting] push master fae289a.. Shane Bryzak removed slf4j
[10:51:31] <jbossbot> git [remoting] push master 3ce2fcc.. Shane Bryzak SEAMREMOTING-31
[10:51:31] <jbossbot> jira [SEAMREMOTING-31] remoting-helloworld - provide build profile for GlassFish [Open (Unresolved) Task, Major, Jozef Hartinger] https://issues.jboss.org/browse/SEAMREMOTING-31
[10:51:32] <jbossbot> git [remoting] push master URL: http://github.com/seam/remoting/compare/f39b9c9...3ce2fcc
[10:58:04] <jharting> sbryzak: ping
[10:58:12] <sbryzak> jharting: pong
[10:59:00] <jharting> sbryzak: Hi Shane, is using of seam-security-external module without the main seam-security module a valid usecase?
[10:59:09] <sbryzak> jharting: no
[11:00:23] <jharting> sbryzak: ok, seems that this is the case in the openid-op example
[11:00:34] <jharting> sbryzak: it works on JBoss AS, but fails on GlassFish
[11:00:45] <sbryzak> that example is...different
[11:00:52] <jharting> Exception while loading the app : org/jboss/seam/security/Authenticator
[11:00:52] <jharting> java.lang.ClassNotFoundException: org.jboss.seam.security.Authenticator
[11:01:02] <sbryzak> hmm, interesting
[11:01:24] <jharting> sbryzak: so I guess it is a valid usecase for an identity provider?
[11:01:55] <jharting> sbryzak: or?
[11:01:56] <sbryzak> only because that code still needs work
[11:02:05] <jharting> sbryzak: ic
[11:02:07] <sbryzak> marcel didn't integrate it with the core security api
[11:02:24] <sbryzak> i've had to go and refactor it, but it's a work in progress
[11:02:44] <jharting> sbryzak: anyway, adding the security module is no help on glassfish: Bean name is ambiguous. Name identity resolves to beans [Managed Bean [class org.jboss.seam.security.examples.openid.Identity] with qualifiers [@Any @Default @Named], Managed Bean [class org.jboss.seam.security.IdentityImpl] with qualifiers [@Any @Default @Named]]
[11:02:52] <sbryzak> i just noticed the dependency for seam-security in the external module is provided
[11:02:55] <sbryzak> i'll remove that
[11:03:15] <jharting> sbryzak: ok, I'll report the ambiguous name, then
[11:03:18] <sbryzak> hmm, ok i'll take a look
[11:03:46] <jbossbot> git [security] push master 269a8b0.. Shane Bryzak fix scope for seam-security dependency
[11:03:46] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/3f972c8...269a8b0
[11:03:52] <sbryzak> i've half a mind to exclude that example from the final release
[11:04:05] <sbryzak> in fact... yes, i'm going to remove it for now
[11:04:15] <sbryzak> i'm not comfortable with the openid provider features the way they are
[11:04:24] <jharting> sbryzak: ic
[11:04:34] <sbryzak> the openid-rp example should be fine
[11:04:41] <sbryzak> we'll just remove openid-op
[11:05:10] <sbryzak> can you raise me a jira for it? i'll need one for SEAMSECURITY to disable it from the distribution, and one for SEAM to remove it from the bundled distribution
[11:05:27] <jharting> sbryzak: sure
[11:05:56] <sbryzak> jharting: btw, is ondra in the office today?
[11:06:36] <jharting> sbryzak: he was, but he is not here ATM
[11:06:49] <sbryzak> np, i want to talk to you guys about the compatibility module
[11:07:14] *** kuuyee has quit IRC
[11:08:08] <jharting> sbryzak: ok, I'll let him know once he returns
[11:08:21] <sbryzak> thanks, we might even have a quick conf call if that's convenient
[11:08:41] <jharting> sbryzak: yes
[11:08:44] *** PeteRoyle has joined #seam-dev
[11:09:09] <jharting> sbryzak: btw, I am a bit confused about logging in seam modules. Should all the modules use jboss logging instead of slf4j?
[11:09:20] <sbryzak> jharting: yeah, i think so
[11:09:28] <sbryzak> jharting: i was going to go through all the modules and remove slf4j
[11:09:31] <jharting> sbryzak: should we enforce this for 3.0 Final?
[11:09:38] <jharting> sbryzak: ok
[11:09:41] <sbryzak> that will at least solve one dependency issue for glassfish
[11:09:49] <sbryzak> sure, let's enforce it
[11:10:02] <sbryzak> if you could raise jiras for each module that still uses slf4j, all the better
[11:10:09] <jharting> sbryzak: ok
[11:10:10] <sbryzak> just so we can track it
[11:12:27] <sbryzak> jharting: were you able to test the SEAMSECURITY-42 issue with a vanilla GF3.1 install?
[11:12:30] <jbossbot> jira [SEAMSECURITY-42] NPE when attempting to login [Reopened (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-42
[11:13:41] <jharting> sbryzak: yes, but I was not able to reproduce the problem. On vanilla GF 3.1 I am getting a random deployment problem related to interceptor / ambiguous dependency
[11:14:00] <jharting> sbryzak: using the simple example
[11:14:09] <sbryzak> ok, in that case i might close the issue
[11:14:12] <sbryzak> as it doesn't seem related
[11:14:54] <jharting> sbryzak: yes, if we stick with the weld plan, it's not relevant anymore
[11:23:10] *** mgencur has quit IRC
[11:24:35] <jbossbot> git [security] push master f819822.. Shane Bryzak SEAMSECURITY-45
[11:24:36] <jbossbot> jira [SEAMSECURITY-45] Exclude the security-openid-op example [Open (Unresolved) Task, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAMSECURITY-45
[11:24:37] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/269a8b0...f819822
[11:25:34] *** Royle has joined #seam-dev
[11:26:09] *** mgencur has joined #seam-dev
[11:28:40] *** PeteRoyle has quit IRC
[11:28:41] *** Royle is now known as PeteRoyle
[11:30:09] <jbossbot> git [dist] push master fae7d74.. Shane Bryzak SEAM-59
[11:30:20] <jbossbot> jira [SEAM-59] Exclude the security-openid-op example [Open (Unresolved) Task, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAM-59
[11:30:20] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/4a35ac3...fae7d74
[11:31:17] *** mgencur has quit IRC
[11:31:58] *** mgencur has joined #seam-dev
[11:34:12] *** koentsje has joined #seam-dev
[12:02:24] *** PeteRoyle has quit IRC
[12:02:28] *** koentsje has quit IRC
[12:09:32] <nickarls> anyone still around?
[12:14:38] *** PeteRoyle has joined #seam-dev
[12:24:27] *** pmuir has joined #seam-dev
[12:28:22] *** PeteRoyle has quit IRC
[12:29:53] *** PeteRoyle has joined #seam-dev
[12:34:31] <sbryzak> i'm here
[12:34:58] <sbryzak> nickarls: delayed response, sorry :)
[12:39:11] *** PeteRoyle has quit IRC
[12:52:49] <nickarls> just wondered if anyone has seen SOLDER-94 before?
[12:55:13] <sbryzak> nickarls: can't say i have, sorry
[12:56:28] *** PeteRoyle has joined #seam-dev
[13:00:36] *** balunasj has joined #seam-dev
[13:20:47] *** jose_freitas has joined #seam-dev
[13:20:52] <jose_freitas> morning
[13:31:28] *** PeteRoyle has quit IRC
[13:32:52] *** shervin_a has quit IRC
[13:35:44] *** jharting has quit IRC
[13:43:13] *** PeteRoyle has joined #seam-dev
[13:44:10] *** PeteRoyle has quit IRC
[13:45:36] <lincolnthree1> morning jose_freitas
[13:50:30] <Diablo-D3> hrm
[13:50:49] <Diablo-D3> with seam config
[13:51:11] <Diablo-D3> where can I drop beans.xmls?
[13:51:48] <jose_freitas> you need to drop it on meta-inf that goes on you classes
[13:52:55] <jose_freitas> if you have use a maven project, put it on META-INF of your resources directory
[13:53:03] <Diablo-D3> I mean, other than that
[13:54:04] <Diablo-D3> like, how would end users configure my webapp if I used seam config
[13:55:20] *** Obsidians has joined #seam-dev
[13:55:49] <lincolnthree1> Diablo-D3: that's a good question, something I've been meaning to look at. I'm not sure there is a feature for external configuration yet... however... i might suggest using your own .properties file and putting it in a home directory. loading that file.
[13:55:52] <lincolnthree1> that's what I've always done
[13:56:07] <lincolnthree1> just read it yourself and set the values when the app starts up
[13:56:29] <lincolnthree1> but stuartdouglas may be able to tell you otherwise, he wrote config
[13:56:50] <lincolnthree1> i think it would be great if it supports (it may already) external configuration files
[13:57:10] <jose_freitas> well, it would, but I think that there's a limitation of loading resources
[13:57:36] <jose_freitas> maybe one could make a class that load a propertie and configure the beans.
[13:58:23] 
[13:59:08] <jose_freitas> but definitelly would be nice to have an external config tool
[13:59:33] <Diablo-D3> so seam config, at this point in time, cant do what I want
[14:00:49] <jose_freitas> nope, but as lincolnthree1 said, stuartdouglas is the one who would be 100% sure of that.
[14:01:26] <Diablo-D3> stuartdouglas: PING
[14:01:46] <Diablo-D3> hrm, hes been afk for 6 hours
[14:01:55] <jose_freitas> what's hrm?
[14:02:13] <jose_freitas> help request at morning?
[14:02:16] <jose_freitas> lol
[14:02:35] <Diablo-D3> hrm is the sound that diablos make when thinking
[14:03:07] <jose_freitas> hmm
[14:03:10] <jose_freitas> ok
[14:07:55] <Diablo-D3> lincolnthree1: I was hoping I could avoid the property files method
[14:07:56] <Diablo-D3> but meh
[14:08:31] <lincolnthree1> Diablo-D3: how did you want to do it intsead?
[14:08:46] <Diablo-D3> I dunno, something simple for users I guess
[14:09:04] <Diablo-D3> dropping a file in the same dir as the war seems simple enough
[14:18:55] <Diablo-D3> actually
[14:19:24] <Diablo-D3> lincolnthree1: can I drop a properties file in the same dir as the war and not have anything go wrong?
[14:22:10] <lincolnthree1> you'd have to figure out how to reference the directory, but sure.
[14:22:24] <Diablo-D3> yeah, thats what Im wondering
[14:22:42] <lincolnthree1> home directory is what i usually go with
[14:22:45] <Diablo-D3> I mean, I probably can check the classpath and grep for war or something
[14:22:46] <lincolnthree1> it's pretty standard
[14:22:48] <lincolnthree1> see Forge
[14:22:53] <lincolnthree1> it creates a ~/.forge/config
[14:23:07] <Diablo-D3> what is this forge you speak of?
[14:23:13] <lincolnthree1> ah
[14:23:27] <lincolnthree1> what it is, is something you might be interested in
[14:23:51] <lincolnthree1> It's an extendable project development tool
[14:23:54] <lincolnthree1> http://pastebin.com/EEGLRHLJ
[14:24:07] <lincolnthree1> that's an example of installing a plugin/extension from a git repository
[14:24:47] <lincolnthree1> it streamlines creating and maintaining projects
[14:25:04] <nickarls> where is the eclipse plugin for forge!? ;-)
[14:25:09] <lincolnthree1> http://pastebin.com/M8LjaDHq
[14:25:20] <lincolnthree1> nickarls: a guy by the name of Koen Aers is writing that
[14:25:27] <Diablo-D3> lincolnthree1: why would you want it further streamlined more than what mvn can do?
[14:25:36] <lincolnthree1> it's based on mvn
[14:25:40] <nickarls> Aers? Hope he's not scottish
[14:28:26] <lincolnthree1> Diablo-D3: do you enjoy creating POM files?
[14:28:37] <lincolnthree1> or creating web.xml, faces-config.xml, persistence.xml, beans.xml
[14:28:40] <lincolnthree1> getting them right
[14:28:43] <lincolnthree1> putting them in the right place
[14:29:04] <lincolnthree1> seam forge takes care of all of that
[14:29:19] <lincolnthree1> using plugins :)
[14:29:23] <lincolnthree1> anyone can create plugins
[14:29:53] <lincolnthree1> forge knows how to download and compile a mvn forge plugin project, install the plugin while running, and reload the classes
[14:30:07] <Diablo-D3> lincolnthree1: erm, huh?
[14:30:18] <lincolnthree1> here: http://seamframework.org/Documentation/SeamForge
[14:30:19] <Diablo-D3> mvn can create new projects with those in place
[14:30:21] <Diablo-D3> so can eclipse
[14:30:26] <Diablo-D3> aaaaaaaaaand
[14:30:47] <Diablo-D3> I'd rather set it up myself so its setup exactly the way I want it
[14:30:56] <lincolnthree1> You can do the same thing with forge...
[14:31:02] <lincolnthree1> it doesn't do anything for you that you don't want
[14:31:08] <lincolnthree1> that's the beauty
[14:31:16] <lincolnthree1> you can let it do as much or as little as you want
[14:31:22] <Diablo-D3> so... why am I just not using mvn directly?
[14:31:32] <lincolnthree1> it creates native mvn projects
[14:31:37] <lincolnthree1> so you just compile normally
[14:31:40] <Diablo-D3> but...
[14:31:42] <lincolnthree1> it doesn't do anything "special"
[14:31:47] <Diablo-D3> mvn can ALREADY create projects. by itself.
[14:31:52] *** balunasj is now known as balunasj_mtg
[14:31:53] <lincolnthree1> what with archetypes?
[14:31:57] <Diablo-D3> yeah
[14:32:00] <lincolnthree1> those are so fun to use
[14:32:12] <sbryzak> archetypes are so elementary it's not funny
[14:32:16] <lincolnthree1> and when you want to customize something you're SOL
[14:32:27] <Diablo-D3> I dunno, maybe Ive been programming for too long, but even setting it up by hand just isnt hard
[14:32:45] <sbryzak> once you've run the archetype and generated your project, that's it
[14:32:48] <sbryzak> it can't do anything else
[14:33:19] <Diablo-D3> but ... why would I want to do anything else?
[14:33:28] <lincolnthree1> let's take setting up JPA
[14:33:38] <sbryzak> you might like to add other features to your app?
[14:33:46] <lincolnthree1> maybe you want a webapp with JPA, but your archetype didn't include it
[14:33:49] <Diablo-D3> sbryzak: but then I just edit the pom
[14:34:10] <sbryzak> you can't just edit the pom to add something like identity management for example
[14:34:15] <sbryzak> you need to create a bunch of entity beans
[14:34:19] <sbryzak> add some configuration to beans.xml
[14:34:23] <sbryzak> create a bunch of views
[14:34:30] <sbryzak> plus some miscellaneous other stuff
[14:34:47] <lincolnthree1> Diablo-D3: http://kennardconsulting.blogspot.com/2011/03/grokking-seam-forge-part-2.html
[14:34:53] <Diablo-D3> but... thats what programming is
[14:35:00] <lincolnthree1> programming is whatever you make of it
[14:35:04] <sbryzak> forge will be able to do that in a single action, once the plugin is written
[14:35:22] <sbryzak> identity management is a common concern for applications
[14:35:32] <lincolnthree1> right, installing a security layer for example
[14:35:37] <nickarls> forge probably has added value for people resolving bug reports and need to create projects often
[14:35:51] <lincolnthree1> <---
[14:36:02] <lincolnthree1> i use it all the time to create empty projects to test bugs
[14:36:17] <sbryzak> why spend hours trying to set it up and get it working when someone else has already done the work for you
[14:36:28] <sbryzak> being a good programmer is also about being productive
[14:36:31] <lincolnthree1> sbryzak :)
[14:36:42] <sbryzak> if you can reach your goals faster, then that's an advantage for you
[14:37:04] <Diablo-D3> sbryzak: well, that leads to issues
[14:37:11] <Diablo-D3> because you have to trust coders to insert code into your program
[14:37:23] <lincolnthree1> Diablo-D3: http://pastebin.com/3bd1jPrm
[14:37:24] <Diablo-D3> at least with jars, you can throw their library out and slide another one in
[14:37:33] <lincolnthree1> Diablo-D3: how is that any different?
[14:37:36] <sbryzak> there's no trust required, the code is all in front of you
[14:37:45] <sbryzak> there's no black box, everything is open
[14:37:46] <Diablo-D3> well, lets try it a different way
[14:37:50] <sbryzak> so if you don't like something, you can modify it
[14:37:56] <Diablo-D3> people need to understand how security works
[14:38:00] <Diablo-D3> just adding it doesn tdo that
[14:38:19] <sbryzak> i could argue with that point
[14:38:24] <sbryzak> a lot of people won't care how it works
[14:38:29] * nickarls starts new projects so rarely so I've got by with copy&paste so far.
[14:38:34] <sbryzak> they'll just want it in their app
[14:38:36] <lincolnthree1> i'd argue that most people don't take the time to understand it well enough to do it right
[14:38:40] <lincolnthree1> so they cut and paste and get it wrong
[14:38:49] <lincolnthree1> exactly sbryzak
[14:38:49] <Diablo-D3> lincolnthree1: but this is just automated copypaste.
[14:39:05] <lincolnthree1> Diablo-D3: no different from including a JAR :)
[14:39:14] <lincolnthree1> except you can see what it does
[14:39:15] <Diablo-D3> hrrrm.
[14:39:44] <Diablo-D3> how can I abuse this for my own purpses?
[14:39:58] <lincolnthree1> write a plugin! http://docs.jboss.org/forge/snapshot/reference/en-US/html_single/
[14:40:04] <lincolnthree1> put it on http://github.com
[14:40:12] <Diablo-D3> could I misuse it to automate deploying my app?
[14:40:21] <lincolnthree1> then get people to install it http://pastebin.com/EEGLRHLJ
[14:40:24] <lincolnthree1> sure you could
[14:40:37] <lincolnthree1> in fact there's someone worknig on that plugin for jboss as now
[14:40:59] <lincolnthree1> but actually im not sure they've started ><
[14:41:05] <lincolnthree1> so it's still up for grabs
[14:41:09] <lincolnthree1> i can put you in touch with them
[14:41:18] <Diablo-D3> I can just wait for them to do it =P
[14:41:26] <Diablo-D3> or just write the plugin myself sometime in the far future
[14:41:55] <lincolnthree1> my favorite plugin is the one that automates linking my commits to JIRA issues
[14:42:04] <Diablo-D3> hehh
[14:45:19] <Diablo-D3> huh
[14:45:21] <Diablo-D3> interesting
[14:45:43] *** tsurdilo has joined #seam-dev
[14:47:08] <Diablo-D3> seam-security-external doesnt pull in seam-security
[14:49:15] <Diablo-D3> Im in ur seam, findin boogz
[14:51:17] *** kpiwko has quit IRC
[14:52:55] <jose_freitas>  does someone knows where and in which features jboss uses NIO ?
[14:53:05] <jose_freitas> java.nio
[14:53:22] <Diablo-D3> I assume networking
[14:55:51] <lincolnthree1> "new IO" i believe
[14:55:56] <lincolnthree1> just faster file based IO
[14:57:37] <Diablo-D3> well
[14:57:40] <Diablo-D3> its not even that faster
[14:57:43] <Diablo-D3> its just a less shittier api
[14:57:57] <Diablo-D3> but nio2 iirc is also under the java.nio namespace
[14:58:08] <sbryzak> it's designed to be scalable
[14:58:25] <nickarls> I/O is one place in java where it would be nice if one could just drop backwards compatibility
[14:58:57] <Diablo-D3> [ERROR] /home/diablo/Workspace/DiabloPool/src/main/java/authentication/OpenIdConfig.java:[7,35] package org.jboss.seam.servlet.event does not exist
[14:59:01] <Diablo-D3> I dont think so mvn
[14:59:56] <jose_freitas> I have a client that want to deploy a jboss app in windows azure (windows is offering the service and he is tempted)
[15:00:17] <Diablo-D3> > azure
[15:00:19] <Diablo-D3> > java
[15:00:20] <Diablo-D3> what
[15:00:28] <jose_freitas> but I read that jboss and jetty had problems running with azure because of the java.nio
[15:03:09] <jose_freitas> microsoft is making some noise saying that they also run java Diablo-D3
[15:03:25] <jose_freitas> and glassfish guys are fireworking that they're azure deployable
[15:04:47] <Diablo-D3> sounds like a trap
[15:06:17] <Diablo-D3> hrm
[15:06:21] <Diablo-D3> maven is confused somewhere
[15:06:35] <Diablo-D3> https://repository.jboss.org/nexus/content/groups/public/org/jboss/seam/security/seam-security-external/3.0.0.CR3/seam-security-external-3.0.0.CR3.pom
[15:06:43] <Diablo-D3> wait
[15:06:49] <Diablo-D3> why are those deps marked as provided?
[15:09:09] *** marekn has quit IRC
[15:09:19] *** marekn has joined #seam-dev
[15:13:39] *** lightguard_jp has joined #seam-dev
[15:19:54] *** jganoff has joined #seam-dev
[15:24:59] <Diablo-D3> gerk
[15:25:01] <Diablo-D3> something isnt right
[15:25:22] *** marekn has quit IRC
[15:42:05] *** amitev has quit IRC
[15:50:35] <jose_freitas> sbryzak: is there an example that uses @Permission ?
[16:01:59] *** tsurdilo1 has joined #seam-dev
[16:03:03] *** balunasj_mtg has quit IRC
[16:05:20] *** tsurdilo has quit IRC
[16:18:25] *** bleathem has joined #seam-dev
[16:23:42] <bleathem> I reformatted the source code of Faces last night.
[16:23:45] <bleathem> It's funny what it did to the github graph of my "impact" on the project.
[16:24:09] <bleathem> It's funny what it did to the github graph of my "impact" on the project.
[16:24:58] <Diablo-D3> its so funny you said it twice
[16:25:37] <bleathem> yeah, silly IRC client, it didn't show up the first time
[16:29:37] *** mgencur has left #seam-dev
[16:33:52] *** cbrock has quit IRC
[16:35:12] <jose_freitas> bleathem: hey
[16:35:44] <bleathem> jose_freitas hey!
[16:35:46] *** oskutka has quit IRC
[16:36:14] <jose_freitas> how r u doing?:
[16:40:05] *** pmuir has quit IRC
[16:40:51] *** koentsje has joined #seam-dev
[16:42:10] <bleathem> bagged!
[16:42:36] <bleathem> late night in IRC last night, but we've come up with a good API for the Faces/Security configuration
[16:42:39] *** tsurdilo1 has quit IRC
[16:42:59] *** tsurdilo has joined #seam-dev
[16:51:38] <jose_freitas> nice
[16:52:06] <jose_freitas> btw, the UIInputContainer ships with a gui component?
[16:52:39] <jose_freitas> I always used the p:input which is coded in booking
[16:52:52] <jose_freitas> but I thought that seam-faces had one by itself
[16:52:58] <bleathem> you'll have to ask lincolnthree1, I still need to dive into that codebase
[16:53:11] <bleathem> ^that part of the codebase
[16:53:14] <jose_freitas> np
[16:53:22] <lincolnthree1> jose_freitas: i beleive there is an issue to bundle p:input with seamfaces
[16:53:30] <lincolnthree1> not sure on its status
[16:53:48] <jose_freitas> hm, it'd be nice to bundle to the final release
[16:53:56] <jose_freitas> I presented the feature yesterday
[16:54:16] <bleathem> gotta love release deadlines!
[16:54:25] <jose_freitas> but to complete the exercise I had to use the component from booking
[16:54:46] <Diablo-D3> man
[16:54:49] <bleathem> we'll have frequent releases post Final
[16:55:15] 
[16:55:18] <bleathem> There are quite a few things that would be nice to make Final that we just don't have the time for
[16:55:34] * Diablo-D3 kicks maven hard
[16:55:39] <bleathem> but they'll come quickly
[16:55:41] <jose_freitas> yes, but seam it's pretty good already
[16:55:43] <Diablo-D3> package org.jboss.seam.security.external.openid.api does not exist
[16:55:50] <Diablo-D3> package org.jboss.seam.servlet.event does not exist
[16:55:56] <Diablo-D3> bullshit, Im staring right at them
[16:56:48] <jose_freitas> Diablo-D3: you said that you program for a lot of years now, how old are you?
[16:56:56] <Diablo-D3> 27
[16:58:13] <Diablo-D3> when were those classes added? before the current versions of their respective projects?
[16:58:41] <jose_freitas> https://issues.jboss.org/browse/SEAMFACES-43
[16:58:50] <jbossbot> jira [SEAMFACES-43] UIInputContainer should come with a standard implementation. (include example p:input from booking example) [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-43
[17:00:53] <jose_freitas> I see that's already planned for 3.0.1
[17:00:59] <Diablo-D3> [INFO] +- org.jboss.seam.security:seam-security-external:jar:3.0.0.CR3:runtime
[17:00:59] <Diablo-D3> [INFO] |  +- org.jboss.seam.servlet:seam-servlet:jar:3.0.0.CR3:runtime
[17:01:09] *** daniel_hinojosa has joined #seam-dev
[17:01:10] * Diablo-D3 repeatedly hits maven with a bat
[17:01:29] <jose_freitas> so if I put some effort this week on it could we have it for 3.0.0 ?
[17:01:48] <jose_freitas> I guess that'd be quite straight forward
[17:02:52] <jose_freitas> since the component in booking is quite stable
[17:04:30] *** amitev has joined #seam-dev
[17:05:30] <bleathem> jose_freitas: I haven't looked at it enough to say...
[17:05:31] <bleathem> If it works as required, and has the interface that we would want, then I don't see why not
[17:07:06] <Diablo-D3> jose_freitas: whydja wanna know?
[17:13:20] *** alesj has quit IRC
[17:15:07] <Diablo-D3> hrrrm
[17:15:13] <Diablo-D3> if I manually add seam-servlet to the pom
[17:15:16] <Diablo-D3> the servlet one goes away
[17:15:51] <Diablo-D3> rutrow
[17:15:52] <Diablo-D3> this is bad
[17:16:01] <Diablo-D3> I changed the pom to CR8
[17:16:47] <Diablo-D3> nm
[17:20:08] <Diablo-D3> nope, rolling it back the whole way to CR1 doesnt fix the problem
[17:25:51] <jose_freitas> bleathem: how do you test your different maven profiles?
[17:25:53] <jose_freitas> manually?
[17:26:37] <bleathem> check out the setup for testing in Seam Persistence.
[17:27:13] <bleathem> there is a separate artifact for what would be each profile you would want to test
[17:27:44] <bleathem> and an inheritance structure to the tests so they get shared amongst all test projects
[17:27:59] <bleathem> it's what Faces is going to adopt when I get the JSFUnit tests in place
[17:28:20] <bleathem> to solve this problem of testing differant configurations without using profiles
[17:29:12] <Diablo-D3> ./org/jboss/seam/security/external/openid/api/OpenIdRelyingPartyApi.class
[17:29:16] <Diablo-D3> goddamnit maven, the class is in the jar
[17:30:16] <Diablo-D3> I feel like Im going insane here
[17:31:41] <Diablo-D3> eclipse doesnt say theres any errors with missing clases
[17:35:34] <jose_freitas> Diablo-D3: maybe you have at eclipse project but maven is not integrated with jboss to deploy the dependencies
[17:35:48] <jose_freitas> jboss-tools have a module to make this integration
[17:35:56] <Diablo-D3> jose_freitas: nope, its mavenized in eclipse and that module is on
[17:36:01] <Diablo-D3> THIS error is from mvn in the command line
[17:36:24] <Diablo-D3> okay I think seam's poms are wrong
[17:36:40] <Diablo-D3> if I add <scope>compile</scope> to the dep for seam-security-external
[17:36:45] <Diablo-D3> it works
[17:45:21] *** gastaldi has joined #seam-dev
[17:45:30] <gastaldi> hello !!
[17:46:06] * Diablo-D3 has done his bug finding for the day
[17:46:29] <gastaldi> Who has commiter privileges on Seam Config ?
[17:47:06] <Diablo-D3> I wonder who I should report my bug to
[17:47:30] <gastaldi> I provided a pull request to SEAMXML-38, so that issue could be resolved as well.
[17:47:32] <jbossbot> jira [SEAMXML-38] Older CDI version specified explicitly [Pull Request Sent (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMXML-38
[17:47:47] <Diablo-D3> gastaldi: well, I found a new wonderful one
[17:47:59] <gastaldi> Diablo-D3: please tell me
[17:48:03] <gastaldi> :)
[17:48:10] <Diablo-D3> <scope>compile</scope> needs to be added to my dep of seam-security-external
[17:48:16] <Diablo-D3> _for no reason_
[17:48:23] <gastaldi> hail to maven !
[17:48:34] <Diablo-D3> Im looking at all the poms involved
[17:48:35] <Diablo-D3> and cant see why
[17:48:46] <gastaldi> Yeah, I got that once too
[17:49:03] <gastaldi> Dependencies are always not as they should be
[17:53:19] *** rruss has joined #seam-dev
[17:54:32] *** cbrock has joined #seam-dev
[17:54:32] *** cbrock has quit IRC
[17:54:33] *** cbrock has joined #seam-dev
[17:55:42] *** alesj has joined #seam-dev
[17:56:01] <Diablo-D3> bam bug filed
[18:01:33] *** gastaldi has quit IRC
[18:08:48] <lincolnthree1> link?
[18:58:22] <mojavelinux> jose making p:input available as a default would be excellent
[18:58:43] <mojavelinux> I would change the namespace though, something that is seamy
[18:58:44] <lightguard_jp> mojavelinux: Welcome back to the land of the living
[18:58:55] <mojavelinux> yeah, dev hangover again
[18:58:57] <lightguard_jp> p:blah looks more like Primefaces
[18:59:00] <mojavelinux> too much thinking
[18:59:04] <mojavelinux> right
[18:59:09] <mojavelinux> well, the prefix we don't have to set
[18:59:11] <mojavelinux> just the url
[18:59:41] <lightguard_jp> True
[19:03:53] *** tsurdilo has quit IRC
[19:05:15] *** sannegrinovero has quit IRC
[19:06:05] <Diablo-D3> lincolnthree1: er
[19:06:09] <Diablo-D3> https://issues.jboss.org/browse/SEAMSECURITY-48
[19:06:10] <jbossbot> jira [SEAMSECURITY-48] mvn dep scope wrong with seam-security-external + seam-bom [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMSECURITY-48
[19:13:47] *** rruss has quit IRC
[19:14:59] *** rruss has joined #seam-dev
[19:16:06] *** rruss has quit IRC
[19:19:13] *** amitev has quit IRC
[19:21:32] *** tsurdilo has joined #seam-dev
[19:35:31] <mojavelinux> the arquillian tests for seam booking are out of date
[19:35:46] <mojavelinux> I think arquillian should be updated to alpha5 in that example when the tests are fixed
[19:37:40] *** jganoff has quit IRC
[19:37:55] *** gastaldi has joined #seam-dev
[19:38:00] <gastaldi> hey stuartdouglas !
[19:38:57] <mojavelinux> I don't understand why I get this all the time
[19:38:59] <mojavelinux> http://stackoverflow.com/questions/850473/git-how-is-a-branch-im-not-committing-to-ahead-of-origin-master
[19:39:08] <mojavelinux> Your branch is ahead of 'origin/master' by 14 commits.
[19:39:10] <gastaldi> stuartdouglas: Would u mind merging https://github.com/seam/config/pull/5 whenever is possible ? That fixes an issue pending for 3.0.0.Final
[19:39:13] <mojavelinux> I clone a repository
[19:39:20] <mojavelinux> I don't touch the source code at all
[19:39:24] <mojavelinux> I do
[19:39:26] <mojavelinux> git pull origin master
[19:39:30] <mojavelinux> now it says
[19:39:35] <mojavelinux> Your branch is ahead of 'origin/master' by 14 commits.
[19:39:37] <mojavelinux> how?
[19:39:49] <mojavelinux> I have no made a single change to the source code or done any commits
[19:39:51] <gastaldi> I would like to know that also
[19:39:58] <gastaldi> I have the same issue Dan is telling about
[19:40:01] <mojavelinux> the only way out of this is
[19:40:07] <lincolnthree1> that's been happening to me too
[19:40:07] <mojavelinux> git --rest hard origin/master
[19:40:12] <lincolnthree1> reset
[19:40:16] <mojavelinux> git --reset hard origin/master
[19:40:16] <mojavelinux> thanks
[19:40:27] <mojavelinux> everyone jumps right to "well, when you commit"
[19:40:37] <mojavelinux> but i'm absolutely not touching the code
[19:41:02] <mojavelinux> everyone meaning responses on stackoverflow
[19:41:40] <gastaldi> GIT is still obscure to me.
[19:42:25] <mojavelinux> I don't think we have to jump right to getting on git's case
[19:42:31] <mojavelinux> my guess is that something is happening when we push
[19:42:35] <mojavelinux> that we are doing wrong
[19:42:44] <mojavelinux> either that, or this is just a part of using git
[19:42:50] <mojavelinux> i'd just like to know which it is
[19:43:02] <mojavelinux> also, i'm trying to figure out when you get this message
[19:43:07] <mojavelinux> even when you have made code changes
[19:43:11] <mojavelinux> how do you see what it is going to push
[19:43:22] <mojavelinux> if I do "git status" it says "up to date"
[19:43:22] <gastaldi> what if you fetch instead of pulling ?
[19:43:37] <mojavelinux> fetch doesn't actually make the changes locally
[19:43:43] <mojavelinux> it just collects them in your .git
[19:43:49] <mojavelinux> it doesn't apply them that is
[19:43:50] <gastaldi> hm
[19:43:58] <mojavelinux> pull is what actually applies the changes
[19:44:09] <mojavelinux> to your current checked out branch
[19:44:41] <gastaldi> From GIT docs: More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.
[19:46:37] <mojavelinux> hmm
[19:46:44] <mojavelinux> interesting
[19:46:45] <mojavelinux> so I did
[19:46:47] <mojavelinux> git pull origin master
[19:46:51] <mojavelinux> that made changes
[19:46:54] <mojavelinux> then I did
[19:46:57] <mojavelinux> git --fetch all
[19:47:00] <mojavelinux> then I did
[19:47:03] <mojavelinux> git pull origin master
[19:47:05] <mojavelinux> that made more changes
[19:47:09] <gastaldi> :P
[19:47:53] <gastaldi> Dan, are u the only one who commits on the repo ?
[19:48:00] <mojavelinux> git makes sense to me except for getting changes from the server
[19:48:03] <mojavelinux> that's where I get all screwed up
[19:48:19] <mojavelinux> syncing my source code
[19:48:26] 
[19:48:36] <gastaldi> Actually, there is no server
[19:48:37] <mojavelinux> I just want to know what I'm supposed to type
[19:49:02] <mojavelinux> let's say I want to make some changes to forge...lincoln has made a lot of changes, my checkout is out of date
[19:49:05] <mojavelinux> what do I type?
[19:49:13] <gastaldi> I do git pull origin master
[19:49:25] <mojavelinux> in my experience, that doesn't get all changes
[19:49:38] <gastaldi> git version maybe ?
[19:50:08] <mojavelinux> I think it's
[19:50:13] <mojavelinux> git --fetch all
[19:50:17] <mojavelinux> git pull origin master
[19:50:30] <mojavelinux> but that is giving me the "you have pending commits"
[19:50:45] <gastaldi> I think you should reset first
[19:51:01] <bleathem> lightguard_jp do you have the power to attend to my pull request on seam build?
[19:55:00] *** jganoff has joined #seam-dev
[19:55:06] <jbossbot> git [persistence] push master d0983bb.. Dan Allen SEAMPERSIST-41 remove explicit CDI API version
[19:55:06] <jbossbot> jira [SEAMPERSIST-41] Older CDI version specified explicitly [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMPERSIST-41
[19:55:07] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/19fe4bb...d0983bb
[19:56:37] *** cbrock has quit IRC
[19:57:40] *** bitshuffler has joined #seam-dev
[19:58:52] *** cbrock has joined #seam-dev
[19:59:00] *** cbrock has quit IRC
[19:59:00] *** cbrock has joined #seam-dev
[19:59:26] <jbossbot> git [build] push master 8c39a3e.. Brian Leathem add code formatting for Netbeans
[19:59:26] <jbossbot> git [build] push master URL: http://github.com/seam/build/compare/4769a36...8c39a3e
[19:59:46] <mojavelinux> thanks brian! we were waiting for those rules ;)
[19:59:53] <mojavelinux> you said you changed the line length
[20:00:03] <mojavelinux> does netbeans use 4 spaces for indentation in all cases?
[20:00:19] <mojavelinux> interesting that the netbeans default is different than the java conventions default
[20:00:55] <mojavelinux> brian, what is it netbeans-eclipse-jboss-formatter-profile?
[20:01:00] <mojavelinux> what's the "eclipse" for?
[20:01:12] <bleathem> yes, 4 for all cases
[20:01:18] <bleathem> oops, c&P error
[20:01:24] <bleathem> copy and paste error
[20:01:29] <bleathem> lol
[20:01:33] <lightguard_jp> bleathem: Yes, I can do it if Dan or Shane don't get to it first
[20:01:36] <bleathem> I'll correct and repush
[20:02:12] <bleathem> I wanted to match the naming convention used for IDEA and Eclipse
[20:02:58] <mojavelinux> i can fix it
[20:03:25] <mojavelinux> we should probably have instructions for how to apply these
[20:03:49] <jbossbot> git [build] push master cf7a5ef.. Dan Allen rename
[20:03:50] <jbossbot> git [build] push master URL: http://github.com/seam/build/compare/8c39a3e...cf7a5ef
[20:03:52] <mojavelinux> there
[20:04:23] <lightguard_jp> mojavelinux: did you just pull in bleathem's changes as well?
[20:04:43] <mojavelinux> yep
[20:05:07] <lightguard_jp> Okay
[20:06:44] <jbossbot> git [persistence] push master 3574ccf.. Dan Allen correct capitalization for JBoss AS naming references
[20:06:44] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/d0983bb...3574ccf
[20:07:10] <mojavelinux> back down to 67 issues
[20:07:20] <mojavelinux> some of these issues are documentation in various places
[20:07:26] <mojavelinux> feel free to snag those if you know the answer
[20:11:36] <bleathem> I haven't tagged this one for Final yet, but it looks like it might be a Weld issue: SEAMFACES-114
[20:11:38] <jbossbot> jira [SEAMFACES-114] DeploymentException: WELD-001408 [Open (Unresolved) Bug, Major, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-114
[20:11:45] <bleathem> anyone recognize that stack trace?
[20:12:07] <bleathem> DeploymentException: WELD-001408 Unsatisfied dependencies for type [FormValidationTypeOverrideExtension] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.faces.util.BeanManagerUtils.classExtension]
[20:13:31] *** alesj has quit IRC
[20:15:36] <cbrock> mojavelinux: ping
[20:17:05] *** gastaldi has quit IRC
[20:20:45] <mojavelinux> hey mike
[20:20:50] <mojavelinux> nope bleathem haven't seen that one yet
[20:21:02] <mojavelinux> I don't think we should worry about getting solder working on the ibm jvm for 3.0.0.Final
[20:21:12] <mojavelinux> that is a whole other can of worms which could trickle down to all modules
[20:21:18] <mojavelinux> that needs to be pushed
[20:21:28] <mojavelinux> though we should have a hudson job checking for each module on the ibm jvm
[20:21:34] <mojavelinux> for completeness
[20:22:46] <lightguard_jp> bleathem: Where do converters go? I also assume I'll need to create a tag?
[20:23:27] <bleathem> are you working on seamfaces-28?
[20:23:55] <bleathem> org.jboss.seam.conversion
[20:23:55] <lightguard_jp> Yep
[20:24:00] <lightguard_jp> api?
[20:24:50] <bleathem> I did one, and had to put it in impl, let me check why
[20:25:51] <bleathem> oh, I think it's because I was using the Message factory from international impl, and disn't want to have a Faces api dependency on intl impl
[20:26:01] <bleathem> regardless, I'm not using that factory, so it could move to api
[20:26:40] <bleathem> if you ant to move the one from impl to api when you create the others, that would be cool
[20:26:49] <bleathem> ^if you want...
[20:27:05] <mojavelinux> in Seam, we need to decide if we are going all uppercase with acronyms, or doing camelcase
[20:27:10] <mojavelinux> because we are inconsistent atm
[20:27:21] <bleathem> you mean inconsistent Atm
[20:27:56] * bleathem fyi that was supposed to be funny
[20:28:00] <cbrock> mojavelinux: just wanted to touch base on the Errai-CDI docs stuff
[20:28:01] <lightguard_jp> Or ATM or aTm or atM or aTM or ATm
[20:28:04] <lightguard_jp> Or AtM
[20:28:10] <lightguard_jp> Think I got them all
[20:28:10] <bleathem> lightguard_jp thanks!
[20:28:27] <mojavelinux> want to talk about it on the call?
[20:28:40] <cbrock> mojavelinux: ok. everything is all ready to go. the 1.2.2 release went out today.
[20:28:47] <mojavelinux> fantastic
[20:29:20] <lightguard_jp> bleathem: Hm, not sure if I can use that abstract converter
[20:29:20] <bleathem> FWIW My preference is normal camel case for acronyms. inconstistentAtm
[20:29:34] <bleathem> you don't have to
[20:29:41] <cbrock> now I need to spin up a Windows Virtual Machine and figure out this problem that lincolnthree1 is upset about in Forge
[20:29:42] <bleathem> it's a convenience for devs to use
[20:29:50] <bleathem> should be no difference if you use it or not
[20:29:58] * lincolnthree1 cracks the whip
[20:30:11] <mojavelinux> i'm partial to the uppercase, though even the jdk isn't consistent
[20:30:12] <lightguard_jp> bleathem: In that case it should go into API
[20:30:27] <bleathem> right, please move it to API
[20:30:33] <bleathem> the abstract one
[20:30:40] <bleathem> if you don't mind :P
[20:30:42] <lightguard_jp> mojavelinux: It's consistently inconsistent
[20:30:48] <lightguard_jp> Okay
[20:31:10] <bleathem> jason lee had lots to say about this at one point
[20:31:36] <lightguard_jp> We're not using package-info.java here, probably something we should address post 3.0.0.final
[20:33:34] <cbrock> I have to like, book my JBoss World stuff at some point
[20:34:17] <cbrock> while VMWare is taking a coffee break, I should perhaps look into that
[20:34:31] * bleathem polling jdlee for his thought
[20:34:34] * bleathem s
[20:35:35] <jbossbot> git [persistence] push master f525e5d.. Dan Allen SEAMPERSIST-42 remove references to slf4j
[20:35:38] <jbossbot> jira [SEAMPERSIST-42] seam-persistence depends on slf4j (TransactionExtension). please replace with jboss-logging [Open (Unresolved) Bug, Blocker, Unassigned] https://issues.jboss.org/browse/SEAMPERSIST-42
[20:35:39] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/3574ccf...f525e5d
[20:35:47] <bleathem> do you prefer: XMLHTMLConverter or: XmlHtmlConverter ?
[20:35:52] <bleathem> I prefer the latter
[20:49:22] <lightguard_jp> What's the scope of a converter?
[20:49:54] <lightguard_jp> I had a route I wanted to go, but now I'm so sure.
[20:50:22] <lightguard_jp> I wanted to use the entity manager, but getting the id isn't as easy as I origianally thought
[20:51:29] <lightguard_jp> Why is it http://download.oracle.com/javaee/6/api/ and http://download.oracle.com/javaee/6/docs/api/ ??
[20:51:32] <lightguard_jp> grr
[20:52:16] <nickarls> jp: jsf converter?
[20:52:52] <mojavelinux> bleathem: fixed SEAMFACES-117 for ya
[20:52:54] <jbossbot> jira [SEAMFACES-117] remove slf4j dependency [Open (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-117
[20:53:11] <lightguard_jp> nickarls: Yeah
[20:54:28] <bleathem> mojavelinux: Great, thanks!
[20:54:31] <nickarls> jp: I think "as short as possible" was the guideline at some point
[20:55:00] <nickarls> or did you mean general @FacesConverter?
[20:56:10] <lightguard_jp> "as short as possible probably works okay"
[20:56:15] <lightguard_jp> Still trying
[20:58:58] *** koentsje has quit IRC
[20:59:17] <nickarls> jp: working on the entityConverter?
[21:01:47] <mojavelinux> we need a blanket issue for upgrading to Arquillian 1.0.0.Alpha5
[21:02:11] <mojavelinux> that should also entail switching from org.jboss.weld.arquillian weld embedded
[21:02:14] <mojavelinux> to the one from arquillian
[21:02:56] <jbossbot> git [config] push master 5d5b650.. George Gastaldi SEAMXML-38
[21:03:00] <jbossbot> jira [SEAMXML-38] Older CDI version specified explicitly [Pull Request Sent (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMXML-38
[21:03:00] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/c38ab33...5d5b650
[21:05:43] <lightguard_jp> nickarls: Yeah
[21:05:49] <jbossbot> git [config] push master b758f30.. Dan Allen Merge branch 'master' of https://github.com/rebecca-newton/config into rebecca-newton-master
[21:05:49] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/5d5b650...b758f30
[21:06:02] <lightguard_jp> nickarls: Thought I had it figured out in my head, proving a little harder to actually implement it
[21:10:18] <lightguard_jp> Wow, really hitting mental brick walls here :(
[21:10:42] <nickarls> jp: seam 2 light version can probably be cloned
[21:10:55] <jbossbot> git [config] push master f9710f9.. Dan Allen add link to JSR-299 proposal draft
[21:10:55] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/b758f30...f9710f9
[21:10:58] <nickarls> hiberante is not first class citizen in seam3 ;-)
[21:11:06] <lightguard_jp> Possibly.
[21:11:10] <lightguard_jp> I need to look
[21:11:22] <nickarls> jp: the design is ok if I recall corretly
[21:11:36] <nickarls> but seam2 had some performance issues, I think
[21:11:47] <nickarls> when used in large dropdowns
[21:11:52] <lightguard_jp> ui/src/main/java/org/jboss/seam/ui/EntityConverter.java
[21:11:54] <lightguard_jp> ?
[21:12:03] <nickarls> I recall using objectconverter
[21:12:07] <nickarls> I think so
[21:12:53] <lightguard_jp> Looks like all the work is done in the AbstractEntityLoader
[21:15:39] <bleathem> mojavelinux: My SecurityPhaseListener now scans SecurityBindingType qualified annotations, looking for a restrictAtPhase method.
[21:15:49] <lightguard_jp> nickarls: It's assuming the id is an integer.
[21:15:49] <nickarls> jp: the implementations is pretty straightforward
[21:15:59] <bleathem> Do we still want to keep the @RestrictAtPhase annotation around?
[21:16:20] <nickarls> jp: no
[21:16:35] <nickarls> the idstore maps object ids to numeric ids
[21:16:37] <bleathem> It would allow one to set the default restriction phase for a group of annotations together
[21:16:52] <lightguard_jp> Unless that was changed since 2.2.1.CR1 (which is the source I'm looking at)
[21:17:00] <mojavelinux> fantastic bleathem
[21:17:03] <mojavelinux> i think we can keep it
[21:17:06] <bleathem> ok
[21:17:06] <nickarls> hmm, let me check, it's been a while
[21:17:17] <bleathem> sounds good
[21:17:46] <nickarls> jp: Identifier
[21:19:17] <nickarls> http://anonsvn.jboss.org/repos/seam/tags/JBoss_Seam_2_2_1_Final/src/main/org/jboss/seam/framework/Identifier.java
[21:19:55] <nickarls> and http://anonsvn.jboss.org/repos/seam/tags/JBoss_Seam_2_2_1_Final/src/main/org/jboss/seam/framework/EntityIdentifier.java
[21:21:18] <nickarls> ending up at http://anonsvn.jboss.org/repos/seam/tags/JBoss_Seam_2_2_1_Final/src/main/org/jboss/seam/Entity.java
[21:21:26] <nickarls> for extracting the id of the entity
[21:22:42] <jbossbot> git [faces] push master 1960dcc.. Brian Leathem Added check for restrictAtView method in SecurityBindingType annotations, temporary drop of @RestrictAtView support
[21:22:43] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/fc52b04...1960dcc
[21:22:48] <lightguard_jp> nickarls: Okay.
[21:23:55] <lightguard_jp> nickarls: Sounds like one way we could do this would be to implement PartialStateHolder
[21:24:14] <lightguard_jp> That would keep all of that info in the converter
[21:24:52] <jbossbot> git [servlet] push master 873f535.. Dan Allen SEAMSERVLET-33 remove hardcoded versions
[21:24:53] <jbossbot> jira [SEAMSERVLET-33] Solder version hardcoded in the API module [Resolved (Done) Bug, Minor, Dan Allen] https://issues.jboss.org/browse/SEAMSERVLET-33
[21:24:53] <jbossbot> git [servlet] push master URL: http://github.com/seam/servlet/compare/4f47e41...873f535
[21:25:07] <mojavelinux> down to 60 issues
[21:25:09] <jbossbot> git [faces] push master 619af21.. Dan Allen SEAMFACES-117 remove slf4j usage in tests
[21:25:17] <nickarls> jp: I think extracting the entity id is still important if you want to go the entitymanager route. or?
[21:25:19] <mojavelinux> with a couple pull requests pending
[21:25:33] <jbossbot> jira [SEAMFACES-117] remove slf4j dependency [Pull Request Sent (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-117
[21:25:33] <jbossbot> git [faces] push master URL: http://github.com/seam/faces/compare/1960dcc...619af21
[21:25:43] <nickarls> object and enumconverters are easyish
[21:26:08] <nickarls> I think seam2 entityconverter even had version-checking if I don't remember wrong
[21:26:37] <mojavelinux> anyone want to try this one using arquillian?
[21:26:38] <lightguard_jp> Maybe I'm just over thinking it
[21:26:46] <mojavelinux> SEAMFACES-71
[21:26:47] <jbossbot> jira [SEAMFACES-71] Document setup for event observer in EJB JAR [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-71
[21:27:35] <bleathem> jose_freitas you sound busy... I can take on SF-101 if you want to focus on the p:input (s:input) support.
[21:28:01] <nickarls> jp: personally I would just go for @Id annotation support in first version
[21:28:19] <nickarls> check field or getter like seam2 but ignore xml
[21:28:24] <lightguard_jp> nickarls: Given the time constraint that's probably a safer bet
[21:28:36] <nickarls> atomicinteger key, mapped int -> identifier
[21:29:15] <jbossbot> git [solder] push master e6b7a0c.. John Ament SOLDER-59 Create logger utility to log the version information about a module.
[21:29:16] <jbossbot> jira [SOLDER-59] Create utility for printing the version number of an extension [Resolved (Done) Feature Request, Major, John Ament] https://issues.jboss.org/browse/SOLDER-59
[21:29:16] <jbossbot> git [solder] push master 55a075f.. John Ament SOLDER-82 provide same functionality in typed logger for cases when no category or typed category present.
[21:29:17] <jbossbot> jira [SOLDER-82] Allow category for typed loggers to be defaulted [Resolved (Done) Enhancement, Minor, John Ament] https://issues.jboss.org/browse/SOLDER-82
[21:29:17] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/7b4dfcd...55a075f
[21:29:51] *** jharting has joined #seam-dev
[21:31:52] *** koentsje has joined #seam-dev
[21:32:17] <mojavelinux> under 60 issues
[21:32:18] <mojavelinux> woot
[21:32:21] <mojavelinux> okay, time for lunch
[21:34:00] *** balunasj has joined #seam-dev
[21:34:02] *** balunasj has joined #seam-dev
[21:35:56] * nickarls is laughing hysterically at SEAMINTL-33
[21:35:57] <jbossbot> jira [SEAMINTL-33] Injections null when Bundles.get(String) is called [Reopened (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-33
[21:36:37] *** alesj has joined #seam-dev
[21:39:25] *** PeteRoyle has joined #seam-dev
[21:40:31] <lincolnthree1> hey mojavelinux you there?
[21:40:33] *** Obsidians has quit IRC
[21:40:42] <lincolnthree1> quick CDI observer question
[21:41:02] <lincolnthree1> Can observer methods observe Genericised Types?
[21:41:16] <lincolnthree1> public void setup(@Observes SetupPlugin<MyPlugin> event)
[21:41:17] <lincolnthree1> {
[21:41:17] <lincolnthree1> }
[21:41:26] <lincolnthree1> maybe lightguard_jp might know? you did something similar in catch?
[21:42:08] <lightguard_jp> Yeah, that works
[21:42:29] <lightguard_jp> All of the CDI lifecycle types are generic
[21:42:49] <lightguard_jp> Well, maybe not all, but I know some of them are
[21:43:11] <lincolnthree1> hmm... tricky part is how to fire that event dynamically
[21:43:31] <lincolnthree1> thanks
[21:44:05] *** balunasj has quit IRC
[21:51:17] <lincolnthree1> https://issues.jboss.org/browse/SEAMFORGE-92
[21:51:20] <jbossbot> jira [SEAMFORGE-92] Centralize the plugin setup process [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFORGE-92
[21:58:08] <jbossbot> git [forge] push master ee929e4.. Mike Brock merge
[21:58:09] <jbossbot> git [forge] push master bc31d86.. Mike Brock Merge branch 'master' of http://github.com/lincolnthree/seam-forge
[21:58:09] <jbossbot> git [forge] push master 2d70112.. Mike Brock fix: output buffer not flushing.
[21:58:09] <jbossbot> git [forge] push master c31bd50.. Lincoln Baxter, III facet installation
[21:58:09] <jbossbot> git [forge] push master 4d9031d.. Lincoln Baxter, III Merge branch 'master' of git://github.com/mikebrock/seam-forge
[21:58:09] <jbossbot> git [forge] push master cfd04d4.. Lincoln Baxter, III Fixed facet installation, much more stable
[21:58:09] <jbossbot> git [forge] push master 2f19c10.. Lincoln Baxter, III SEAMFORGE-91
[21:58:14] <jbossbot> jira [SEAMFORGE-91] Tab completion should automatically fill the next required named option [Closed (Done) Enhancement, Major, Lincoln Baxter III] https://issues.jboss.org/browse/SEAMFORGE-91
[21:58:14] <jbossbot> git [forge] push master a3e026d.. Lincoln Baxter, III Improved error messaging for plugins with commands, fixed bug with Null Enum based @options
[21:58:15] <jbossbot> git [forge] push master 7b783d3.. Lincoln Baxter, III Fixed repo plugin installer. Updated help plugin. Updated ShellColor.ITALIC
[21:58:15] <jbossbot> git [forge] push master 1baf3a1.. Lincoln Baxter, III Moved facet manipulation to project plugin
[21:58:15] <jbossbot> git [forge] push master 6d0a5c6.. Lincoln Baxter, III SEAMFORGE-81
[21:58:15] <jbossbot> jira [SEAMFORGE-81] Documentation issues [Closed (Done) Bug, Major, Lincoln Baxter III] https://issues.jboss.org/browse/SEAMFORGE-81
[21:58:15] <jbossbot> git [forge] push master 8dfb7de.. Lincoln Baxter, III SEAMFORGE-81
[21:58:16] <jbossbot> git [forge] push master 4ca3b15.. Lincoln Baxter, III mention AS7
[21:58:16] <jbossbot> git [forge] push master e5ded07.. Lincoln Baxter, III ForgePlugin no longer gives duplicate abort messages
[21:58:17] <jbossbot> git [forge] push master c9ba936.. Lincoln Baxter, III fixed nullpointers when calling shell.print(null) and related methods
[21:58:17] <jbossbot> git [forge] push master 6cab6ca.. Lincoln Baxter, III Added XML to string serialization methods
[21:58:18] <jbossbot> git [forge] push master f718893.. Lincoln Baxter, III Moved InstallFacets operations to ProjectPlugin, which is now a built-in plugin for the time being. Tested ShellPrintWriter methods. Improved HelpFacet
[21:58:18] <jbossbot> git [forge] push master 1b786dd.. Lincoln Baxter, III Updated docs to include Shading dependencies
[22:01:16] *** cbrock has quit IRC
[22:01:22] <mojavelinux> if someone can explain to Mark Struberg how to run the Solder tests, he will get the open web beans profile working
[22:01:31] <mojavelinux> this may require an upgrade to Arquillian 1.0.0.Alpha5
[22:01:39] <mojavelinux> because I think the open web beans integration was fixed
[22:02:14] <aslak> mojavelinux, fixed and upgraded to openwebbeans 1.0 final
[22:02:17] *** cbrock has joined #seam-dev
[22:02:17] *** cbrock has quit IRC
[22:02:17] *** cbrock has joined #seam-dev
[22:06:29] *** alesj has quit IRC
[22:06:52] *** alesj has joined #seam-dev
[22:09:40] *** PeteRoyle has quit IRC
[22:13:36] *** oskutka has joined #seam-dev
[22:14:21] <mojavelinux> super!
[22:14:30] <mojavelinux> unfortunately, solder needs an update to alpha5
[22:14:35] <mojavelinux> and that hasn't been done yet
[22:21:22] <lincolnthree1> SEAM-38
[22:21:25] <jbossbot> jira [SEAM-38] new-entity command throws java.lang.NoSuchMethodError: org.eclipse.jdt.internal.compiler.impl.CompilerOptions.getSeverity(J)I [Open (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAM-38
[22:22:23] <lightguard_jp> https://gist.github.com/885926
[22:22:29] <lightguard_jp> What does everyone think? ^^
[22:24:30] <lightguard_jp> nickarls: That may actually take care of all cases.
[22:25:18] <nickarls> jp: have to melt the idea a bit, never used a PSH ;-)
[22:25:25] *** Camilo has joined #seam-dev
[22:26:35] *** tsurdilo has quit IRC
[22:29:11] *** jganoff has quit IRC
[22:29:20] <nickarls> jp: but yes, anything more simple than that can't possibly work :-)
[22:29:33] <sbryzak> stuartdouglas: ping
[22:29:41] <stuartdouglas> sbryzak: pong
[22:29:48] <sbryzak> hey stuart
[22:29:50] <mojavelinux> if we bump issues from 3.0.0.Final, let's make sure they end up in a version like 3.0.1.Beta1
[22:29:59] <mojavelinux> so they don't fall off the map
[22:30:04] <sbryzak> stuartdouglas: i need you to bump your issues
[22:30:10] <mojavelinux> i added 3.0.1.Beta1 to several modules already (solder, servlet, wicket)
[22:30:15] <mojavelinux> others may need target versions setup
[22:30:19] <sbryzak> unless it's something that absolutely must make it into the 3.0 release
[22:30:22] <Diablo-D3> did you see the new issue I posted?
[22:30:27] <stuartdouglas> ok, do you want me to go through and bump them?
[22:30:31] <mojavelinux> any issue that says "add API" should probably be bumped
[22:30:35] <sbryzak> stuartdouglas: yes please
[22:30:53] <Diablo-D3> https://issues.jboss.org/browse/SEAMSECURITY-48
[22:30:55] <jbossbot> jira [SEAMSECURITY-48] mvn dep scope wrong with seam-security-external + seam-bom [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMSECURITY-48
[22:30:55] <sbryzak> we need to narrow that list down to focus on just the issues for 3.0
[22:31:03] *** bitshuffler has quit IRC
[22:31:04] <Diablo-D3> that should be fixed before 3.0 final
[22:31:21] <lightguard_jp> nickarls: Let me know.
[22:31:32] <sbryzak> Diablo-D3: yes i saw it, thanks for raising it
[22:32:09] <lightguard_jp> bleathem or mojavelinux If you want to look at that gist I posted, that's my current impl for entityConverter
[22:32:22] <sbryzak> be right back, need to reboot my PC
[22:32:45] *** sbryzak has quit IRC
[22:33:00] *** jharting has left #seam-dev
[22:33:10] <mojavelinux> looking in a moment
[22:33:25] *** jharting has joined #seam-dev
[22:33:25] <nickarls> jp: did you try it in action?
[22:33:53] <lightguard_jp> nickarls: No, not yet.
[22:34:10] <lightguard_jp> Finish it and posted it up to get initial feedback
[22:34:42] <lightguard_jp> bleathem: Are the tests for faces good enough I could write an arquillian test for this converter instead of a full blown app?
[22:34:52] <nickarls> a way to control scope would be nice
[22:35:08] <bleathem> lightguard_jp so far looks good!
[22:35:31] <bleathem> we've got arquillian tests in faces, just no JSFUnit tests yet
[22:35:48] <lightguard_jp> bleathem: I'd need to get an FacesContext to test this
[22:36:07] <lightguard_jp> nickarls: I'm not sure how that works in Seam faces (the scope of converters).
[22:36:42] <lightguard_jp> They may just be page scoped
[22:37:01] <bleathem> SeamFaces will replace JSF managed instances of Converters and validaotrs with instances retrieved from the bean manager
[22:37:06] <nickarls> is there some factory in faces that can be overridden for it?
[22:37:12] <bleathem> this is how we get injection to work in convertors/validators
[22:37:23] <bleathem> I suppose it would support scopes as well,
[22:37:31] <lightguard_jp> I just add a scope to the converter then?
[22:37:32] <bleathem> but what would define the context?
[22:37:40] <bleathem> yeah, try addind a scope
[22:37:55] <bleathem> add a @PostConstruct logger to see how often it gets initalised
[22:38:02] <oskutka> sbryzak: https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12314299
[22:38:02] <oskutka> sbryzak: This list includes also bugs that don't have "fix version" filled in.
[22:38:02] <oskutka> sbryzak: The good news is that you can some of them (at least the first two) mark as "out of date"
[22:38:02] <oskutka> sbryzak: The bad news is there will be still bie87 to go...
[22:38:10] <nickarls> it would perhaps be confusing if seam had a @FacesConverter of its own
[22:39:18] <oskutka> ...premature enter. Shane's not here yet.
[22:39:40] *** sbryzak has joined #seam-dev
[22:39:40] *** sbryzak has quit IRC
[22:39:40] *** sbryzak has joined #seam-dev
[22:39:41] <lightguard_jp> oskutka: No, he is
[22:40:04] <oskutka> sbryzak: https://issues.jboss.org/secure/IssueNavigator.jspa?mode=hide&requestId=12314299
[22:40:05] <oskutka> sbryzak: This list includes also bugs that don't have "fix version" filled in.
[22:40:05] <oskutka> sbryzak: The good news is that you can some of them (at least the first two) mark as "out of date"
[22:40:05] <oskutka> sbryzak: The bad news is there will still be 87 to go...
[22:40:09] <mojavelinux> aslak, do you think you could fork solder, update it to Arquillian Alpha 1.0.0.Alpha5 and add an OWB profile?
[22:40:27] <mojavelinux> to set it up, it shouldn't be too much effort
[22:40:46] <sbryzak> oskutka: ok, i guess the first thing we need to do is set up some future versions
[22:40:47] <lightguard_jp> Looks like I'll have to create a simple app to test this converter, oh, I need a tag too don't I?
[22:40:47] <aslak> sure
[22:40:49] <mojavelinux> we'll let Mark actually worry about running the tests...they don't have to pass for 3.0.0.Final, but I do want to seize his offer
[22:41:02] <sbryzak> oskutka: 3.0.1.Beta I guess
[22:41:25] <sbryzak> oskutka: I'll go through the list now and assign as many versions as i can
[22:41:26] <oskutka> sbryzak: Either that or just "FUTURE" or "TBD" as in other projects.
[22:41:41] <sbryzak> oskutka: yeah that might be more appropriate
[22:42:58] <sbryzak> i'm constantly getting bad gateway errors in jira
[22:43:07] *** PeteRoyle has joined #seam-dev
[22:43:42] <mojavelinux> i can't believe there is no getId() method for a jpa entity
[22:43:48] <mojavelinux> not on the entity, but on the entitymanager
[22:43:54] <mojavelinux> I swear there was one
[22:44:25] <sbryzak> mojavelinux: you can just scan for the @Id annotation
[22:44:31] <lightguard_jp> mojavelinux: Nope, gotta go through the metamodel
[22:44:34] <mojavelinux> that's what jason is doing
[22:44:40] <mojavelinux> sorry, yes
[22:44:41] *** Royle has joined #seam-dev
[22:44:45] <mojavelinux> you are using metamodel
[22:44:46] <sbryzak> i'm pretty sure that's what i do in security
[22:44:52] <lightguard_jp> sbryzak: But you can also define your entities in XML
[22:44:54] <nickarls> and check orm.xml
[22:44:59] <mojavelinux> I remember walking down the streets of san fran talking to emmanuel and gavin about this method
[22:45:03] <mojavelinux> guess they lost ;)
[22:45:06] <sbryzak> that's when it becomes a problem i guess
[22:45:10] <lightguard_jp> Yep
[22:45:25] <nickarls> @EmbeddedId
[22:45:31] <jbossbot> git [solder] push master 54f078f.. Stuart Douglas SOLDER-94 fix thread safety issue
[22:45:32] *** oskutka has quit IRC
[22:45:34] <lightguard_jp> The metamodel gives you want you want, little cumbersome though.
[22:45:43] <jbossbot> jira [SOLDER-94] ConcurrentModificationException looking up BeanManager [Open (Unresolved) Bug, Critical, Stuart Douglas] https://issues.jboss.org/browse/SOLDER-94
[22:45:43] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/55a075f...54f078f
[22:45:43] <lightguard_jp> nickarls: Yeah that too
[22:46:13] <bleathem> lightguard_jp regarding your converter name, that's a long ID to have to type in a facelet file.
[22:46:26] <bleathem> How about just org.jboss.seam.EntityCOnverter ?
[22:46:37] <lightguard_jp> bleathem: Can do that too
[22:46:46] <bleathem> Still will be unique
[22:46:52] <mojavelinux> I think that was the convention we were going with
[22:46:53] <mojavelinux> yes
[22:46:59] <mojavelinux> just qualify it to us
[22:46:59] <nickarls> @IdClass check needed too?
[22:47:03] <mojavelinux> the context does the rest
[22:47:12] <nickarls> or was @Id still used with @EmbeddedId and @IdClass?
[22:47:15] <mojavelinux> here is the code in Seam 2 that does this check
[22:47:31] *** PeteRoyle has quit IRC
[22:47:32] *** Royle is now known as PeteRoyle
[22:47:33] <mojavelinux> http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_3/src/main/org/jboss/seam/Entity.java
[22:48:43] <lightguard_jp> mergeAnnotationAndOrmXml ... ouch
[22:49:14] <mojavelinux> I think in jpa 2 that isn't required
[22:49:18] <mojavelinux> that's what Metamodel does for you
[22:49:19] <mojavelinux> unless
[22:49:29] <lightguard_jp> Yep
[22:49:33] <mojavelinux> the Metamodel is the actual generated classes
[22:49:41] <mojavelinux> not sure if you get Metamodel if you don't generate the classes
[22:49:43] <lightguard_jp> No, they're not.
[22:49:43] <mojavelinux> hmm
[22:49:57] <mojavelinux> okay, so there is a getId() method
[22:50:01] <mojavelinux> it's on EntityType
[22:50:02] <mojavelinux> oh, btw
[22:50:10] <mojavelinux> you don't need to do getJavaMember() and check what it is
[22:50:14] <mojavelinux> you can use getIdType()
[22:50:18] <mojavelinux> that will tell you the same info
[22:50:24] <lightguard_jp> Provides access to the metamodel of persistent entities in the persistence unit.
[22:50:46] <jbossbot> git [solder] push master a61f83f.. Stuart Douglas SOLDER-3
[22:50:47] <jbossbot> jira [SOLDER-3] OTT Exception wrapping [Closed (Done) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/SOLDER-3
[22:50:47] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/54f078f...a61f83f
[22:50:55] <mojavelinux> hasSingleIdAttribute Whether the identifiable type has a single id attribute. Returns true for a simple id or embedded id; returns false for an idclass.
[22:51:26] <mojavelinux> I can't believe there is no getIdValue()
[22:51:50] <lightguard_jp> But the getJavaMember will actually allow me to get the value from the instance
[22:52:00] <mojavelinux> ah, but that you should delegate to Solder
[22:52:06] <nickarls> time to file a request for JPA 2.1
[22:52:14] <mojavelinux> if there isn't a method in solder to fit, we can add one
[22:52:22] <nickarls> EntityManager.isDirty(Object) would be nice, too
[22:52:23] <mojavelinux> but it should be in the properties
[22:52:27] <mojavelinux> seriously
[22:53:11] <lightguard_jp> Delegate to solder... There's something is solder that'll do that for me?
[22:53:43] <mojavelinux> yep
[22:53:49] <mojavelinux> Properties.createProperty(Member)
[22:53:56] <mojavelinux> Property p = Properties.createProperty(Member)
[22:54:14] <mojavelinux> p.getValue(instance);
[22:54:15] <mojavelinux> voila
[22:54:48] <mojavelinux> a
[22:54:52] <mojavelinux> p.setAccessible()
[22:55:07] <mojavelinux> also does it in priviledged ;)
[22:57:14] <lightguard_jp> Sweet
[22:58:06] <nickarls> now all you need is an elegant way to find out *which* member to query
[22:59:31] <lightguard_jp> Updated with that
[22:59:42] <lightguard_jp> nickarls: Huh?
[22:59:49] *** koentsje has quit IRC
[23:00:02] <lightguard_jp> nickarls: I should have the correct member for the id from the metamodel
[23:00:34] <mojavelinux> yeah, he's got that
[23:00:41] <mojavelinux> it just reduces all those lines of code ;)
[23:01:40] <mojavelinux> i'm curious to know if that works if you don't use jpa 2
[23:01:50] <mojavelinux> but heck, that can be a feature enhancement ;)
[23:01:53] <mojavelinux> if not
[23:01:55] <lightguard_jp> Yeah, the updated version is nice and really concise now.
[23:02:09] <mojavelinux> gist?
[23:02:10] <lightguard_jp> Like JPA1?
[23:02:19] <mojavelinux> yeah, if you don't use the metamodel generator
[23:02:20] <lightguard_jp> mojavelinux: https://gist.github.com/885926 the same one
[23:02:22] <nickarls> EntityManager doesn't have metamodel in JPA1
[23:02:33] <mojavelinux> right, I mean
[23:02:46] <mojavelinux> if you use jpa2 like it's jpa 1 and don't have the metamodel classes generated
[23:02:52] <mojavelinux> does the Metamodel still give you that information
[23:02:58] <mojavelinux> and does it merge in what is in orm.xml
[23:03:04] <lightguard_jp> mojavelinux: The javadocs don't mention anything about having to have them generated.
[23:03:06] <mojavelinux> I just don't know the answer to that, but ike could tell us
[23:03:11] <mojavelinux> yep, -> ike
[23:03:23] <mojavelinux> sandbox environment
[23:03:59] <mojavelinux>  @Inject @Any
[23:03:59] <mojavelinux>     private EntityManager entityManager;
[23:04:02] <mojavelinux> is that going to work?
[23:04:05] *** alesj has left #seam-dev
[23:04:07] <mojavelinux> I thought you needed to do
[23:04:17] <mojavelinux> @Inject @Any private Instance<EntityManager> entityManager;
[23:04:25] <mojavelinux> still not sure how you know which one to use
[23:04:59] <lightguard_jp> Instance<?> still has me a little confused when to use it
[23:05:39] <mojavelinux> two cases
[23:05:45] <mojavelinux> first, you want to defer the lookup of a bean
[23:05:56] <mojavelinux> it's a resolver
[23:06:05] <mojavelinux> second case, it is an iterator of resolvers
[23:06:14] <stuartdouglas> sbryzak: solder and persistence I am happy to bump all the remaining issues
[23:06:31] <stuartdouglas> but a lot of the solder issues are ones dan reported, so you might want to check with mojavelinux
[23:06:37] <mojavelinux> in the second case, you use @Any to say, i want all beans of this type, regardless of what they are qualified with
[23:06:42] <mojavelinux> looking...
[23:08:09] <nickarls> jp: would it be worth cacheing the id lookup?
[23:08:19] <mojavelinux> SOLDER-92 is not our problem, that's the glassfish issue, so that gets bumped for sure
[23:08:21] <jbossbot> jira [SOLDER-92] Integration tests broken for incontainer-glassfish-rest profile [Open (Unresolved) Bug, Blocker, Unassigned] https://issues.jboss.org/browse/SOLDER-92
[23:08:29] <nickarls> jp: since there will be a 1:1 mapping between the object class and the id class. or?
[23:08:31] <mojavelinux> keep SOLDER-61
[23:08:32] <jbossbot> jira [SOLDER-61] Write documentation for JBoss Logging [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-61
[23:08:34] <mojavelinux> I need to do that
[23:08:55] <mojavelinux> I really want SOLDER-78 and SOLDER-79, but I can be convinced to wait I suppose
[23:08:57] <jbossbot> jira [SOLDER-78] Provide convenience APIs for creating a bean instance [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-78
[23:08:57] <jbossbot> jira [SOLDER-79] Provide convenience APIs for injecting into a non-managed instance [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-79
[23:09:03] <mojavelinux> yeah, let's say 3.0.1.Beta1 for those
[23:09:06] <mojavelinux> so just keep 61
[23:09:15] <nickarls> jp: not that the reflection operation is that heavy but jsf components have a tendenency of getting called a lot.
[23:09:35] <mojavelinux> why not fix SOLDER-22? seems easy
[23:09:36] <jbossbot> jira [SOLDER-22] Cause a definition error if a unwrapping producer method declares a scope [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-22
[23:09:58] *** koentsje has joined #seam-dev
[23:10:23] <mojavelinux> i think SOLDER-89 should be done for final as it's a documentation issue
[23:10:34] <jbossbot> jira [SOLDER-89] Document utilities provided by AnnotationInspector [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-89
[23:10:40] <mojavelinux> so I would keep 61 and 89, bump the rest
[23:11:23] <lightguard_jp> nickarls: I'd almost need to cache it per row (db) the entity references
[23:12:03] <lightguard_jp> Might need to think about that some more, or add it for a future enhancement
[23:12:17] <mojavelinux> oh, and do solder 22 if you think it's a quick change
[23:12:29] *** jharting has quit IRC
[23:12:57] *** koentsje has quit IRC
[23:13:49] <lightguard_jp> mojavelinux: JPA 2 spec 6.2: Static metamodel classes corresponding to the managed classes of the persistence unit can be gen- erated by means of an annotation processor or can be created by the application developer, or the meta- model	can	be	accessed	dynamically	by	use	of	the javax.persistence.metamodel.Metamodel interface.
[23:14:02] <lightguard_jp> That seems to imply that I don't need to generate the classes to get the meta model
[23:14:21] <mojavelinux> excellent!
[23:14:25] <mojavelinux> success!
[23:14:35] <nickarls> metamodel generation in mvn is a bitch
[23:14:42] <lightguard_jp> nickarls: I've heard
[23:14:45] <mojavelinux> it's much better now
[23:14:55] <lightguard_jp> mojavelinux: success!! (Context ?)
[23:15:03] <mojavelinux> that it does what we want
[23:15:07] <lightguard_jp> Ah
[23:15:16] <mojavelinux> I complained hard about the metamodel generator
[23:15:27] <mojavelinux> and I believe it was gunnar that made it awesome
[23:15:42] *** Camilo has quit IRC
[23:15:43] *** 36DABD92N has joined #seam-dev
[23:16:37] <jbossbot> git [solder] push master 38349af.. Stuart Douglas SOLDER-22
[23:16:38] <jbossbot> jira [SOLDER-22] Cause a definition error if a unwrapping producer method declares a scope [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-22
[23:16:38] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/a61f83f...38349af
[23:17:07] <mojavelinux> most excellent
[23:32:27] *** ChanServ sets mode: +o mojavelinux
[23:32:34] *** ChanServ sets mode: +o lightguard_jp
[23:32:47] *** ChanServ sets mode: +o sbryzak
[23:33:02] <lightguard_jp> There we are, ops now
[23:36:04] *** 36DABD92N has quit IRC
[23:37:17] <jbossbot> git [forge] push master 39883f2.. Lincoln Baxter, III added ability to include/exclude shaded deps
[23:37:17] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/1b786dd...39883f2
[23:38:02] <mojavelinux> yeah!!!!!
[23:38:05] <mojavelinux> we are operators!
[23:38:10] <mojavelinux> this channel finally has operators again
[23:38:11] <mojavelinux> :)
[23:38:23] <mojavelinux> thanks to Jason for rescuing it from floating at sea
[23:39:16] <bleathem> what are operators?
[23:39:22] * bleathem IRC noob still
[23:39:23] <nickarls> over on ircnet I'm on a channel that lost ops in a split ~10 years ago ;-)
[23:39:37] <mojavelinux> fortunately, red hat has a central administator
[23:39:40] <mojavelinux> he saved us
[23:40:04] <jbossbot> git [forge] push master aae5132.. Lincoln Baxter, III messaging improvement
[23:40:04] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/39883f2...aae5132
[23:40:16] <nickarls> bleathem: channel operators are the demigods that can kick people from the channel etc ;-)
[23:40:27] *** mojavelinux changes topic to "test"
[23:40:27] <bleathem> oic
[23:40:30] <mojavelinux> woot!
[23:40:33] <bleathem> sounds like fun :P
[23:40:35] <nickarls> ircops are even more badass
[23:40:38] <mojavelinux> actually, the topic test is accurate
[23:40:50] *** mojavelinux changes topic to "Development discussions for Seam (seamframework.org). For user discussions, go to #seam. Logs at http://echelog.matzon.dk/logs/browse/seam-dev"
[23:41:07] <lightguard_jp> Looks like we're good
[23:41:08] <bleathem> does this mean we *have* to saty on topic now?  It's going to get awfully quiet around here...
[23:41:14] <sbryzak> mojavelinux: do you want to take care of SEAM-50 ?
[23:41:16] <jbossbot> jira [SEAM-50] seam booking - errors in integration tests [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAM-50
[23:42:38] *** mojavelinux changes topic to "Preparing for Seam 3.0.0.Final. Development discussions for Seam (seamframework.org). Join #seam for user discussions. See http://seamframework.org/Seam3/Chat for logs and more info."
[23:42:52] <mojavelinux> cool, that's a better topic
[23:43:00] <mojavelinux> now we can actually set the topic when we have a meeting
[23:43:17] <mojavelinux> now we can kick people
[23:43:25] <mojavelinux> so if you break a build, we can take action
[23:43:26] <mojavelinux> hahaha
[23:44:58] <mojavelinux> now if lincoln's alter ego shows up, we can remove him from the channel
[23:45:30] *** koentsje has joined #seam-dev
[23:45:35] *** mojavelinux sets mode: +m
[23:45:55] *** mojavelinux sets mode: -v bleathem
[23:45:59] <mojavelinux> bleathem: try to speak
[23:46:27] *** mojavelinux sets mode: +v bleathem
[23:46:33] <bleathem> :'(
[23:46:35] *** cbrock has quit IRC
[23:46:37] <mojavelinux> hahaha
[23:46:39] <sbryzak> it looks like dan has a new toy
[23:46:54] *** mojavelinux sets mode: -m
[23:46:57] <bleathem> now no one will interupt during the community meeting
[23:47:06] <bleathem> oh no wait, that's already the case!
[23:47:10] <bleathem> :D
[23:47:13] <mojavelinux> :)
[23:47:16] <lightguard_jp> If we promote jbott to op it'll change the topic in the meetings and change back when the meeting is over
[23:47:52] *** mojavelinux has left #seam-dev
[23:47:54] *** mojavelinux has joined #seam-dev
[23:48:36] <sbryzak> phew, down to 41 issues
[23:49:53] *** ChanServ sets mode: +o mojavelinux
[23:50:42] <sbryzak> anyone seen cpopetz online?
[23:51:11] *** mojavelinux sets mode: -v bleathem
[23:51:32] <sbryzak> mojavelinx: can we bump any SEAMSERVLET issues?
[23:52:07] *** PeteRoyle has quit IRC
[23:52:15] <mojavelinux> looking...
[23:52:19] <mojavelinux> okay, we have a grasp on op now
[23:54:22] <sbryzak> jose_freitas: how's SEAM-31 going?
[23:54:23] 
[23:54:57] <sbryzak> lightguard_jp: are you ok to get SEAMCATCH-51 and SEAMCATCH-52 fixed today?
[23:54:58] <jbossbot> jira [SEAMCATCH-51] Typo in the basic-servlet example [Open (Unresolved) Bug, Major, Jason Porter] https://issues.jboss.org/browse/SEAMCATCH-51
[23:54:59] <jbossbot> jira [SEAMCATCH-52] BasicServletTest.testAssertionError() expects incorrect response [Open (Unresolved) Bug, Major, Martin Gencur] https://issues.jboss.org/browse/SEAMCATCH-52
[23:55:49] <lightguard_jp> sbryzak: Today or tomorrow
[23:56:06] <sbryzak> lightguard_jp: great, thanks
[23:59:04] <mojavelinux> shane, I may bump SEAMSERVLET-24
[23:59:06] <jbossbot> jira [SEAMSERVLET-24] Add built-in configurable exception handler [Open (Unresolved) Feature Request, Major, Dan Allen] https://issues.jboss.org/browse/SEAMSERVLET-24
[23:59:14] <mojavelinux> I think the other two are doable as they are tests
[23:59:38] *** PeteRoyle has joined #seam-dev





top