[00:18:39] *** tsurdilo1 has joined #seam-dev
[00:20:40] *** tsurdilo has quit IRC
[00:42:21] *** tsurdilo1 has quit IRC
[00:42:40] *** tsurdilo has joined #seam-dev
[00:47:59] *** rruss has joined #seam-dev
[00:53:39] *** tsurdilo has quit IRC
[00:56:48] *** aslak has quit IRC
[01:04:42] *** lightguard_jp has quit IRC
[01:20:40] *** tsurdilo has joined #seam-dev
[01:48:38] *** mbg has quit IRC
[02:23:13] *** mbg has joined #seam-dev
[02:23:13] *** mbg has quit IRC
[02:23:13] *** mbg has joined #seam-dev
[02:48:11] *** tsurdilo has quit IRC
[03:12:16] *** bleathem has joined #seam-dev
[03:36:52] *** bleathem has quit IRC
[05:11:15] *** cbrock has joined #seam-dev
[05:12:03] *** cbrock has quit IRC
[05:30:32] *** bleathem has joined #seam-dev
[05:30:46] <bleathem> lincolnthree: ping
[05:56:41] *** rruss has quit IRC
[05:58:32] *** rruss has joined #seam-dev
[06:02:35] *** lincolnthree has quit IRC
[06:02:37] *** lincolnthree1 has joined #seam-dev
[06:02:40] <lincolnthree1> bleathem: pong
[06:07:44] *** rruss has quit IRC
[06:24:13] *** rruss has joined #seam-dev
[06:28:51] *** rruss has quit IRC
[06:34:02] *** rruss has joined #seam-dev
[07:11:12] *** oskutka has joined #seam-dev
[08:21:06] *** lincolnthree has joined #seam-dev
[08:35:40] *** lincolnthree1 has quit IRC
[08:43:29] *** mbg has left #seam-dev
[09:16:01] *** jharting has joined #seam-dev
[09:16:50] *** epbernard has joined #seam-dev
[09:16:50] *** epbernard is now known as emmanuel
[09:21:08] *** marekn has joined #seam-dev
[11:11:21] <jbossbot> git [config] push master 2f3b8de.. Stuart Douglas Move Seam Config to use seam solder rather than weld extentsions
[11:11:21] <jbossbot> git [config] push master URL: http://github.com/seam/config/compare/c2af7c1...2f3b8de
[11:26:56] *** aslak has joined #seam-dev
[11:26:56] *** aslak has quit IRC
[11:26:56] *** aslak has joined #seam-dev
[11:31:55] *** pmuir has joined #seam-dev
[11:31:55] *** pmuir has quit IRC
[11:31:55] *** pmuir has joined #seam-dev
[11:46:15] <stuartdouglas> pmuir: were you happy with my changes to solder?
[11:46:19] <stuartdouglas> If so I will merge
[11:46:30] <pmuir> stuartdouglas: yes, assuming all tests pass
[11:47:03] <stuartdouglas> ok, I will merge
[11:47:33] <pmuir> cool
[11:47:37] <pmuir> thanks stuart
[11:49:33] <jbossbot> git [solder] push master 1c37e9d.. Stuart Douglas SOLDER-29 Add setAccessible() method to Property
[11:49:34] <jbossbot> jira [SOLDER-29] Property needs a setAccessible method [Resolved, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-29
[11:49:34] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/57c5c5c...1c37e9d
[11:50:59] <jbossbot> git [solder] push master 0ebbf03.. Stuart Douglas SOLDER-46 Add ability to get only writable properties to PropertyQuery
[11:50:59] <jbossbot> jira [SOLDER-46] Allow PropertyQuery to query for writable properties only [Resolved, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-46
[11:51:00] <jbossbot> git [solder] push master 3665aee.. Stuart Douglas Merge branch 'writableProperties' of https://github.com/stuartwdouglas/solder into stuartwdouglas-writableProperties
[11:51:00] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/1c37e9d...3665aee
[11:51:32] <stuartdouglas> damn, should have rebased the second one
[11:51:39] <stuartdouglas> now there is a merge commit
[11:51:59] <stuartdouglas> should I rewrite history or just leave it?
[11:52:41] <pmuir> if you've pushed to solder/master you need to leave it
[11:53:06] <stuartdouglas> ok, damn
[12:03:28] *** bleathem_ has joined #seam-dev
[12:03:38] *** bleathem has quit IRC
[12:06:05] <pmuir> i don't see any problem with us rewriting history in our forks of stuff
[12:06:13] <pmuir> as that is clearly a development ground
[12:06:36] <pmuir> but master needs to remain consistent as someone might be cloning it and we could really piss them off
[12:11:31] <stuartdouglas> yes, I stuffed up by just blindly following the instructions on the pull request, instead of thinking about what I was doing
[12:17:04] *** emmanuel has quit IRC
[12:23:14] <pmuir> hehe
[12:23:53] <pmuir> i suggest always doing git log -n (n+1) where n is the number of commits you expect
[12:23:58] <pmuir> before pushing
[12:24:56] <stuartdouglas> good idea
[12:25:37] <pmuir> just as a sanity check
[12:25:37] *** aslak has quit IRC
[12:26:12] *** aslak has joined #seam-dev
[12:26:26] <stuartdouglas> pmuir: what sort of time frame are you looking at for a solder release?
[12:26:42] <pmuir> we should review the open issues
[12:26:44] <pmuir> got time now?
[12:26:51] <stuartdouglas> yep
[12:26:53] <pmuir> i need to release weld this weekend
[12:26:54] <pmuir> so after that
[12:27:13] <stuartdouglas> sounds good
[12:27:38] <pmuir> there are a few big issues in there
[12:27:45] <pmuir> SOLDER-1
[12:27:46] <jbossbot> jira [SOLDER-1] ELResolver assumes flat deployment structure [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-1
[12:28:03] <pmuir> i have no idea how to fix this one...
[12:28:22] <stuartdouglas> I have not really thought about it
[12:28:31] <stuartdouglas> but nothing really comes to mind
[12:28:33] <pmuir> SOLDER-4 needs doing but is trivial
[12:28:33] <jbossbot> jira [SOLDER-4] CNFE: InterceptorExtension [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-4
[12:28:47] <pmuir> same with SOLDER-5
[12:28:48] <jbossbot> jira [SOLDER-5] el-api should be scope provided [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-5
[12:29:11] <stuartdouglas> I think 4 is already done
[12:29:23] <pmuir> SOLDER-10 is similar
[12:29:23] <jbossbot> jira [SOLDER-10] To run arquillian tests jboss-logging must be explicitly stated as a dependency of the project [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-10
[12:29:32] <pmuir> ok can you verify -4 and close if it is?
[12:29:45] <pmuir> SOLDER-9 is similar
[12:29:46] <jbossbot> jira [SOLDER-9] JTA should not be a required dep but Getting Started chapter says it is [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-9
[12:29:48] <stuartdouglas> yea, its done, I wanted to mark it off the other day but did not have permission
[12:30:09] <pmuir> ok you do now :-)
[12:30:18] <pmuir> have you looked at SOLDER-11 at all?
[12:30:19] <jbossbot> jira [SOLDER-11] Performance on startup of weldx is extremely slow [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-11
[12:30:38] <stuartdouglas> no, although I think that was probably more a weld think
[12:30:57] <stuartdouglas> and changing to ArraySet rather than HashSet should have improved this considerable
[12:31:08] <pmuir> ok
[12:31:14] <stuartdouglas> I will run over it in jprofiler though, and make sure there is nothing obvios
[12:31:18] <pmuir> ok
[12:31:28] <pmuir> do you have a way to produce any metrics?
[12:32:04] <stuartdouglas> not really, for all my testing I have been using the bean-generator from the performance guys
[12:32:04] *** aslak has quit IRC
[12:32:10] <pmuir> ok
[12:32:24] <stuartdouglas> although how representative it is of real world beans I am not sure
[12:32:26] <pmuir> do we want to ask martin to add some tests for this?
[12:32:53] *** aslak has joined #seam-dev
[12:32:54] <stuartdouglas> yes, that would be good
[12:33:09] <stuartdouglas> performance is such a relative thing, you really need to do all the tests on one computer
[12:33:19] <pmuir> ok
[12:33:20] <stuartdouglas> if you want to start comparing things
[12:33:21] <pmuir> let's do that
[12:33:33] <pmuir> SOLDER-20 would be good to do
[12:33:33] <jbossbot> jira [SOLDER-20] Extract API into separate module [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-20
[12:33:46] <stuartdouglas> ok, I can take that one if you want
[12:34:11] <pmuir> ok that would be good
[12:34:20] <pmuir> btw you did the generic bean changes (to only use qualifiers) right?
[12:34:41] <stuartdouglas> not yet, I did the configure using managed beans one
[12:34:52] <pmuir> ok
[12:34:55] <pmuir> that would be good to do
[12:35:07] <pmuir> SOLDER-27 -- is that it, or something else?
[12:35:07] <jbossbot> jira [SOLDER-27] Allow generic beans to be configured via any class type not just annotations [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-27
[12:36:03] <stuartdouglas> that is the qualifiers one
[12:36:07] <pmuir> ok
[12:39:50] <pmuir> shouldn't https://jira.jboss.org/browse/SOLDER-36 be closed?
[12:39:51] <jbossbot> jira [SOLDER-36] Allow generic beans to be configured via managed beans [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-36
[12:40:59] <stuartdouglas> yes, done
[12:41:41] <pmuir> close it :-D
[12:42:06] <pmuir> SOLDER-44
[12:42:07] <jbossbot> jira [SOLDER-44] InjectableMethod should make method accessible before invoking [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-44
[12:42:53] <stuartdouglas> looks pretty minor
[12:42:53] <pmuir> SOLDER-47
[12:42:54] <jbossbot> jira [SOLDER-47] Cannot use Solder in Glassfish 3.1 [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-47
[12:43:05] <stuartdouglas> that is a GF issue isn't it?
[12:43:18] <pmuir> yes, but would like to verify with siva it's working before closing it out
[12:43:29] *** epbernard has joined #seam-dev
[12:43:29] *** epbernard is now known as emmanuel
[12:43:33] <pmuir> those are the issues I think we need to fix for a release
[12:43:36] <pmuir> anything you want to add?
[12:44:18] <stuartdouglas> what about SOLDER-35
[12:44:19] <jbossbot> jira [SOLDER-35] Remove slf4j usage from weldx [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-35
[12:44:55] <stuartdouglas> and probably SOLDER-7
[12:44:55] <jbossbot> jira [SOLDER-7] Disposer methods for @Default producer methods declared on generic beans require explicit definition of @Default [Open, Major, Unassigned] https://jira.jboss.org/browse/SOLDER-7
[12:45:33] <stuartdouglas> although I am not sure if 7 is still an issue, I have a feeling it may have been filled before my last big generic beans refactoring
[12:45:46] <pmuir> ok can you checkout -7
[12:45:50] <pmuir> we can do -35 as well
[12:46:12] <pmuir> do you want to fix up JIRA so that the ones we discussed are in the .next bin and the rest aren't?
[12:46:39] <stuartdouglas> yep, Beta2 is the next release right, we are not changing it with the rename?
[12:47:02] <pmuir> no no change
[12:47:11] <pmuir> i mean no change
[12:55:59] <stuartdouglas> ok, done
[12:57:28] <stuartdouglas> pmuir: I am going to bed, unless you have anything else?
[12:58:55] <pmuir> nope thats good :-)
[13:00:08] <stuartdouglas> ok, later
[13:04:50] *** rruss has quit IRC
[13:05:34] *** rruss has joined #seam-dev
[13:21:01] *** balunasj has joined #seam-dev
[13:25:01] *** balunasj has quit IRC
[14:00:46] *** rruss has quit IRC
[14:03:37] *** rruss has joined #seam-dev
[14:38:31] *** pmuir has quit IRC
[15:00:07] *** balunasj has joined #seam-dev
[15:02:37] *** tsurdilo has joined #seam-dev
[15:06:43] *** lightguard_jp has joined #seam-dev
[15:16:42] *** tsurdilo1 has joined #seam-dev
[15:17:10] *** tsurdilo1 has quit IRC
[15:17:32] *** tsurdilo1 has joined #seam-dev
[15:19:38] *** tsurdilo has quit IRC
[15:25:35] *** adamw1pl has joined #seam-dev
[15:35:53] *** bleathem_ has quit IRC
[15:58:17] *** tsurdilo has joined #seam-dev
[15:58:18] *** tsurdilo1 has quit IRC
[16:02:33] *** lincolnthree has joined #seam-dev
[16:02:40] *** mbg has joined #seam-dev
[16:03:03] *** tsurdilo has quit IRC
[16:03:24] *** mbg is now known as mbg|afk
[16:06:46] <lincolnthree> stuartdouglas: noticed you closed the weldx boot performance issue, if you have a minute, what did you change? I'm curious.
[16:09:12] *** tsurdilo has joined #seam-dev
[16:35:41] <lightguard_jp> http://lightguard-jp.blogspot.com/2010/12/seam-catch-alpha2.html
[16:44:20] <clerum> http://www.spacex.com/webcast.php
[16:44:27] *** bleathem has joined #seam-dev
[16:44:41] <clerum> 50 seconds
[16:49:23] <lincolnthree> Is this a live space launch?
[16:50:07] <lincolnthree> 3.7KM/second LOL
[16:52:03] <clerum> yep
[16:52:17] <clerum> first launch of falcon 9 with real payload
[16:53:20] <lightguard_jp> Why can't I be notified of new posts on seamframework.org when I add a comment?
[16:54:15] <clerum> you want you phone to ring when you make a call?
[16:55:21] <lincolnthree> lightguard_jp: it's a shortcoming in the system
[16:55:46] <lightguard_jp> Gah.  Well, the RSS feed will sufice.
[17:05:09] <lightguard_jp> clerum: Sorry, new posts after I comment on a thread
[17:06:47] *** marekn has quit IRC
[17:12:47] <lincolnthree> It only works if you started the thread afaik
[17:15:55] *** adamw1pl has quit IRC
[17:28:27] <bleathem> lightguard_jp: Hey Jason
[17:28:35] <lightguard_jp> bleathem: Hm?
[17:28:42] <lightguard_jp> lincolnthree: lame
[17:28:50] <bleathem> I don't see a jira issue for using Seam catch to create JSF messages.
[17:29:00] <bleathem> Is one needed?
[17:29:39] <lincolnthree> bleathem: yeah, the faces integration still needs to be done by somebody
[17:29:45] <lincolnthree> bleathem: wanna have a go? ;)
[17:29:53] <lightguard_jp> It should be a sub task of https://jira.jboss.org/browse/SEAMCATCH-7
[17:29:54] <jbossbot> jira [SEAMCATCH-7] Create a JSF bridge [Open, Major, Jason Porter] https://jira.jboss.org/browse/SEAMCATCH-7
[17:30:06] <lightguard_jp> It should probably be in the Faces project.
[17:30:10] <lincolnthree> yeap
[17:30:17] <lightguard_jp> We decided to do the integrations in the modules.
[17:30:31] <lightguard_jp> They'll be the next things I'll tackle
[17:30:33] <bleathem> Ok, cool
[17:30:35] <lincolnthree> It's a matter of writing a FacesExceptionFactory
[17:30:45] <lincolnthree> And a lifecycle/navigation hook.
[17:30:45] <lightguard_jp> For JSF and JAX-RS (which is basically written in the Catch example)
[17:30:47] <bleathem> I don't mind giving it a shot
[17:30:56] <lightguard_jp> Yeah, it's pretty dead easy
[17:31:03] <bleathem> I like easy :D
[17:31:16] <lincolnthree> The only questionable part is the Faces ExceptionHandlerFactory
[17:31:40] <lightguard_jp> Look at http://www.jsfsummit.com/blog/ed_burns/2009/09/dealing_gracefully_with_viewexpiredexception_in_jsf2
[17:31:47] <lincolnthree> Last time I checked, wrapping that is next to impossible (e.g. if someone else writes one, it replaces yours.)
[17:31:52] *** mbg|afk is now known as mbg
[17:31:54] <lincolnthree> But it is possible
[17:31:55] <bleathem> Yeah, I followed ed'
[17:31:57] <bleathem> s
[17:32:20] <lincolnthree> Ah, there is a wrapper.
[17:32:21] <bleathem> Yeah, I followed ed's recommendation for handling ConversationExpired exceptions
[17:32:37] <lincolnthree> Yes very good - that'll work without issues. They fixed it in JSF2
[17:32:57] <lincolnthree> There's still the chance for someone else to intercept it, but..
[17:32:58] <lincolnthree> Meh
[17:33:05] <lightguard_jp> Yeah, so you'll create a JSF exception handler that will just fire the event into catch and that's it.
[17:33:12] <lincolnthree> Yep :)
[17:33:13] <lincolnthree> Well
[17:33:24] <lincolnthree> Don't you also need a State object?
[17:33:25] <bleathem> Wow, nice.
[17:33:34] <lightguard_jp> And I think there's something else that may need to be done for Ajax exceptions, but not sure.
[17:33:35] <lincolnthree> With some information about JSF, like the FacesContext and such?
[17:33:42] <lightguard_jp> lincolnthree: State object is so three months ago :P
[17:33:59] <lightguard_jp> Catch has moved beyond it.
[17:34:02] <lincolnthree> So how do you get the NavigationHandler? Or do you just inject FacesContext
[17:34:09] <lincolnthree> or the navhandler, for that matter
[17:34:10] <lightguard_jp> Inject what you need :)
[17:34:14] <lincolnthree> Fair enough.
[17:34:28] <lightguard_jp> Handlers work like Observers now, anything you need just inject into the handler method
[17:35:21] <lightguard_jp> Catch also supports Solder ServiceHandlers so all of this could be done in a ServiceHandler and done declaratively.
[17:35:48] <bleathem> that was your blog post this morning
[17:35:57] <lightguard_jp> Yep :)
[17:36:05] <lightguard_jp> Dan added that feature
[17:36:17] <bleathem> "I love it when a plan comes together!"
[17:36:40] <lightguard_jp> hehe
[17:38:41] *** balunasj has quit IRC
[17:38:53] <lincolnthree> Wow
[17:39:03] <lincolnthree> Somehow my JavaParser now works on interfaces
[17:39:11] <lincolnthree> I don't recall making that possible.
[17:39:56] <lincolnthree> omg it works
[17:39:58] <lincolnthree> this is exciting
[17:45:19] <lincolnthree> ahh crap, but enums are broken
[17:45:56] <lincolnthree> at least the unit tests run in about a second :)
[17:47:59] <bleathem> It's always nice when you write something and get things "for free"
[17:48:13] <lightguard_jp> :)
[17:48:32] <lincolnthree> annotations and enums work differently than classes/interfaces apparently
[17:48:38] <lincolnthree> This could be tricky :)
[17:48:40] <lincolnthree> I like tricky
[17:49:02] <lightguard_jp> Yeah, they're both funky language tricks
[17:49:13] <lincolnthree> Enums really need inheritance.
[17:49:55] <lincolnthree> And the only way that would work is if you extend an Enum isntance, which is a weird idea i know
[17:50:00] <lincolnthree> But Enum.FOO
[17:50:07] <lincolnthree> well
[17:50:12] <lincolnthree> Foo.FOO
[17:50:19] <lincolnthree> Bar extends Foo.FOO
[17:50:40] <lincolnthree> Would work great :)
[17:50:43] <lightguard_jp> That's kinda what happens already
[17:50:49] <lincolnthree> Except you can't do it.
[17:50:53] <lightguard_jp> All enums are an instance of Enum
[17:50:54] <lightguard_jp> Yeah
[17:51:00] <lightguard_jp> Same with Annotation
[17:51:03] <lincolnthree> yeah
[17:51:10] <lightguard_jp> inheritance of annotations would be great
[17:51:14] <lincolnthree> truly
[17:51:49] <lightguard_jp> I bet after another year or so when lots of people have been using CDI they'll start asking for it more
[17:52:19] <lightguard_jp> Anyone heard news about Apache dropping from the JCP EC?
[17:52:29] <lincolnthree> I haven't, was there an announcement?
[17:52:37] <lincolnthree> I know they threatened.
[17:52:38] <lightguard_jp> I haven't heard one yet
[17:52:40] <lightguard_jp> Yeah
[17:53:04] <lightguard_jp> Waiting to see who moves first in this political game of chicken
[18:02:41] *** oskutka has quit IRC
[18:03:22] *** kpiwko has joined #seam-dev
[18:04:42] <lincolnthree> I think this is awesome:
[18:04:46] <lincolnthree> public interface JavaClass extends Packaged<JavaClass>, Compiled<JavaClass>, Abstractable<JavaClass>, VisibilityScoped<JavaClass>, AnnotationTarget<JavaClass>, Importer<JavaClass>
[18:09:58] *** kpiwko has quit IRC
[18:36:41] <lightguard_jp> What is that telling it, exactly?
[18:37:14] <lightguard_jp> Aside from generics are very tricky (which I knew, Enum<E extends Enum> is the same thing)
[18:37:29] <lincolnthree> public interface JavaClass extends
[18:37:29] <lincolnthree>       CompilationUnit<JavaClass>,
[18:37:29] <lincolnthree>       Abstractable<JavaClass>,
[18:37:29] <lincolnthree>       FieldHolder<JavaClass>,
[18:37:29] <lincolnthree>       MethodHolder<JavaClass>
[18:37:29] <lincolnthree> {
[18:37:29] <lincolnthree> }
[18:37:35] <lincolnthree> it's a little simpler now
[18:38:14] <lincolnthree> It's basically saying that JavaClass is a compilation unit, which means it's a source file that can be parsed or produced by the JavaParser - compilation unit has imports, visibility scoping, a package declaration, and a name
[18:38:40] <lincolnthree> JavaEnum is also a CompilationUnit
[18:38:44] <lincolnthree> same with JavaAnnotation
[18:39:07] <lincolnthree> But JavaEnum is not abstractable
[18:39:15] <lincolnthree> and JavaAnnotation is not a MethodHolder
[18:39:16] <lincolnthree> etc
[18:39:31] <lincolnthree> Under the covers, there's still a giant JavaClassImpl God class
[18:39:47] <lincolnthree> but depending on the interface you're using, you expose different functionality
[18:40:56] <lightguard_jp> Ah
[18:41:02] <lightguard_jp> But annotations actually do have methods
[18:41:04] <lightguard_jp> Sort of
[18:42:02] <lincolnthree> they do?
[18:42:39] <lincolnthree> That's news to me!
[18:42:50] <lightguard_jp> I don't know exactly what they are, but when you define "properties" on an annotation I think they're actually methods
[18:43:15] <lightguard_jp> If you create an AnnotationLiteral that contains properties they come in as methods
[18:43:24] <lincolnthree> oh.. sure
[18:43:39] <lincolnthree> they basically get compiled from literal values into methods
[18:43:47] <lightguard_jp> I'm not sure what they are in the byte code, probably worth looking at
[18:43:48] <lincolnthree> but that's a compiler trick
[18:44:06] <lincolnthree> in the source they are something completely different when it comes to parsing
[18:44:24] <lightguard_jp> Yeah
[18:45:17] <lincolnthree> I'm not sure what they're called either
[18:49:14] <lightguard_jp> Wow
[18:49:17] <lightguard_jp> I LOVE ZSH!!
[18:49:51] <lightguard_jp> javap -classpath target/classes -pcs org.<TAB>.<TAB>.<TAB> etc awesomeness
[18:50:54] <lightguard_jp> Yeah, in the bytecode they're methods
[18:51:02] <lightguard_jp> As it compiles down to an interface
[18:51:29] <lightguard_jp> Not quite sure how it does defaults, must be a runtime proxy
[18:51:51] <lincolnthree> compile time
[18:51:57] <lincolnthree> it's all compile time
[18:52:55] <lincolnthree> the compiler processes each annotation instance compile time, so if there's no value, it just uses the default instead
[18:53:10] <lightguard_jp> Where's the impl then?
[18:53:17] <lincolnthree> nothing in an annotation can be declared dynamically
[18:53:23] <lincolnthree> it all has to be resolvable at compile time
[18:53:31] <lincolnthree> the annotation impl?
[18:53:33] <lightguard_jp> javap -classpath target/classes -private -c org.jboss.seam.exception.control.Handles
[18:53:36] <lightguard_jp> Compiled from "Handles.java"
[18:53:39] <lightguard_jp> public interface org.jboss.seam.exception.control.Handles extends java.lang.annotation.Annotation{
[18:53:42] <lightguard_jp> public abstract org.jboss.seam.exception.control.TraversalPath during();
[18:53:45] <lightguard_jp> public abstract int precedence();
[18:53:47] <lightguard_jp> }
[18:53:50] <lightguard_jp> Yes
[18:53:58] <lightguard_jp> Both of those have defaults
[18:54:03] <lightguard_jp> In the java source
[18:55:37] <lightguard_jp> There's no class for that impl
[18:55:46] <lightguard_jp> Now I'm very curious
[18:55:58] <lincolnthree> You have to look at the class that defines the annotation.
[18:56:00] <lincolnthree> Err
[18:56:03] <lincolnthree> That uses the annotation.
[18:56:35] <lincolnthree> Also, I think there's more information in the bytecode that's not showing up with JavaP
[18:56:37] <lightguard_jp> Ah, they're in the class file, but javap doesn't show it to you
[19:17:46] <tsurdilo> hey guys, anyone up to help me with a seam 2 issue with deployment ?
[19:49:58] *** emmanuel has quit IRC
[20:02:27] <clerum> try #seam
[20:25:46] <stuartdouglas> lincolnthree: I did not close the weldx performance issue, Just set the fix version
[20:40:39] *** balunasj has joined #seam-dev
[20:46:08] <stuartdouglas> lincolnthree: Also the JVM provides it's own actual annotation implementation when the annotation is loaded that sublcasses the abstract annotation implementation
[20:46:37] <stuartdouglas> This provided impl has the hashCode and equals methods, and one method per attribute that returns the attribute value
[20:47:15] <lincolnthree> Thank you :)
[20:47:42] <lincolnthree> Which is why AnnotationLiteral works
[20:51:33] <lightguard_jp> stuartdouglas: Thought so
[21:03:09] *** balunasj has quit IRC
[21:33:13] *** jharting has quit IRC
[22:15:13] *** rruss has quit IRC
[22:47:47] *** lightguard_jp has quit IRC
[23:01:26] *** tsurdilo has quit IRC
[23:37:59] *** mbg has quit IRC





top