[00:00:14] <stuartdouglas> because enums are not beans, so modifying the AnnotatedType is meaninless
[00:00:14] <jbossbot> git [dist] push master d407ab7.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[00:00:14] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/dc92acc...d407ab7
[00:00:16] <bleathem> ok, interface fields it is
[00:01:08] *** gastaldi has quit IRC
[00:03:13] <jbossbot> git [dist] push master dc92acc.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR9
[00:03:14] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/e934558...dc92acc
[00:08:54] <bleathem> stuartdouglas: switching to interfaces worked.  w00t!
[00:08:58] <bleathem> small change really
[00:11:14] <bleathem> The @ViewConfig which use to look like this:
[00:11:15] <bleathem> http://pastie.org/1693957
[00:11:18] <bleathem> now look like this:
[00:11:27] <bleathem> http://pastie.org/1694073
[00:11:52] <bleathem> a few more unnecessary characters, but otherwise acceptable
[00:12:03] <bleathem> thanks stuartdouglas!
[00:12:18] <jbossbot> git [security] push master 57e5dc0.. Shane Bryzak update broken package names
[00:12:18] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/b14a128...57e5dc0
[00:13:10] <sbryzak> bleathem: let me know when you're ready to integrate the security stuff
[00:17:19] *** Royle has joined #seam-dev
[00:17:36] *** PeteRoyle has quit IRC
[00:18:22] *** aslak has quit IRC
[00:26:21] <jbossbot> git [security] push master deb3e38.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR3
[00:26:21] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/57e5dc0...deb3e38
[00:26:33] <jbossbot> git [security] push master f0a2463.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[00:26:33] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/deb3e38...f0a2463
[00:28:16] <bleathem> sbryzak you bet
[00:28:49] <bleathem> so far I have it working with a simple EL based @Restrict annotation (for testing purposes)
[00:29:06] <bleathem> Will work on the Security integration once I have a few more wrinkles ironed out
[00:31:10] <sbryzak> sounds good
[00:31:38] <sbryzak> you need to allow for the configuration of two views
[00:31:51] <sbryzak> one for authorization exceptions, and one for the login page
[00:32:50] <bleathem> you mean two different view outcomes for authorization failure?
[00:33:12] <bleathem> I was thinking of even making the view outcome arbitrary
[00:33:16] <sbryzak> actually
[00:33:29] <bleathem> via an annotation parameter
[00:33:35] <sbryzak> you don't need one for the authorization failure
[00:33:40] <sbryzak> that can be handled by catch
[00:33:52] <sbryzak> you need to be able to configure the login view though
[00:33:58] <bleathem> for instance, if you are not allowed to view a particular item, you may want to redirect to a list of items
[00:34:19] <sbryzak> the behaviour should depend on whether the user is currently authenticated
[00:34:30] <sbryzak> if they're not, then an authorization check should redirect them to a login page
[00:34:37] <sbryzak> otherwise it should redirect them to an error page
[00:35:22] <bleathem> I agree redirect to an error page by default, but an option to redirect o a specific view on auth failure would be useful
[00:36:04] <bleathem> configurable per view, probably using an annotation, or a property of an annotation
[00:36:06] <sbryzak> it should always redirect to a login page if they're not logged in and try to access a restricted page
[00:36:11] <bleathem> right
[00:36:36] <bleathem> 1) if not logged in, redirect to a login page
[00:37:10] <bleathem> 2) if logged in, and auth fails, redirect to an error page by default, with option of providing an "auth failed view" via anotation or parameter
[00:37:38] <sbryzak> perfect
[00:37:43] <bleathem> cool
[01:01:56] <bleathem> Solder/CDI experts
[01:01:59] <bleathem> Solder/CDI experts:
[01:02:41] <bleathem> I have a class that listens to CDI events to enforce view security
[01:02:55] <bleathem> I want to disable this class when Seam Security is not on the classpath
[01:03:08] <bleathem> Is @Requires the best way to do this?
[01:03:34] <bleathem> So that the CDI events in the class will not be observed if the @required class is not present?
[01:08:50] <sbryzak> yep, use @Requires
[01:09:00] <bleathem> @Requires("org.jboss.seam.security.extension.SecurityExtension")
[01:09:30] <sbryzak> which event are you observing?
[01:10:03] <bleathem> one of: AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER
[01:10:14] <bleathem> I can givve you the actual events if you prefer
[01:10:29] <bleathem> But the CDI events that correspond to those phase boundaries
[01:11:42] <bleathem> PostRestoreStateEvent | ?? | PreRenderViewEvent
[01:11:52] <bleathem> looking for the ^ ?? one still
[01:12:01] <sbryzak> np
[01:12:59] <bleathem> PhaseEvent, with the @InvokeApplication and @Before qualifiers
[01:18:59] *** johnament has joined #seam-dev
[01:19:40] <bleathem> sbryzak: the event I should through, to indicate a Seam Security check is required, should that event be in Faces, or in Seam Security?
[01:19:51] <bleathem> s/through/throw/
[01:20:40] <sbryzak> hmm, good question
[01:20:41] * bleathem is a phonetic typer, and an after-the-fact grammar checker
[01:20:53] <johnament> solder
[01:20:54] <johnament> ?
[01:21:10] <bleathem> "when in doubt, throw it in solder!" :D
[01:21:12] <sbryzak> it could potentially be used by other view layers
[01:21:23] <johnament> but does it apply to anything but security?
[01:21:37] <bleathem> Don't think so
[01:21:41] <sbryzak> no
[01:21:48] <johnament> then security makes sense.
[01:21:57] <johnament> to me.
[01:21:57] <bleathem> agreed
[01:22:08] <sbryzak> yeah, i'll create the class in the security module
[01:22:13] <bleathem> so that in can be used by other view layers
[01:22:25] <bleathem> What parameters should it take?
[01:22:59] <bleathem> or rather, what properties should it have
[01:23:21] <bleathem> that'll be kind of view specific I think
[01:23:36] <bleathem> Or it could be done Catch style
[01:23:44] <bleathem> where required parameters are injected in
[01:23:58] <bleathem> things like the FacesContext
[01:24:32] <sbryzak> it would need to contain the annotation literals for each of the security bindings
[01:24:58] <sbryzak> i'll have to look at it later today, i need to go out for a while now
[01:25:05] <bleathem> right, and it would need to perform any navigation redirect, unless that is done by raising another event in turn
[01:25:23] <sbryzak> faces module will be responsible for the redirect
[01:25:35] <sbryzak> anyway, back in a bit
[01:25:59] <bleathem> ok, let me give it more thought
[01:26:20] <bleathem> I'll create the event in Faces, we can move it to Security later
[01:41:34] *** tsurdilo has joined #seam-dev
[01:43:44] <johnament> nickarls: you around?
[01:46:50] <johnament> bleathem: does seam faces fix the issue w/ jboss where the welcome file has to be a real file, even if you're using JSF?
[01:47:25] *** wdrai has left #seam-dev
[01:47:57] <bleathem> Oooh good one, file a jira for that please!
[01:48:13] <bleathem> (pet peeve of min for sure)
[01:48:20] <bleathem> s/min/mine/
[01:48:24] <johnament> bleathem: is that something you can fix though?
[01:48:31] <bleathem> dunno off hand
[01:48:53] <johnament> i was looking at an issue for nickarls in intl, and didn't read through his project structure correctly :/
[01:49:02] <bleathem> I'm amazed at what kind of things Faces is able to do, once you comb through the spec looking for extension points
[01:49:32] <bleathem> If you file a jira, we can explore the fesibility there.
[01:49:39] <bleathem> ^feasibility
[01:50:03] * bleathem this keyboard might was well be a type-writer for how hard I have to press
[01:50:47] <johnament> do you sometimes say your typoes as well?
[01:51:07] <bleathem> what do you mean?
[01:51:20] <johnament> a friend of mine does that.. he tried to say aristocrat, but said abercrombie
[01:51:45] <bleathem> funny
[01:51:56] <bleathem> no, I don't have that problem... yet
[01:52:08] <johnament> haha
[01:52:58] <johnament> SEAMFACES-110
[01:53:00] <jbossbot> jira [SEAMFACES-110] Support virtual files in welcome file list [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SEAMFACES-110
[01:53:13] <bleathem> thanks!
[02:08:54] *** tsurdilo has quit IRC
[02:12:46] <bleathem> stuartdouglas: you know your ViewDataStore (now called ViewConfigStore)...
[02:12:53] <stuartdouglas> yes?
[02:13:15] <bleathem> if I stuffed into the cache, a list of annotations that were qualified by another annotation, keyed by that qualified annotation
[02:13:21] <bleathem> would that break the intent of the API?
[02:13:45] <bleathem> for instance, I want to retrieve all anotations Qualified with @SecurityBindingType
[02:14:03] <bleathem> I can build that list for a view, and stuff it in the cache, keyed by SecurityBindingType
[02:14:37] * stuartdouglas looks
[02:15:02] <bleathem> it's quite possible that makes no sense by the way :P
[02:16:14] <stuartdouglas> I would say that that should be a different cache / set of methods to retrieve the data
[02:16:35] <bleathem> I was worried you would say that :P
[02:17:24] <bleathem> thanks for looking
[02:18:11] <bleathem> do you think it's worth it?  The number of annotations returned for an indivual view is going to be small
[02:18:30] <bleathem> and caching the result may be overkill to save a small number of loop iterations
[02:19:47] <stuartdouglas> the caching is to deal with assigning annotations to a given concrete view
[02:19:57] <stuartdouglas> for if you have /app/d/mypage/xhtml
[02:20:18] <stuartdouglas> you do not need to parse wildcard stuff each time
[02:20:26] <stuartdouglas> instead it is just a hash lookup
[02:22:47] <bleathem> so it's the wildcard stuff that necessitates the caching, rather than some simple performance optimisation
[02:23:07] <bleathem> I'll just loop over the returned annotations for the given view
[02:23:23] <bleathem> w/o trying to get fancy caching the result
[02:23:26] <bleathem> dinner!
[02:23:47] <stuartdouglas> getAllDataForCurrentViewId does not return all annotations for a view
[02:24:09] <stuartdouglas> it return a list of all annotations of the same type that are applied to the view and all parent views
[02:24:35] <stuartdouglas> this allows you to do things like inherit security stuff from parent views
[02:30:04] *** tsurdilo has joined #seam-dev
[02:46:29] <bleathem> stuartdouglas: I get it now, that's waht you mean by "most specific at the start of the list"
[02:46:40] <stuartdouglas> yes
[02:46:42] <bleathem> I thought you meant most specific class-heierarchy wise
[02:47:14] <bleathem> So I will need a sperate retriever to get all annotations Qualified with a specifc qualifier
[02:47:17] <bleathem> getAll won't do it
[02:47:18] <stuartdouglas> can annotations even inherit from each other?
[02:47:36] <bleathem> guess not :P
[02:47:37] * bleathem blushes
[02:47:55] *** jose_freitas has quit IRC
[02:48:07] <bleathem> wasn't thinking along those lines!
[02:48:28] <stuartdouglas> you will probably need to make some changes to support what you want to do
[02:48:35] <bleathem> it was the <T extends Annotation> that threw me in that direction though
[02:49:04] <bleathem> yep will do! thanks for the direction.
[02:50:27] *** kenfinnigan has joined #seam-dev
[02:52:52] <bleathem> ViewConfigStoreImpl is a living example demonstrating the need for the Java 7 <> (diamond) operator
[02:53:05] <stuartdouglas> yea
[02:53:15] *** Diablo-D3 has joined #seam-dev
[02:57:29] *** clerum has quit IRC
[03:03:36] *** tsurdilo has quit IRC
[03:08:35] *** kuuyee has joined #seam-dev
[03:11:49] *** kuuyee_ has joined #seam-dev
[03:12:52] *** kuuyee_ has quit IRC
[03:14:54] *** gastaldi has joined #seam-dev
[03:15:07] <gastaldi> hey all !
[03:16:51] <kuuyee> :)
[03:19:08] *** johnament has quit IRC
[03:22:11] <kenfinnigan> sbryzak: when do we need to complete fixes for the Final release?
[03:23:41] <kenfinnigan> stuartdouglas: do you know when we need to complete fixes for Final?
[03:23:57] <stuartdouglas> not sure
[03:24:27] <kenfinnigan> I think it's some time this week but not sure when
[03:27:53] <sbryzak> kenfinnigan: by friday this week would be great
[03:28:16] <kenfinnigan> so if I can finish up on the i18n module by around wed/thu that would be fine?
[03:28:31] <sbryzak> yep, perfect
[03:28:32] <kenfinnigan> would aim to complete it before then
[03:28:39] <kenfinnigan> cool
[03:28:47] <kenfinnigan> will let you know when it is ready for a final release
[03:29:25] *** kenfinnigan has left #seam-dev
[03:29:49] *** tsurdilo has joined #seam-dev
[03:31:33] <sbryzak> awesome, thanks
[03:31:36] <jbossbot> git [security] push master d3b78ac.. Shane Bryzak added authorization example to distribution
[03:31:36] <jbossbot> git [security] push master 467eda1.. Shane Bryzak add authorization example
[03:31:36] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/f0a2463...467eda1
[03:33:24] <gastaldi> Is Seam security integrated with drools ?
[03:33:43] <sbryzak> gastaldi: you can use drools with rule-based permissions, but it's an optional feature
[03:34:10] <gastaldi> Right
[03:34:43] <gastaldi> Also, I was thinking on how could I create Credentials objects for Seam JCR
[03:35:06] <gastaldi> Just browsing Seam Security searching for some tips
[03:35:13] <sbryzak> gastaldi: what's your requirements?
[03:36:42] <gastaldi> SEAMJCR-12
[03:36:47] <jbossbot> jira [SEAMJCR-12] API for injecting Credentials [Open (Unresolved) Feature Request, Major, John Ament] https://issues.jboss.org/browse/SEAMJCR-12
[03:37:23] <sbryzak> not enough information in that issue for me to understand it
[03:37:52] <gastaldi> Yeah, we are still thinking on it
[03:40:01] 
[03:40:20] <gastaldi> And maybe be addressed by seam security
[03:41:07] <sbryzak> most likely
[03:42:22] <gastaldi> Also, we are searching for a better way to inject Repository objects without attaching to the current configuration itself
[03:42:44] *** kuuyee has quit IRC
[03:43:15] <gastaldi> Nowadays, you must explicitly place configuration properties on @JcrConfiguration annotation on top of the @Injected Repository objs
[03:44:11] <gastaldi> Of course, unless creating a Qualifier for it
[03:45:02] <gastaldi> sorry, Stereotype
[03:49:07] *** kuuyee has joined #seam-dev
[03:52:08] <gastaldi>  is there a way to retrieve a @Qualifier on an InjectionPoint that stands on a @Stereotype ?
[03:52:10] <bleathem> stuartdouglas I'd like to get rid of the *ForCurrentViewId methods, and require the view id to be passed in by all consumers of the API.
[03:52:20] <stuartdouglas> ok
[03:52:27] <bleathem> did you find them useful/necessary when you put this together?
[03:53:00] <stuartdouglas> actually, I don't thing that is such a good idea
[03:53:12] <bleathem> why's that?
[03:53:16] <stuartdouglas> 99% of the time people getting the data will be getting it for the current view
[03:53:34] <stuartdouglas> so I don't think we should force them to get that themselves then pass it in
[03:53:57] <bleathem> but it won't be exposed directly to application developpers
[03:54:13] <bleathem> it will almost always be fronted by other framewrok code
[03:54:18] <stuartdouglas> but it is exposed to extension writers
[03:54:40] <bleathem> what I don't like is returning null is the currentViewId is null
[03:54:57] <bleathem> it seems like the call should never be made if the currentviewId isnull
[03:55:07] <bleathem> which pushes it back up to the extension writer
[03:55:21] <bleathem> pushes it - meaning pushes the null check responsibility
[03:55:26] <stuartdouglas> that is a good point
[03:55:37] <stuartdouglas> ok, in that case I am fine with it
[03:55:47] <bleathem> ok cool
[03:57:26] <Diablo-D3> you know
[03:57:33] <Diablo-D3> facelets + richfaces isnt all that bad
[03:57:45] <gastaldi> Have u used Primefaces ?
[03:57:51] <Diablo-D3> no
[03:58:03] <gastaldi> You should give it a try
[03:58:04] <Diablo-D3> I havent used jsp either
[03:58:18] <bleathem> Primefaces vs. richfaces, I'm not going through all that again!
[03:58:21] <gastaldi> :)
[03:58:30] <Diablo-D3> what license is primefaces under?
[03:58:52] <gastaldi> Apache v2
[03:59:04] <gastaldi> Check it out on http://www.primefaces.org/
[03:59:15] <Diablo-D3> what can it do that richfaces cant?
[03:59:29] <gastaldi> many things. Check the showcase
[03:59:31] <Diablo-D3> Im not particularly interested in stupid visual effects, btw
[03:59:39] <Diablo-D3> I can bang out all that stuff _by hand_ in javascript
[03:59:45] <gastaldi> Sure
[04:00:04] <Diablo-D3> (and I can do it easily with jquery using 2-3 lines of JS)
[04:00:07] <bleathem> have you checked out the RichFaces demo gastaldi?
[04:00:17] <bleathem> v4
[04:00:26] <gastaldi> Not yet, just v3
[04:00:26] <Diablo-D3> richfaces supplies everything I'd ever need for the ajax<->java bean side of shit
[04:00:37] <gastaldi> I like Richfaces
[04:00:38] <Diablo-D3> and its already part of the jboss family of shit
[04:00:38] <bleathem> http://richfaces-showcase.appspot.com/
[04:01:09] <Diablo-D3> btw, can anyone figure out what is providing facelets in jboss as 6?
[04:01:09] <gastaldi> v3 was too messy
[04:01:16] <bleathem> I dislike the JSF/javascript disconnect of Primefaces
[04:01:26] <Diablo-D3> because it almost looks like its using the sun impl of it
[04:01:30] <gastaldi> But I guess v4 has not all the components yet
[04:01:31] <bleathem> facelets is part of JSF now (as of v2)
[04:01:35] <Diablo-D3> morajja or whatever it is
[04:01:38] <Diablo-D3> morraja?
[04:01:43] <gastaldi> Mojarra
[04:01:47] <Diablo-D3> thats it
[04:03:03] <gastaldi> bleathem: cool
[04:03:22] <bleathem> the RF v4 demo site you mean?
[04:03:26] 
[04:03:28] <gastaldi> yes
[04:03:31] <Diablo-D3> heh
[04:03:39] <Diablo-D3> is there any frameworks that really compete with jquery?
[04:03:54] <bleathem> the nice thing about Richfaces, is the components are not *just* JSF wrappers around JQuery UI, the way Primefaces is
[04:03:55] <Diablo-D3> too many either have UI widget libraries that consume the fx part
[04:04:04] <Diablo-D3> or are not meant to be used alone, and are part of a bigger thing
[04:04:15] <bleathem> Richfaces put some real though into the component/JSF integration
[04:04:21] <gastaldi> yeah
[04:04:25] <Diablo-D3> jquery has the fx shit as part of jquery, not the ui package
[04:04:36] * Diablo-D3 just stabs the entire internet
[04:04:59] <Diablo-D3> oh, and whats with all the damned "me too" shit
[04:05:23] <Diablo-D3> google has a js framework for ONE reason
[04:05:27] <Diablo-D3> just to say they have one
[04:06:09] <gastaldi> google JS framework sucks
[04:06:15] <gastaldi> GWT sucks
[04:06:28] <Diablo-D3> yeah, I dont understand any of it
[04:06:36] <Diablo-D3> infact I used to hate javascript and refuse to use it
[04:06:47] <Diablo-D3> because I was looking at it the way all these frameworks handled it
[04:07:15] <Diablo-D3> then I discovered jquery
[04:07:21] <Diablo-D3> and you know what, js wasnt so bad after that.
[04:07:54] <Diablo-D3> jquery was written for people who already know how to program
[04:08:21] <Diablo-D3> instead of noob web devs who bang everything out in some sort of wysiwydg editor
[04:08:35] <gastaldi> just going off-topic: Anyone can recomend a good CDI reference ? A book or something ?
[04:09:31] <gastaldi> Or: Can Anyone ...
[04:09:50] <Diablo-D3> CDI is just injection stuff
[04:09:57] <gastaldi> Yes
[04:11:14] <gastaldi> Here is a good material: http://www.theserverside.com/tip/Dependency-Injection-in-Java-EE-6-Part-6
[04:11:20] <Diablo-D3> I mean, why would you need a book? :D
[04:12:04] <Royle> You
[04:12:10] <Royle> You've read the spec?
[04:12:18] <gastaldi> yes
[04:12:22] <Diablo-D3> yeah, Royle is right, the spec is enough
[04:12:35] <Diablo-D3> you could even bang out your own microcontainer that just injects using the spec
[04:12:38] <gastaldi> Not in its entirely, but yes
[04:13:08] <Diablo-D3> basically, the container has a pile of (sometimes scoped) objects of certain clases
[04:13:27] <Diablo-D3> it scans your bean for injection points, and matches the points with objects, and plugs them in
[04:13:49] 
[04:14:12] <gastaldi> I think that my problem is a bit specific
[04:14:37] <gastaldi> Like: I have a @Producer method that has an InjectionPoint
[04:14:52] <gastaldi> Now I want to get the Qualifiers on that InjectionPoint
[04:15:11] <gastaldi> That resides on the Stereotypes placed on that InjectionPoint
[04:15:12] <gastaldi> :)
[04:15:23] <gastaldi> One stereotype, sorry
[04:18:47] <gastaldi> Tough uh  ? :)
[04:27:45] <Royle> Yikes. can't work that one out from the spec
[04:28:06] <Royle> (I can't anyway)
[04:28:54] <gastaldi> :)
[04:28:59] <Diablo-D3> gastaldi: I dont think you can do that with CDI alone
[04:29:08] <gastaldi> :P
[04:29:47] <gastaldi> My idea is to decouple Seam JCR configuration from code
[04:30:02] <Diablo-D3> might have to look at extensions provided by weld or solder
[04:30:36] 
[04:34:15] <Royle> mayb esection 11.3.13? "A portable extension may test an annotation to determine if it is a qualifier type, scope type, stereotype or interceptor bind- ing type, obtain the set of meta-annotations declared by a stereotype or ..."
[04:34:17] <Royle> would that help
[04:34:18] <Royle> ?
[04:34:54] <Royle> If you go InjectionPoint.getBean().getStereotypes() first?
[04:35:04] <gastaldi> hummm
[04:35:12] <Diablo-D3> btw, unrelated, I just found the funniest thing you can do in XML
[04:35:22] <Diablo-D3> <tag lots of attributes />
[04:35:26] <Diablo-D3> thats the whole xml file
[04:36:04] <Diablo-D3> its so hilarious, eclipse thinks its an error
[04:36:27] <gastaldi> strange thing is that getBean() returns null
[04:36:54] <Diablo-D3> oh wait sorry, eclipse doesnt think its an error
[04:36:56] <Royle> then call beanManager.getStereotypeDefinition(stereotype)
[04:37:28] <gastaldi> humm, let me try that
[04:39:02] <gastaldi> That way I must have the stereotype known
[04:39:28] <gastaldi> The idea is to place the annotation configuration under a stereotype
[04:39:35] <Royle> which you can get from the injectionPoint (according to the spec)
[04:39:38] <Diablo-D3> woah this is interesting
[04:39:45] <Diablo-D3> facelets can be named *.faces
[04:39:51] <Diablo-D3> but eclipse doesnt recognize this extension
[04:40:42] 
[04:41:04] <Royle> no probs mate, I'm as curious as you are :)
[04:41:17] <Royle> just hope I'm not leading you astray
[04:41:46] <gastaldi> not at all
[04:41:56] <Royle> we'll see ;)
[04:42:15] <gastaldi> gotta sleep
[04:42:23] <gastaldi> Bye everyone and Thanks again
[04:42:31] <Royle> cya
[04:42:38] *** gastaldi has quit IRC
[05:00:44] *** rruss has joined #seam-dev
[05:04:57] <jbossbot> git [validation] push master 6898be1.. Shane Bryzak use combined jar
[05:04:58] <jbossbot> git [validation] push master URL: http://github.com/seam/validation/compare/e79214d...6898be1
[05:06:44] <jbossbot> git [rest] push master 6524c20.. Shane Bryzak use combined jar
[05:06:44] <jbossbot> git [rest] push master URL: http://github.com/seam/rest/compare/33d5d33...6524c20
[05:19:00] <bleathem> if I call getAnnotations() on a qualifier, it's going to return all of the @Retention and @Target annotations isn't it?!
[05:19:26] <stuartdouglas> yes
[05:19:27] <jbossbot> git [dist] push master f3e7733.. Shane Bryzak fix example dependencies, fix distribution
[05:19:27] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/d407ab7...f3e7733
[05:19:41] <stuartdouglas> why are you calling getAnnotations on a qualifier?
[05:20:26] <bleathem> end goal, I want to know which annotations are qualified with @SecurityBindingType
[05:20:51] <bleathem> so I know which are the Seam Security annotations associated with the ViewPattern
[05:21:06] <stuartdouglas> ok, why not just getAnnotation or isAnnotationPresent ?
[05:21:31] <bleathem> I started building up a generic dataStore, to support any such qualifier
[05:21:54] <bleathem> I'm now thinking to suppport specifically the Seam Security one, and generalise it later if required
[05:22:23] <bleathem> Or maybe I can have a static list of supported Qualifers
[05:22:41] <bleathem> in which case, yes I'll just use isAnnotationPresent()
[05:23:40] <stuartdouglas> you could just filter all java.* annotations and still use getAnnotations()
[05:24:11] <bleathem> yeah, that'd work!
[05:34:31] <jbossbot> git [examples] push master 9c27f12.. Shane Bryzak cleanup
[05:34:31] <jbossbot> git [examples] push master e79f3a1.. Shane Bryzak removed seamspace example
[05:34:32] <jbossbot> git [examples] push master 88cf874.. Shane Bryzak Merge branch 'master' of github.com:seam/examples
[05:34:32] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/263b717...88cf874
[05:35:41] <bleathem> I'm having one of those "this'll never work" moments :D
[05:40:41] <jbossbot> git [examples] push master 237c6fa.. Shane Bryzak update seam-bom, add booking to modules list, add new gwt example
[05:40:41] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/88cf874...237c6fa
[05:46:20] <jbossbot> git [examples] push master 9fec440.. Shane Bryzak ws
[05:46:21] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/237c6fa...9fec440
[05:49:04] <jbossbot> git [examples] push master f666e16.. Shane Bryzak updated dependency versions
[05:49:05] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/9fec440...f666e16
[05:49:19] <bleathem> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Identity] with qualifiers [@Default]
[05:49:20] <bleathem> at injection point [[field] @Inject org.jboss.seam.security.SecurityEventMessages.identity]
[05:50:09] <bleathem> sbryzak I got this ^^ when I added Seam security to my sample app
[05:50:33] <bleathem> hmm, maybe I should read the docs first
[05:50:54] <sbryzak> interesting...
[05:51:06] <sbryzak> i'm guessing you're just adding the api, and not the impl
[05:51:15] <bleathem> added the api and the impl
[05:51:18] <sbryzak> should always use the combined jar dependency
[05:51:32] <bleathem> ok, I'll try that
[05:52:13] <bleathem> the faces combined jar was broken for a while, so I got used to using separate dependencies
[05:54:15] <bleathem> why does Secuirty pull Persistence into my war?
[05:54:51] <bleathem> now I'm getting:
[05:54:59] <sbryzak> it's required for the management beans
[05:55:13] <bleathem> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Synchronizations] with qualifiers [@Default] at injection point [[field] @Inject private org.jboss.seam.persistence.transaction.DefaultSeamTransaction.synchronizations]
[05:55:35] <bleathem> on glassfish 3.1 btw
[05:55:35] <sbryzak> hmm, that's the wrong package
[05:55:48] <bleathem> it pulled in Persitence CR1
[05:55:58] <sbryzak> security did?
[05:55:59] <bleathem> if that makes a difference
[05:56:02] <bleathem> yep
[05:56:07] <sbryzak> it should be using CR4
[05:56:07] <bleathem> Security CR2
[05:56:13] <sbryzak> use CR3
[05:56:15] <sbryzak> CR2 is broken
[05:56:23] <bleathem> ok :)
[05:56:36] <sbryzak> if you use seam-bom 3.0.0.CR9 it will give you all the right versions
[05:56:38] <bleathem> I thought we were all on the same CR number
[05:57:00] <sbryzak> we're not ;)
[05:57:09] <bleathem> apparently!
[05:57:49] <sbryzak> maven is pissing me off big time
[05:58:02] <sbryzak> it's still running tests for a release build, when i'm telling it to skip them
[05:58:27] <bleathem> I have the feeling maven's days with Seam are numbered...
[05:58:41] <bleathem> you guys should hire a gradle expert!
[05:59:07] <bleathem> oh wait, you did!
[05:59:10] <sbryzak> i'm losing my patience with it, that much is true
[05:59:26] <sbryzak> yeah jason is hopefully going to help out in that department
[05:59:51] <bleathem> There was a post to Seam dev today, listing all the modern stuff that Seam uses, citing it as a detriment to adoption
[06:00:16] <bleathem> it made me realise how much of a "sweet spot" Seam 3 is in, using all the latest/sexiest tooling
[06:00:27] <sbryzak> Denis' post?
[06:00:29] <bleathem> which I think will attract a lot of developers
[06:00:32] <bleathem> yeah, that one
[06:00:56] <bleathem> maven fits in that role.  Lots of devs are familiar with it right now
[06:01:18] <bleathem> happy to hack on a project that uses it, cause it fits with everything else they are doing.
[06:01:39] <bleathem> But I guess Denis' point was that at one time SVN, Ant etc. were in a similar sweet  spot
[06:02:52] <sbryzak> i need to respond to that post when i have time
[06:03:17] <bleathem> it's a good one, I agree with his arguments about making sure Seam 3 is sufficiently polished
[06:04:23] <bleathem> Seam 3 has to shake the "1.0 - don't use it!" reputation it's going to inherit from Weld's 1.0 release problems
[06:04:42] <sbryzak> stupid maven release plugin.. it's running the tests when i don't want it to
[06:05:02] <sbryzak> all initial releases have that reputation
[06:05:14] <sbryzak> we have to go through that growing pain unfortunately
[06:09:14] <bleathem> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Synchronizations] with qualifiers [@Default]
[06:09:16] <bleathem> at injection point [[field] @Inject private org.jboss.seam.transaction.DefaultSeamTransaction.synchronizations]
[06:09:27] <bleathem> This is killing me!
[06:09:46] <stuartdouglas> bleathem: Is this on GF?
[06:09:54] <bleathem> yep
[06:10:04] <bleathem> latest weld snapshot
[06:10:12] <bleathem> well latest as of this morning
[06:11:07] <bleathem> I can go back to eclipse/AS 6, I don't need to set breakpoints anymore
[06:11:15] <bleathem> if you think that'll make a difference
[06:11:54] <jbossbot> git [examples] push master 53adf4d.. Shane Bryzak skip tests for release build
[06:11:54] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/f666e16...53adf4d
[06:12:15] <bleathem> oh wait, scrolling way up I see:
[06:12:17] <bleathem> WARNING: Could not instantiate service class org.jboss.seam.transaction.TransactionExtension
[06:12:19] <bleathem> java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
[06:12:30] *** rruss has quit IRC
[06:12:58] <bleathem> Why would I need slf4j for Seam Persistence?
[06:13:45] <stuartdouglas> It has probably not been moved over to jboss logging yet, and hibernate has a dependency on it
[06:13:54] <jbossbot> git [examples] push master 0dcab1a.. Shane Bryzak [maven-release-plugin] prepare release 3.0.0.CR1
[06:13:54] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/53adf4d...0dcab1a
[06:14:01] <jbossbot> git [examples] push master 6ff8ac1.. Shane Bryzak [maven-release-plugin] prepare for next development iteration
[06:14:01] <jbossbot> git [examples] push master URL: http://github.com/seam/examples/compare/0dcab1a...6ff8ac1
[06:14:11] <stuartdouglas> although seam persistence should work without hibernate, so that will not be an issue
[06:17:49] <bleathem> org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Identity] with qualifiers [@Default]
[06:17:50] <bleathem> at injection point [[field] @Inject org.jboss.seam.security.SecurityEventMessages.identity]
[06:18:15] <bleathem> I made a round trip - back at the first deployment exception again!
[06:18:32] <bleathem> I'll try AS 6.
[06:18:59] <sbryzak> is the IdentityImpl class in the classpath?
[06:20:31] <jbossbot> git [dist] push master 3aa651c.. Shane Bryzak update booking example version
[06:20:31] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/f3e7733...3aa651c
[06:20:33] <bleathem> Yep, they are in the seam-security-3.0.0.CR3.jar, in the WEB-INF/lib folder
[06:20:57] <bleathem> s/they are/it is/
[06:22:57] <bleathem> Works fine on AS 6
[06:23:07] <bleathem> I guess the GF 3.1 troubles aren't over yet :P
[06:30:52] <jbossbot> git [dist] push master bb8b413.. Shane Bryzak update readme
[06:30:52] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/3aa651c...bb8b413
[06:38:59] <Diablo-D3> http://ocpsoft.com/prettyfaces/
[06:39:00] <Diablo-D3> yeargh!
[06:40:13] <bleathem> sbryzak: Seam Security integration starting:
[06:40:18] <bleathem> org.jboss.seam.security.SecurityDefinitionException: No matching authorizer found for security binding type [ at org dot jboss.seam.faces.security.Restrict] on method [ca.triumf.mis.jsf.Pages.INDEX]
[06:41:13] <bleathem> I tried just adding a @SecurityBindingType qualifier to an annotation, to see if I could pull @ViewConfig annotations that used that qualifier
[06:41:28] <bleathem> but I guess I need to do more than just add that annotation.
[06:41:44] <bleathem> I'll look at the Security sample you gave me the other day
[06:41:55] <sbryzak> you'll need an authorizer method also
[06:42:12] <sbryzak> it can be any bean method
[06:42:26] <sbryzak> in your case it will need to be annotated with @Secures @Restrict
[06:43:50] <Diablo-D3> actually
[06:43:52] <Diablo-D3> this things right
[06:43:58] <Diablo-D3> why istn there already a jboss solution for this?
[06:44:45] <Diablo-D3> ...
[06:45:16] <Diablo-D3> this software is written by lincoln baxter
[06:45:20] <Diablo-D3> he works for jboss
[06:45:23] * Diablo-D3 facepalms
[06:45:43] <bleathem> It's on the roadmap to integrate Prettyfaces with Seam Faces
[06:45:58] <Diablo-D3> screw that
[06:46:04] <Diablo-D3> why isnt it intergrated with richfaces :D
[06:46:43] <bleathem> Richfaces is for components, SeamFaces is for the framework bits.  It's a pretty clean split actually
[06:47:02] <Diablo-D3> yeah, but prettyfaces is not framework or component
[06:47:17] <Diablo-D3> well, its not cleanly either, its a filter
[06:47:49] <Diablo-D3> so
[06:47:50] * Diablo-D3 shrugs
[06:47:57] <Diablo-D3> Im adding it to my toolkit of nifty toys
[06:53:35] <bleathem> sbryzak ok, that worked.  thanks
[06:56:34] <bleathem> oh, and it works now in Glassfish 3.1 - don't ask me which change enbaled that!
[06:59:18] <bleathem> Well, at least I can go to bed knowing my Qualilfier parsing didn't work :(
[06:59:24] *** kpiwko has joined #seam-dev
[06:59:53] <bleathem> It's gotta be something minor, I'm sure I'll find it tomorrow!
[06:59:59] * bleathem keeping a postive attitude so I will actually sleep
[07:00:57] *** bleathem has quit IRC
[07:10:53] *** kuuyee has quit IRC
[07:14:33] <jbossbot> git [dist] push master 84d528a.. Shane Bryzak SEAM-29
[07:14:35] <jbossbot> jira [SEAM-29] seam3 generated API docs in doc/api references j2se/1.5.0 classes instead of javaee/6 classes [Open (Unresolved) Bug, Major, Shane Bryzak] https://issues.jboss.org/browse/SEAM-29
[07:14:35] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/bb8b413...84d528a
[07:25:26] *** daniel_hinojosa has quit IRC
[08:06:38] <sbryzak> Seam 3.0 CR3 is out, finally
[08:08:55] <nickarls> \o/
[08:09:33] <nickarls> you sure have been releasing a lot these past few days
[08:09:46] <nickarls> apparently it's not just bumping a property and doing mvn release ;-)
[08:10:11] <sbryzak> i wish it were
[08:10:36] <sbryzak> the actual process involves a lot of lack of sleep
[08:11:04] <nickarls> gradle-advocates whispering in your ears already?
[08:11:29] <sbryzak> have been for some time
[08:11:38] <sbryzak> i'm sure it will happen eventually ;)
[08:12:18] <sbryzak> right, i'm getting away from this computer for the rest of the evening
[08:12:20] <nickarls> it appears that at some point the svn-mvn curve tips to git-gradle when the project expands...
[08:12:54] <nickarls> do that, you can sort of the damage of the release tomorrow ;-)
[08:19:00] <Diablo-D3> hrm
[08:19:04] <Diablo-D3> you know whats funny?
[08:19:13] <Diablo-D3> this dude goes out of his way to provide a maven repo
[08:19:21] <Diablo-D3> but then doesnt provide the xml for the lazy people among us
[08:19:34] <nickarls> ?
[08:20:01] <Diablo-D3> http://ocpsoft.com/prettyfaces/
[08:27:35] *** kuuyee has joined #seam-dev
[08:28:44] *** PeteRoyle has joined #seam-dev
[08:31:23] *** Royle has quit IRC
[08:48:33] *** maschmid has joined #seam-dev
[08:55:27] *** marekn has joined #seam-dev
[08:59:23] *** shervin_a has joined #seam-dev
[09:09:40] *** oskutka has joined #seam-dev
[09:13:50] *** PeteRoyle has joined #seam-dev
[09:21:21] *** alesj has joined #seam-dev
[09:31:15] *** Royle has joined #seam-dev
[09:33:44] *** aslak has joined #seam-dev
[09:34:16] *** PeteRoyle has quit IRC
[09:51:38] *** sannegrinovero has quit IRC
[10:28:45] *** echelog-2 has joined #seam-dev
[10:53:08] *** Royle has quit IRC
[10:57:03] *** sannegrinovero has joined #seam-dev
[10:58:16] *** kpiwko is now known as kpiwko_afk
[11:06:26] *** kuuyee has quit IRC
[11:17:05] *** wdrai has joined #seam-dev
[11:24:14] *** alesj has quit IRC
[11:31:24] *** pmuir has joined #seam-dev
[11:34:48] <nickarls> oskutka: "<sbryzak> right, i'm getting away from this computer for the rest of the evening"
[11:43:54] *** kpiwko_afk is now known as kpiwko
[11:50:37] <oranheim_> upgraded to seam-bom:CR9 and upon deployment seam-conversation-spi-3.0.0.CR1.jar fails due to error with wrong namespace in beans.xml:19.. any idea?
[11:58:10] <oskutka> nickarls: Thanks.
[12:02:07] *** alesj has joined #seam-dev
[12:07:23] *** wdrai has quit IRC
[12:10:35] *** PeteRoyle has joined #seam-dev
[12:12:24] *** jose_freitas has joined #seam-dev
[12:13:17] *** PeteRoyle has quit IRC
[12:18:18] *** wdrai has joined #seam-dev
[12:28:53] *** PeteRoyle has joined #seam-dev
[12:32:38] *** tsurdilo has joined #seam-dev
[12:49:14] <sbryzak> oranheim_: could you please raise a jira issue with steps to reproduce?
[12:49:36] <oranheim_> will do
[12:50:08] <sbryzak> in http://issues.jboss.org/browse/SEAM
[12:54:13] *** PeteRoyle has quit IRC
[13:02:43] <jose_freitas> sbryzak
[13:02:45] <jose_freitas> ping
[13:02:49] <sbryzak> pong
[13:02:54] <jose_freitas> morning
[13:03:04] <sbryzak> morning
[13:03:54] <jose_freitas> I was working yesterday with the booking example and implemented the authentication with seam security
[13:04:08] <sbryzak> jose_freitas: cool
[13:04:10] <jose_freitas> but my question is about the conversation timeout
[13:04:35] <jose_freitas> is there a place (web.xml for instance) where I can define the timeout for all conversations?
[13:04:43] <jose_freitas> or do I have to set it on the bean?
[13:05:00] <sbryzak> um, you can provide cdi with a 'suggested' timeout
[13:05:53] <sbryzak> use conversation.setTimeout()
[13:07:18] <jose_freitas> but this refers to the conversation for that bean, right?
[13:08:01] <sbryzak> it's for that conversation scope
[13:08:25] <jose_freitas> hm... so if I set in the application Initializer every conversation will use that
[13:08:52] <sbryzak> you need to call it when you start the conversation
[13:09:05] <jose_freitas> hm, ok
[13:09:21] <jose_freitas> that seemed a little weird
[13:09:25] <jose_freitas> but it's ok then
[13:10:03] <jose_freitas> one thing that I noticed is that by default it uses a fraction of session timeout, right?
[13:10:31] 
[13:10:46] <sbryzak> i don't think the spec says
[13:11:06] <sbryzak> weld might use a fraction of the session timeout, but other implementations might be different
[13:11:12] <sbryzak> pmuir: could you please clarify?
[13:11:16] *** daniel_hinojosa has joined #seam-dev
[13:12:32] <pmuir> jose_freitas: the spec doesn't provide a way to set a default conversation timeout
[13:12:35] <pmuir> but weld does
[13:12:38] <pmuir> you can do
[13:12:45] <pmuir> @Inject ConversationContext ctx;
[13:12:51] *** PeteRoyle has joined #seam-dev
[13:13:16] <jose_freitas> hm
[13:14:34] 
[13:14:56] <pmuir> one min
[13:14:59] <sbryzak> just set it wherever you want to extend the conversation timeout
[13:15:08] <jose_freitas> ok
[13:15:08] <sbryzak> it should just be in one place, in the hotel booking action
[13:15:12] <jose_freitas> yes
[13:16:52] <pmuir> ctx.setDefaultTimeout()
[13:17:04] <pmuir> and no, it's nothing to do with session timeout
[13:17:31] <pmuir> by default in Weld it's 10 mins
[13:17:36] <pmuir> 10 * 60 * 1000 ms
[13:18:28] <oranheim_> sbryzak: https://issues.jboss.org/browse/SEAM-44
[13:18:36] <jbossbot> jira [SEAM-44] Seam Conversation SPI fails due to wrong namespace in XML config [Open (Unresolved) Bug, Blocker, Unassigned] https://issues.jboss.org/browse/SEAM-44
[13:19:00] <sbryzak> oranheim_: thank you :)
[13:19:30] <alesj> sbryzak: ups :-)
[13:19:42] <sbryzak> alesj: should i assign to you? :)
[13:20:03] <alesj> already done ;-)
[13:20:16] <sbryzak> cool, thanks
[13:20:44] <alesj> dunno why it didn't fail for me ...
[13:21:16] <sbryzak> didn't fail for me either
[13:22:49] <oranheim_> please see my updated lib deps comment, would that have something to do with it? (SEAM-44)
[13:22:50] <jbossbot> jira [SEAM-44] Seam Conversation SPI fails due to wrong namespace in XML config [Open (Unresolved) Bug, Blocker, Ales Justin] https://issues.jboss.org/browse/SEAM-44
[13:24:53] <alesj> sbryzak, oranheim_ : strange, i think i already have this namespaces set
[13:25:46] <oranheim_> the META-INF/beans.xml defines      <beans />     that's it
[13:25:56] <alesj> ah, yes
[13:26:00] <alesj> the old one
[13:26:18] <alesj> https://github.com/alesj/conversation/blob/master/spi/src/main/resources/META-INF/beans.xml
[13:26:21] <alesj> i have this one now
[13:26:30] <alesj> sbryzak: can you pull this one in, somehow
[13:26:34] <alesj> do some git magic :-)
[13:26:47] <sbryzak> my git fu is weak
[13:27:07] <sbryzak> so i'll use the ancient but reliable copy-paste
[13:27:22] <oranheim_> :)
[13:27:39] <alesj> perhaps cherry-pick these comments?
[13:27:39] <alesj> https://github.com/alesj/conversation/commits/master
[13:27:51] <alesj> "exclude api, proper reg exp"
[13:27:53] <alesj> :-)
[13:28:03] <oranheim_> what's the rasoning bgeind the scan exclude for api?
[13:28:23] <alesj> just limiting what we should scan
[13:28:33] <alesj> not really neccessary
[13:28:40] <alesj> but it won't hurt to exclude
[13:28:45] <sbryzak> already took that file
[13:28:48] <jbossbot> git [conversation] push master d88b9a6.. Shane Bryzak SEAM-44
[13:28:49] <jbossbot> jira [SEAM-44] Seam Conversation SPI fails due to wrong namespace in XML config [Open (Unresolved) Bug, Blocker, Ales Justin] https://issues.jboss.org/browse/SEAM-44
[13:28:49] <jbossbot> git [conversation] push master URL: http://github.com/seam/conversation/compare/a775eb0...d88b9a6
[13:28:57] <oranheim_> thx
[13:32:01] <oranheim_> nice response time! i must say :) thanks again
[13:35:33] *** PeteRoyle has quit IRC
[14:56:43] *** echelog-2 has joined #seam-dev
[15:16:19] <Diablo-D3> http://ocpsoft.com/prettytime/
[15:16:21] <Diablo-D3> ding!
[15:19:59] *** shervin_a has quit IRC
[15:20:22] *** tsurdilo has quit IRC
[15:21:25] *** tsurdilo has joined #seam-dev
[15:22:56] *** tsurdilo1 has joined #seam-dev
[15:25:53] *** tsurdilo has quit IRC
[15:28:44] *** tsurdilo1 has quit IRC
[15:29:11] *** tsurdilo has joined #seam-dev
[15:38:28] <jbossbot> git [security] push master a8beaba.. Shane Bryzak removed unwanted bin directories
[15:38:28] <jbossbot> git [security] push master URL: http://github.com/seam/security/compare/467eda1...a8beaba
[15:45:33] *** marekn has quit IRC
[15:46:58] *** bleathem has joined #seam-dev
[15:47:50] <jbossbot> git [rest] push master 749c481.. Shane Bryzak SEAM-30
[15:47:51] <jbossbot> jira [SEAM-30] Seam release should not depend on any SNAPSHOT artifacts [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAM-30
[15:47:52] <jbossbot> git [rest] push master URL: http://github.com/seam/rest/compare/6524c20...749c481
[15:48:43] <jbossbot> git [solder] push master 18c3775.. Shane Bryzak SEAM-30
[15:48:44] <jbossbot> jira [SEAM-30] Seam release should not depend on any SNAPSHOT artifacts [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAM-30
[15:48:44] <jbossbot> git [solder] push master URL: http://github.com/seam/solder/compare/5a5f6c4...18c3775
[15:53:43] *** lightguard_jp has quit IRC
[16:06:09] *** cbrock has joined #seam-dev
[16:07:11] *** aslak has quit IRC
[16:07:37] *** aslak has joined #seam-dev
[16:17:06] *** tsurdilo1 has joined #seam-dev
[16:20:17] *** tsurdilo has quit IRC
[16:28:58] *** lightguard_jp has joined #seam-dev
[16:38:12] <lightguard_jp> Good day everyone
[16:38:32] <nickarls> jp: g'day
[16:39:02] <nickarls> jp: when was/is the D-day?
[16:39:28] <lightguard_jp> nickarls: To which day are you referring?
[16:39:58] <nickarls> you expected #4 around these times?
[16:40:24] <lightguard_jp> Ah, due date is April 30th
[16:40:38] <lightguard_jp> Was thinking about the day I start at Red Hat
[16:40:41] <nickarls> in that case, no news is good news ;-)
[16:42:00] <nickarls> few 9-month projects with that complex release artifact finish max 2 weeks over
[16:42:35] <nickarls> (or how much do they let it go overdue over there?)
[16:42:36] <lightguard_jp> My wife always goes early.
[16:42:54] <lightguard_jp> All of the previous three have been early.
[16:43:03] <lightguard_jp> The last one was three weeks early I think
[16:43:18] <lightguard_jp> Typically though they only let you go a week, maybe two over
[16:43:41] *** tsurdilo1 has quit IRC
[16:44:04] <nickarls> yeah, they might as well grow in size on the outside after that point.
[16:44:46] <lightguard_jp> As long as they're healthy and can survive on their own I don't care :)
[16:47:01] <jose_freitas> good day lightguard_jp
[16:47:43] <nickarls> what is the reasoning behind the fact that Seam 3 CR3 uses seam-bom CR9? Considering most of CRn have appeared recently?
[16:48:26] <sbryzak> nickarls: please don't ask
[16:48:33] <jose_freitas> hehehe
[16:48:36] <jose_freitas> I'm curious about that too
[16:48:54] <sbryzak> i'm trying to forget about it and you guys are bringing it up
[16:49:10] <lightguard_jp> Haha
[16:49:22] <lightguard_jp> As I recall, it was a walk through Maven Hell.
[16:51:57] *** cbrock has quit IRC
[16:52:12] *** rruss has quit IRC
[16:52:12] <nickarls> "Seam 3 is final! Please upgrade to 3.0.0.Final15!"
[16:52:41] <sbryzak> nickarls: the stars will align for the final, don't you worry
[16:54:07] <jose_freitas> sbryzak: are you planning the final for next weekend?
[16:54:15] <sbryzak> yes
[16:54:39] <jose_freitas> I have to rush things :)
[16:57:10] <bleathem> nickarls how's your baby? fever went away?
[16:58:28] <nickarls> bleathem: a little better, thanks. Now's just a cough and green stuff running from the nose
[16:59:04] <bleathem> at least the fever is gone.  It's never fun when the little ones get sick!
[16:59:08] <lightguard_jp> nickarls: Cold?
[16:59:59] <nickarls> her brother had a 5-day fever on-and-off last week, probably a sling of that.
[17:01:18] <lightguard_jp> No fun.
[17:01:27] <lightguard_jp> We had some of that going around our house a while ago too.
[17:01:44] <nickarls> fever for older kids are not that bad - they just lie around and do less damage ;-)
[17:03:12] <nickarls> Seam is a mature project, devs are talking deliveries and kids sickness instead of how much they drank last night...
[17:03:14] <mojavelinux> hahaha
[17:03:43] <alesj> and you call yourself devs ? cccc ...
[17:03:45] <alesj> :-)
[17:04:05] <mojavelinux> looking through the backlog, it seems that no all devs are aware of the fact that solder has utilities for checking for annotations on a stereotype
[17:04:20] <mojavelinux> or I should say, if you ask a class if it has an annotation, the steroetypes are checked
[17:05:06] <mojavelinux> that's more on us for not documenting it well...sounds to me like a jira
[17:05:13] <mojavelinux> I'll link to the utility
[17:05:54] <mojavelinux> http://docs.jboss.org/seam/3/solder/latest/api/org/jboss/seam/solder/reflection/AnnotationInspector.html
[17:05:56] <mojavelinux> super helpful
[17:06:04] <mojavelinux> extensions should be using that instead of doing their own annotation walking
[17:06:57] <mojavelinux> there are a few methods on Reflections that need to probably be relocated to the inspector for consistency
[17:08:09] <lightguard_jp> Solder needs a run through of all it's features and the current docs
[17:08:17] <lightguard_jp> IIRC, they're in pretty poor shape.
[17:10:44] <mojavelinux> SOLDER-89
[17:10:53] <jbossbot> jira [SOLDER-89] Document utilities provided by AnnotationInspector [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SOLDER-89
[17:11:13] <mojavelinux> this one in particular is important because if a lot of code is written that read annotations inconsistently, then it becomes confusing for the developer
[17:11:28] <lightguard_jp> Very true
[17:11:28] <mojavelinux> imho, these utility methods may be candidates for the CDI API, but that's another story
[17:11:35] <lightguard_jp> haha
[17:12:46] <mojavelinux> there is one paragraph of documentation for AnnotationInspector, but it covers one method
[17:12:49] <mojavelinux> it's not enough
[17:13:05] <jose_freitas> yes, it definitelly needs more info
[17:13:14] <mojavelinux> the reflection utilities documetation is only an introduction
[17:13:30] *** kpiwko has quit IRC
[17:13:31] <mojavelinux> we should even cite examples from Seam 3 modules...for context
[17:14:44] <lightguard_jp> Yep, the Solder docs are really lacking
[17:15:50] <bleathem> mojavelinux: AnnotationInspector looks useful - I can use that right now
[17:16:21] <lightguard_jp> Exactly the point. People don't know about it
[17:16:24] <lightguard_jp> Or all the features
[17:16:31] <lightguard_jp> So we re-invent the wheel all the time.
[17:18:00] <mojavelinux> yep...part of what shane, jason and I do is keep an eye on when duplicate work is being done, in the auxiliary sense
[17:18:12] <mojavelinux> however, everyone should be looking at solder first
[17:18:16] *** tsurdilo has joined #seam-dev
[17:18:20] <mojavelinux> if you need some utility
[17:18:35] <mojavelinux> of course, we'll document better so that task isn't so much like fishing
[17:28:31] *** lincolnthree1 has joined #seam-dev
[17:30:44] <pmuir> the javadoc for solder is (well was last I looked) quite complete
[17:43:08] *** oskutka has quit IRC
[17:50:10] *** gastaldi has joined #seam-dev
[17:50:21] <gastaldi> hello everyone !
[17:50:55] <gastaldi> *breeedet*
[17:51:26] *** pmuir has quit IRC
[17:51:29] * bleathem *crickets*
[17:51:52] <gastaldi> *chirp*
[17:52:21] <lightguard_jp> :)
[17:52:45] <bleathem> now that's community building!
[17:53:10] <lincolnthree1> *ribbit*
[17:53:46] <jose_freitas> hello
[17:54:21] <bleathem> jose_freitas you could have at least gone with: *hello* !!
[17:55:42] * lightguard_jp waves
[17:57:57] <jbossbot> git [forge] push master 035130b.. Lincoln Baxter, III removed unnecessary project.registerFacet() calls in install() method isntances
[17:57:57] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/d6ed7d9...035130b
[17:58:05] <nickarls> *banjos plaing*     *locals staring*
[17:58:15] * mojavelinux cartwheels
[17:58:15] <nickarls> s/i/y
[17:58:18] <mojavelinux> top that one
[17:58:18] <jose_freitas> *hello*
[17:58:20] <jose_freitas> lol
[17:58:32] * lincolnthree1 does the worm
[17:58:33] <jose_freitas> gotta start a seam training in two minutes
[17:58:35] <jose_freitas> byw
[17:58:37] <jose_freitas> bye
[17:58:40] <mojavelinux> good luck
[17:58:41] <lincolnthree1> nice! have fun jose_freitas
[17:58:53] <lincolnthree1> show em how it's done
[17:59:03] <bleathem> knock 'em dead!
[18:03:07] *** maschmid has quit IRC
[18:05:12] <gastaldi> hehe
[18:08:24] <jbossbot> git [forge] push master a1ca374.. Lincoln Baxter, III removed spurious dependencies from dist pom
[18:08:24] <jbossbot> git [forge] push master URL: http://github.com/seam/forge/compare/035130b...a1ca374
[18:14:12] *** alesj has left #seam-dev
[18:14:14] *** alesj has quit IRC
[18:16:26] *** cbrock has joined #seam-dev
[18:17:01] *** Diablo-D3 has quit IRC
[18:22:10] *** lightguard_jp is now known as lightguard_jp_aw
[18:22:51] <clerum> mojavelinux: think you will have any time this week to take a peak at seam mail and why render isn't testing with arquillian?
[18:23:03] <mojavelinux> sure thing
[18:25:31] <clerum> cool. I tried upgrading to Alpha5 but things didn't seem to want to play nice
[18:25:53] <clerum> unfortuatntly I don't have the time to troubleshoot it
[18:25:57] <mojavelinux> k, I noted it down on my list :)
[18:26:00] <mojavelinux> no problem
[18:26:05] <clerum> thanks
[18:26:19] <clerum> I think it's time to start writing the docs and release
[18:26:37] <clerum> so if you want to give one more look at the new consolidated api as well and give some critisims that would be cool
[18:27:58] *** lincolnthree1 has quit IRC
[18:28:16] *** lincolnthree1 has joined #seam-dev
[18:30:26] <mojavelinux> yep, i've had that on my list too...got busy last week working on the gf issues
[18:30:51] <mojavelinux> this week looks better
[18:33:16] <clerum> k
[18:33:44] <lincolnthree1> hows that going btw mojavelinux ?
[18:35:46] <mojavelinux> pretty much there at this point
[18:36:13] <mojavelinux> although some issues may come up, devs are hopefully aware of how to get out of the problem
[18:36:21] *** gastaldi has quit IRC
[18:36:35] <mojavelinux> there is one compat test still failing, and I'd like to know if that's supposed to pass or whether that's still a bug in weld/glassfish
[18:37:13] *** lightguard_jp_aw is now known as lightguard_jp
[18:38:01] <lincolnthree1> if it is a bug, is there a workaround?
[18:43:57] <mojavelinux> no
[18:44:03] <mojavelinux> not for this one
[18:44:06] <mojavelinux> this one is pure suck
[18:46:38] <jbossbot> git [mail] push master 794492d.. Cody Lerum don't need logger def for velocity
[18:46:38] <jbossbot> git [mail] push master URL: http://github.com/seam/mail/compare/8cdf307...794492d
[18:49:12] *** wdrai1 has joined #seam-dev
[18:49:41] *** wdrai has quit IRC
[18:59:04] *** gastaldi has joined #seam-dev
[19:03:13] *** wdrai1 has left #seam-dev
[19:47:25] *** alesj has joined #seam-dev
[20:03:07] *** bitshuffler has joined #seam-dev
[20:03:54] *** gastaldi has left #seam-dev
[20:07:48] <mojavelinux> snapshots of the Weld OSGi bundle are now available in the jboss snapshots repository
[20:07:49] <mojavelinux> https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/weld/weld-osgi-bundle/1.1.0-SNAPSHOT/
[20:08:07] <mojavelinux> just drop that jar into the glassfish/modules/ directory (minus the version number) to upgrade Weld
[20:17:23] *** marekn has joined #seam-dev
[20:17:36] *** marekn has left #seam-dev
[20:23:16] <bleathem> nice, I'll add that to my blog post.
[20:23:36] <bleathem> Do we want some official Seam documentation (on sfwk.org) telling people how to do this?
[20:23:59] <lightguard_jp> Good iead
[20:24:01] <lightguard_jp> idea
[20:24:09] <lightguard_jp> You could add a sticky post pointing to your blog
[20:25:14] <lincolnthree1> Dudes. This is badass
[20:25:22] <lincolnthree1> I have forge installing plugins from git repositories
[20:25:27] <lincolnthree1> downloads the source from git
[20:25:31] <lincolnthree1> builds the plugin locally
[20:25:32] <bleathem> Should I do so from the Seam Faces page, or should this be a more central Seam 3 page
[20:25:35] <lincolnthree1> then installs it and restarts itself
[20:25:42] <bleathem> wow, nice
[20:25:55] <lincolnthree1> sorry to interrupt
[20:25:56] <lincolnthree1> :)
[20:26:19] <bleathem> next you'll be telling us you've set up "Forge Central", and are looking to mirror it in Europe because of the high traffic requirements
[20:26:30] <lincolnthree1> that's the end goal...
[20:26:39] <lincolnthree1> but wihtout hosting any actual artifacts
[20:26:57] <lincolnthree1> you just put your plugin source online, register it in the central index (we approve it maybe) and then forge folks can build and install it
[20:27:12] <lincolnthree1> and they also get your sources in a pre-ready git repo, so it encourages sharing
[20:27:14] <lincolnthree1> and openness
[20:27:14] <lincolnthree1> :)
[20:27:23] <bleathem> Cool.
[20:27:32] <lincolnthree1> mojavelinux: should like this one
[20:27:36] <lincolnthree1> ^^
[20:35:36] *** lightguard_jp has quit IRC
[20:36:57] *** cbrock has quit IRC
[21:03:27] *** monkeyden has joined #seam-dev
[21:18:17] <nickarls> where does AS7 stand on this osgi-thingie?
[21:23:42] <mojavelinux> bleathem: upgrading weld in glassfish likely belongs in the weld ref guide
[21:30:19] <bleathem> ok
[21:31:08] *** monkeyden has quit IRC
[21:31:56] <bleathem> mojavelinux It would be useful to prominently link to any compatibility issues from the Seam 3 home page, until the issue is resolved upstream.
[21:32:11] <bleathem> People are going to experience this problem, and come looking for answers
[21:32:28] <mojavelinux> agreed...perhaps a section on the "status" page
[21:32:33] <mojavelinux> that seems to be the most fitting place
[21:32:41] <mojavelinux> even above the modules
[21:33:50] <bleathem> Yes that's prominent.
[21:34:07] <bleathem> I would also advocate adding a little alert "news box" on the front page (let's resurrect the <blink> tag!)
[21:34:34] <bleathem> temporary, to remove once the issue is fixed upstream
[21:35:17] <bleathem> "Attention Glassfish 3.1 users: please see this notice about Seam 3 compatibility"
[21:38:29] *** alesj has left #seam-dev
[21:39:03] <mojavelinux> yeah, reasonable
[21:39:11] <mojavelinux> that's currently on the faces page, I think it's more fitting on the status page
[21:39:25] <mojavelinux> the module page should just link to the status and say "watch this space for compatibility issues"
[21:40:30] <bleathem> agreed.  Otherwise, disparate/inconsistent compatibility notices would be inevitable.
[21:51:36] <bleathem> AnnotationInspector methods take AnotatedElement and Anotated as parameters.
[21:51:58] <bleathem> Where do you get these Anotated* objects from?
[21:56:15] <bleathem> And a meta annotation is an annotation on an anotation right?
[21:56:43] <stuartdouglas> Annotated* comes from lifecycle events
[21:56:53] <stuartdouglas> or you can build them using AnnotatedTypeBuilder
[22:01:13] *** bitshuffler has quit IRC
[22:01:28] <bleathem> tks!
[22:27:12] *** lightguard_jp has joined #seam-dev
[22:38:00] *** PeteRoyle has joined #seam-dev
[22:38:44] *** clerum has quit IRC
[22:40:37] *** Royle has joined #seam-dev
[22:40:37] *** PeteRoyle has quit IRC
[22:43:01] <bleathem> I *so* fixed my qualifier cache using unit tests.
[22:43:04] <bleathem> TDD for the win!
[22:43:32] <bleathem> well, almost TDD.
[22:44:58] <bleathem> If I was a logger and seamfaces-33 was a tree, I would start chopping from the other side ot the tree right about now.
[22:45:48] <bleathem> clarification for the devs out there: a logger is someone who cuts down trees, not something that records messages in your code!
[22:45:50] <Royle> Test Driven Debugging?
[22:46:07] <bleathem> I like that!
[22:46:42] <Royle> :)
[22:47:59] <nickarls> bleathem: @Inject LumberJack
[22:48:03] *** daniel_hinojosa has quit IRC
[22:48:40] *** sannegrinovero has quit IRC
[22:48:57] <bleathem> right! LumberJack would have been better...
[22:49:28] <bleathem> This demonstrates the power of having a strong developer community behind a nice clean API.
[22:51:54] <nickarls> so what's the current status on.... loggers and solder? solder has a producer for a jboss-logging Logger, or?
[22:52:04] <nickarls> or multiple types?
[22:52:34] *** daniel_hinojosa has joined #seam-dev
[22:54:22] <bleathem> Good question, I've just been using Logger.getLogger(...)
[22:57:10] <bleathem> speaking of which, it's correct to use "private transient final" for loggers, over "private static final" - correct?
[23:06:04] <lightguard_jp> Don't use static (thought we went over that one before)
[23:06:42] <bleathem> we did, I was just confirming I remembered it right.  tks!
[23:12:03] *** clerum has joined #seam-dev
[23:18:48] <bleathem> sbryzak should a single ViewPattern be allowed to have more than one annotation qualified by @SecurityBindingType ?
[23:18:59] <sbryzak> bleathem: definitely
[23:19:19] <bleathem> ok
[23:24:50] <mojavelinux> if anyone is going to be in the UK during JAX London (Apr 11 - 13) and you want go for free, let me know
[23:24:58] <mojavelinux> I've got a pass with your name on it ;)
[23:25:04] <mojavelinux> tell your UK friends :)
[23:26:02] <lightguard_jp> Cool
[23:28:07] <bleathem> @sbryzak, how will we deal with hierarchical view structures?  @Admin on "/admin/*" and @Owner on "/admin/editItem.xhtml" ?
[23:28:17] <bleathem> Are the security annotations always going to be additive?
[23:28:43] <sbryzak> bleathem: it should inherit the restriction from the wildcard
[23:28:44] <bleathem> or do we want the single set of security annotations on the most specific view pattern?
[23:28:54] <bleathem> ok
[23:29:54] <bleathem> So a security restricition is the collection of all security annotations on view patterns that apply to a given view id,
[23:29:57] <sbryzak> afk a bit, on a conf call
[23:30:04] <sbryzak> bleathem: yes
[23:30:06] <bleathem> and contradictions are left to the developer to resolve
[23:30:09] <bleathem> ok
[23:30:15] <bleathem> thks
[23:37:16] *** clerum has quit IRC
[23:38:29] *** clerum has joined #seam-dev
[23:44:41] <mojavelinux> we should have some rules about obtaining a logger on the code conventions page
[23:44:53] <mojavelinux> eventually, we want to switch totally to typed loggers
[23:45:12] <mojavelinux> we've held off until the annotation processor was in place, because you saw the nightmares we got w/o it :)
[23:45:20] <mojavelinux> so now that it's there, you should likely start going down that path
[23:45:30] <mojavelinux> you should @Inject the logger if in a bean
[23:45:38] <mojavelinux> or use the static method to get a reference if you are in an extension
[23:45:46] *** stuartdouglas has quit IRC
[23:45:51] <mojavelinux> also, we should decide on how to name the categories
[23:45:56] <mojavelinux> in Seam servlet I'm using "seam-servlet"
[23:46:02] <mojavelinux> this overrides the classname
[23:46:25] <mojavelinux> we probably should have something more fine-grained than that...since it limits the ability to control the levels if you group them all together
[23:46:39] <mojavelinux> for instance, we should probably have things like "bootstrap", "events", etc
[23:46:54] <lightguard_jp> Sweet: https://chrome.google.com/webstore/detail/dbepggeogbaibhgnhhndojpepiihcmeb (for those who like Vim)
[23:46:55] <mojavelinux> seam-servlet.bootstrap for instance
[23:47:04] <mojavelinux> btw, Royle, good to see you around
[23:47:17] <mojavelinux> we had a question for you when we saw you next
[23:47:32] <Royle> hey :). OK shoot
[23:48:01] <mojavelinux> would you be willing to add basic async support for non-ejbs to seam cron? i imagine it's pretty straightforward
[23:48:14] <mojavelinux> and likely most of the logic is in seam 2 if you need the reference
[23:48:29] <mojavelinux> we have transactions for non-EJBs in the persistence (soon to be transaction module)
[23:48:42] <mojavelinux> and folks have been asking about the async support
[23:48:57] <mojavelinux> the idea for cron, at least in my head, was timing related stuff (non-jms)
[23:49:04] <mojavelinux> though there was discussion of putting @Asynchronous in solder
[23:49:21] <mojavelinux> then having a jms provider and an SE (thread) provider
[23:49:39] <mojavelinux> the thread provider would be in cron, at least that's my thought
[23:49:43] <mojavelinux> wdyt?
[23:49:53] <mojavelinux> then we could push out an alpha of cron :)
[23:50:12] <mojavelinux> all in favor of @Asynchronous in solder? I think we had already settled on this at some point
[23:50:51] <sbryzak> i guess it makes sense
[23:51:09] <mojavelinux> btw, we really appreciate the weld se functionality...it really has benefited arquillian
[23:52:21] <Royle> ok. I can't say I've fully got my head around what you need, but it sounds simple enough and I'm happy to start doing work on cron again soon
[23:52:32] <Royle> especially if it means we can get it out ther
[23:53:05] <mojavelinux> cool! I'll add a vote from cody too, cause it's a great use case to match cron and mail together
[23:53:26] <lincolnthree1> wewt! i got maven embedded into forge :) now you don't need to install maven
[23:53:39] *** stuartdouglas has joined #seam-dev
[23:53:40] <mojavelinux> we are on a roll right now with getting modules released, so it's a good time to leverage the momentum
[23:53:52] <mojavelinux> in fact, soon enough, lincoln will have forge writing modules for us ;)
[23:54:08] <lincolnthree1> hah!
[23:54:09] <lightguard_jp> lincolnthree1: maven embedded or Aether?
[23:54:16] <lincolnthree1> technically both
[23:54:19] <mojavelinux> lincolnthree1: that's a really nice feature
[23:54:38] <mojavelinux> I like when build systems can come along for the ride instead of being installed externally
[23:55:59] <Royle> so arquillian uses SE as well?
[23:56:03] <Royle> (weld se)
[23:56:08] <mojavelinux> oh heck yeah
[23:56:15] <mojavelinux> it's the cornerstone of the weld-embedded containers
[23:56:21] <mojavelinux> aslak did an ee container
[23:56:25] <mojavelinux> which is pretty cool, it uses weld se
[23:56:31] <stuartdouglas> actually I am pretty sure arq uses it's own se implementation
[23:56:33] <mojavelinux> but then it also implements all the ee APIs from weld
[23:56:39] <mojavelinux> so weld se can run like it's ee
[23:56:43] <stuartdouglas> or at least it used to
[23:56:54] <sbryzak> lincolnthree1: are you going to have another forge release for me this week? :)
[23:57:10] <lincolnthree1> depends, what do you want in it? :)
[23:57:16] <lincolnthree1> hopefully yes
[23:57:17] <sbryzak> anything you've got
[23:57:22] <sbryzak> but mainly the update jansi jar
[23:57:23] <aslak> mojavelinux, Royle, well, we don't really use Weld SE, we emulate Weld SE
[23:57:24] *** clerum has quit IRC
[23:57:51] <Royle> fair enough. it's not hard to do :)
[23:57:55] <aslak> mojavelinux, Royle, we use the Environments.SE
[23:58:24] <sbryzak> lincolnthree1: also, i was wondering if it was possible to have a configurable classpath
[23:58:36] <lincolnthree1> sbryzak: configurable how so?
[23:58:41] <lincolnthree1> for starting forge?
[23:58:41] <mojavelinux> ah, yep, it's switched out, but certainly followed the lead
[23:58:51] <sbryzak> lincolnthree1: well, first of all a question - does forge require solder?
[23:58:58] <lincolnthree1> sbryzak: shouldn't anymore
[23:59:08] <mojavelinux> I remember hacking on it at an earlier stage, we might have been copying the code even then, but still, it was very much the starting point
[23:59:16] <sbryzak> lincolnthree1: ah, that's good, maybe the classpath doesn't matter then
[23:59:41] <sbryzak> lincolnthree1: my concern was that forge might require libraries from the /artifacts directory of the bundled distribution
[23:59:50] <sbryzak> i.e. solder





top