[00:00:06] <sbryzak> the good thing about the servlet module is that it's very narrow in scope
[00:00:11] <lightguard_jp> I added an issue for servlet
[00:00:12] <sbryzak> so not much to go wrong ;)
[00:00:21] <lightguard_jp> I can probably send a pull request for it though
[00:00:29] *** clerum has quit IRC
[00:00:35] <sbryzak> what's the issue ID?
[00:00:38] *** clerum has joined #seam-dev
[00:00:45] <sbryzak> ah, SEAMSERVLET-28 ?
[00:00:46] <jbossbot> jira [SEAMSERVLET-28] Integrate Catch with *EventBridge* classes [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/SEAMSERVLET-28
[00:00:48] * lightguard_jp looking
[00:00:51] <lightguard_jp> Yep
[00:01:02] <lightguard_jp> It's a try / catch block :)
[00:01:03] <sbryzak> is that an easy fix?
[00:01:14] <lightguard_jp> try / catch fire event to Catch
[00:01:17] <sbryzak> cool, if you send a pull request through i'll apply it
[00:01:30] <sbryzak> i'll set the fix version to CR1, and make it a blocker
[00:01:30] <lightguard_jp> Okay
[00:02:03] *** tsurdilo has joined #seam-dev
[00:02:06] <sbryzak> on the subject of jira, i need to spend some time updating versions, issues, etc
[00:02:33] <sbryzak> it's a little behind, because i had to rush to get a bunch of releases done last weekend to get beta 2 out
[00:02:44] <lightguard_jp> sbryzak: Is there a chance of getting fisheye to index our github repos so it'll link it all up?
[00:03:01] <sbryzak> lightguard_jp: someone brought that to my attention last week
[00:03:10] <lightguard_jp> I think we need to apply the workflow to the rest of the modules if it's not done too.
[00:03:12] <sbryzak> i'll look into it
[00:03:36] <sbryzak> last module on the list is wicket
[00:03:58] <lightguard_jp> Is Dan the main one in charge of it?
[00:03:59] <sbryzak> it doesn't look like clint is online
[00:04:00] <lightguard_jp> Still
[00:04:17] <sbryzak> for wicket?
[00:04:30] <lightguard_jp> Yes. You said clint though, so I guess not
[00:04:48] <sbryzak> i didn't think so
[00:04:54] <lightguard_jp> I know he was working on it.
[00:05:02] <sbryzak> to tell the truth, i don't really know what's happening with the wicket module
[00:05:24] <sbryzak> since it already had a beta release, it got included in the seam bundled beta releases
[00:05:25] *** koentsje has quit IRC
[00:05:50] <sbryzak> and there doesn't seem to be many outstanding issues for it
[00:06:07] <sbryzak> i'll need to follow that up with dan when he gets back
[00:06:42] <sbryzak> i think that brings us to the end
[00:06:43] <lightguard_jp> Has everyone seen the new Seam Social module?
[00:06:50] <sbryzak> which is good timing, because it's exactly 1 hour
[00:07:04] <sbryzak> lightguard_jp: i haven't had a chance to look at it
[00:07:11] *** daniel_hinojosa has quit IRC
[00:07:15] <lightguard_jp> nor I, but I know he's looking for feedback
[00:07:55] <sbryzak> the only social networking site i use is twitter
[00:08:11] <lightguard_jp> I think that's the only one that works right now
[00:08:12] <sbryzak> that's as far as i go, i'll be dead before i join facebook
[00:08:13] <lightguard_jp> IIRC
[00:08:25] <lightguard_jp> linkedIn ?
[00:08:25] *** daniel_hinojosa has joined #seam-dev
[00:08:37] <lightguard_jp> daniel_hinojosa: Just in time for the end of the meeting
[00:08:40] <sbryzak> linkedin doesn't really count ;)
[00:09:16] <sbryzak> does anyone have any other items they want to bring up before we close the meeting?
[00:09:18] <lightguard_jp> hehe
[00:09:21] <daniel_hinojosa> ha
[00:09:44] <sbryzak> in that case, thanks everyone for joining
[00:09:54] <daniel_hinojosa> great meeting everyone
[00:09:58] <sbryzak> and have a great weekend (working on Seam ;)
[00:10:33] <sbryzak> i've actually forgotten what a weekend is
[00:10:39] <sbryzak> is just kind of blurs in with all the other days
[00:11:52] *** jose_freitas_1 has joined #seam-dev
[00:11:58] <jose_freitas_1> sbryzak, the way security module works with the authorization is the same way it used to work with seam 2?
[00:12:14] <jose_freitas_1> with @Restrict and etc. ?
[00:12:14] <sbryzak> authorization is mostly the same
[00:12:18] <jose_freitas_1> nice
[00:12:20] <sbryzak> no, there's no more @Restrict
[00:12:24] <sbryzak> as it's not typessafe
[00:12:32] <sbryzak> for now, you need to @Inject the Identity bean
[00:12:59] <sbryzak> and call hasPermission(), hasRole(), inGroup(), etc
[00:13:11] <jose_freitas_1> and what about url permission?
[00:13:21] *** jose_freitas has quit IRC
[00:13:30] <sbryzak> that's up to the view layer
[00:13:35] *** jose_freitas_1 is now known as jose_freitas
[00:14:28] <sbryzak> actually i'm not sure where we got up to with that in the seam-faces module
[00:14:50] <jose_freitas> hm
[00:15:01] <sbryzak> i need to follow it up with lincoln, i was discussing it with him a few months ago
[00:15:25] <jose_freitas> well, IMHO thats a really important feature
[00:15:56] <sbryzak> well, more important is that your backend services are secured
[00:16:07] <sbryzak> if they are, then it doesn't matter what the view does
[00:16:47] <lightguard_jp> Especially if there's multiple entry points to the app.
[00:16:53] <jose_freitas> sure
[00:16:55] <sbryzak> exactly
[00:17:07] <jose_freitas> I dont mean that its an exclusive option
[00:17:11] <sbryzak> so you might very well be able to browse to an admin-only page as a normal user
[00:17:41] <sbryzak> but it won't display any sensitive data or allow you to execute any privileged operations if your beans are secured
[00:19:09] <jose_freitas> ok
[00:19:40] *** lightguard_jp has quit IRC
[00:20:04] *** lightguard_jp has joined #seam-dev
[00:20:22] <lightguard_jp> It's /leave not /quite oops :)
[00:22:19] <ssachtleben> guys
[00:22:21] <ssachtleben> i
[00:22:38] <ssachtleben> m not sure but I still get these bunch of log messages with current snapshot of faces
[00:22:40] <ssachtleben> http://pastebin.com/WUqWM0M2
[00:22:53] <ssachtleben> not funny to get 50 log messages with each click from faces ^^
[00:27:27] <lightguard_jp> ssachtleben: Brian isn't here, but please raise a JIRA issue
[00:27:39] <lightguard_jp> Sounds like most of those should be debug or trace level
[00:28:40] <ssachtleben> oki
[00:32:13] *** jharting has quit IRC
[00:34:15] *** johnament has joined #seam-dev
[00:37:59] <ssachtleben> SEAMFACES-86
[00:38:01] <jbossbot> jira [SEAMFACES-86] Current SNAPSHOT version produces much log messages (for each f:converter and a4j:mediaOutput) [Open (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-86
[00:38:06] <ssachtleben> hihi :)
[00:42:39] <lightguard_jp> ssachtleben: Thank you
[00:44:12] <ssachtleben> np
[00:45:21] <ssachtleben> maybe the converter messages depending on SEAMFACES-82
[00:45:23] <jbossbot> jira [SEAMFACES-82] Injection in faces Converters broken [Open (Unresolved) Bug, Critical, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-82
[00:45:34] <ssachtleben> not sure about the other
[00:46:48] *** ssachtleben has quit IRC
[00:47:09] <lightguard_jp> I think Brian knows about that one
[00:47:38] <johnament> lightguard_jp: btw, those examples worked perfect for what we were trying.
[00:47:42] <johnament> so thanks.
[00:47:59] <lightguard_jp> johnament: Which examples?
[00:48:09] <johnament> lightguard_jp: injecting the extension.
[00:48:27] <lightguard_jp> johnament: Ah, perfect, glad that helped
[00:48:39] <lightguard_jp> johnament: Sorry, so many conversations :)
[00:52:13] <johnament> hmmm just thought of something.  can i store AfterBeanDiscovery in my extension and then play with it later on? e.g. register a new observer method after the event has been processed..
[00:54:16] <lightguard_jp> No
[00:54:34] *** bleathem has joined #seam-dev
[00:54:48] <lightguard_jp> If you're using the standard @Observes you cannot mess with any of that stuff after CDI starts
[00:54:50] <bleathem> lightguard_jp I got your DM
[00:54:55] <lightguard_jp> bleathem: :)
[00:55:10] <lightguard_jp> There's a new JIRA too: SEAMFACES-86
[00:55:11] <jbossbot> jira [SEAMFACES-86] Current SNAPSHOT version produces much log messages (for each f:converter and a4j:mediaOutput) [Open (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-86
[00:55:19] <bleathem> Yeah, I was just reading that one
[00:55:34] <bleathem> I got a little carried away with logging  :P
[00:55:49] <lightguard_jp> Logging is probably fine, but that stuff should probably be debug or trace level
[00:56:22] <johnament> lightguard_jp: that's what i figured.  but wanted to give it one last thought before i send out my new proposed JMS API.
[00:56:28] <bleathem> Well, one of them I didn't realize would be logged only at application startup
[00:56:52] <lightguard_jp> johnament: Yeah, there have been a few people that have wanted to do stuff like what you're doing in JMS and it's just not possible
[00:57:05] <lightguard_jp> Unless you do what Catch is doing and not use @Observes
[00:57:06] <bleathem> the oterone has to do with WELD-846
[00:57:07] <jbossbot> jira [WELD-846] Incorrect handling of cyclic dependencies between BeanDeploymentArchives [Closed (Done) Bug, Major, Stuart Douglas] https://issues.jboss.org/browse/WELD-846
[00:57:28] <bleathem> And I want to log a warning message, but Ideally only once
[00:57:41] <johnament> lightguard_jp: well, it's possibly an option.
[00:58:57] <lightguard_jp> johnament: I think the main idea was they wanted CDI to discover everything up front and tell you at deployment time instead of having a runtime exception when you try to call.
[00:59:06] <lightguard_jp> Makes things a little difficult though
[00:59:25] <johnament> chegg's happen then.
[01:05:19] <bleathem> sbryzak: You're looking for a Faces update?  Would you prefer to hear on the seam-dev mail list?
[01:05:45] <sbryzak> bleathem: it's up to you
[01:05:52] <johnament> bleathem: you break it, you bought it.
[01:06:13] <bleathem> Well essentially, there are more issues to resolve than I can do on my own.
[01:06:27] <bleathem> I haven't managed to recruit any fresh blood yet
[01:06:50] <bleathem> And Dan and Lincoln are busy with other things.
[01:07:10] <bleathem> I'm plugging away at it.  But I don't see myself able to do it all.
[01:07:20] <sbryzak> which blockers are there for a CR release?
[01:07:37] <bleathem> lemme look, 1 sec
[01:11:56] *** tsurdilo has quit IRC
[01:12:09] *** lightguard_jp has quit IRC
[01:12:50] <bleathem> SEAMFACES-85, SEAMFACES-86, SEAMFACES-75 seem like the only blockers to me.
[01:12:52] <jbossbot> jira [SEAMFACES-85] Remove / update license headers [Open (Unresolved) Task, Minor, Brian Leathem] https://issues.jboss.org/browse/SEAMFACES-85
[01:12:53] <jbossbot> jira [SEAMFACES-86] Current SNAPSHOT version produces much log messages (for each f:converter and a4j:mediaOutput) [Open (Unresolved) Bug, Minor, Unassigned] https://issues.jboss.org/browse/SEAMFACES-86
[01:12:54] <jbossbot> jira [SEAMFACES-75] Messages not displayed [Open (Unresolved) Bug, Major, Dan Allen] https://issues.jboss.org/browse/SEAMFACES-75
[01:13:12] <bleathem> First 2 are trivial, I don't know where the 3rd one is at.
[01:13:38] <bleathem> The rest seem like they could be bumped
[01:13:49] <bleathem> Many of them post 3.0.0 if necessary
[01:14:25] <sbryzak> ok, if we could just sort out those few issues perhaps
[01:14:27] <sbryzak> and bump the others
[01:14:38] <bleathem> will do.
[01:14:41] <sbryzak> i can take care of the license headers if you like
[01:14:46] <sbryzak> just assign the issue to me
[01:14:55] <bleathem> When is CR1 is at the end of the month right?
[01:15:13] <sbryzak> yes, but the module releases should be done by wednesday next week at the latest
[01:15:17] <sbryzak> earlier if possible
[01:15:20] <bleathem> ok
[01:16:00] <bleathem> Remember the WELD issues I was telling you about last night?
[01:16:29] <bleathem> Well I blogged about updating weld in GF 3.1, to which Pete replied (via twitter) that Weld 1.2 will have breaking SPI changes.
[01:16:43] <bleathem> So that strategy is kind of out the window
[01:16:57] <sbryzak> that sucks
[01:17:00] <bleathem> Unless we can get weld to do a 1.1.1 release, with no SPI changes.
[01:17:20] <bleathem> I've asked Pete about that, but no answer yet.
[01:17:33] <sbryzak> unless they already plan to do a 1.1.1 release, i don't think it will happen
[01:17:35] <bleathem> I suppose I should bring it up via more formal channels.
[01:17:36] <johnament> does 1.2 have to have SPI changes?
[01:18:33] <bleathem> I don't know.  Presumably they don't make such changes frivolously.
[01:19:04] <bleathem> Jason Lee said if Weld 1.2 has SPI changes, we probably won't see Weld 1.2 in glassfish until Glassfish 3.2
[01:19:22] <bleathem> This is bad news for several faces features.
[01:22:46] <bleathem> Is it worth trying to escalate these issues to find some kind of resolution?  Or do we just document it, and wait it out?
[01:23:37] <sbryzak> i think you need to discuss with ales and pete, to make them aware of them problems
[01:24:12] <stuartdouglas> personally I am against changing the SPI in a backwards incompatible way, I don't think that there will be enough of a performance benefit to justify any changes
[01:24:22] <bleathem> Ok, will do.  Is the seam-dev mail list the appropriate place?  Or does Weld have a mail list of it's own?
[01:24:30] <sbryzak> weld-dev
[01:24:40] <bleathem> thanks
[01:25:03] <sbryzak> https://lists.jboss.org/mailman/listinfo/weld-dev
[01:25:03] <bleathem> stuartdouglas: From my perspective, SPI changes should be few and far between
[01:25:24] <bleathem> too many things depend on weld to not be able to benefit from bug fixes.
[01:51:26] *** johnament has quit IRC
[01:52:20] *** daniel_hinojosa has quit IRC
[01:52:37] <jbossbot> git [dist] push master 2862f46.. Shane Bryzak removed lgpl license, fixed missing dependencies
[01:52:37] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/03f2f61...2862f46
[01:52:38] *** johnament has joined #seam-dev
[01:54:01] *** cbrock has quit IRC
[01:55:15] <jbossbot> git [persistence] push master 7a93147.. Stuart Douglas Clean up some holes in the documentation
[01:55:15] <jbossbot> git [persistence] push master URL: http://github.com/seam/persistence/compare/d5c9de7...7a93147
[02:14:30] *** cbrock has joined #seam-dev
[02:14:31] *** cbrock has quit IRC
[02:14:31] *** cbrock has joined #seam-dev
[02:22:54] *** daniel_hinojosa has joined #seam-dev
[02:24:48] *** jose_freitas has quit IRC
[02:37:58] <johnament> hmmm how good is arquillian at managing event firing test cases
[02:54:13] *** daniel_hinojosa has quit IRC
[02:54:20] *** cbrock has quit IRC
[03:28:33] <jbossbot> git [dist] push master 120925c.. Shane Bryzak fix dependencies, update missing versions
[03:28:33] <jbossbot> git [dist] push master URL: http://github.com/seam/dist/compare/2862f46...120925c
[04:15:15] *** nraf has quit IRC
[05:20:39] *** daniel_hinojosa has joined #seam-dev
[05:53:46] *** rruss has joined #seam-dev
[06:03:09] *** cbrock has joined #seam-dev
[06:03:09] *** cbrock has quit IRC
[06:03:09] *** cbrock has joined #seam-dev
[06:23:19] *** cbrock has quit IRC
[06:36:19] *** rpetruescu has joined #seam-dev
[07:24:06] *** lukaszlenart has joined #seam-dev
[07:24:29] *** oskutka has joined #seam-dev
[07:32:53] *** mgencur has joined #seam-dev
[07:39:54] *** cbrock has joined #seam-dev
[07:39:54] *** cbrock has quit IRC
[07:39:54] *** cbrock has joined #seam-dev
[07:53:19] *** kpiwko has joined #seam-dev
[07:58:58] *** ulath has joined #seam-dev
[08:45:22] *** rruss has quit IRC
[08:52:03] *** daniel_hinojosa has quit IRC
[08:58:34] *** marekn has joined #seam-dev
[08:59:57] *** marekn has quit IRC
[09:00:39] *** marekn has joined #seam-dev
[09:01:18] *** maschmid has joined #seam-dev
[09:07:20] *** emmanuel has joined #seam-dev
[09:18:20] *** jharting has joined #seam-dev
[09:22:13] *** emmanuel has quit IRC
[09:29:19] *** koentsje has joined #seam-dev
[10:01:01] *** jharting has quit IRC
[10:16:15] *** jharting has joined #seam-dev
[10:18:16] *** cbrock has quit IRC
[11:06:27] *** mgencur has quit IRC
[11:32:39] *** alesj has joined #seam-dev
[11:59:00] *** oskutka has quit IRC
[12:00:29] *** oskutka has joined #seam-dev
[12:08:05] *** pmuir has joined #seam-dev
[12:22:03] <pmuir> johnament: ping
[12:38:20] *** adamw1pl has joined #seam-dev
[13:02:39] <johnament> pmuir: just woke up
[13:03:12] <johnament> pmuir: the issue you just reopened, that was the issue that Jordan had raised on the seam-dev list last week, where he couldn't access beans in ABD.
[13:03:58] <pmuir> johnament: right there were two issues I wanted to talk to you about
[13:04:04] <pmuir> do you want to do it now or later?
[13:04:23] <johnament> pmuir: i'm probably going to end up late for work, would you mind email?
[13:04:31] <johnament> pmuir: john.d.ament at gmail dot com
[13:04:53] <pmuir> sync would be easier
[13:05:03] <pmuir> as i'm missing something and we're not making it via email
[13:05:12] <pmuir> can you tell me when you can do?
[13:06:32] *** rruss has joined #seam-dev
[13:08:11] <johnament> let's talk a little now then.
[13:26:42] <pmuir> sorry johnament was distracted
[13:26:51] <pmuir> can you explain what the exact problem is?
[13:26:58] <pmuir> with not being able to resolve beans
[13:27:47] <pmuir> is it because you need to be able route requests to beans at that point? or?
[13:33:38] <johnament> so the original idea (for the observer interfaces) was that you could define @AnyQualifier Topic t as the topic that would handle the JMS messages.
[13:34:09] <johnament> The problem though is that during AfterBeanDiscovery, there is no guarantee that the @Produces for @AnyQualifier Topic t was ready yet.
[13:35:16] <johnament> I've suspected this for a few weeks now and created WELD-850 to track it.  Then Ales moved it to SEAMJMS-16 when I mentioned I was trying this as a part of Seam JMS
[13:35:17] <jbossbot> jira [WELD-850] Redirected to: https://issues.jboss.org/si/jira.issueviews:issue-xml/SEAMJMS-16/SEAMJMS-16.xml
[13:35:19] <jbossbot> jira [SEAMJMS-16] Event to JMS to Event mapping behavior [Reopened (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMJMS-16
[13:36:27] <johnament> Jordan had followed this up with a way to define @Produces Route route in your code to define routes.  When the Seam QA guys went to start building examples, none of them worked.
[13:36:58] <johnament> which is when you guys noted on seam-dev that there is no guarantee that the beans are ready (or something along those lines).
[13:38:04] <johnament> which lead to my alternate API support email last night to be able to define a certain set of qualifiers, which wouldn't be treated as qualifiers, to be able to at least get the module running.
[13:38:24] <johnament> because we still don't have an Alpha2 :-)
[13:40:16] <johnament> so I've gotta go walk the dogs, then head to work.  I'll try to get on to webchat from work, maybe around 1400 GMT?  If that doesn't work, would you be available tomorrow morning?
[13:58:17] <johnament> pmuir: so i'm heading out.  i'll try you around 1400.
[13:58:25] *** johnament has quit IRC
[14:29:39] *** jose_freitas_afk is now known as jose_freitas
[14:54:20] *** ulath has quit IRC
[14:54:40] *** monkeyden has joined #seam-dev
[15:03:34] *** amitev has quit IRC
[15:12:05] *** johnament has joined #seam-dev
[15:13:17] <johnament> pmuir: ping
[15:13:24] <pmuir> heta
[15:13:33] <pmuir> sorry johnament if I don't respond use pete or pmuir
[15:13:36] <pmuir> so I get a popup ;-)
[15:13:56] <pmuir> what I'm trying to understand is *why* you need the producers during ABD
[15:14:25] <pmuir> I know there is a problem that the JMS inflow starts earlier and so you have to block on receiving them until after ADV
[15:14:31] *** lukaszlenart has left #seam-dev
[15:16:00] <johnament> ADV?
[15:16:17] <johnament> hold on give me 5, i've been elected to make the coffee.
[15:16:33] *** rruss has quit IRC
[15:17:06] <pmuir> AfterDeploymentValidation
[15:21:27] <johnament> pmuir: so the issue is that as a part of this whole flow, the egress stuff needs to get processed during ABD since it requires us to create new ObserverMethods
[15:22:18] <pmuir> ok, but that shouldn't require you to execute producer methods or look them up should it?
[15:22:32] <johnament> pmuir: are you referring to what was done in SEAMJMS-3 or SEAMJMS-6 ?
[15:22:34] <jbossbot> jira [SEAMJMS-3] Event Mapping Observer Method Interfaces - Egress [Open (Unresolved) Feature Request, Blocker, John Ament] https://issues.jboss.org/browse/SEAMJMS-3
[15:22:35] <jbossbot> jira [SEAMJMS-6] Routes should be produced instead of returned from an annotated method [Closed (Done) Feature Request, Major, Jordan Ganoff] https://issues.jboss.org/browse/SEAMJMS-6
[15:23:07] <johnament> pmuir: i can't speak to SEAMJMS-6 unfortunately, I just know it's what caused Jordan to come up with the issue as well.
[15:23:09] <jbossbot> jira [SEAMJMS-6] Routes should be produced instead of returned from an annotated method [Closed (Done) Feature Request, Major, Jordan Ganoff] https://issues.jboss.org/browse/SEAMJMS-6
[15:23:34] <pmuir> i'm just talking about the email you sent the list
[15:24:07] <johnament> pmuir: apparently, using @SomeQualifier Topic t was defined in the original 299 spec.
[15:24:23] <johnament> as an example of what an example application could do.
[15:24:32] <pmuir> yes
[15:24:44] <pmuir> absolutely
[15:24:50] <johnament> how do i resolve @SomeQualifier if I can't look up the bean?
[15:25:00] <johnament> errr @SomeQualifier Topic t
[15:25:09] <johnament> regardless of whether it's a producer method or field.
[15:26:02] <pmuir> you need to do this once the app is fully started
[15:26:11] <pmuir> not during ABD
[15:26:24] <johnament> pmuir: but i can't, because I need to register the observer method during ABD
[15:26:29] <pmuir> yeah
[15:26:37] <pmuir> so this brings be to the question that I asked above
[15:26:46] <johnament> which one?
[15:26:52] <pmuir> why do you need to resolve these things in order to register an observer method
[15:26:58] <pmuir> thats what I don't get
[15:27:30] <johnament> pmuir: it may be another issue then, because when I provide bean manager to the observer method, it still cannot lookup beans.
[15:27:43] <pmuir> which BM? the one from ABD?
[15:27:51] <johnament> pmuir: yes, it's the only one i have.
[15:27:59] <pmuir> correct, that one can't
[15:28:08] <johnament> pmuir: ok, so i'm not going crazy then.
[15:28:09] <pmuir> you need to use the one associated with the producer method
[15:28:19] <johnament> pmuir: but how do i get that one?
[15:28:34] <pmuir> your producer methods are special somehow right?
[15:28:47] <pmuir> they have some unique feature about their signature?
[15:28:57] <pmuir> i.e. return Topic? or something like that
[15:28:59] <johnament> pmuir: no, not at all, ideally they can be defined by the app developer, not the API.
[15:29:01] <pmuir> or have an annotation
[15:29:52] <johnament> pmuir: we were not putting any restriction on the app developer for requiring an annotation.
[15:29:54] <pmuir> I thought we were talking about things like
[15:30:01] <pmuir> @Resource(name="java:global/env/jms/Events")
[15:30:01] <pmuir> @Produces @Events Topic eventTopic;
[15:30:16] <johnament> pmuir: that example actually doesn't work either.
[15:30:30] <johnament> pmuir: you rejected my issue about it.
[15:30:41] <pmuir> hmm, ok
[15:30:45] <pmuir> which one?
[15:31:09] *** bleathem has quit IRC
[15:31:29] <pmuir> anyway, we can discuss that later
[15:31:37] <johnament> pmuir: i'd have to dig it up, it's a few months old.
[15:31:47] <pmuir> ok
[15:31:56] <pmuir> but you are saying that a producer method
[15:32:10] <pmuir> @Produces Object getFoo() { ... } is a valid target
[15:32:10] <pmuir> ?
[15:32:34] <johnament> if the returned object passes instance of Destination.class then yes it would.
[15:33:17] <johnament> WELD-814
[15:33:18] <jbossbot> jira [WELD-814] Resources injected to producer fields fail to be produced [Closed (Rejected) Bug, Major, Pete Muir] https://issues.jboss.org/browse/WELD-814
[15:34:21] <pmuir> so IMO then the distinctive part of the signature is that the return type of the producer is Destination
[15:34:26] <pmuir> but regardless
[15:34:30] <pmuir> there is another way to do it
[15:34:48] <pmuir> if you do a lookup for the BM inside the ObserverMethod using the stuff from Solder
[15:35:01] <pmuir> you will be the right BM for the registered observer methods bean classs
[15:35:03] <johnament> pmuir: at least when i tried that, it failed.
[15:35:11] <pmuir> which will be able to look at beans
[15:35:19] <pmuir> it can access
[15:35:41] <pmuir> the lookup from solder?
[15:35:52] <pmuir> but my approach to this
[15:36:09] <pmuir> would be to require the producer methods to reuturn a subclass of destination as part of their signature
[15:36:14] <pmuir> as they must do this anyway
[15:36:32] <pmuir> then install a PB listener that watches for this
[15:36:42] <johnament> PB Listener?
[15:36:42] <pmuir> and collects all the beans
[15:36:47] <pmuir> ProcessBean<>
[15:37:03] <pmuir> meh
[15:37:14] <pmuir> it's a bit ugly
[15:37:23] <pmuir> as you need to resolve stuff yourself then
[15:37:28] <pmuir> no, the Solder way is better
[15:37:48] <pmuir> oh actually
[15:37:49] <johnament> pmuir: at least when i tried the solder way, maybe it's just because i wasn't doing it right, i couldn't locate a bean manager.
[15:38:44] <pmuir> why not do this is ProcessObserverMethod
[15:38:49] <pmuir> just store the BM along with the OM
[15:39:05] <pmuir> thats the BM with exactly the right visibility
[15:39:16] <pmuir> and access
[15:39:17] <johnament> does ProcessObserverMethod allow me to create observer methods?
[15:39:20] <pmuir> no
[15:39:25] <pmuir> but extensions are stateful
[15:39:37] <pmuir> so you do Collection<ObserverMethod> myMethods
[15:39:48] <pmuir> myMethods.add(new MyOM(...));
[15:39:51] <johnament> so grab the bean manager in process observer and add the bean manager to each observer method there?
[15:39:54] <pmuir> and then in ABD add each of them
[15:39:56] *** emmanuel has joined #seam-dev
[15:39:57] <pmuir> yes
[15:40:22] <pmuir> but don't try to use that BM until you actually need it during application processing (not deployment)
[15:43:10] <pmuir> you do have another problem
[15:43:22] <pmuir> which is that the TCCL is not set quite right during the message inflow
[15:43:31] <pmuir> which means that Weld can't correcctly locate itself
[15:43:35] <pmuir> in JBoss AS
[15:43:40] <pmuir> which is the bug I reopened today
[15:44:13] <pmuir> btw the issue i rejected is due to the producer having to be @Dependent, not the style in general
[15:48:16] <johnament> so you're saying, if i look up the destinations when notifying, it'll work?
[15:50:21] <pmuir> from the BM that you get from the ProcessObserverMethod callback, yes
[15:50:32] <pmuir> you need to also hold notifications until the app i started
[15:50:36] <pmuir> is started
[15:50:56] <pmuir> which I suggest you do by having a flag on the extension that watches for ADV
[15:51:13] <pmuir> and "inject" the extension into the OM
[15:51:18] <johnament> pmuir: i don't think that'll be an issue, as the whole notification workflow starts with the application firing events.
[15:51:32] <pmuir> and create some sort of queue to hold them
[15:51:38] <johnament> ick.
[15:51:39] <pmuir> what about if it's just inflow from some outside source
[15:51:48] <pmuir> e.g. the POP3 RA
[15:51:58] <johnament> JMS wont' send messages until deployment is complete.
[15:52:06] <pmuir> ok
[15:52:12] <pmuir> jboss always used to ;-)
[15:52:13] <johnament> and i think the mail-ra in AS 6 is broken right now.
[15:52:16] <pmuir> but maybe that is fixed
[15:52:41] <pmuir> ok
[15:52:43] <johnament> definitely not in 6.0.0.  we used to use it to process email.
[15:53:06] <pmuir> no i mean the early sending of messages before deployment is started
[15:53:14] <pmuir> idk about mail-ra
[15:53:34] <johnament> I'll double check on it, but yeah, it's still a problem cross platform that potentially it could happen prior to completion.
[15:54:20] <pmuir> do you understand the issue with why you get the error from weld in as about no singleton set?
[15:54:39] <johnament> so you're saying define public void processObserver(@Observes ProcessObserverMethod<?> pom, BeanManager bm) to load the bean manager in to the observer methods.
[15:54:43] <pmuir> yes
[15:54:57] <pmuir> BM is the only thing you can inject into extensions safely :-D
[15:55:37] <johnament> pmuir: yes, it's essentially a classloader problem where the app and JMS are not in the classloader, but JMS is trying to send an event to the app.
[15:55:55] *** tsurdilo has joined #seam-dev
[15:56:20] <johnament> pmuir: personally, I think a definition exception should occur if something else gets injected. but that's just me.
[16:00:46] *** bitshuffler has joined #seam-dev
[16:03:34] <pmuir> johnament: good point, can you file a CDI issue
[16:03:45] <pmuir> johnament: ok, so on the issue you said "the spec requires this"
[16:03:47] <pmuir> which spec?
[16:07:29] <johnament> which issue?
[16:09:14] <pmuir> https://issues.jboss.org/browse/SEAMJMS-16
[16:09:17] <jbossbot> jira [SEAMJMS-16] Event to JMS to Event mapping behavior [Reopened (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/SEAMJMS-16
[16:11:14] <johnament> the only time i mention the spec is when i rejected it, which was based on the idea that the application was not ready during ABD.
[16:11:27] <pmuir> ah ok
[16:11:33] *** amitev has joined #seam-dev
[16:11:40] <pmuir> so i think I thought you meant something else
[16:11:46] <pmuir> not to worry - so we can now fix the issue?
[16:12:22] <pmuir> :-D
[16:13:54] <johnament> well, i still think it should be rejected, since in fact the bean manager is not really all there in ABD.
[16:15:42] <pmuir> ok, could you explain the issue using different words
[16:15:50] <pmuir> as you seem to be talking about something different to me
[16:17:19] <johnament> pmuir: ?
[16:17:31] <johnament> pmuir: could you explain maybe what you think i'm saying?
[16:17:32] <pmuir> so the issue that I see you reporting
[16:18:28] <pmuir> is that when you are trying to have JMS send an incoming message over the event bus
[16:18:37] <pmuir> it doesn't work because the TCCL isn't set properly
[16:18:42] <pmuir> so Weld doesn't set up properly
[16:19:00] <pmuir> this seems somewhat core to the point of Seam JMS so I don't understand why we can reject it
[16:19:50] <johnament> pmuir: except, it doesn't happen currently when i define the message listener in a separate bean.
[16:20:16] <pmuir> ok, can you give me an example of both?
[16:20:19] <johnament> pmuir: the current seam jms code base delegates the creation of listeners to a bean, which correctly can load everything.
[16:20:31] <pmuir> ok
[16:20:34] <johnament> pmuir: in the example in the issue, i was using the bean manager from ABD
[16:20:44] <pmuir> so perhaps I just don't get the issue
[16:20:48] <pmuir> :-)
[16:20:58] <pmuir> as long as it works correctly during app processing then it's fine ;-)
[16:21:19] *** oskutka has quit IRC
[16:21:43] <johnament> pmuir: the problem was really that i was using the bean manager from ABD to create some beans, and it was only kind of working.  now that i have moved that to a separate bean and doing it on app start up, everything works right.
[16:21:54] <pmuir> ok
[16:21:55] <pmuir> nice
[16:22:11] <johnament> pmuir: based on what you've proposed here, i may try doing it during the extension again, using the bean manager from POM.
[16:22:26] <pmuir> k
[16:22:49] <johnament> pmuir: but basically at that point, neither Jordan nor I realized that the bean manager from ABD was bad.
[16:23:21] <johnament> so the error is essentially one of the things that could happen when playing with that BM in different areas.
[16:24:19] <pmuir> gotcha
[16:39:26] *** pmuir has quit IRC
[16:40:40] *** marekn has quit IRC
[16:58:46] *** alesj has quit IRC
[16:59:11] *** bitshuffler has quit IRC
[17:05:49] *** johnament has left #seam-dev
[17:09:45] *** amitev has quit IRC
[17:15:01] *** rruss has joined #seam-dev
[17:15:23] *** rruss has quit IRC
[17:18:04] *** jharting has quit IRC
[17:19:48] *** adamw1pl has quit IRC
[17:21:09] *** maschmid has quit IRC
[17:34:33] *** kpiwko has quit IRC
[17:42:32] *** ssachtleben has joined #seam-dev
[18:01:03] *** ssachtleben has quit IRC
[18:26:10] *** bitshuffler has joined #seam-dev
[18:26:51] *** daniel_hinojosa has joined #seam-dev
[18:48:31] *** daniel_hinojosa has quit IRC
[19:11:44] *** lukaszlenart has joined #seam-dev
[19:15:04] *** emmanuel has quit IRC
[19:22:17] *** lukaszlenart has quit IRC
[19:47:08] *** ssachtleben has joined #seam-dev
[19:48:27] <ssachtleben> hey
[19:48:35] <ssachtleben> is egit the way to go with eclipse?
[19:49:20] <ssachtleben> I want to put seam modules in eclipse
[19:49:57] <jose_freitas> yes
[19:50:10] <ssachtleben> ok
[19:50:32] <jose_freitas> just clone the repository and then import as a maven project
[19:54:34] <ssachtleben> lol the contributor workflow looks pretty crazy xD
[19:57:25] *** kpiwko has joined #seam-dev
[19:58:47] <ssachtleben> so its better to check out from git and import to eclipse as using egit to checkout directly?
[20:00:51] <jose_freitas> yes, because egit doesnt see the project as an eclipse project
[20:01:36] <jose_freitas> you can apply patch (or share project), though. And then after import as a maven project, you can commit, pull, push and etc.
[20:02:30] <jose_freitas> dont remember if the correct is share project or apply patch
[20:02:42] <ssachtleben> ok
[20:02:45] <jose_freitas> but I'd go for apply patch, and then select the project at the repository
[20:02:58] <ssachtleben> and I need other projects also except the modules?
[20:03:03] <ssachtleben> like parent or something?
[20:03:38] <jose_freitas> hm
[20:03:42] <jose_freitas> which module?
[20:03:50] 
[20:03:53] <ssachtleben> well any like faces or something
[20:04:03] <jose_freitas> but you have to download them
[20:04:14] <ssachtleben> ok
[20:04:17] <jose_freitas> clone the entire project
[20:04:26] <jose_freitas> I mean, the entire module
[20:06:02] <jose_freitas> you might want to fork it before clonning.
[20:07:13] <ssachtleben> not sure what I means :D
[20:07:20] <ssachtleben> I used only svn and cvs before ^^
[20:09:00] <jose_freitas> hm
[20:09:14] <ssachtleben> ok found link on github I going to read about that
[20:09:22] <jose_freitas> fork is what is best about github
[20:10:32] <jose_freitas> but everyone has a hard time using git for the first time
[20:10:52] <jose_freitas> everyone was used to svn and cvs
[20:10:55] <jose_freitas> hehehe
[20:11:00] <ssachtleben> :D
[20:11:14] *** lincolnthree has joined #seam-dev
[20:12:17] *** lincolnthree has left #seam-dev
[20:12:58] <ssachtleben> ok fork means to get a legal copy of source code
[20:13:16] <ssachtleben> but what happens if someone commit a change after I folk?
[20:13:27] <ssachtleben> fork*
[20:13:43] <jose_freitas> well, commit is just local
[20:14:14] <jose_freitas> a push go to the server
[20:14:24] <jose_freitas> and you push to your fork
[20:14:32] <jose_freitas> so you can mess it up the way you want
[20:16:55] <jose_freitas> if someone push a new code after you fork, it wont conflict with your fork
[20:17:02] <jose_freitas> I believe
[20:17:25] <ssachtleben> ok but then my source code different from the head version or? :D
[20:17:39] <ssachtleben> I can just think in svn way at moment lol
[20:17:41] <ssachtleben> oh well
[20:17:48] <jose_freitas> ok
[20:17:56] <jose_freitas> I understand your question
[20:18:01] <jose_freitas> but I cant answer hehehe
[20:18:06] <ssachtleben> hehe
[20:18:10] <jose_freitas> you can clone the original
[20:18:15] <jose_freitas> and push to the fork
[20:18:25] <jose_freitas> if you want to push something
[20:18:39] <jose_freitas> the thing is that if you want to control your version of code
[20:18:48] <jose_freitas> you'll lose track of the codebase
[20:19:13] <jose_freitas> I believe so, maybe someone more experienced can answer it better
[20:19:34] <ssachtleben> mhmm....
[20:21:14] <jose_freitas> but probably everyone has cloned the original, and use the fork to new pushs
[20:22:03] <jose_freitas> while updating the original with another changes
[20:22:14] <jose_freitas> *I have to study that more
[20:22:26] <jose_freitas> one thing you can do, is to create a project
[20:22:31] <jose_freitas> and test it
[20:22:34] <ssachtleben> hehe
[20:22:37] <ssachtleben> yeah I just try that
[20:22:43] <jose_freitas> I have one created
[20:22:47] <ssachtleben> I have forked to the international mdoule
[20:22:54] <jose_freitas> ok]
[20:22:56] <ssachtleben> now I try to clone lol
[20:23:35] *** monkeyden has quit IRC
[20:26:23] <ssachtleben> The authenticity of host 'github.com (207.97.227.239)' can't be established.
[20:26:25] <ssachtleben> mhmm.... ^^
[20:26:39] <jose_freitas> ?
[20:27:10] <ssachtleben> $ git clone git at github dot com:ssachtleben/international.git
[20:27:12] <ssachtleben> Cloning into international...
[20:27:14] <ssachtleben> The authenticity of host 'github.com (207.97.227.239)' can't be established.
[20:27:37] <jose_freitas> hm
[20:28:32] <ssachtleben> Permission denied (publickey).
[20:28:41] <ssachtleben> how to switch to private key?
[20:29:15] <jose_freitas> what protocol are you using at egit?
[20:29:23] <ssachtleben> its not egit
[20:29:30] <ssachtleben> its just git windows tools
[20:29:44] <jose_freitas> ahn, ok
[20:30:24] <jose_freitas> you got the ssh url
[20:30:38] <jose_freitas> try with http
[20:31:22] *** cbrock has joined #seam-dev
[20:31:22] *** cbrock has quit IRC
[20:31:22] *** cbrock has joined #seam-dev
[20:32:39] <ssachtleben> error: Couldn't resolve host 'github.com:ssachtleben' while accessing http://git at github dot com:ssachtleben/international.git/info/refs
[20:33:01] <ssachtleben> awwwww feeling so noobish :S
[20:34:18] <jose_freitas> hm
[20:34:29] <jose_freitas> dont
[20:34:50] <jose_freitas> hehehe. dont bother yourself feeling noobish, it's normal
[20:35:30] <jose_freitas> can you clone the read only (git url) url?
[20:36:24] <ssachtleben> so at least the fingerprint in my git account and git tool is the same
[20:36:31] <ssachtleben> what is the read only url? ^^
[20:38:52] <ssachtleben> aaaaah
[20:39:00] <ssachtleben> found the urls on github
[20:40:21] <ssachtleben> yes it worked with https url
[20:40:28] <jose_freitas> good
[20:40:47] <jose_freitas> =)
[20:44:27] <jose_freitas> sorry, I wasn't clear enough when I asked to try with http
[20:46:34] <ssachtleben> well it was my fault
[20:46:39] <ssachtleben> just open eyes helps alot :D
[20:46:57] <ssachtleben> thanks for your help
[20:47:28] <jose_freitas> np
[20:47:57] <ssachtleben> oh well now I have to download the all jars of the world AGAIN :D
[20:48:06] <ssachtleben> at least it feels so ^^
[20:50:43] <jose_freitas> i believe its not downloading from the internet
[20:50:54] <jose_freitas> is downloading from your m2 repository to the project
[20:51:09] <jose_freitas> if you already have the jars in your m2 of course
[20:51:15] <ssachtleben> I dont have most of the jar files
[20:51:19] <ssachtleben> like docbook and stuff
[20:51:33] <jose_freitas> hmm
[20:51:55] *** kpiwko has quit IRC
[20:58:42] *** daniel_hinojosa has joined #seam-dev
[21:09:53] *** daniel_hinojosa has quit IRC
[21:12:27] <ssachtleben> uh nice debugging works :D
[21:22:54] *** cbrock has quit IRC
[21:42:46] *** bitshuffler has quit IRC
[21:54:32] *** lightguard_jp has joined #seam-dev
[22:01:42] *** rpetruescu has quit IRC
[22:07:57] *** daniel_hinojosa has joined #seam-dev
[22:12:11] *** cbrock has joined #seam-dev
[22:12:11] *** cbrock has quit IRC
[22:12:11] *** cbrock has joined #seam-dev
[22:14:36] *** jose_freitas has quit IRC
[22:28:07] <jbossbot> git [catch] push master aeab8ae.. LightGuard Merge branch 'master' of github.com:seam/catch
[22:28:07] <jbossbot> git [catch] push master d7da443.. LightGuard Fixes SEAMCATCH-45...
[22:28:09] <jbossbot> jira [SEAMCATCH-45] Misc documentation issues [Reopened (Unresolved) Bug, Minor, Jason Porter] https://issues.jboss.org/browse/SEAMCATCH-45
[22:28:09] <jbossbot> git [catch] push master URL: http://github.com/seam/catch/compare/e98b4a7...d7da443
[22:34:05] <ssachtleben> mhmm.... question
[22:34:35] <ssachtleben> if I made a module change whats the best way to test that in another project ?
[22:35:35] <lightguard_jp> Build an example or arquillian test
[22:36:12] <ssachtleben> well I have a project but it uses the jar from the maven dependency not my changed one in eclipse ^^
[22:37:08] <lightguard_jp> ssachtleben: did you check out the source and make the change the built the dep?
[22:37:48] <ssachtleben> uhm I have checked out the module from git
[22:37:53] <ssachtleben> added as project in eclipse
[22:37:58] <lightguard_jp> Okay
[22:38:05] <ssachtleben> changed it and added as project reference to my other project
[22:38:11] <lightguard_jp> You'll need to do a mvn install from the checked out module
[22:38:24] <lightguard_jp> Then change the dep in the other project to be a SNAPSHOT
[22:39:04] <ssachtleben> ah
[22:39:09] <ssachtleben> sounds like a plan :>
[22:40:25] <lightguard_jp> ssachtleben: First time working with maven?
[22:40:49] <ssachtleben> uhm no but first time using my own dependencies ;)
[22:40:56] <lightguard_jp> Ah
[22:41:06] <lightguard_jp> May the force be with you
[22:41:17] <ssachtleben> I use it normally just to handle the dependencies of my projects
[22:41:24] <ssachtleben> thanks :D
[22:42:46] <ssachtleben> lightguard_jp: which project needs to be build?
[22:42:48] <ssachtleben> parent?
[22:43:14] <lightguard_jp> Just the one you changed
[22:43:18] <ssachtleben> ah ok
[22:43:21] <lightguard_jp> mvn clean install
[22:44:43] <ssachtleben> awwwwww download the whole internet again :D
[22:44:51] <lightguard_jp> figures
[22:44:53] <ssachtleben> ok thanks seems to work
[22:45:20] <lightguard_jp> np
[22:47:55] *** jose_freitas has joined #seam-dev
[22:57:17] *** jose_freitas has quit IRC
[22:57:39] <ssachtleben> damn
[22:57:50] <ssachtleben> fixed one bug but produced another one xD
[22:58:02] <ssachtleben> thought that its not that easy ^^
[22:58:08] <lightguard_jp> :(
[22:58:22] <lightguard_jp> Which module are you working on?
[22:58:55] <ssachtleben> trying to get the available locales working from config xml
[22:59:12] <ssachtleben> SEAMINTL-25
[22:59:13] <jbossbot> jira [SEAMINTL-25] AvailableLocales.locales always has zero elements when configuration follows the documentation [Open (Unresolved) Bug, Major, Ken Finnigan] https://issues.jboss.org/browse/SEAMINTL-25
[22:59:20] <lightguard_jp> Ah
[23:00:12] <ssachtleben> well just to get start and getting deeper into seam for understanding
[23:00:18] <ssachtleben> not sure if I can fix it
[23:09:39] *** lightguard_jp has quit IRC
[23:15:42] *** koentsje has quit IRC
[23:23:55] *** alesj has joined #seam-dev
[23:38:31] *** rpetruescu has joined #seam-dev
[23:58:21] <ssachtleben> org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318 Cannot resolve an ambiguous dependency between [Managed Bean [class org.jboss.seam.international.locale.LocaleConfiguration] with qualifiers [@Any @Default], Managed Bean [class org.jboss.seam.international.locale.LocaleConfiguration] with qualifiers [@Any @Default]]
[23:58:24] <ssachtleben> damn why? :D





top