02:37:56 #startmeeting 02:38:02 Meeting started Wed May 4 02:37:56 2011 UTC. The chair is lightguard_jp. Information about MeetBot at http://wiki.debian.org/MeetBot. 02:38:02 Useful Commands: #action #agreed #help #info #idea #link #topic. 02:38:03 either it has to work fully, or it's not worth doing 02:38:07 #topic Seam 2 Compat / migration 02:38:11 sbryzak: exactly 02:38:16 that's my personal opinion 02:38:20 i'm happy to hear other views 02:38:24 I completely agree with that 02:38:34 #info Seam 2 Compat is really difficult, any solution will probably only be a partial solution 02:38:44 #agreed 02:38:58 #chair sbryzak 02:39:03 Current chairs: lightguard_jp sbryzak 02:39:03 interesting bot you have there 02:39:07 i'll remain standing, thanks 02:39:12 ha 02:39:20 Diablo-D3: MeetBot 02:39:24 #comedian sbryzak 02:39:28 :P 02:39:33 lol 02:39:37 so, what do you all think 02:39:41 * Diablo-D3 shoves sbryzak out a window? 02:39:45 What other things do we need to capture in this? 02:39:51 *drum beat* 02:39:56 do we concentrate our efforts on the migration guide instead? 02:40:05 I'll probably post a link to the minutes on the web site 02:40:10 well, you cant script everything 02:40:15 I vote no 02:40:19 from what Ive seen of seam 2, some stuff just doesnt work the same at all 02:40:24 or should we investigate the feasibility of the compatibility module a little further 02:40:29 So any other #idea / #info would be good just as a recap. 02:40:33 Leave Seam 2 happy as it is 02:40:37 entirely different philosophy behind certain components 02:40:42 I like the idea of a very thorough migration guide 02:40:49 migration guide works 02:41:00 especially if you have a lot f stuff that says "if you have this pattern, you want this pattern" 02:41:08 someone get dan in here 02:41:14 yeah 02:41:18 I'll call, he's not answering txt 02:41:22 we need him 02:41:27 i'd like to know what he thinks 02:41:31 let developers focus on their code quality more and less on reading the seam 3 manual 02:41:52 I mean, hell, I'd raid that migration guide just for the code examples 02:41:56 part of my reasoning is that developers are going to have to learn cdi and seam 3 anyway if they're going to be migrating 02:42:01 Doh, phone may be dead, I'll walk down the hall 02:42:25 sbryzak: yeah, but pattern -> pattern examples are ALWAYS valuable 02:42:39 sometimes a developer needs to turn his brain off for a few lines of code 02:43:28 going "this is how you code this, canonically" is immensely valuable 02:43:35 it teaches devs how to think in seam 3 or whatnot 02:43:46 breaking them of their old seam 2 habits, etc etc 02:43:53 Diablo-D3: we don't like to enforce certain patterns though 02:44:05 sbryzak: thats a somewhat bad policy in some ways 02:44:12 using frameworks is a form of ritualized coding 02:44:20 no matter if you like it or not, thats how it is 02:44:24 the point of seam is that it adds to your application unobtrusively without forcing anything on the developer 02:44:36 yes, but you still have to do it the cdi/seam way 02:45:00 which is either going to come for those developers in, a) by wrote, b) by patterns 02:45:11 and honestly banging your own code out half blindly using example-free code sucks 02:45:15 er 02:45:20 example-free docs 02:45:30 don't you mean rote? 02:45:40 pretend I can spell. 02:45:46 ok ;) 02:46:27 i just want to avoid "best practice" or anything like that 02:46:36 it's really up to the developer how they use our libraries 02:46:44 yeah, but theres only so many ways to code any given generic task 02:46:49 it's up to us to provide a clean, meaningful API 02:46:53 most code is assembled out of said generic tasks 02:47:34 at some point, to do migrations quickly and painlessly, you're going to have to write a guide that has like 50 examples of old -> new 02:47:50 sure, i agree 02:48:12 and you cant automate it by script, as I said, because some components just work using a different paradigm 02:48:16 but most of the examples will be how to apply the equivalent of the new cdi annotations in place of your old seam 2 annotations 02:48:28 sbryzak: sure, thats fine, if it applies. 02:48:54 but if we used forge to do the migration, it should be able to recognise the places that need to be re-written, and mark them for you 02:49:06 and automate the stuff that can be automated 02:49:10 stuartdouglas: yeah, but whos clever enough to write that 02:49:34 stuartdouglas: a compiler would do it also ;) 02:49:39 me :-) 02:49:46 lawlz go stuart :D 02:50:08 disclaimer: That was not me volenteering to write it 02:50:49 stuartdouglas: i think that solution would essentially be a glorified form of documentation 02:51:23 i.e. the compiler highlights an error (missing seam 2 class/annotation) and the user is informed how to fix/migrate that piece of code 02:51:33 /TODO: Hi, Seamclippy here, my heuristics say that you're trying to thwart the creation of Skynet... I mean... convert to Seam 3 02:51:54 i think we can just address it with a migration document 02:51:58 sbryzak: you know, thats actually a rather good idea 02:52:03 seam2-bitch module 02:52:16 ape all the seam2 classes and annotations just to make javac bitch 02:52:22 in fact, i'd almost suggest that we organize the migration docs in alphabetical order 02:52:32 by annotation/class name 02:52:38 I agree with that 02:52:50 something worth considering maybe 02:53:33 But still it would not be possible to replace all the features Seam 2 have 02:53:44 we could even develop the guide in parallel 02:53:48 Not until they exist in Seam 3 as modules ! :) 02:53:53 give everyone an annotation to write docs for 02:54:13 gastaldi: true, and there's no simple answer for that 02:54:17 what exists in seam 2 thats not in 3? 02:54:21 besides 02:54:26 'wait for it to be written in seam 3' 02:54:32 we even have prettyfaces intergration 02:54:51 Diablo-D3: Drools and JBPM support for example 02:55:59 It would be too late to change to org.jboss.seam3 package names ? 02:56:06 yes 02:56:10 gastaldi: bad idea, not future proof 02:56:15 final already shipped 02:56:19 hum, yeah 02:56:24 sorry about that 02:56:28 :) 02:56:37 where are those bot commands ? 02:56:47 and honestly, it should have used seam3 02:57:05 Diablo-D3: But how about when Seam 4 is launched ? 02:57:10 I doubt it will change 02:57:14 Diablo-D3: so we update all the classes to seam4 later on? 02:57:18 and then seam5? 02:57:23 yeah, bad idea 02:57:27 if you're busting the API that much? yes 02:57:31 seam27? 02:57:35 but seam3 is probably going to be the last 02:57:40 lol 02:57:44 its basically perfect. 02:58:01 In theory, you should rarely use Seam 3 classes at all 02:58:05 and what busted everything was going to CDI 02:58:16 we'll still be using CDI in seam4 through 27 02:58:20 that's the price of standardization 02:58:25 yeah 02:58:46 the cost of not sucking is to have to fix a few lines of code 02:58:52 its worth it 02:59:35 It´s interesting that "org.jboss" is used instead of "org.rh" or "org.redhat" 02:59:43 or com.redhat 02:59:48 gastaldi: yeah but 02:59:54 com.redhat has no place in java 03:00:03 unfortunately 03:00:28 jboss is our middleware brand 03:00:47 * Diablo-D3 changes the company motto 03:00:54 JBoss is a hell of a brand ! :D 03:00:59 fly into the sun, like a jBAWS 03:01:04 It sounds much better than RedHat btw 03:01:08 :) 03:01:12 wait, that sounds wrong 03:02:19 ok, so I believe that what´s missing in Seam 3 compared to Seam 2 will become modules in a near future 03:02:37 Like Drools and JBPM and excel, pdf, etc 03:02:57 gastaldi: cdi/drools will be implemented by the drools team 03:03:09 same with jbpm 03:03:13 oh, makes sense even more 03:03:41 Then they can evolve as the version increases 03:03:58 good idea 03:04:18 Seam JCR should be part of Modeshape then 03:04:38 doesn't it support jackrabbit also? 03:04:49 But since it supports Jackrabbit it should be there 03:04:54 right 03:05:11 it's different, seam jcr is integration with a spec 03:05:22 Just as Seam Mail 03:05:28 right 03:06:03 Seam Cron should be using JODA and that new DateTime api spec also 03:06:21 suggest it to PeteRoyle ;) 03:06:26 Or we could have a Seam Date :) 03:06:30 hehehe 03:06:34 got it 03:07:06 PeteRoyle: what do you think, is it going to rain this afternoon? 03:07:20 depends which block you're standing on I guess 03:07:36 well weather report says possible shower 03:07:40 was pretty patchy yesterday 03:07:47 radar pic on ourbrisbane.com looks pretty intense though 03:08:07 Man, it´s cold in Brazil 03:08:12 oh damn, that was just the thumbnail 03:08:16 Winter is coming 03:08:25 it may not rain then 03:08:42 bom looks pretty dry 03:08:48 gastaldi: i thought winter was coming here, that's why i didn't wear a hat the other day 03:08:57 but the aussie sun is still a killer even at this time of year 03:09:02 wear a red hat :) 03:09:13 any hat would have been red, from the reflection of my face 03:09:24 haha I saw your tweet 03:09:30 red as a shrimp 03:09:35 yeah, it still hurts 03:10:08 sbryzak: Do you know a thing called "sunblocker" ? 03:10:31 sun block 03:10:38 :) 03:10:50 i think i've heard of it 03:11:23 You should try it, or else an after sun lotion will be the only choice 03:11:54 i'm usually very sun smart 03:12:01 Here in brazil we say "Too sleep in a coat hanger" 03:12:09 but the other day it was freezing cold, and i didn't think i'd get burnt 03:12:22 was that on Sunday perchance? 03:12:35 PeteRoyle: it was either sunday or monday 03:13:27 were you still in melb or in brissy? 03:13:32 brisbane 03:13:40 i was in melbourne a couple of weeks ago 03:15:13 time to get off irc and do some work 03:15:40 before you go, I've got a blocking issue stopping me from implementing @asynchronous 03:16:01 PeteRoyle: Share with us 03:16:12 it's either in Weld or JBoss Interceptors 03:16:23 WELD-862 03:16:27 jira [3WELD-862] Interceptors not threadsafe [10Open (Unresolved) Bug,7 Major,6 Unassigned] https://issues.jboss.org/browse/WELD-862 03:17:17 PeteRoyle: i would ask Pete, or Ales 03:17:35 Apparently in something called SimpleInterceptorChain but I can't seem to find it 03:17:40 thanks sbryzak 03:18:58 strange 03:20:02 Related to that - would non-threadsafe interceptors be considered in conflict with the spec, or would it be considered an implementation detail? 03:20:16 lightguard_jp: you there ? 03:20:20 Because it will impact the portability of Seam Cron 03:20:33 (eg: if GlassFish has a similar bug) 03:20:47 bug/implementation detail 03:21:12 PeteRoyle: I believe that is an implementation detail. An InvocationContext should be like a closure 03:22:05 gastaldi: in what way? 03:23:03 An InvocationContext should not be tied to the current thread 03:23:31 However, the getContextData() might be changed across multiple threads 03:24:07 hum, or I guess they are a readonly map ? let me see the spec 03:24:20 what spec is that? 03:24:40 EJB 3.0 03:24:47 thanks 03:26:02 Strange, there is a getTimer() on the JEE 6 spec 03:26:43 I really believe that shouldn´t be there 03:27:09 http://download.oracle.com/javaee/6/api/javax/interceptor/InvocationContext.html 03:27:52 why not? 03:28:13 It´s strange, isn´t it ? 03:28:17 it allows you to get details about the timer that caused the invocation 03:28:21 mostly it is null 03:28:36 Yeah, but it´s tied to EJB 03:29:51 PeteRoyle: Shouldn´t the result be a Future object ? 03:30:10 Take EJB 3.1 for instance 03:30:16 http://javahowto.blogspot.com/2010/03/simple-asynchronous-methods-in-ejb-31.html 03:30:41 In most cases it probably will be 03:30:50 And I will have to make sure I support that 03:40:26 PeteRoyle: I didn´t find anything about that on the spec 03:40:31 even on 3.1 03:42:18 But I suggest you use the Executor framework provided by the Java Concurrency Utilities package for scheduling tasks 03:43:00 Or you may run out of resources 03:43:50 Consider firing some events when a job is started and finished 03:46:02 sounds feasible ? 03:50:34 stuartdouglas: Is @Veto already scheduled be included in CDI 1.1 ? 03:50:43 I think so 03:51:52 great 03:52:13 sorry gastaldi I had to take a call 03:52:34 Ideally Cron will support mupltiple backends, including Executor 03:52:44 Currently it uses Quartz 03:52:56 (as you well know I just realised) 03:54:26 no problem on that. I was thinking on your proposed code in WELD-862 03:54:31 jira [3WELD-862] Interceptors not threadsafe [10Open (Unresolved) Bug,7 Major,6 Unassigned] https://issues.jboss.org/browse/WELD-862 03:54:46 ah gotchya 03:57:39 yeah events would be a nice idea gastaldi :) 03:58:15 great 03:58:33 stuartdouglas: I have a question regarding @ServiceHandler 03:58:38 ok 03:59:14 stuartdouglas: Shouldn´t the implementation be declared in a @Dependent scope ? 03:59:48 what do you mean? 04:00:10 The handler class that must have a method with the following signature: @AroundInvoke public Object aroundInvoke(final InvocationContext invocation) throws Exception 04:00:29 Isn´t required to be in a @Dependent scope? 04:00:52 as it behaves like an interceptor ? 04:02:25 @Dependent is the default scope 04:03:22 Yeah, but is it ok to specify another scope for this handler class ? 04:03:30 no 04:03:48 That was my doubt 04:04:16 I needed to ask because I am documenting for CDI 1.1 04:04:29 That feature will really rock 04:04:59 It should be possible to give the interface bean a scope, and the handler will last for the lifetime of the bean 04:05:25 That´s what the @Dependent is for right ? 04:05:34 ... is for, right ? 04:06:15 yes 04:06:25 although the handler is not actually a bean 04:06:31 great 04:06:36 yes 04:06:41 so that does not really apply 04:06:46 It should not be anyway 04:07:16 Actually it´s an interceptor, only for abstract and interfaces 04:07:31 And it should be treated like an interceptor 04:09:47 What about that instead of @ServiceHandlerType, be @ServiceHandlerBinding 04:10:04 yea, that is the way it should be 04:10:15 there is a solder issue for it 04:10:23 Ok, I´ll make sure it will get correctly on CDI 1.1 04:10:40 it also would allow you to have multiple handlers, but then you need some way of dealing with ordering 04:11:18 humm 04:11:43 I don´t really like the idea of multiple handlers 04:12:00 I don't think there is a compelling case for them 04:12:04 but it is an option 04:12:18 Because you would end up with different impls, and then you would need a Qualifier to choose which will be called 04:13:17 How would you handle when handler returned objects? 04:13:33 the same way interceptors do 04:14:54 hum. That might be true 04:15:14 Maybe it should be considered for the spec 04:15:47 SOLDER-51 04:15:55 jira [3SOLDER-51] Decouple service handler annotation from implementation class [10Open (Unresolved) Feature Request,7 Critical,6 Unassigned] https://issues.jboss.org/browse/SOLDER-51 04:19:14 cool 04:19:25 It will rock ! :D 04:20:23 Is anyone writing something for CDI 1.1 ? 04:20:35 in the docbook ? 04:21:59 *chirp* 04:22:24 let me be the first to say 04:22:28 no. 04:22:51 :) 04:23:10 Thanks, it seems I am the only one this far :) 04:24:01 cool :) 04:28:49 Isn´t CDI-28 a duplicate of CDI-110 ? 04:28:53 jira [3CDI-28] Abstract methods on decorators [10Open (Unresolved) Bug,7 Major,6 Unassigned] https://issues.jboss.org/browse/CDI-28 04:28:58 jira [3CDI-110] Provide support for binding an invocation handler to an interface or abstract class [10Open (Unresolved) Feature Request,7 Major,6 George Gastaldi] https://issues.jboss.org/browse/CDI-110 04:29:54 Or, ServiceHandlers are used when the interface is unknown 04:30:12 And decorators when the interface is known 04:32:07 How about ServiceHandler on method-level ? That makes sense ?? 04:42:26 hum.. They are much alike an Interceptor 04:43:19 When dealing with an abstract class, I may have concrete methods 04:43:47 It behaves exactly the same as an Interceptor in this scenario 04:45:25 However, if we allow an Interceptor to intercept abstract methods as in CDI-28, the ServiceHandler feature become useless 04:45:29 jira [3CDI-28] Abstract methods on decorators [10Open (Unresolved) Bug,7 Major,6 Unassigned] https://issues.jboss.org/browse/CDI-28 04:45:37 any thoughts ? 04:49:31 ok, need to sleep... bye everyone 07:15:52 Signing off, sorry about that, but it doesn't look like I missed anything 07:15:59 #endmeeting