[00:19:40] *** tsurdilo has joined #seam-dev
[02:33:02] *** maxandersen has quit IRC
[02:49:49] *** aslak has quit IRC
[06:42:09] *** oskutka has quit IRC
[07:01:37] *** tsurdilo has quit IRC
[07:14:52] *** sbryzak has joined #seam-dev
[07:14:52] *** sbryzak has quit IRC
[07:14:52] *** sbryzak has joined #seam-dev
[07:49:15] *** clerum has quit IRC
[07:52:50] *** jharting has joined #seam-dev
[08:03:04] *** oskutka has joined #seam-dev
[08:38:00] *** kpiwko has joined #seam-dev
[08:41:48] *** jharting has quit IRC
[09:44:21] *** aslak has joined #seam-dev
[09:44:21] *** aslak has quit IRC
[09:44:21] *** aslak has joined #seam-dev
[09:55:16] *** mbg is now known as mbg|afk
[10:10:52] *** mbg|afk has quit IRC
[10:17:05] *** emmanuel has joined #seam-dev
[10:18:09] *** emmanuel has quit IRC
[10:18:29] *** emmanuel has joined #seam-dev
[10:20:59] *** jharting has joined #seam-dev
[10:48:31] *** shervin_a has joined #seam-dev
[11:33:53] *** maxandersen has joined #seam-dev
[11:43:44] <jbossbot> git [solder] push master 280c9ad.. Shane Bryzak fix parent version for solder docs
[11:43:44] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/072d596...280c9ad
[11:47:41] <jbossbot> git [solder] push master 7d10e2d.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.Beta1
[11:47:41] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/280c9ad...7d10e2d
[11:47:54] <jbossbot> git [solder] push master a6823b4.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[11:47:54] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/7d10e2d...a6823b4
[12:32:47] <jbossbot> git [dist] push master 70da935.. Shane Bryzak added seam solder, removed weld-extensions
[12:32:47] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/947869b...70da935
[12:53:33] <jbossbot> git [js-remoting] push master 4a4a3cc.. Amir a minor change...
[12:53:33] <jbossbot> git [js-remoting] push master URL: http://github.com/seam/js-remoting/compare/9d258ed...4a4a3cc
[13:07:30] <maxandersen> someone around to help decrypt the spec and an example about how it decides what to inject ? (i.e. jbosstools thinks the code is wrong, but runs under weld..)
[13:08:50] <Nik> max: you could try ;-)
[13:15:01] <jharting> maxandersen: do you have a specific example?
[13:15:15] <maxandersen> yes 2 sec
[13:15:54] <maxandersen> https://issues.jboss.org/browse/JBIDE-7950
[13:15:55] <jbossbot> jira [JBIDE-7950] Abstract classes is being considered injectable [Open, Critical, Viacheslav Kabanovich] https://issues.jboss.org/browse/JBIDE-7950
[13:16:45] <maxandersen> found while tinkering with seam-forge and saw this pattern which i'm not seeing which rule in the spec makes the producer method the only "injector"
[13:16:51] <maxandersen> jharting: Nik: ^
[13:17:49] *** akazakov has joined #seam-dev
[13:18:45] <maxandersen> jharting: Nik: akazakov is the one having "fun" investigating this.
[13:19:51] <maxandersen> akazakov: why is it you say the abstract class is injectable but projectimpl is not ? Both are equally "good" is it not ?
[13:20:06] <jharting> maxandersen: well, section 3.1.1 says that only concrete classes are considered managed beans, is it the rule you are looking for?
[13:20:49] *** jharting is now known as jharting_afk
[13:20:52] <maxandersen> jharting: yes that explains the abstract; but how do we "ignore" the concrete implementor of Project (i.e. ProjectImpl) ?
[13:21:04] <akazakov> maxandersen: no, My question is why projectImpl is not injectable.
[13:21:04] <Nik> "A bean type may be an interface, a concrete class or an abstract class, and may be declared final or have final methods"
[13:21:13] <Nik> @Typed etc
[13:21:32] <Nik> @Typed({}) actually
[13:22:27] <Nik> if you have Foo and a producer for Foo (that does custom construction etc), you have to have the original class @Typed or you get ambiguous resolves
[13:22:49] <maxandersen> so ProjectImpl should have @Typed to be "ignored" ?
[13:22:59] <maxandersen> Nik: I wonder how this works in Weld then ;)
[13:23:37] <Nik> shouldn't AP be annotated since it can't be instantiated anyway(?)
[13:24:17] <maxandersen> Nik: annotated with what exactly ? (note: this is simply just seam-forge i'm referencing ;)
[13:25:10] <Nik> @Typed({}) so it's not eligable for anything
[13:26:08] <maxandersen> Nik: never actually seen/noticed that annotation in real use...
[13:26:31] <Nik> hmm, abstract types can be injection points. but if there are no other classes, how can the injection point be satisfied
[13:26:39] <Nik> since it can never be instantiated
[13:26:53] <maxandersen> I gotta run out for a bit - if you guys can figure out how Weld chooses over this (which seem to go against the spec) that would be great ;)
[13:27:10] <maxandersen> ill be back later.
[13:27:20] *** maxandersen is now known as maxandersen_afk
[13:27:30] <Nik> and if you add a producer, you increase the number of concrete classes from 0 to 1, so why is it ambiguous?
[13:27:40] <Nik> mostly used @Typed with concrete classes
[13:32:26] <akazakov> Nik: there are two classes with Project bean types: ProjectImpl and AbstractProject. AbstractProject can't be injected but ProjectImpl can. Also we have a producer which can be injected too. So we have two beans to be injected: ProjectImpl (I guess it's a managed bean) and the producer method. Where is my mistake?
[13:32:51] <Nik> akaz: just commented on the jira
[13:36:12] *** jharting_afk is now known as jharting
[13:37:24] <Nik> akaz: so I don't think it's the abstract class that's being considered, it's a fight between the ProjectImpl and the Project producer you have to settle
[13:38:58] <jharting> akazakov: so in weld this project fails to deploy with ambigouousResException?
[13:39:05] <akazakov> Nik: yes. But why weld doesn't have any problem there. It injects the producer. But Tools treats it as ambiguous.
[13:39:24] <akazakov> jharting: Max told me that it works in weld
[13:39:44] <Nik> I find it strange that is would work in weld at a quick glance
[13:40:24] <jharting> akazakov: seems unlikely to me as well, but if it works it is a bug in weld
[13:40:44] <Nik> trying it...
[13:41:13] <akazakov> this code is from seam-forge
[13:43:23] <Nik> fails for me
[13:44:56] <Nik> I don't see how weld could pick between ProjectImpl and what the producer method gives you
[13:47:00] <Nik> so it's up to max to prove it works in weld ;-)
[14:10:36] *** tsurdilo has joined #seam-dev
[14:19:15] *** tsurdilo has quit IRC
[14:24:31] *** tsurdilo has joined #seam-dev
[14:53:32] <maxandersen_afk> Nik: its from seamforge - which uses weld afaik?.
[14:56:42] *** daniel__ has joined #seam-dev
[15:01:29] <Nik> well, the Weld/AS doesn't know where the files came from, just copy&pasted from the JIRA
[15:02:59] * Nik is in denial (and heading home soon)
[15:04:06] *** balunasj has joined #seam-dev
[15:04:11] <Nik> mr Forge will probably wake up soon so he can comment on if there is any @Veto or similar used for forge...
[15:05:18] *** lightguard_jp has joined #seam-dev
[15:11:06] *** balunasj has quit IRC
[15:21:52] *** antoine_sd has joined #seam-dev
[15:52:19] *** clerum has joined #seam-dev
[15:55:26] *** shervin_a has quit IRC
[16:18:32] *** oskutka has quit IRC
[16:19:32] *** kpiwko has quit IRC
[16:30:01] *** mbg has joined #seam-dev
[16:30:01] *** mbg has quit IRC
[16:30:01] *** mbg has joined #seam-dev
[16:31:50] *** shervin_a has joined #seam-dev
[16:37:13] <lightguard_jp> antoine_sd: Jason Porter here, glad you got things figured out :)
[16:44:43] *** arbi has joined #seam-dev
[16:45:09] <arbi> http://seamframework.org/Seam3/DistributionDownloads
[16:45:18] <arbi> will there be a single multi-module download?
[16:47:04] <clerum> did a new seam parent get released?
[16:47:08] <clerum> for solder?
[16:47:41] <lightguard_jp> Yes, no and no
[16:47:48] <lightguard_jp> At least not to my knowledge
[16:48:29] <antoine_sd> thxs Jason, I'm ready to put the skeleton of my module on github, but perhaps will wait until the migration to solder
[16:51:35] <lightguard_jp> antoine_sd: Your call :) The sooner it's up though, the sooner others can look at it and make suggestions as needed
[16:53:18] *** jharting has quit IRC
[16:53:22] <antoine_sd> ok, for the moment I just have a basic Twitter Client for search API, not very rich... I'l try to implement OAuth signature with RestEasy interceptors before publication.
[16:54:00] <lightguard_jp> antoine_sd: You may want to look into Seam Security / Picketlink and see if there's anything there that could help you
[16:56:46] <antoine_sd> lightguard_jp: yes, I looked at those 3 weeks ago without finding what I needed but as the modules are changing a lot, I'll give another look tonight. The same for Seam Rest ;-).
[16:57:05] <lightguard_jp> :)
[16:57:43] *** maxandersen_afk has quit IRC
[17:05:33] <antoine_sd> any idea when a new Seam Parent with solder will be released ? Can we add solder in our parent pom without conflict with weldx in the meantime ?
[17:06:18] <lightguard_jp> antoine_sd: Hm, probably not.  You'd possibly hit classpath hell, though maybe not if the packages changed.
[17:06:32] <lightguard_jp> A new parent, not sure, possibly some time this week (hopefully)
[17:57:25] *** antoine_sd has quit IRC
[18:19:37] *** shervin_a has quit IRC
[18:54:10] *** tsurdilo1 has joined #seam-dev
[18:57:36] *** tsurdilo has quit IRC
[19:04:40] *** mojavelinux has joined #seam-dev
[19:08:05] *** lincolnthree has joined #seam-dev
[19:16:25] <jbossbot> git [solder] push master b88f97c.. Dan Allen SOLDER-56 distribution build
[19:16:27] <jbossbot> jira [SOLDER-56] Create a distribution build [Open, Major, Dan Allen] https://issues.jboss.org/browse/SOLDER-56
[19:16:27] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/a6823b4...b88f97c
[19:22:21] *** lincolnthree has quit IRC
[19:31:45] *** arbi has quit IRC
[19:42:07] *** lincolnthree has joined #seam-dev
[19:44:15] <jbossbot> git [forge] push master 74d4072.. Lincoln Baxter, III manually applied merge from maxandersen
[19:44:15] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/d95d438...74d4072
[20:12:27] <jbossbot> git [forge] push master 2555254.. Lincoln Baxter, III added forge windows launcher
[20:12:28] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/74d4072...2555254
[20:27:34] <jbossbot> git [solder] push master 587a78a.. Dan Allen SOLDER-53 use dual observers per Pete's suggestion
[20:27:35] <jbossbot> jira [SOLDER-53] Seam Solder incontainer tests fail [Closed, Major, Dan Allen] https://issues.jboss.org/browse/SOLDER-53
[20:27:36] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/b88f97c...587a78a
[20:31:15] <jbossbot> git [forge] push master 5877966.. Lincoln Baxter, III improved spacing of default config on windows
[20:31:15] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/2555254...5877966
[20:40:27] *** tsurdilo has joined #seam-dev
[20:43:50] *** tsurdilo1 has quit IRC
[20:48:02] *** tsurdilo1 has joined #seam-dev
[20:49:40] *** tsurdilo has quit IRC
[21:02:07] *** lazarotti has joined #seam-dev
[21:09:19] <jbossbot> git [forge] push master c7db13b.. Lincoln Baxter, III updated launcher & MOTD
[21:09:19] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/5877966...c7db13b
[21:14:40] *** tsurdilo1 has quit IRC
[21:14:50] *** tsurdilo has joined #seam-dev
[21:26:14] *** marekn has joined #seam-dev
[21:51:09] *** stuartdouglas_ has joined #seam-dev
[21:51:22] *** stuartdouglas has quit IRC
[21:51:23] *** stuartdouglas_ is now known as stuartdouglas
[21:55:09] *** tsurdilo1 has joined #seam-dev
[21:57:40] *** tsurdilo has quit IRC
[21:58:43] *** lazarotti has quit IRC
[22:09:11] *** tsurdilo2 has joined #seam-dev
[22:11:20] *** tsurdilo1 has quit IRC
[22:17:15] *** tsurdilo has joined #seam-dev
[22:20:30] *** tsurdilo2 has quit IRC
[22:23:23] *** tsurdilo1 has joined #seam-dev
[22:26:47] *** tsurdilo has quit IRC
[22:28:01] *** maxandersen has joined #seam-dev
[22:33:25] *** tsurdilo has joined #seam-dev
[22:33:25] *** tsurdilo1 has quit IRC
[22:38:39] <maxandersen> lincolnthree: boing
[22:42:12] <maxandersen> lincolnthree: didnt realize seam 3 were "special" with respect to codestyle and being different from most others ;( ill try and switch ;)
[22:42:29] <lightguard_jp> maxandersen: What's different?
[22:42:39] <lightguard_jp> Or is it just forge?
[22:42:51] <lincolnthree> maxandersen: hey
[22:43:13] <lincolnthree> yeah, np - a lot of people do the same thing
[22:43:13] <maxandersen> all 7 years i've been coding on hibernate/seam/jboss i've just used standard Sun convention (the one that is default in all Java IDE's afaik.)
[22:43:34] <maxandersen> anyhow
[22:43:39] <lincolnthree> not sure when all that started, but im happy since it's actually close to the standards I like :)
[22:43:46] <maxandersen> lincolnthree: got a tricky question
[22:43:55] <lincolnthree> sure
[22:44:04] <maxandersen> lincolnthree: yeah - im not liking it much on my 13" screen ;)
[22:44:12] <lincolnthree> lol
[22:44:12] <lincolnthree> yea
[22:44:41] <lincolnthree> what's your q?
[22:44:42] <maxandersen> lincolnthree: problem is that jboss tools is finding that @Inject for certain patterns in seamforge should simply not work since its ambigious
[22:44:51] <maxandersen> let me find the jira
[22:44:51] <lincolnthree> hmmm
[22:45:05] <maxandersen> https://issues.jboss.org/browse/JBIDE-7950
[22:45:07] <jbossbot> jira [JBIDE-7950] Abstract classes is being considered injectable [Open, Critical, Viacheslav Kabanovich] https://issues.jboss.org/browse/JBIDE-7950
[22:45:55] <lincolnthree> ok, but that's not a Forge issue, the CDI impl is functioning correctly, yes?
[22:46:00] <lincolnthree> i havent seen that warning
[22:46:20] <lincolnthree> maybe im on an old JBT
[22:46:22] <maxandersen> it revealed a bug in jbosstools (the model were seeing abstract classes as injectable) but the model in seam-forge is giving two candidates for injection ...
[22:46:50] <maxandersen> lincolnthree: you probably haven't enabled CDI for your project  (another bug I found that our maven integration only enabled cdi on war where it should do it on jars too ;)
[22:47:01] <lincolnthree> hm
[22:47:04] <lincolnthree> yeah probably
[22:47:19] <maxandersen> lincolnthree: problem is - there are two beans that matches @Inject Project project;
[22:47:22] <maxandersen> how come that is working ?
[22:47:49] <maxandersen> i.e. ProjectImpl and @Current Project getCurrent() are equally injectable as far as I can see.
[22:48:13] <lincolnthree> The reason it works is because @Current is a qualifier
[22:48:17] <maxandersen> I want to figure out if i'm missing something obvious or if we've found a bug in the spec or the CDI impl.
[22:48:23] <lincolnthree> so technically that makes it a different injection target
[22:48:35] <lincolnthree> it comes from a producer method
[22:48:41] <lincolnthree> instead of creating a new instance
[22:48:59] <lincolnthree> in theory, ProjectImpl should have @Veto
[22:49:01] <maxandersen> so @Current "hides" the default class option ?
[22:49:16] <lincolnthree> not really
[22:49:23] <lincolnthree> It qualifies an injection point
[22:49:40] <lincolnthree> You can do both @Inject Project p, and @Inject @Current Project cp;
[22:49:43] <lincolnthree> In the same class.
[22:49:45] <maxandersen> Nik: is saying ProjectImpl should have @Types({}) on it to "hide" it
[22:49:55] <lincolnthree> They literally mean different things
[22:49:59] <lincolnthree> In this case, he's correct
[22:50:02] <lincolnthree> :)
[22:50:13] <Nik> there was no mentioning of @Current in the JIRA(?)
[22:50:15] <lincolnthree> But it won't break anything with or without it
[22:50:24] <maxandersen> so seamforge is wrongly implemented and CDI is to "friendly"
[22:50:30] <lincolnthree> No
[22:50:40] <lincolnthree> @Inject Project is completely acceptable
[22:50:45] <lincolnthree> it just doesn't do anything
[22:50:52] <lincolnthree> you get an empty un-initialized project instance
[22:51:03] <maxandersen> eh ?
[22:51:11] <maxandersen> @Inject should always resolve shouldnt it ?
[22:51:14] <lincolnthree> It does
[22:51:18] <lincolnthree> You get a ProjectImpl
[22:51:24] <maxandersen> from where ?
[22:51:27] <lincolnthree> From ProjectImpl
[22:51:34] <maxandersen> hmm...
[22:51:48] <lincolnthree> ProjectImpl is a CDI bean
[22:52:01] <lincolnthree> adding @Typed() would simply remove all types from that bean
[22:52:05] <lincolnthree> making it non-injectable
[22:52:09] <lincolnthree> in that case
[22:52:14] <lincolnthree> if you did:
[22:52:17] <lincolnthree> @Inject Project p;
[22:52:22] <lincolnthree> you would get an Unsatisfied Dependency error
[22:52:35] <lincolnthree> because CDI no longer has any Project types to satisfy the injection target
[22:52:46] <lincolnthree> @Inject @Current Project p, would work however
[22:53:02] <lincolnthree> So there's one thing that might make all this a little clearer
[22:53:08] <lincolnthree> @Inject Project p;
[22:53:11] <lincolnthree> is the same as:
[22:53:15] <lincolnthree> @Inject @Default Project p;
[22:53:39] <lincolnthree> @Inject  has an assumed qualifier of @Default if none are specified
[22:54:03] <lincolnthree> CDI is correct in its strictness
[22:54:09] <lincolnthree> it's forge that's a little too "friendly"
[22:54:18] <lincolnthree> forge should not let you @Inject @Project p;
[22:54:20] <lincolnthree> but it does
[22:54:30] <lincolnthree> you just get a straight ProjectImpl instance
[22:54:33] <lincolnthree> that did not come from the Shell
[22:54:34] <lincolnthree> it came frmo CDI
[22:54:49] <lincolnthree> when you @Inject @Current Project cp; it comes from the Forge shell projectContext
[22:54:54] <lincolnthree> does that make sense?
[22:54:55] * maxandersen franticly trying to find the warning I had yesterday...
[22:55:07] <maxandersen> yes I grok that
[22:55:15] <lincolnthree> grok :)
[22:55:16] <maxandersen> just didn't notice the @Current ?.
[22:55:37] <lincolnthree> frankly i'm not completely sure @Inject @Current project p; is working, but if it is, awesome :)
[22:55:37] *** tsurdilo1 has joined #seam-dev
[22:55:48] <lincolnthree> I haven't completed that migration yet.
[22:55:52] <lincolnthree> IT *should* work
[22:55:56] <lincolnthree> just not completely sure
[22:57:27] <Nik> are we talking @Current or @Default?
[22:57:33] <lincolnthree> @Current
[22:57:37] <lincolnthree> don't inject project
[22:57:40] *** tsurdilo has quit IRC
[22:57:41] <maxandersen> okey - so JBT has a  bug in resolving based on quailifiers ;(
[22:57:46] <lincolnthree> if you want to inject project, use @Current Project
[22:57:48] <maxandersen> akazakov: ping
[22:58:12] <akazakov> maxandersen: pong
[22:58:38] <maxandersen> lincolnthree: waait - the examle in the jira the getCurrent has @Default on the producer method meaning its equal to ProjectImpl...
[22:58:44] <maxandersen> right ?
[22:59:30] <maxandersen> and I just checked forge code ?getCurrent() has @Default..
[22:59:46] <Nik> l3: the final spec contains 0 accounts of @Current
[22:59:57] <lincolnthree> Nik: I defined @Current
[22:59:58] <Nik> the only thing I recall of Current is that it was the old @Inject
[23:00:10] <maxandersen> akazakov: does CDI model in JBT take qualifiers into consideration ?
[23:00:16] <lincolnthree> Nik: current is my qualifier
[23:00:29] <akazakov> maxandersen: sure
[23:00:35] <Nik> l3: recycling old annotations is evil ;-)
[23:00:39] <maxandersen> lincolnthree: ?and i'm saying seamforge in *this* example doesn't...
[23:01:06] <lincolnthree> I just looked at the code
[23:01:10] <maxandersen> lincolnthree: look in the jira - its stripped version of what is in seam forge?.which part of the annotations makes it select the right one ?
[23:01:13] <lincolnthree> @Current is only used for Resources atm
[23:01:27] <maxandersen> lincolnthree: yes - and those doesn't trigger the warning...
[23:01:45] *** tsurdilo has joined #seam-dev
[23:01:47] <lincolnthree> Well first of all, CurrentProject is not a Project in your example
[23:01:56] <lincolnthree> oh
[23:01:57] <lincolnthree> nm
[23:01:58] <lincolnthree> hang on
[23:02:02] <maxandersen> akazakov: I think there are some missing ?.seam-forge is triggering a lot of warnings and some of them dosn't look right.
[23:02:22] <lincolnthree> maxandersen: in your situation, there should be an error
[23:02:28] <lincolnthree> in the JIRA, the error is correct
[23:02:36] <maxandersen> lincolnthree: this is the same as in seam-forge ;)
[23:02:41] <lincolnthree> let me take a look
[23:02:55] <maxandersen> lincolnthree: at least what I saw 2am last night ;)
[23:04:02] <maxandersen> akazakov: i.e. CDI does not seem to allow @Inject BeanManager beanManager; even though weld is on the classpath which has BeanManagerImpl; ...
[23:04:10] <akazakov> maxandersen: there maybe bugs in bean resolving in JBT. I will look at seam-forge injections as soon as we fix already found critical bugs in CDI tooling
[23:04:27] <lincolnthree> akazakov: it depends on your environment ? you may not have contextual injection available
[23:04:28] <maxandersen> akazakov: ok :)
[23:04:31] <lightguard_jp> Isn't there a built-in enumeration to iterator class in the JDK?
[23:04:59] *** tsurdilo1 has quit IRC
[23:05:22] <maxandersen> lincolnthree: CDI doesn't have contextual injection not defined in types? (unless you use some evil extension ;)
[23:06:29] <lincolnthree> ok so there's a lot going on right now. let me get this sorted, max, im looking at your issue
[23:06:51] <lincolnthree> Ok, to answer your question
[23:06:57] <lincolnthree> ProjectImpl is not a CDI bean in Forge
[23:07:12] <lincolnthree> it does not have a public zero-arg constructor
[23:07:16] <lincolnthree> it has a public 1 arg constructor
[23:07:25] <lincolnthree> this would be a problem if the constructor had @Inject on it
[23:07:27] <lincolnthree> but it doesnt
[23:09:22] <akazakov> lincolnthree: can we be sure in design time that a class without a default public constructor is not a managed bean?
[23:10:00] <lincolnthree> yes
[23:10:06] <akazakov> if so then we can exclude such classes when we are resolving injections
[23:10:14] <lincolnthree> because if CDI is going to provide it as a bean, then it has to know how to construct it
[23:10:27] <lincolnthree> it will not know how to construct it unless the constructor is annotated with @Injecty
[23:10:33] <Nik> (unless you use unsafe instantiation but that's weld only)
[23:11:32] <maxandersen> Nik: lincolnthree: any chance you know where in the spec that is defined ?
[23:12:05] <mojavelinux> it's under proxyable beans
[23:13:07] <mojavelinux> "If a bean class does not explicitly declare a constructor using @Inject, the constructor that accepts no parameters is the bean constructor."
[23:13:15] <maxandersen> mojavelinux: I see a "Unproxyable beans" section.
[23:13:37] <maxandersen> and that section seem to indicate we should treat it as an error...
[23:14:00] <mojavelinux> 5.5.1 defines which constructor it uses
[23:14:01] <mojavelinux> When the container instantiates a managed bean or session bean with a constructor annotated @Inject, the container calls this constructor, passing an injectable reference to each parameter. If there is no constructor annotated @Inject, the container calls the constructor with no parameters.
[23:14:49] <maxandersen> mojavelinux: yup I get that - but then when there is a matching bean but no matching constructor when I read the spec it should be considered an error....
[23:14:51] <mojavelinux> but hold on, I see that we are asking a different question
[23:14:54] <mojavelinux> ah
[23:15:00] <mojavelinux> good question
[23:15:11] <mojavelinux> yes, I'm pretty certain that's an error
[23:15:15] <maxandersen> and that to make it spec compliant you have to add @Veto or put @Types({}) on it ?
[23:15:18] <lincolnthree> it's an error, im not sure it's documented
[23:15:42] <maxandersen> well its implicitly documented but apparently not implemented in Weld ;)
[23:15:47] <mojavelinux> if you don't want it to be a bean, then yes, you have to veto it, because based on the types it's a candidate
[23:15:48] <maxandersen> since seamforge shouldnt be able to run IMO
[23:15:58] <mojavelinux> very interesting arquillian test case ;)
[23:16:24] <mojavelinux> but i'm pretty sure
[23:16:38] <mojavelinux> that you can't hide a bean by making it have an unaccessible constructor
[23:16:54] <mojavelinux> lincoln is correct in that there is no strong assertion for that in the spec
[23:17:23] <Nik> deployment of the bean should fail if there are no good constructors, right?
[23:17:36] <maxandersen> mojavelinux: I would say this is pretty assertive:
[23:17:37] <lincolnthree> Nik: if that were the case, every deployment would fail
[23:17:37] <mojavelinux> it's one of those comes back to bite you things...the cdi spec has very strong assertions, unlike most other specs
[23:17:40] <maxandersen> "If an injection point whose declared type cannot be proxied by the container resolves to a bean with a normal scope, the container automatically detects the problem and treats it as a deployment problem."
[23:17:53] <mojavelinux> so when an assertion is missing, we sort of wonder whether it should be implied (like we do with all other specs)
[23:17:53] <lincolnthree> if that were the case, you'd have to @Veto every class with a non-public default constructor
[23:18:14] <mojavelinux> there you go maxandersen
[23:18:18] <mojavelinux> which section was that?
[23:18:22] <maxandersen> lincolnthree: or add @Inject for a constructor
[23:18:26] <maxandersen> mojavelinux: "Unproxyable beans"
[23:18:29] *** marekn has left #seam-dev
[23:18:31] <mojavelinux> ah, right
[23:18:34] *** tsurdilo1 has joined #seam-dev
[23:18:48] <mojavelinux> the question is, what about dependent beans
[23:18:51] <Nik> l3: deps
[23:18:52] <maxandersen> so JBT validator is correct and weld is too forgiven ?
[23:18:58] <maxandersen> oh another question ;)
[23:19:00] *** tsurdilo has quit IRC
[23:19:00] <lincolnthree> i disagree
[23:19:03] <mojavelinux> wouldn't surprise me, but the spec is the authority
[23:19:05] <lincolnthree> I think the spec is not specific enough
[23:19:07] <Nik> would be all right without the constructors?
[23:20:54] <Nik> 3.1.1 says it needs a no-args constructor (the default one will do) or one annotated with @Inject
[23:21:04] <Nik> so most normal classed will be fine
[23:21:41] <mojavelinux> interesting...so in a sense, it isn't a managed bean and thus would be ignored
[23:21:50] *** emmanuel has quit IRC
[23:21:52] <mojavelinux> this could go either way
[23:21:57] <mojavelinux> because in 3.7, it says
[23:22:03] <jbossbot> git [forge] push master c320c2e.. Lincoln Baxter, III added name for MVN Dep Facet, made projectFactor.installFacet available
[23:22:03] <jbossbot> git [forge] push master 4a1b7fc.. Lincoln Baxter, III Added @Option(completer=...) argument for customizable Option completers
[23:22:04] <mojavelinux> If a bean class does not explicitly declare a constructor using @Inject, the constructor that accepts no parameters is the bean constructor.
[23:22:04] <jbossbot> git [forge] push master 282251d.. Lincoln Baxter, III renamed persistence facet
[23:22:04] <jbossbot> git [forge] push master d7d7b7b.. Lincoln Baxter, III added autocomplete support for InstallFacet plugin, also added correct dependencies to ScaffoldFacet and improved InstallFacetPlugin
[23:22:04] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/c7db13b...d7d7b7b
[23:22:08] <lincolnthree> (sorry)
[23:22:10] <mojavelinux> If a bean class does not explicitly declare a constructor using @Inject, the constructor that accepts no parameters is the bean constructor.
[23:22:52] <mojavelinux> but that implies that it's working with a bean that otherwise has a no-args constructor (i.e., it seemed to work out that this has already been checked)
[23:23:19] <mojavelinux> in a sense, Lincoln is right in that the bean should just be ignored if it doesn't have a candidate constructor
[23:23:21] <mojavelinux> *unless*
[23:23:28] <mojavelinux> it has a CDI annotation on it, then it's definitely a failure
[23:23:31] <mojavelinux> so, for instance
[23:23:36] <mojavelinux> if it has the annotation @RequestScoped
[23:23:45] <maxandersen> Nik: "it" being the class it self ?
[23:23:47] <lincolnthree> From my perspective, that's the only behavior that makes sense. Otherwise usability goes down the toilet.
[23:23:47] <mojavelinux> then that's a failure case, because you can't have it both ways
[23:23:51] <lincolnthree> mojavelinux: agreed
[23:24:00] <mojavelinux> so, no annotations
[23:24:03] <lincolnthree> unless you're using a producer
[23:24:09] <mojavelinux> no default constructor (and no @Inject constructor)
[23:24:25] <lincolnthree> nm
[23:24:27] <lincolnthree> i take that back
[23:24:29] <lincolnthree> ignore me
[23:24:35] <lincolnthree> i agree 100%
[23:24:43] <Nik>  /ignore lincolnthree
[23:24:58] <maxandersen> lincolnthree: mojavelinux: so you are saying seamforge is compliant because the default class has no-noarg constructor ?
[23:25:15] <lincolnthree> and thus it's not a managed bean, yes
[23:25:34] <mojavelinux> ProjectImpl has no indication it should be a managed bean, and no noargs constructor, so it's ignored
[23:26:08] <maxandersen> mojavelinux: is that actually why Weld ignores it ? just wondering if there is some other "interpretation" in Weld that we need to consider too ? :)
[23:26:21] <mojavelinux> nope, that seems to make sense
[23:26:30] <mojavelinux> and is consistent with my observation in the past
[23:26:37] <mojavelinux> even w/ managed beans w/o cdi
[23:26:49] <Nik> ProjectImpl has some other constructor?
[23:26:50] <lincolnthree> spring does the same thing IIRC
[23:26:59] <mojavelinux> sometimes it's upsetting
[23:27:02] <lincolnthree> Nik: no, but it's produced with a CDI @Produces method
[23:27:04] <mojavelinux> because you can't tell why it is ignored
[23:27:11] <mojavelinux> I might make that a warning in jbt
[23:27:32] <lincolnthree> What really bothers me is that @Annotated beans in CDI are ignored without warning if a classloading error occurs.
[23:27:35] <mojavelinux> most of the time people are not going to realize it's not a managed bean
[23:27:37] <lincolnthree> THAT is a problem
[23:27:50] <maxandersen> so let me ask this: if ProjectImpl had constructor with @Inject but that inject is not satisfiable then it would still be considered ambigious right ?
[23:27:50] <mojavelinux> yeah, but that is where tooling comes in
[23:28:06] <mojavelinux> this is the perfect case for tooling...it catches those silent errors that Weld shouldn't waste time on
[23:28:09] <lincolnthree> maxandersen: correct, it would be ambiguous
[23:28:15] <mojavelinux> not to say I agree in every case, but in general, that's the value of tooling
[23:28:20] <mojavelinux> it helps you do what you intend
[23:28:21] <lincolnthree> mojavelinux: tooling won't find a CDNFE exception
[23:28:38] <maxandersen> akazakov: you following this ? :)
[23:28:49] <mojavelinux> "if ProjectImpl had constructor with @Inject but that inject is not satisfiable then it would still be considered ambigious right ?"
[23:28:53] <maxandersen> lincolnthree: that is defined by spec or how weld is implemented ?
[23:28:54] <mojavelinux> that would be a failure
[23:29:01] <lincolnthree> maxandersen: weld impementation guidelines
[23:29:25] <maxandersen> lincolnthree: okey and yes, we can't spot those - that is runtime dependent
[23:29:31] <mojavelinux> oh, I see what you are saying lincoln
[23:29:34] <maxandersen> and I would agree it should fail.
[23:29:46] <maxandersen> (at least on first intuition)
[23:29:53] <mojavelinux> yeah, that is a swallowing problem
[23:29:57] <Nik> so a class Foo with a constructor with arguments together with a producer for Foo is OK since Foo itself is ignored, right?
[23:30:01] <lincolnthree> it gets reported at debug level
[23:30:06] <mojavelinux> somewhere when the class is loaded it's failing and weld is saying just ignore that
[23:30:13] <mojavelinux> ah
[23:30:13] <lincolnthree> Nik: correct
[23:30:30] <lincolnthree> mojavelinux: yes, it's "correct" behavior, it's just annoying because I want to know about those in forge
[23:30:40] <akazakov> ok we can check constructors during bean resolving. Should we check other CDI annotations? If a class has some cdi annotation (injection field for example) should we threat it as a bean?
[23:30:53] <lincolnthree> say, if a plugin fails to load due to classloading issues, i want to know? i had to hack a log4j appender and filter to get that working
[23:31:01] <mojavelinux> no, because then weld wouldn't look at it either
[23:31:06] <mojavelinux> basically, to get in the door
[23:31:13] <mojavelinux> you have to have a candidate constructor
[23:31:18] <mojavelinux> w/o that, we stop looking
[23:31:26] <akazakov> mojavelinux: ok
[23:31:38] <mojavelinux> in summary, it's like this
[23:32:08] <mojavelinux> 1. if it has no CDI annotations (like a scope), then see if it is a managed bean; if so proceed all is good
[23:32:23] <mojavelinux> 2. if it has a CDI annotation (like a scope), then it better be a managed bean; and it also has to be proxiable if the scope requires it
[23:32:37] *** tsurdilo has joined #seam-dev
[23:33:00] <mojavelinux> would be interested to see if Weld supports all those edge cases
[23:33:06] <Nik> I don't think CDI annotations should matter since there are dependent beans. Scope annotations might bring proxing restrictions, though.
[23:33:09] <mojavelinux> like a @Dependent annotated bean w/o a candidate constructor
[23:33:20] <mojavelinux> right, but see what I'm saying nik
[23:33:23] <mojavelinux> if you add @Dependent
[23:33:27] <mojavelinux> and there is no way to instantiate
[23:33:37] <mojavelinux> then that's a failure case, because you actually said it was a managed bean
[23:33:42] <mojavelinux> if it had no annotation
[23:33:48] <mojavelinux> well, okay, you never asked for it
[23:34:14] <lincolnthree> It might not be a failure case, but it should certainly be a warning
[23:34:25] <lincolnthree> ie, if CDI does not complain, JBT should tell you anyway
[23:34:58] *** bleathem has joined #seam-dev
[23:35:00] <maxandersen> akazakov: mojavelinux: lincolnthree: I've created https://issues.jboss.org/browse/JBIDE-7967 to capture this special case. let me know if that captures it or not ? :)
[23:35:02] <jbossbot> jira [JBIDE-7967] nonannotated classes without default constructor and no CDI scope or inject annotations on class or constructor should not be considered beans [Open, Critical, Alexey Kazakov] https://issues.jboss.org/browse/JBIDE-7967
[23:35:23] <lincolnthree> sounds right
[23:35:26] *** tsurdilo1 has quit IRC
[23:35:39] <lincolnthree> yep
[23:36:07] <mojavelinux> that's the longest titled i've ever seen (though I'm sure there are longer ones)
[23:36:08] <mojavelinux> hehe
[23:36:12] <lincolnthree> :-p
[23:38:25] <maxandersen> it feels good to eat our dog food to make the turd prettier ;)
[23:38:58] <maxandersen> if I hadn't had seam-forge I wouldn't have found all these JBT/Weld ambiguities ;)
[23:39:01] <maxandersen> greatness
[23:39:23] <lincolnthree> Forge is kind of cool for a few reasons around this
[23:39:26] <lincolnthree> 1. it uses weld-SE
[23:39:50] <lincolnthree> 2. It makes heavy use of the BeanManager
[23:40:07] <lincolnthree> it has flushed out a bunch of bugs in weld as well
[23:40:10] <lincolnthree> and in maven
[23:40:10] <lincolnthree> lol
[23:40:20] <lincolnthree> the "hub" projects always do I suppose
[23:40:24] <lincolnthree> integration is where you find bugs :)
[23:40:29] *** lightguard_jp has quit IRC
[23:41:17] <lincolnthree> just wait until we integate forge and JBT
[23:41:23] <lincolnthree> then you'll find all the forge bugs
[23:41:33] <lincolnthree> (even more)
[23:42:35] <Nik> then there is of course the "A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE specification" ;-)
[23:42:38] <maxandersen> lincolnthree: well I already did a good bit last night ;)
[23:42:42] <mojavelinux> interesting, so I did some playing around w/ Arquillian and JBT
[23:43:03] <Nik> so EJBs and JSF beans should be taken into account, too
[23:43:06] <mojavelinux> maxandersen akazakov it looks like you currently do ignore beans that have no candidate instructor
[23:43:18] <mojavelinux> because @Inject says "no candidate bean"
[23:43:48] <mojavelinux> if I take away the default constructor
[23:43:51] <maxandersen> mojavelinux: note: I found about 5 or 6 rather big annoying bugs in JBT which triggers when you got multiproject dependencis?without those fixed JBT is *very* annoying.
[23:43:54] <mojavelinux> and there is no @Inject constructor
[23:43:55] <mojavelinux> so that's good
[23:44:05] <Nik> (the current duplication of CDI and JSF scopes is a mess)
[23:44:14] <maxandersen> mojavelinux: it does in some cases...
[23:44:15] <mojavelinux> but I notice that Weld will silently ignore beans, even if annotated with @Dependent or @RequestScoped that have no candidate constructor
[23:44:25] <lincolnthree> well JSF beans are not currently CDI beans
[23:44:28] <mojavelinux> but to me, as a developer, I'd rather know that my bean is misconfigured
[23:44:28] <lincolnthree> so there's no problem
[23:44:34] <lincolnthree> though it does make JSF beans completely useless
[23:44:38] *** tsurdilo1 has joined #seam-dev
[23:44:57] <mojavelinux> JSF managed beans should be put in front of a firing squad
[23:45:01] <mojavelinux> and we should have our day
[23:46:04] <mojavelinux> basically, if I do this:
[23:46:05] <mojavelinux> @Dependent
[23:46:05] <mojavelinux> public class GreeterImpl implements Greeter
[23:46:06] <mojavelinux> {
[23:46:06] <mojavelinux>    private final String greeting;
[23:46:06] <mojavelinux>
[23:46:06] <mojavelinux>    public GreeterImpl(String greeting)
[23:46:07] <mojavelinux>    {
[23:46:07] <mojavelinux>       this.greeting = greeting;
[23:46:07] <mojavelinux>    }
[23:46:08] <mojavelinux>
[23:46:08] <mojavelinux>    public String greet(String userName)
[23:46:09] <mojavelinux>    {
[23:46:09] <mojavelinux>       return greeting + " " + userName;
[23:46:10] <mojavelinux>    }
[23:46:10] <mojavelinux> }
[23:46:17] <mojavelinux> I'd like JBT to tell me I'm doing it wrong
[23:46:33] <mojavelinux> if I take away the annotation....it's hard to say
[23:46:38] <mojavelinux> because I might be using the class for something else
[23:46:39] <lincolnthree> yeah, that should at least be a warning
[23:46:43] <lincolnthree> without the annotations, no warning
[23:46:47] <mojavelinux> exactly
[23:46:48] <lincolnthree> IMO
[23:47:02] *** tsurdilo has quit IRC
[23:47:12] <mojavelinux> now, you could have a quick fix available still
[23:47:20] <mojavelinux> that would say, add bean constructor
[23:47:21] <mojavelinux> or something
[23:47:24] <mojavelinux> but not a warning
[23:47:51] <mojavelinux> like a light bulb
[23:48:16] <Nik> another thing that helps seam 2 people is https://issues.jboss.org/browse/WELD-397
[23:48:18] <jbossbot> jira [WELD-397] Warn if a scope annotation is put at an injection point [Closed, Minor, Nicklas Karlsson] https://issues.jboss.org/browse/WELD-397
[23:48:37] <akazakov> mojavelinux: maxandersen: yes we already ignore classes w/o candidate constructors... but only until it's not a valid bean type of some bean
[23:48:51] <maxandersen> mojavelinux: you mean because you put a CDI annotation on the bean we should tell you its not a valid CDI bean and provide quickfix for it ?
[23:49:06] <Nik> e.g. thou shalt not @Inject @ApplicationScoped. For it does nothing.
[23:49:19] <akazakov> so it's why ProjectImpl is treated as injectable bean in JBT
[23:49:36] <lincolnthree> It shouldn't be :)
[23:49:53] <lincolnthree> but we all know that by this point. hehe
[23:49:59] <maxandersen> Nik: ooh..why doesn't that do anything ? what am I missing ?
[23:50:13] <Nik> max: a bean has a defined scope
[23:50:19] <Nik> it doesn't change
[23:50:21] <maxandersen> lincolnthree: yup - JBT needs to be "trained" to ignore it
[23:50:26] <mojavelinux> maxandersen: I'm saying even with no annotations, you should have a "tip fix" (whatever that's called) to make it a candidate managed bean
[23:50:40] <mojavelinux> but yes, if you add an annotation
[23:50:46] <mojavelinux> then that would be updated to do the right thing for that case
[23:50:59] <Nik> max: with seam 2 you had the liberty to inject and outject cross-scope
[23:51:00] <mojavelinux> ah, so in the first case, I mean upgrading it to a regular dependent-scoped bean
[23:51:37] <mojavelinux> in the second case, to whatever scope annotation you added, if any
[23:51:41] <Nik> max: but if you have @Produce @RequestScoped Foo, @Inject @ApplicationScoped Foo is still request scope
[23:51:41] <mojavelinux> which is probably the same thing anyway
[23:51:44] <maxandersen> Nik: so you are saying @Inject @ApplicationScoped == @Inject or @inject @ApplicationScope == <noop> or its error ?
[23:51:49] <Nik> (because it's ignored)
[23:51:55] <mojavelinux> but also has some restrictions like it has to be proxiable
[23:52:09] <mojavelinux> @Inject @*Scope is wrong in any case
[23:52:17] <maxandersen> mojavelinux: if no annotation how should we know your class is intended to be a CDI ? because its in a project with CDI enabled ?
[23:52:26] <mojavelinux> yes
[23:52:38] <mojavelinux> if you are in a bean archive project
[23:52:40] <Nik> bean deployment archive, well
[23:53:02] <maxandersen> "in a bean archive project" ?!
[23:53:54] <Nik> max: going to sleep, dan and linc will explain the scope annotation on injection points if needed ;-)
[23:53:57] <Nik> z
[23:54:01] <maxandersen> so about providing a "quickfix" then quickfixes needs a corresponding warning - you can configure it to not show certain warnings though?.not sure it will keep the quick fix around...
[23:54:08] <maxandersen> Nik: night night
[23:56:15] <akazakov> maxandersen: warning or any problem marker. it can be a info marker.
[23:56:46] <akazakov> not sure it's much better than a warning... ;)
[23:56:46] <mojavelinux> yeah, an info marker
[23:56:52] <mojavelinux> like when you want to rename a file or something
[23:56:59] <mojavelinux> you get a little lightbulb
[23:57:39] <mojavelinux> by default I get "Rename in file" "Rename in workspace"
[23:57:48] <mojavelinux> can't it be like "Convert to managed bean"
[23:58:16] <mojavelinux> which fixes whatever is making it not a candidate as a managed bean (which in this case is making sure it has a no-args constructor)
[23:58:19] <maxandersen> aah - quick fix based on contexts is doable yes..but we would have to have computed that there is a "problem"
[23:58:58] <maxandersen> actually what you see are Refactorings based on context (i.e. in this case a Java Class or Method is under the cursor)
[23:59:02] <mojavelinux> oh, well, if there is any other way to provide some assistance without showing a warning, then you can do it that way instead
[23:59:09] <mojavelinux> yeah, refactoring
[23:59:11] <mojavelinux> that makes sense
[23:59:17] <maxandersen> likewise we would need to be able to (fast) know we should provide a  "fix CDI bean" :)





top