May 22, 2011 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
May 22, 2011 NOTICE: This channel is no longer actively logged.
[02:21:12] *** kcbabo has joined #jboss-as7[02:21:12] *** ChanServ sets mode: +v kcbabo[02:31:17] *** aslak has quit IRC[02:56:54] <Nihility> Hi[03:27:46] *** miclorb_ has joined #jboss-as7[04:07:01] *** miclorb_ has quit IRC[04:17:14] *** kcbabo has quit IRC[04:53:55] *** sgilda has quit IRC[05:48:13] *** smarlow has quit IRC[09:07:17] *** jfclere has joined #jboss-as7[10:39:33] *** spagop has joined #jboss-as7[10:39:33] *** ChanServ sets mode: +v spagop[10:40:39] *** spagop has quit IRC[10:47:04] *** aslak has joined #jboss-as7[10:47:04] *** ChanServ sets mode: +v aslak[13:16:52] <stuartdouglas> dmlloyd: I just did a clean build of your rebased branch and got no test failures (except for the integration ones that were already failing).[13:17:00] <stuartdouglas> which tests was failing for you?[13:22:44] <stuartdouglas> dmlloyd: you also need my jboss metadata changes from my fork at https://github.com/stuartwdouglas/metadata[13:35:32] *** hardy_ has joined #jboss-as7[13:35:53] *** hardy_ has left #jboss-as7[14:17:25] *** alesj has joined #jboss-as7[14:37:16] *** alesj has quit IRC[15:22:34] *** kcbabo has joined #jboss-as7[15:22:34] *** ChanServ sets mode: +v kcbabo[16:56:38] <bobmcw> dmlloyd: hey, so between Beta3 and recent git, more things went from public to package-protected[16:56:42] <bobmcw> JMSServices, for instance[16:56:53] <bobmcw> am I swimming upstream to get those made public again?[16:57:20] <bobmcw> I'll be happy to fork/pull-request, just wanna know the intention/attitudes towards it[16:58:06] <bobmcw> oddly, JMSServices is full of public members, but the whole class is pkg-protected[16:58:39] <bobmcw> also, fwiw, I preferred the "old" strategy of FooServices.whatever(someArg), instead of FooServices.WHATEVER_BASE.append( someArg )[16:58:47] <bobmcw> just in terms of style[17:03:17] *** jfclere has joined #jboss-as7[17:21:38] <dmlloyd> stuartdouglas: ah okay, then I won't merge until metadata is released[17:22:09] <dmlloyd> bobmcw: no, I think making these services public is the right thing to do[17:22:43] <bobmcw> dmlloyd: what's the solution to my use-case then, where a user's application can cause (implicitly or explicitly) new JMS queues to get deployed?[17:22:57] <dmlloyd> I think what you're doing is right[17:23:11] <bobmcw> copying JMSQueue.java into my source tree?[17:23:16] <bobmcw> and having to keep it in-sync?[17:23:21] <dmlloyd> no, making those classes public[17:23:29] <bobmcw> ah, I mis-read[17:23:34] <dmlloyd> tbh I think most if not all of our subsystem services should be public[17:23:39] <bobmcw> "no, I think..." I took to be negative :)[17:23:41] <dmlloyd> unless there's a security issue[17:23:47] <bobmcw> 'k, awesome![17:23:51] <dmlloyd> and those can be fixed by introducing perm checks[17:24:23] <bobmcw> cool, I'll get pulls to you about JMS* and WebVirtualHost publicitity this week[17:31:58] *** jfclere has quit IRC[17:46:39] *** frainone has joined #jboss-as7[17:46:39] *** ChanServ sets mode: +v frainone[17:46:56] <bobmcw> maven central just die?[18:32:33] <nickarls> and upstream master doesn't compile[18:32:51] <nickarls> DomainServerMan.java cannot access RepositorySelector[18:57:41] *** bobmcw has quit IRC[19:26:38] *** bobmcw has joined #jboss-as7[19:26:38] *** ChanServ sets mode: +v bobmcw[19:31:30] *** kcbabo has quit IRC[20:05:36] *** bobmcw has quit IRC[20:11:24] *** bobmcw has joined #jboss-as7[20:11:24] *** ChanServ sets mode: +v bobmcw[20:21:13] *** kcbabo has joined #jboss-as7[20:21:13] *** ChanServ sets mode: +v kcbabo[20:21:21] *** kcbabo has quit IRC[22:42:37] *** misty has joined #jboss-as7[22:42:50] *** bstansberry has joined #jboss-as7[22:42:50] *** ChanServ sets mode: +v bstansberry[22:43:43] <stuartdouglas> morning[22:46:43] <misty> morning[22:46:46] <bstansberry> howdy[22:46:48] <misty> *yawn*[22:46:51] <bstansberry> lol[22:47:03] <misty> bstansberry: not quite 7am here[22:47:38] <misty> since the world did not end, time to get cracking :)[22:47:45] <stuartdouglas> hehe[22:47:54] <bstansberry> everyone you know accounted for?[22:48:07] <bstansberry> particularly the not-evil ones?[22:48:58] <bstansberry> the following is addressed to no one in particular :)[22:49:11] <bstansberry> our handling in the runtime of a deployment's name vs its runtime-name seems off[22:50:08] <bstansberry> looks like most subsystems are quite reasonably using deploymentUnit.getName() to find the name[22:50:43] <bstansberry> but we're not sticking the runtime-name there, and I think in every case what callers want is the runtime-anem[22:51:27] <stuartdouglas> afaik the ee sub system wants the deployment name[22:51:44] <stuartdouglas> because it needs to do jndi bindings based on the module / app name[22:52:14] <bstansberry> that's the runtime-name[22:52:51] <bstansberry> in the model, say there is a resource at address /deployment=x ...[22:53:23] <bstansberry> "x" can be anything; it's an arbitrary unique name the user gives the deployment[22:53:48] <stuartdouglas> ok, in that case then we are using the wrong name[22:54:24] <bstansberry> yeah, I think that "name" is only relevant in the management layers; the runtime services should not use it[22:55:27] *** ccrouch has left #jboss-as7[23:00:45] <misty> seems like I remember that naming things is one of the two big programming problems of all time. The other one is caching, and also off-by-one errors. :)[23:01:04] <bstansberry> :-)[23:01:30] <misty> oh, and infinite recursion. oh, and infinite recursion. oh, and ....[23:12:39] <bstansberry> AS7-845[23:12:40] <jbossbot> jira [AS7-845] Incorrect handing of name and runtime-name in deployers [Open (Unresolved) Bug, Blocker, Unassigned] https://issues.jboss.org/browse/AS7-845[23:13:04] <bobmcw> bstansberry: I, for one, use unit.getName(), assuming it was 'right' in many cases[23:13:13] <bobmcw> but only recently figured out RUNTIME_NAME was even available[23:13:46] <bobmcw> to encourage usage, a unit.getRuntimeName() would kinda be nice[23:14:07] <stuartdouglas> would it be possible to change the behaviour of getName()?[23:14:14] <bstansberry> the original design intent was "name" vs "runtime-name" was something that would only matter to the management layer[23:14:34] <bstansberry> deployers, subsystems would only see the runtime-name[23:15:01] <bstansberry> i.e. deploymentUnit.getName() would give you the runtime-name[23:15:06] <bobmcw> that'd be nice[23:15:39] <bstansberry> I just need to look at all the usages and see what would break if the original concept was put in place :-)[23:15:51] <bobmcw> btw, rebased torquebox from AS Beta3 to AS-friday-afternoon, and everything seems happy[23:16:13] <bobmcw> a few changes, but nothing very breaky[23:16:33] <stuartdouglas> beta3 does not have the EE refactor merged[23:16:50] <bobmcw> but friday does, right?[23:16:52] <stuartdouglas> rebasing onto upstream will probably be a bit more work :-([23:16:55] <bobmcw> I had ContextNames changes[23:17:33] <bobmcw> we're rebased against current jbossas/jboss-as#master[23:17:34] <bobmcw> https://github.com/jbossas/jboss-as/commit/13ae916bd49f67d77f07baaac965f8e726a3599f[23:17:35] <jbossbot> git [jboss-as] 13ae916.. Darran Lofthouse [AS7-865] Drop the 's' from management-interfaces.[23:17:36] <jbossbot> jira [AS7-865] Drop the 's' from management-interfaces [Open (Unresolved) Task, Major, Darran Lofthouse] https://issues.jboss.org/browse/AS7-865[23:17:53] <stuartdouglas> ok, well in that case you are all good :-)[23:17:55] <bobmcw> is there more in the pipeline I'm missing?[23:18:27] <bobmcw> stuartdouglas: hey, I did have to add this hack[23:18:27] <bobmcw> https://github.com/torquebox/torquebox/blob/as7-snapshot/modules/cdi/src/main/java/org/torquebox/cdi/HackWeldBeanManagerServiceProcessor.java[23:18:39] <bobmcw> else never got BeanManager for my deployments, since we don't endsWith( "war" )[23:18:58] <bobmcw> we also don't have the EEModule stuff[23:19:05] <bobmcw> but we do want a BeanManager deployed[23:19:49] <stuartdouglas> ok, I may have to revisit that code to make your hack unnecessary[23:19:57] <bobmcw> it'd be awesome if y'all's WeldBMSvcProc was a little more flexible[23:20:14] <bobmcw> ie, if no EEModDesc, still do BeanManager, just ignore components[23:20:22] <bobmcw> and perhaps some flag instead of extension-checking on .war[23:20:31] <bobmcw> flag/marker/whatnot[23:20:51] <stuartdouglas> sure, can you file a JIRA and assign to me?[23:20:57] <bobmcw> sure thing![23:25:28] <bobmcw> AS7-866[23:25:30] <jbossbot> jira [AS7-866] WeldBanManagerServiceProcessor is too pick for TorqueBox to integrate with CDI [Open (Unresolved) Enhancement, Major, Stuart Douglas] https://issues.jboss.org/browse/AS7-866[23:41:37] *** jwulf has joined #jboss-as7