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