Switch to DuckDuckGo Search
   February 28, 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 | >


NOTICE: This channel is no longer actively logged.

Toggle Join/Part | bottom
[00:01:19] *** bstansberry has joined #jboss-as7
[00:01:20] *** ChanServ sets mode: +v bstansberry
[00:02:49] *** wmprice has joined #jboss-as7
[00:11:31] *** miclorb has joined #jboss-as7
[00:18:03] *** stuartdouglas_ has joined #jboss-as7
[00:19:10] <stuartdouglas_> back
[00:21:58] *** bstansberry has quit IRC
[00:22:32] *** bstansberry has joined #jboss-as7
[00:22:33] *** ChanServ sets mode: +v bstansberry
[00:33:13] <dmlloyd> stuartdouglas: am I correct in my understanding that CDI injection can be applied to EE @AroundInvoke and @Pre|PostDestroy interceptor object instances?
[00:34:30] <stuartdouglas_> dmlloyd: yes
[00:36:21] <baileyje> bstansberry: So may plan is to try and turn the FS scanner stuff over to you tomorrow after I get it integrated with your change
[00:37:06] <baileyje> It still doesn't support exploded deployments. Mainly because we haven't tackled how the deployment repository will handle deployment content coming from the deployment dir
[00:37:06] *** bstansberry has quit IRC
[00:37:08] *** bstansberry_ has joined #jboss-as7
[00:37:08] *** bstansberry_ has joined #jboss-as7
[00:37:09] *** ChanServ sets mode: +v bstansberry_
[00:37:15] <bstansberry_> so I have a thumbs up to push that?
[00:37:46] <bstansberry_> baileyje: just noticed I was talking to you in the wrong room :)
[00:38:04] <baileyje> Yeah. It looks good to me. I asked you in the other room if you want me to install and run the tests for your change?
[00:38:27] <baileyje> It looks good, but I am not sure I have time to actually run the commits now
[00:40:08] <bstansberry_> i'm not worried about the tests; i've run them a lot
[00:40:17] *** bstansberry_ is now known as bstansberry
[00:40:20] <baileyje> Yeah. Then I would go ahead
[00:40:29] <bstansberry> k; will do
[00:41:15] <bstansberry> thanks!
[00:41:18] <baileyje> Did you see my messages before you dropped off a bit ago?
[00:41:23] <stuartdouglas_> dmlloyd: According to the CDI spec any component class that supports injection also needs to support CDI injection
[00:44:49] <dmlloyd> okay, that will make this more uniform
[00:49:28] <bstansberry> cool; 12 deer in my backyard right now
[00:54:46] * dmlloyd afk for 60-80 minutes to get kids fed and in bed
[00:56:52] *** laubai has joined #jboss-as7
[00:59:49] <Nihility> bstansberry: That would be a very large deer jerky supply
[01:00:08] <bstansberry> yeah' i'd need another freezer
[01:00:55] * Nihility is on his phone bbl
[01:02:46] *** jpearlin has quit IRC
[01:18:22] <jbossbot> git [jboss-as] push master acc10c1.. bstansberry at jboss dot com [JBAS-8906] Move rollback handling into controller...
[01:18:24] <jbossbot> jira [JBAS-8906] Service in START_FAILED state does not transition when mode is changed to REMOVE [Reopened (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/JBAS-8906
[01:18:24] <jbossbot> git [jboss-as] push master c0d6269.. bstansberry at jboss dot com ModelController should not throw OperationFailedException
[01:18:24] <jbossbot> git [jboss-as] push master 60a6a6d.. bstansberry at jboss dot com Output full details when composite ops fail...
[01:18:24] <jbossbot> git [jboss-as] push master 63046a5.. bstansberry at jboss dot com When replace calls into deploy, it needs to provide the runtime context, not the OperationContext
[01:18:24] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/f232102...63046a5
[01:29:33] *** bstansberry is now known as bstans_afk
[01:31:11] *** stuartdouglas_ has quit IRC
[01:46:09] *** miclorb has quit IRC
[02:08:17] * dmlloyd is back
[02:15:55] *** bobmcw has quit IRC
[02:16:03] *** bobmcw has joined #jboss-as7
[02:16:03] *** ChanServ sets mode: +v bobmcw
[02:32:47] *** bstans_afk is now known as bstansberry
[02:41:53] *** bgeorges has joined #jboss-as7
[02:41:53] *** ChanServ sets mode: +v bgeorges
[02:51:59] *** miclorb_ has joined #jboss-as7
[03:05:30] *** wmprice has quit IRC
[03:12:04] *** miclorb_ has quit IRC
[03:14:09] <dmlloyd> man
[03:14:28] <dmlloyd> I am absolutely certain I added static util methods that generate a service name for a JNDI context
[03:14:37] <dmlloyd> can't find em though
[03:15:12] <dmlloyd> ah nm, found it
[03:15:18] <dmlloyd> it was in the EE subsystem, not naming...
[03:15:44] <bobmcw> well, that makes sense
[03:17:51] *** bstansberry has quit IRC
[03:18:11] *** bstansberry has joined #jboss-as7
[03:18:11] *** ChanServ sets mode: +v bstansberry
[03:42:56] *** wmprice has joined #jboss-as7
[03:57:55] *** miclorb has joined #jboss-as7
[04:12:11] *** bstansberry_ has joined #jboss-as7
[04:12:11] *** bstansberry_ has joined #jboss-as7
[04:12:11] *** ChanServ sets mode: +v bstansberry_
[04:12:11] *** bstansberry has quit IRC
[04:12:11] *** bstansberry_ is now known as bstansberry
[04:17:19] *** pgier has joined #jboss-as7
[04:17:19] *** ChanServ sets mode: +v pgier
[05:02:11] *** bstansberry_ has joined #jboss-as7
[05:02:11] *** ChanServ sets mode: +v bstansberry_
[05:02:11] *** bstansberry has quit IRC
[05:02:11] *** bstansberry_ is now known as bstansberry
[05:12:18] *** wmprice has quit IRC
[05:58:02] *** bstansberry has quit IRC
[06:11:35] *** baileyje has quit IRC
[06:12:07] *** baileyje has joined #jboss-as7
[06:12:07] *** ChanServ sets mode: +v baileyje
[06:12:55] <baileyje> wow, it was my turn for a hard crash
[06:13:08] *** pferraro has joined #jboss-as7
[06:13:09] *** ChanServ sets mode: +v pferraro
[06:14:05] *** pferraro has quit IRC
[07:28:41] <nickarls> Going to be a lot of releases today since Beta1 is scheduled and Alpha2 isn't released yet! ;-)
[08:07:26] *** miclorb has quit IRC
[08:12:31] *** opalka has joined #jboss-as7
[08:12:31] *** opalka has joined #jboss-as7
[08:12:31] *** ChanServ sets mode: +v opalka
[08:28:12] *** bgeorges has quit IRC
[09:08:24] *** pilhuhn has joined #jboss-as7
[09:08:24] *** pilhuhn has joined #jboss-as7
[09:08:24] *** ChanServ sets mode: +v pilhuhn
[09:17:01] *** maeste has joined #jboss-as7
[09:17:02] *** ChanServ sets mode: +v maeste
[09:22:50] *** emuckenhuber has joined #jboss-as7
[09:22:50] *** emuckenhuber has joined #jboss-as7
[09:22:50] *** ChanServ sets mode: +v emuckenhuber
[09:50:32] *** rmaucher has joined #jboss-as7
[10:11:06] *** emuckenhuber has quit IRC
[10:31:51] *** emuckenhuber has joined #jboss-as7
[10:31:51] *** ChanServ sets mode: +v emuckenhuber
[10:33:41] *** jhalliday has joined #jboss-as7
[10:40:46] *** kkhan has joined #jboss-as7
[10:40:47] *** ChanServ sets mode: +v kkhan
[10:54:32] *** alesj has joined #jboss-as7
[10:57:27] *** asoldano has joined #jboss-as7
[10:57:27] *** ChanServ sets mode: +v asoldano
[11:01:03] *** opalka is now known as opalka_lunch
[11:08:20] *** jcosta has joined #jboss-as7
[11:08:20] *** ChanServ sets mode: +v jcosta
[11:30:05] *** wolfc has joined #jboss-as7
[11:30:05] *** ChanServ sets mode: +v wolfc
[11:46:36] *** torben has joined #jboss-as7
[11:46:37] *** torben has joined #jboss-as7
[11:46:37] *** ChanServ sets mode: +v torben
[12:13:36] *** jwulf has quit IRC
[12:21:49] *** darranl has joined #jboss-as7
[12:21:50] *** darranl has joined #jboss-as7
[12:21:50] *** ChanServ sets mode: +v darranl
[12:31:52] *** asoldano is now known as asoldano_lunch
[12:35:00] *** darranl has quit IRC
[12:36:25] *** darranl has joined #jboss-as7
[12:36:26] *** darranl has joined #jboss-as7
[12:36:26] *** ChanServ sets mode: +v darranl
[12:55:30] <wolfc> dmlloyd, I'm picking the first position on the queue :-)
[13:07:05] *** opalka_lunch is now known as opalka
[13:13:19] *** mmoyses has joined #jboss-as7
[13:13:19] *** ChanServ sets mode: +v mmoyses
[13:29:28] *** asoldano_lunch is now known as asoldano
[13:29:33] <asoldano> wolfc, lol
[13:31:02] *** emmanuel has joined #jboss-as7
[13:31:02] *** ChanServ sets mode: +v emmanuel
[13:37:28] *** stansilvert has joined #jboss-as7
[13:48:50] *** emmanuel has quit IRC
[13:56:28] *** frainone has joined #jboss-as7
[13:56:28] *** ChanServ sets mode: +v frainone
[14:02:13] <opalka> dmlloyd, I'm picking the second position on the queue :-)
[14:04:02] * jhalliday pays some random bloke to stand in the queue for him and goes down the pub instead
[14:14:02] <wolfc> how much? since I stand a 50% chance of getting some money. :-)
[14:14:36] *** emmanuel has joined #jboss-as7
[14:14:37] *** ChanServ sets mode: +v emmanuel
[14:18:01] <jhalliday> I'll bring you back a bag of crisps from the pub. It's not like you're doing any extra work really :-)
[14:28:18] <nickarls> http://www.oreillymaker.com/link/39728/coding-drunk/
[14:28:42] *** jpederse has joined #jboss-as7
[14:28:51] *** jpederse has joined #jboss-as7
[14:31:42] *** aloubyansky has joined #jboss-as7
[14:38:09] *** bgeorges has joined #jboss-as7
[14:47:09] <alesj> nickarls: the book title should mention Bacos ;-)
[14:48:45] <baileyje> dmlloyd: I'll take the second position.
[15:08:00] <dmlloyd> wolfc, opalka, baileyje ok let me have it :)
[15:08:36] <wolfc> dmlloyd, how are you faring on the EE component?
[15:08:44] <wolfc> what can I do to help out?
[15:09:15] <dmlloyd> well it doesn't compile yet, unfortunately, and last night I got stuck on a technical detail
[15:09:21] <dmlloyd> but the form of the API is there
[15:09:38] <dmlloyd> I can push it out if you want to look it over
[15:09:57] <dmlloyd> http://github.com/dmlloyd/jboss-as/tree/ee
[15:11:12] <dmlloyd> I want to get it finished this morning so that baileyje can give me a hand with getting it working
[15:11:49] <wolfc> I saw some commits going back and forth on getInstance. It is going to be handled by a system interceptor, not?
[15:13:15] <dmlloyd> you mean on JndiInjectable?
[15:13:26] <dmlloyd> that deals with proxy instances in most cases
[15:13:38] <dmlloyd> from the perspective of an injectee, you're only ever dealing with proxies
[15:14:16] <dmlloyd> excepting of course java:comp/ORB and stuff like that
[15:14:21] <wolfc> https://github.com/dmlloyd/jboss-as/commit/a3b8fdf0d0bfd9c218394a6b787291339f99c5dc#L2L32
[15:14:21] <jbossbot> git [jboss-as] a3b8fdf.. David M. Lloyd temp
[15:14:52] <dmlloyd> yeah that was in the wrong place
[15:15:37] <dmlloyd> you're much better off judging: https://github.com/dmlloyd/jboss-as/compare/jbossas:master...ee
[15:15:58] <dmlloyd> though like I said it's not yet complete
[15:18:50] <wolfc> So what's is wisdom at this stage?
[15:19:21] <dmlloyd> EEModuleDescription is attached to the DU, it contains a complete list of every component
[15:19:45] <dmlloyd> ComponentDescription is abstract; each component type extends it with component-specific stuff
[15:20:16] <dmlloyd> view bindings and resource injections are all added to a list as well
[15:20:24] <dmlloyd> for each component
[15:20:50] <dmlloyd> JNDI is reworked so that every entry in java: has a corresponding Service<JndiInjectable> at a predictable location
[15:21:04] <dmlloyd> that includes env entries for field and method bindings
[15:21:58] <dmlloyd> when the Component is created, the ComponentDescription is transformed into a ComponentConfiguration which contains the actual runtime info, and that is passed into the AbstractComponent constructor
[15:22:15] <dmlloyd> so the logic that was in AbstractComponent's constructor is shifted out
[15:22:41] <dmlloyd> also, this week stuartdouglas is going to convert servlets to be components as well
[15:22:52] <dmlloyd> and hopefully also hook in CDI
[15:23:11] <dmlloyd> from the perspective of EJB, not much should actually change (I hope), mostly it'll just be shuffling things around
[15:23:55] <wolfc> that would be cool. Jaikiran should be ready soon with annotation scanning and I want to put proper Pool and Cache implementations in place.
[15:24:05] <wolfc> Will we have EE injection?
[15:25:05] <dmlloyd> we will have full EE injection of everything this week
[15:25:07] <dmlloyd> afaik
[15:25:17] <dmlloyd> today, hopefully
[15:26:10] <wolfc> Excellent, then we can start running TCK tests.
[15:28:05] <alesj> and we might even pass CDI TCK … :-)
[15:28:21] <dmlloyd> just having a little problem around uninjection
[15:28:38] <wolfc> alesj, we don't have enough EJB yet in master
[15:28:57] <alesj> damn … :-)
[15:31:28] *** pferraro has joined #jboss-as7
[15:31:28] *** ChanServ sets mode: +v pferraro
[15:32:32] *** kkhan has quit IRC
[15:38:39] *** emmanuel has quit IRC
[15:44:54] *** epbernard has joined #jboss-as7
[15:44:54] *** epbernard is now known as emmanuel
[15:44:54] *** ChanServ sets mode: +v emmanuel
[15:48:36] *** smarlow has joined #jboss-as7
[15:48:37] *** ChanServ sets mode: +v smarlow
[15:52:28] *** darranl is now known as darranl_afk
[15:55:11] *** emmanuel has quit IRC
[15:57:14] *** bgeorges has quit IRC
[15:58:34] <dmlloyd> baileyje / opalka ?
[15:58:53] <baileyje> dmlloyd: Mine was basically the same as wolfc. How is it going, and how can I help
[15:59:27] *** bgeorges has joined #jboss-as7
[15:59:33] <dmlloyd> baileyje, I ran into an interesting dilemma
[15:59:41] <baileyje> yeah?
[15:59:45] <dmlloyd> bridging between JndiInjectable and ResourceInjection
[16:00:02] <dmlloyd> the problem is, when it comes 'round time to uninject, I no longer have any idea what value I injected in the first place
[16:00:20] *** mbg has joined #jboss-as7
[16:00:20] *** ChanServ sets mode: +v mbg
[16:00:23] <dmlloyd> so I changed ResourceINjection to have inject() return a handle with an uninject method on it
[16:00:39] <baileyje> dmlloyd: Ok. Makes sense. Does it work?
[16:00:49] <wolfc> Uninject is not allowed by spec
[16:00:50] <dmlloyd> so for it seems OK but I haven't gotten through everything yet
[16:01:08] <dmlloyd> oh really?
[16:01:16] <wolfc> Yeah, ran into interesting problems
[16:01:39] <dmlloyd> what about bounding the lifecycle of things that are injected by the lifecycle of what they are injected into?
[16:01:40] <wolfc> @Resource void setVar(Object var) { if(var == null) throw new IllegalArgumentException(); this.var = var); }
[16:01:48] <dmlloyd> interesting
[16:01:53] <dmlloyd> so maybe it's not even a problem after all...
[16:02:01] <opalka> dmlloyd, wanted to discuss with U the following commit - https://github.com/ropalka/jboss-as/commit/780704a7991718b737560e30259862abb80ef3c5
[16:02:02] <jbossbot> git [jboss-as] 780704a.. Richard Opalka some cleanup of new aggregation module + applied applyCXF... to make it work for now
[16:02:21] <opalka> dmlloyd, i have this dependencies wrapper module.xml - https://github.com/ropalka/jboss-as/blob/wsintegration/build/src/main/resources/modules/org/jboss/as/webservices/server/integration/main/module.xml
[16:02:37] *** bstansberry has joined #jboss-as7
[16:02:37] *** ChanServ sets mode: +v bstansberry
[16:02:37] <opalka> dmlloyd, and I have to do this hack to make it work - https://github.com/ropalka/jboss-as/blob/wsintegration/webservices/server-integration/src/main/java/org/jboss/as/webservices/deployers/WSDependenciesProcessor.java
[16:02:48] <opalka> dmlloyd, method applyCXFExtensionImportFilters
[16:02:55] <wolfc> dmlloyd, also not possible: @Stateful { MyMBean get() { return bean; } }
[16:03:15] <wolfc> And voila I exposed something outside of my lifecycle
[16:03:34] <dmlloyd> sure but you already have the same problem if you get at something after it's @PreDestroy was called
[16:03:48] *** mmoyses is now known as mmoyses_
[16:04:10] <wolfc> For EJB that only happens after @Remove :-) (and timeouts)
[16:04:28] <wolfc> But why not depend on gc?
[16:05:09] <dmlloyd> if, say, a SFSB injects a SFSB, doesn't the second SFSB's lifecycle depend on the first?
[16:05:14] <wolfc> no
[16:05:56] <wolfc> We ran into a shitload of trouble when we had that on AS 4.
[16:06:02] *** ccrouch has joined #jboss-as7
[16:06:02] *** ChanServ sets mode: +v ccrouch
[16:06:08] <dmlloyd> hm, interesting
[16:06:27] <wolfc> basically every EE component has a life of its own
[16:06:46] <Nihility> imo the two-phase model solves alot of this
[16:07:05] <wolfc> two-phase model?
[16:07:21] <Nihility> from a correctness perspective we really dont want a an ejb to get a request when its dep hasnt yet started right?
[16:07:33] <baileyje> bstansberry: Time for a question or two?
[16:07:43] <bstansberry> sure
[16:07:50] <dmlloyd> Nihility: it has nothing to do with deps
[16:08:00] <dmlloyd> that problem is solved already
[16:08:11] <baileyje> bstansberry: I will PM you to get not get too much noise in here
[16:08:13] <dmlloyd> the question is if A injects B, when A is destroyed, is B destroyed?
[16:08:18] <bstansberry> k
[16:08:19] <Nihility> ah i thought thats what you meant by "econd SFSB's lifecycle depend on the first"
[16:09:19] <Nihility> dmlloyd: that sounds backwards
[16:09:38] *** balunasj has joined #jboss-as7
[16:09:39] *** balunasj has joined #jboss-as7
[16:09:39] *** ChanServ sets mode: +v balunasj
[16:09:39] <Nihility> you mean A has @EJB("B")
[16:10:03] <Nihility> when A is gone B certainly should not go
[16:10:09] <jpederse> Nihility: call ?
[16:10:47] * opalka gotta go. Will be online later today ...
[16:11:00] <dmlloyd> here's another angle on it: if A injects B and they are both SFSBs, when A is destroyed does B get repooled, or must be be explicitly repooled
[16:11:21] *** opalka has quit IRC
[16:14:34] <dmlloyd> or are SFSBs not pooled
[16:23:17] <wolfc> SFSBs are cached
[16:23:26] <wolfc> which is basically the same thing, but with a key :-)
[16:24:14] <dmlloyd> so in this case will both SFSBs belong to the same session ID?
[16:24:23] <wolfc> no, each has its own
[16:24:30] <wolfc> they can even be separately passivated
[16:24:45] *** balunasj is now known as balunasj_busy
[16:25:24] <dmlloyd> so from what you can see, there is basically no situation in which an injected resource can ever be implicitly destroyed, repooled, or uninjected in any way?
[16:25:45] *** frainone has quit IRC
[16:26:13] <dmlloyd> if I were to remove this code it would make things much simpler but I'm sort of afraid of painting myself in to a corner by doing so
[16:27:13] <wolfc> I would stick to an independent lifecycle
[16:27:32] *** darranl_afk is now known as darranl
[16:27:32] <wolfc> But what is the underlying need to get a mbean properly removed?
[16:28:03] <wolfc> besides being neat and correct :-)
[16:28:05] <dmlloyd> when I was reading the spec this weekend it seemed implied, but I may have misread
[16:32:39] *** kkhan has joined #jboss-as7
[16:32:39] *** ChanServ sets mode: +v kkhan
[16:35:38] *** epbernard has joined #jboss-as7
[16:35:38] *** epbernard is now known as emmanuel
[16:35:38] *** ChanServ sets mode: +v emmanuel
[16:36:20] *** AndyTaylor has quit IRC
[16:38:49] *** smcgowan has joined #jboss-as7
[16:38:49] *** ChanServ sets mode: +v smcgowan
[16:40:31] <wolfc> if you can find that part, maybe we missed something
[16:40:47] *** AndyTaylor has joined #jboss-as7
[16:40:47] *** ChanServ sets mode: +v AndyTaylor
[16:41:38] *** ALR has joined #jboss-as7
[16:41:38] *** ChanServ sets mode: +v ALR
[16:42:24] <dmlloyd> well it just says "Similarly, for classes whose lifecycle is managed by the container, the @PreDestroy annotation (or, equivalently, the pre-destroy entry of a deployment descriptor) may be applied to one method that will be called when the class is taken out of service and will no longer be used by the container."
[16:42:52] <dmlloyd> it seems to me that injections are managed by the container, but the wording isn't what I'd call precise
[16:43:22] <dmlloyd> that's in EE.5.2.5
[16:44:17] <emuckenhuber> bstansberry: hmm, are composite operations on the domain supposed to work already?
[16:44:35] <kkhan> bstansberry: A few commits at https://github.com/kabir/jboss-as/commits/domain-op. https://github.com/kabir/jboss-as/commit/8c3848ae889754bf0f456d9bfe055eb8d4fc6d03 and https://github.com/kabir/jboss-as/commit/973365c4a2be324214d36b9061577ea401f29a69. You might want to see if the "Register host controllers..." one clashes with your intent
[16:44:35] <jbossbot> git [jboss-as] 8c3848a.. kabir Get rid of ModelControllerClient.Type
[16:44:36] <jbossbot> git [jboss-as] 973365c.. kabir Register host controllers in the proxy registry and fix test
[16:44:39] *** emmanuel has quit IRC
[16:45:47] <bstansberry> emuckenhuber: no
[16:47:21] <kkhan> bstansberry: Do you have anything you would like me to look at?
[16:47:42] <bstansberry> kkhan: the idea was a DomainModel would only have a reference to the HostModel running inside the same VM
[16:47:53] <wolfc> dmlloyd, it doesn't say anything that allows for uninjection or ties lifecycles of components together. In fact you could inject SFSB A into SFSB B, then remove A. It would make using A from B impossible (NoSuchEJBException), but it's theocratically possible.
[16:47:58] <maeste> Nihility: ping
[16:48:39] <bstansberry> the DomainController is responsible for proxying requests addressed directly to other hosts
[16:48:56] <kkhan> bstansberry: ok, it all seemed to work fine when running the actual AS but something was going wrong in the RemoteDomainControllerTestCase
[16:49:04] <kkhan> I think I might just delete that test
[16:49:22] <kkhan> or maybe not
[16:50:03] *** pmuir has joined #jboss-as7
[16:50:03] *** ChanServ sets mode: +v pmuir
[16:50:21] <kkhan> bstansberry: So are you basically saying that the last commit should only register the proxy if we are in master mode?
[16:50:25] <kkhan> Or something else
[16:51:10] <kkhan> missed your second comment
[16:51:20] <dmlloyd> wolfc, okay, if you're sure of that, and we're sure that the managed beans TCK isn't going to check for @PreDestroy when the injecting instance is destroyed, then I will remove all support for it
[16:51:26] <bstansberry> kkhan: looking at the patch, it seems like it was already doing what it was supposed to do
[16:51:28] <dmlloyd> which will simplify this code quite a lot
[16:51:46] <bstansberry> DomainControllerImpl knows how to talk to everyone
[16:52:03] <bstansberry> DomainModel knows how to talk to its local host model
[16:52:08] <wolfc> I think we can safely rely on the gc. If people start to expose their MBs they are on their own.
[16:52:51] <wolfc> dmlloyd, although we ourselves might want it somewhat differently
[16:53:20] <dmlloyd> another option is, I can keep full support for uninjection but just not use it for standard components
[16:53:22] <wolfc> If I have a Pool/Cache that is a 'MB' I want to have it properly destroyed once the governing Component itself goes down.
[16:53:34] <dmlloyd> in case those lunatics on the EG specify it more specifically
[16:54:28] <wolfc> uninjection I think will never happen, but tying it to another lifecycle might (and happens in CDI)
[16:54:56] <wolfc> pmuir, ping
[16:55:27] <pmuir> wolfc: pong
[16:55:41] <wolfc> In CDI does a ManagedBean have a PreDestroy facility?
[16:57:22] <wolfc> Hmm, it's not really a sensible question :-)
[16:57:39] <pmuir> yes
[16:57:53] <wolfc> yes to which part? :-)
[16:58:13] <pmuir> managed beans have @PreDestroy
[16:58:15] <wolfc> It's a JSF MB then, not?
[16:58:43] <pmuir> huh?
[16:59:02] <wolfc> Okay, never mind that
[16:59:34] <wolfc> pmuir, a @Named? not @ManagedBean, right?
[17:00:28] <pmuir> yes, CDI has relatively little do with @ManagedBean
[17:00:37] <pmuir> it doesn't have to be @Named
[17:00:47] <pmuir> just any managed bean, can have a EL name or not
[17:01:26] <wolfc> "Any managed bean instance obtained via the dependency injection service is a contextual instance. It is bound to a life-cycle context and is available to other objects that execute in that context. The container automatically creates the instance when it is needed by a client. When the context ends, the container automatically destroys the instance."
[17:01:43] <wolfc> pmuir, ah I think I found the bit
[17:01:57] <pmuir> yes
[17:02:24] <pmuir> as CDI gives everything a specific lifecycle (or it is dependent) then it's possible to have anb ex
[17:02:30] <pmuir> an explict destroy
[17:02:53] <wolfc> dmlloyd, did you get that? If it is scoped, it has a lifecycle.
[17:03:34] <wolfc> but scopes are outside of the EJB scope
[17:05:28] *** pilhuhn is now known as pil-bbl-afk
[17:08:50] *** emuckenhuber has quit IRC
[17:09:40] *** balunasj_busy has quit IRC
[17:11:19] <Nihility> ah uninjection
[17:11:26] <Nihility> thats what you were referring to
[17:12:30] <Nihility> i think any kind of automatic remove() propogation would confuse people and be dangerous
[17:12:55] *** mmoyses_ is now known as mmoyses
[17:13:05] <wolfc> I see uninjection and lifecycle as two separate things.
[17:13:21] <wolfc> Well, no uninjection => no tied lifecycle :-)
[17:13:28] <Nihility> uninjection would be ok potentially but there is thread safety contract issues
[17:13:55] <wolfc> unjection can't work because of: @Resource void setVar(Object var) { if(var == null) throw new IllegalArgumentException(); this.var = var); }
[17:13:59] <Nihility> in away its already supported by the proxy throwing an exception
[17:14:26] <Nihility> right it would potentially break old code
[17:14:34] <Nihility> you would have to have some kind of even feature
[17:14:46] <Nihility> where the container told the bean "A" just went away
[17:14:57] <Nihility> even = event
[17:15:18] <Nihility> which has thread timing problems
[17:15:36] <Nihility> because you cant deliver the event until an ejb method on the instance is not executing
[17:15:42] <Nihility> which may be too late
[17:15:59] <Nihility> best solution is that the ejb be developed to handle it going away
[17:16:11] <Nihility> catch (NoSuchEjbExcetion e) { recover }
[17:17:00] <Nihility> (recover is probably let this instance die)
[17:17:42] <wolfc> = not catching NoSuchEJBException
[17:17:54] <Nihility> right
[17:18:16] <wolfc> but dmlloyd wants to have such EJB features on MBs ;-)
[17:18:23] <maeste> Nihility: ping
[17:18:28] <Nihility> maeste: hi
[17:18:36] * wolfc is running away for food
[17:18:48] <maeste> Nihility: hi, have you seen my reply
[17:19:49] <Nihility> yes i did
[17:20:03] <Nihility> osgi is trying to redo their patch anyway
[17:20:07] <Nihility> so disabling it should be ok
[17:20:32] <maeste> Nihility: yep,but smoke tests fail with osgi disabled
[17:21:20] <maeste> Nihility: or do you mean that who need should disable it atm, waiting for patch?
[17:21:39] <Nihility> well are the tests that are failing osgi tests?
[17:24:20] <maeste> Nihility: no, ManaedBean and ServiceLoader
[17:24:42] <Nihility> ok those sytems whould not be affected by osgi
[17:25:07] <Nihility> s/would/should
[17:25:15] <maeste> Nihility: but I'm sure is just enabling/disabling osgi that results changes
[17:25:47] <Nihility> hmm maybe the deployers call into osgi to check if its an osgi deployment
[17:25:50] <maeste> Nihility: in master too
[17:27:53] *** balunasj has joined #jboss-as7
[17:27:53] *** balunasj has joined #jboss-as7
[17:27:53] *** ChanServ sets mode: +v balunasj
[17:28:19] <maeste> Nihility: anyway if you want I can re-enable it and rebase
[17:28:26] *** balunasj is now known as balunasj_busy
[17:28:43] <maeste> Nihility: to have it pushed and get smarlow something to play with
[17:28:44] <dmlloyd> seems like the logical next step
[17:29:08] <maeste> dmlloyd: yep it seems to me to
[17:29:11] <maeste> doing
[17:30:36] <Nihility> we certainly need to fix that osgi issue
[17:30:47] <Nihility> removing the osgi subsystem should not break managedbeans
[17:34:39] *** asoldano is now known as asoldano_afk
[17:35:03] <maeste> Nihility: oki, re-enabled osgi and rebased against last upstream/master
[17:35:24] <maeste> Nihility: same branch of pull request email
[17:39:12] <Nihility> ok sec
[17:42:02] *** asoldano_afk is now known as asoldano
[17:52:05] <jbossbot> git [jboss-as] push master 4189bc6.. Stefano Maestri Fixing problems reported form smarlow's tests and JBAS-8892. Implementing a generic JndiService for deployed connectionFactory and AdminObjec dependency injection (JBAS-8709). Enabling also JDBC-DEPLOYER
[17:52:06] <jbossbot> jira [JBAS-8892] Error during deployment of null while deploying JDBC data source [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8892
[17:52:07] <jbossbot> jira [JBAS-8709] Create a service for each resource adapter [Open (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/JBAS-8709
[17:52:07] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/63046a5...4189bc6
[17:52:10] <Nihility> maeste: thanks
[17:53:24] <smarlow> maeste, Nihility: thanks guys! :)
[17:56:10] <maeste> smarlow: have you read about osgi?
[17:56:33] <smarlow> maeste: no, is that about the classloader problem?
[17:56:42] <maeste> smarlow: in pushed branch is enabled, but our deployers/service don't start properly with osgi enabled
[17:56:53] <maeste> smarlow: just comment it out from standalone.xml
[17:57:10] <maeste> smarlow: until osgi's team fixed it
[17:57:13] <smarlow> maeste: cool, sounds like a good workaround, thanks! :)
[17:57:31] <alesj> maeste: what does osgi introduce that breaks your stuff?
[17:58:27] *** emuckenhuber has joined #jboss-as7
[17:58:28] *** emuckenhuber has joined #jboss-as7
[17:58:28] *** ChanServ sets mode: +v emuckenhuber
[17:58:28] <maeste> alesj: something in deployer. In fact it results in null module if I well remember the effect. let me have a look to a sent mail
[17:59:25] *** frainone has joined #jboss-as7
[17:59:25] *** ChanServ sets mode: +v frainone
[17:59:37] <dmlloyd> yeah basically they create their own module completely independently
[18:01:08] <maeste> alesj: yep that is
[18:01:18] <maeste> alesj: ah ok dmlloyd already answered you
[18:01:18] *** asoldano is now known as asoldano_afk
[18:01:50] *** maeste is now known as maeste_away
[18:02:36] *** jcosta has quit IRC
[18:04:30] <dmlloyd> the fix is to merge the module create path
[18:04:44] <dmlloyd> come up with some consistent rules that let both OSGi semantics and EE/modular semantics coexist
[18:05:05] <dmlloyd> it's a broader problem - basically any EE deployment that also includes OSGi manifest properties will fail
[18:05:44] <Nihility> ohhhh
[18:05:54] <Nihility> oh no wait
[18:05:58] <Nihility> thats a separate issue
[18:06:02] <Nihility> we have too issues
[18:06:12] <Nihility> 1) disabled osgi = no managed beans
[18:06:43] <dmlloyd> that one might be an issue for stuartdouglas to look at
[18:06:49] <dmlloyd> I bet it relates to manifest processing
[18:07:04] <Nihility> i think its because there is a line in there that says
[18:07:13] <Nihility> (is this an osgi deployment?"
[18:07:25] <Nihility> that calls into the osgi subsystem
[18:30:27] *** asoldano_afk is now known as asoldano
[18:40:23] *** alesj has quit IRC
[18:46:08] <Nihility> has anyone seen jaxp classloading issues
[18:46:18] <Nihility> in upstream
[18:46:19] <Nihility> ?
[18:56:41] *** torben has quit IRC
[19:08:09] * dmlloyd back
[19:16:13] *** darranl is now known as darranl_afk
[19:17:48] *** ALR has left #jboss-as7
[19:18:11] *** ALR has joined #jboss-as7
[19:18:11] *** ChanServ sets mode: +v ALR
[19:20:22] *** asoldano is now known as asoldano_dinner
[19:26:53] *** mbg is now known as mbg|away
[19:36:40] *** ccrouch has quit IRC
[19:39:57] *** alesj has joined #jboss-as7
[19:59:15] *** AndyTaylor has quit IRC
[20:03:37] <dmlloyd> stansilvert: are JSF managed beans expected to participate in EE injection as EE managed beans?
[20:03:52] *** AndyTaylor has joined #jboss-as7
[20:03:52] *** ChanServ sets mode: +v AndyTaylor
[20:12:06] *** kkhan has quit IRC
[20:12:57] *** ccrouch has joined #jboss-as7
[20:12:57] *** ChanServ sets mode: +v ccrouch
[20:27:20] *** pil-bbl-afk is now known as pilhuhn
[20:29:00] *** AndyTaylor has quit IRC
[20:32:31] *** mbg|away is now known as mbg
[20:37:41] *** bgeorges_ has joined #jboss-as7
[20:39:09] <rmaucher> I believe JSF beans are going through the Servlet container instance manager, so the injection is the same as for servlets
[20:40:07] *** bgeorges has quit IRC
[20:40:53] *** asaldhan has joined #jboss-as7
[20:40:54] *** ChanServ sets mode: +v asaldhan
[20:55:02] *** smarlow has quit IRC
[20:56:23] *** smarlow has joined #jboss-as7
[20:56:24] *** ChanServ sets mode: +v smarlow
[21:05:10] *** smcgowan has quit IRC
[21:14:38] *** opalka has joined #jboss-as7
[21:14:39] *** opalka has joined #jboss-as7
[21:14:39] *** ChanServ sets mode: +v opalka
[21:21:46] * stuartdouglas slowly wakes up
[21:27:05] *** pmuir has quit IRC
[21:41:07] <stansilvert> dmlloyd: Yes, but I don't see that javax.annotation.ManagedBean is really used/needed.
[21:41:30] <stansilvert> dmlloyd: I've verified the @PreDestroy and @PostConstruct are working.
[21:42:25] <stansilvert> dmlloyd: The others in the JSF spec like @Resource and @EJB probably aren't working yet.
[21:42:29] <stuartdouglas> I was always under the impression that JSF 2.0 managed beans were extensions of managed beans as defined by the managed bean spec, but the JSF spec does not really reference the managed bean spec at all
[21:43:16] <stansilvert> dmlloyd: Some JSR-250 annotations won't be required until JSF 2.2 http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-495
[21:43:59] <stansilvert> Not directly. You can see what there is in section 5.4.
[21:44:32] <stansilvert> This all works in AS6 but we don't yet set an injection provider in AS7.
[21:44:49] <stansilvert> But there might be some magic going on. I haven't tried it out yet.
[21:49:57] *** pilhuhn has quit IRC
[21:57:28] *** asoldano_dinner has quit IRC
[21:59:34] <smarlow> Do we have any examples of how an injector could magically discover the DeploymentUnit for the class that is being injected into?
[22:06:15] <stuartdouglas> Is anyone looking at the test failures when osgi is disabled? If not I will take it
[22:06:18] *** smcgowan has joined #jboss-as7
[22:06:18] *** ChanServ sets mode: +v smcgowan
[22:07:49] <dmlloyd> stuartdouglas: go for it
[22:10:35] *** mmoyses has quit IRC
[22:16:51] *** jpederse has quit IRC
[22:22:10] *** miclorb has joined #jboss-as7
[22:31:59] <jbossbot> git [jboss-as] push master 95982b2.. kabir Test parsing and marshalling of standalone.xml, host.xml and domain.xml
[22:31:59] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/4189bc6...95982b2
[22:34:02] *** stansilvert has quit IRC
[22:49:53] <stuartdouglas> hmm, no osgi module means no META-INF/services in the modules path, very odd
[22:51:17] *** smarlow has quit IRC
[22:54:33] *** jhalliday has quit IRC
[23:30:43] <stuartdouglas> dmlloyd: The osgi subsystem provides a VFSStreamHandlerFactory, so a lot more than just managed beans will break when it is removed
[23:31:21] <stuartdouglas> should I add a VFSStreamHandlerFactory to the main server module, or does it belong somewhere else (like the vfs module itself)
[23:31:36] *** wolfc has quit IRC
[23:32:28] <dmlloyd> there already is one in jboss-vfs
[23:32:47] <dmlloyd> org.jboss.vfs.protocol.VfsUrlStreamHandlerFactory
[23:33:17] <stuartdouglas> ok, in that case it is probably not being loaded due to services not being imported or something
[23:33:25] <dmlloyd> yeah probably
[23:34:12] <dmlloyd> it should probably be right on the command line for now as -Djboss.protocol.handler.modules=org.jboss.vfs
[23:34:30] <dmlloyd> somewhere in early boot
[23:38:11] *** smarlow has joined #jboss-as7
[23:38:12] *** ChanServ sets mode: +v smarlow
[23:53:12] *** ccrouch has left #jboss-as7
top

   February 28, 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 | >