[00:00:21] <Nihility> i can j ust grab it off the attachment
[00:01:26] <Nihility> duh
[00:01:39] <Nihility> i blame eclipse for my stupidity
[00:12:33] <dmlloyd> well, it's tricky
[00:12:40] <dmlloyd> because UserTransaction is bound per component
[00:13:07] <stuartdouglas> yea, so the processor is going to need to iterate over the components
[00:13:16] <stuartdouglas> and bind any that have their own namespace
[00:16:01] <dmlloyd> there are other subsystems with a similar relationship
[00:16:15] <stuartdouglas> weld for instance
[00:17:01] <dmlloyd> yeah a processor can iterate over the component defs, good idea
[00:18:38] <Nihility> DataSource properties are not intended to be directly accessible by JDBC clients. This design is reinforced by defining the access methods on the implementation class rather than on the public DataSource interface used by applications. Furthermore, the object that the client manipulates can be a wrapper that only implements the DataSource interface. The setter and getter methods for the properties need not be exposed to the client.
[00:18:39] <Nihility> Management tools that need to manipulate the properties of a DataSource implementation can access those properties using introspection.
[00:18:45] <Nihility> That is gross!
[00:19:07] <Nihility> have they every heard of SPIs?
[00:28:32] *** baileyje has joined #jboss-as7
[00:28:32] *** ChanServ sets mode: +v baileyje
[00:33:16] *** baileyje has quit IRC
[00:34:24] *** baileyje has joined #jboss-as7
[00:34:25] *** ChanServ sets mode: +v baileyje
[00:36:56] *** jpearlin has joined #jboss-as7
[00:37:33] <baileyje> dmlloyd: There?
[00:37:49] *** jpearlin1 has quit IRC
[00:38:13] <dmlloyd> maybe
[00:38:15] <dmlloyd> :)
[00:38:19] <dmlloyd> how's it going
[00:39:00] <baileyje> Not too bad.  Just sitting a bit before diner.   Still not home though.
[00:39:17] <baileyje> How has the EE task been going?
[00:39:28] <dmlloyd> pretty well
[00:39:44] <dmlloyd> it's pretty much integrated though stuartdouglas has more stuff he's fixing
[00:39:56] <dmlloyd> we should get EJB at least kinda working this week
[00:40:04] <baileyje> Nice..
[00:41:42] <baileyje> Well I should be back late on tuesday.
[00:43:31] *** bstans_afk has quit IRC
[00:43:35] *** bstansberry has joined #jboss-as7
[00:43:36] *** ChanServ sets mode: +v bstansberry
[00:59:56] *** smarlow has quit IRC
[01:02:29] *** baileyje has quit IRC
[01:02:53] *** opalka has quit IRC
[01:03:18] *** nickarls has joined #jboss-as7
[01:12:20] <stuartdouglas> when injecting UserTransaction using @Resource do we also need to bind a java:comp/env reference, the way we would for normal @Resource injection?
[01:15:38] <stuartdouglas> I am going to assume that I do..
[01:23:09] *** FordPrefect has joined #jboss-as7
[01:45:12] *** FordPrefect has quit IRC
[01:48:24] <stuartdouglas> dmlloyd: Are you around?
[01:54:39] *** jwulf has joined #jboss-as7
[01:56:54] *** pferraro has joined #jboss-as7
[01:56:54] *** ChanServ sets mode: +v pferraro
[01:59:49] <jpearlin> Nihility:  found one issue with using the BoundaryDelimitedInputStream as is:  it does not remove the header (content-disposition, etc) from the stream
[02:00:22] <Nihility> right yeah it doesnt do that
[02:00:25] <jpearlin> I am going to go ahead and modify the class to handle the header (I was thinking something like reading and storing it until you advance to the next block)
[02:00:34] <jpearlin> so we will need that if we want to detect the content type
[02:00:54] <Nihility> if you look in that same
[02:00:57] <Nihility> package
[02:01:05] <Nihility> i also had a multipart thing
[02:01:13] <jpearlin> ah...ok...let me see if that helps
[02:01:22] <Nihility> although it would need to be modified slightly
[02:01:30] <Nihility> as it was designed for multipart/related
[02:01:41] <Nihility> as opposed to multipart/form or whatever its called
[02:01:41] <jpearlin> right...I can cherry pick what we need
[02:01:45] <jpearlin> yeah
[02:01:58] <Nihility> but if it sucks you can do whatever
[02:01:59] <jpearlin> multipart/form is correct...unless we are planning on uploading multiple files in one form
[02:02:58] <jpearlin> MultipartRelatedDecoder?
[02:03:22] <Nihility> yep
[02:03:29] <jpearlin> ok..cool...I'll give it a shot
[02:04:13] *** miclorb_ has quit IRC
[02:04:19] <Nihility> also be sure to pick the version wihtout that retarded patch
[02:04:20] <Nihility> :)
[02:04:30] <jpearlin> yeah...I have been
[02:04:42] <jpearlin> unless there is more than one of those patches out there :)
[02:05:04] *** smarlow has joined #jboss-as7
[02:05:04] *** ChanServ sets mode: +v smarlow
[02:05:30] <jpearlin> ah...you cheated!  that class uses the Java Mail API InternetHeaders to nicely grab the headers from the stream
[02:05:44] <jpearlin> are you okay with adding the mail api to the http api project?
[02:05:58] <Nihility> ah that might have been a bad idea
[02:06:04] <jpearlin> yeah...
[02:06:07] <jpearlin> I can do something similar
[02:06:21] <Nihility> i needed it for soap attachments
[02:06:23] <jpearlin> in terms of reading the full header...I had that code earlier before I deleted it
[02:06:34] <Nihility> because the saaj api actually has javamail stuff in it
[02:06:39] <jpearlin> yeah
[02:06:58] <Nihility> like it neded to convert raw images and stuff
[02:07:08] <Nihility> yeah like i said if this class is not helpful dont use it
[02:07:20] <jpearlin> the stream is helpful, but I will need to mod it to get the headers
[02:07:42] <Nihility> yeah this doesnt help at all actually
[02:07:45] <Nihility> im looking at the source
[02:07:49] <jpearlin> yeah
[02:08:01] <jpearlin> I didn't want to say it ;)
[02:08:18] <Nihility> notice how that one stupid patch
[02:08:24] <Nihility> lead to a chain of other stupid patches
[02:08:28] <jpearlin> ha
[02:09:22] <jpearlin> okay...so I am thinking of just adding something that checks to see if you are at the start of an inner stream, extract the header, then move on
[02:09:36] <Nihility> right
[02:09:43] <Nihility> you can use a liine input reader
[02:09:51] <Nihility> or well
[02:09:55] <Nihility> manual works as well
[02:09:59] <jpearlin> right...
[02:10:06] <jpearlin> I was going to add another "boundary"
[02:10:11] <jpearlin> "headerBoundary"
[02:10:20] <jpearlin> and check for that sequence to read the full header
[02:10:31] <jpearlin> then I can create a class that parses the header data to make it easy to get at the content type
[02:10:43] <Nihility> yeah you could just skip everything up until crlfcrlf
[02:10:46] <jpearlin> yup
[02:10:55] <jpearlin> that was exactly how I did it before
[02:11:00] <jpearlin> I changed it to use your input stream
[02:11:13] <jpearlin> except I was discarding the header
[02:11:20] <jpearlin> but now we want to hold on to it
[02:11:58] <jpearlin> ok...I'm going to need to think about how exactly to make this work nicely
[02:12:26] <jpearlin> but what we have for now will work if the only thing in the upload is the war (even though the content type gets written to the war, it seems to not corrupt the file)
[02:13:01] <Nihility> really the content type ends up in the file and it still works?
[02:13:06] <jpearlin> yeah
[02:13:14] <Nihility> there is no way it will actually deploy
[02:13:18] <jpearlin> I agree
[02:13:25] <jpearlin> but the file seems to still be a valid archive/zip
[02:13:41] <jpearlin> but I bet it would fail any md5/checksum
[02:13:42] <jpearlin> that's for sure
[02:13:47] <Nihility> it cant be, the first few bytes indicate its a zip
[02:14:03] <jpearlin> its possible the tools I am using to open it are just forgiving
[02:14:30] <Nihility> try jar on it
[02:15:41] <jpearlin> interesting...it didn't complain, but it didnt do anything either
[02:16:34] <jpearlin> I can list the contents
[02:16:42] <jpearlin> jar -tf <file> reads everything fine from it
[02:18:16] <Nihility> wierd
[02:18:19] <jpearlin> very
[02:18:27] <Nihility> do you have xxd installed?
[02:18:32] <jpearlin> well...it needs to be fixed anyway
[02:18:34] <jpearlin> no
[02:18:43] <Nihility> you use cygwin?
[02:18:47] <jpearlin> I can
[02:19:02] <jpearlin> im not too worried about this, since it is not the real solution anyways
[02:19:04] <Nihility> ah ok well xxd is a hex dump toool
[02:19:07] <jpearlin> let me get the header stuff in there
[02:19:13] <jpearlin> I can open it in a hex editor
[02:19:29] <Nihility> oh you know what
[02:19:32] <Nihility> of course it will work
[02:19:34] <Nihility> DUH
[02:19:42] <Nihility> zip stores the index at the end
[02:20:00] <jpearlin> and the end is fine
[02:20:09] <jpearlin> so it *should* work for now
[02:20:14] <jpearlin> but its not the right solution
[02:20:16] <Nihility> things might not understand
[02:20:19] <Nihility> the header
[02:20:25] <jpearlin> agreed
[02:20:32] <Nihility> i was just curious why it worked at all
[02:20:34] <Nihility> too funny
[02:20:44] <jpearlin> magic
[02:20:55] <jpearlin> the best kind of software engineering
[02:22:35] *** pferraro has quit IRC
[02:29:17] <Nihility> jpearlin: but yes please fix that :)
[02:29:22] <jpearlin> of course
[02:31:13] <stuartdouglas> Nihility: dmlloyd I have added UserTransaction and TransactionSynchronizationRegistry @Resource  support: https://github.com/stuartwdouglas/jboss-as/tree/webComponents
[02:31:28] <stuartdouglas> it also fixes quite a few wrong jndi service names
[02:32:03] <Nihility> great!
[02:32:34] <stuartdouglas> It seems to work, but I am getting: failed to load Last Resource Optimisation Interface org.jboss.tm.LastResource: java.lang.ClassNotFoundException: org.jboss.tm.LastResource from [Module "deployment.war-example.war:main" from Service Module Loader]
[02:33:15] <stuartdouglas> which I belive is a known problem with jboss tm using the wrong classloader?
[02:33:28] <Nihility> it uses TCCL all over the place
[02:33:50] <Nihility> so you have to get i t to initialize in its CL
[02:33:54] <Nihility> and then copy the refs
[02:35:10] <Nihility> maybe you could have a factory method in the transaction subsystem
[02:35:23] <Nihility> that you would call from your deployment processing stuff
[02:35:45] <Nihility> then we dont have to do TCCL mangling outside of the transaction subsystem
[02:36:23] <stuartdouglas> maybe I could just begin and then end a transaction when the subsystem starts
[02:36:46] <Nihility> haha
[02:36:49] <Nihility> clever
[02:36:56] <stuartdouglas> nasty
[02:36:57] <Nihility> oh you know what
[02:37:00] <Nihility> there is another way
[02:37:10] <Nihility> if its coming from static initializers
[02:37:23] <stuartdouglas> just load the class ourselves?
[02:37:24] <Nihility> you can just do a Class.forName with link set to true
[02:45:27] <stuartdouglas> That fixed it
[02:48:00] <stuartdouglas> back on the subject of the InjectionFactory stuff, I think that CDI injection is sufficiently different to our other resource based injection that it is not worth trying to merge it with our existing resource injection stuff
[02:50:09] *** jpearlin has quit IRC
[02:54:43] <Nihility> sounds reasonable to me
[02:55:55] *** pferraro has joined #jboss-as7
[02:55:56] *** ChanServ sets mode: +v pferraro
[03:08:26] *** miclorb_ has joined #jboss-as7
[03:08:55] <Nihility> dmlloyd: do you want to me to hold off merging stuarts patch until you review it tommorow?
[03:34:03] *** bstansberry has left #jboss-as7
[03:40:18] *** miclorb_ has quit IRC
[03:47:25] *** miclorb_ has joined #jboss-as7
[03:55:02] <stuartdouglas> do we need to get Bean Validation in for this milestone? And if so, is anyone working on it?
[03:58:21] *** miclorb_ has quit IRC
[04:06:58] *** miclorb_ has joined #jboss-as7
[04:08:13] *** miclorb_ has quit IRC
[04:11:07] <Nihility> stuartdouglas: yes we do
[04:11:17] <stuartdouglas> Is anyone working on it?
[04:11:51] <Nihility> stuartdouglas: i dont think so, scott was integrating it with jpa, but we dont have the jndi stuff
[04:20:30] <Nihility> stuartdouglas: you want to do it? :)
[04:20:52] <stuartdouglas> sure, I am just having a look at what smarlow has
[04:21:06] <smarlow> I got BV to initialize yesterday
[04:21:16] <stuartdouglas> In your master?
[04:21:30] <smarlow> yup
[04:22:07] <smarlow> I'll find it...
[04:22:09] <stuartdouglas> where is the code for it? Is it in it's own subsystem?
[04:22:25] <smarlow> https://github.com/scottmarlow/jboss-as/tree/master/jpa/src/main/java/org/jboss/as/jpa/beanvalidation
[04:23:12] <smarlow> I think we should do more (e.g. work with any BV impl) but its a start
[04:23:59] <stuartdouglas> we also need to read the deployment descriptors, and it should probably use a service based approach
[04:24:41] <stuartdouglas> Nihility: Should bean validation get it's own subsystem? I would think so
[04:24:50] <Nihility> hmm not sure
[04:24:56] <Nihility> we could put it in ee
[04:25:07] <Nihility> does it have any global config?
[04:25:26] <stuartdouglas> not afaik
[04:25:59] <Nihility> haha so i totally found a way to make deployments block forever
[04:26:13] <Nihility> define a resource on a bean
[04:26:25] <Nihility> and then create another resource with a lookup that maps to its name
[04:26:42] <stuartdouglas> hmm
[04:27:34] <stuartdouglas> I fixed some naming stuff in my webComponents branch, but probably not that one
[04:27:43] <stuartdouglas> does it result in a circular dep?
[04:28:05] <stuartdouglas> is is one of the names wrong (if it is just the wrong name it is probably fixed)
[04:28:21] <smarlow> stuartdouglas:  oh sorry, I didn't answer.  No, I didn't put BV in its own subsystem.  Hibernate BV did have some configuration but I only set what I had to for a successful initialization.  Some docs are http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/validator-xmlconfiguration.html
[04:28:24] <Nihility> not sure didnt look too deeply
[04:28:39] <Nihility> what names where wrong?
[04:28:52] <stuartdouglas> smarlow: That is not global config though, it is per deployment
[04:29:00] <smarlow> oh, maybe this  then http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/validator-bootstrapping.html
[04:29:03] <smarlow> that is for booting
[04:30:15] <stuartdouglas> Nihility: most of them :-)
[04:30:32] <Nihility> like was java:module wrong?
[04:30:37] <stuartdouglas> prety much everything that uses ContextServiceName builder is wrong
[04:30:41] <stuartdouglas> such as java:module
[04:30:46] <stuartdouglas> :-)
[04:30:46] <Nihility> ah
[04:30:55] <stuartdouglas> https://github.com/stuartwdouglas/jboss-as/commit/2eb185b85f9f176e428f11a67ed7c48462b7d7b6#L3R58
[04:30:56] <jbossbot> git [jboss-as] 2eb185b.. Stuart Douglas Add java:comp/UserTransaction java:comp/TransactionSynchronizationRegistry
[04:31:23] <stuartdouglas> also there is still a bit of funkiness with the java:comp aliasing with web modules, but I think that commit makes it a fair bit better
[04:32:04] <Nihility> oh yeah the other funny thing
[04:32:16] <Nihility> is that InitialContext() with jndi doesnt seem to work
[04:32:20] <Nihility> in a managed bean
[04:32:34] <stuartdouglas> it works in a servlet :-)
[04:32:51] <stuartdouglas> The think that dets up namespaces in arquillian may not have been fixed up yet
[04:32:56] * stuartdouglas looks
[04:34:13] <stuartdouglas> hmm, that may or may not have been fixed by that commit as well
[04:35:01] <stuartdouglas> it certainly would not have hurt it :-)
[04:36:53] <stuartdouglas> Nihility: smarlow I think that we can get away with making BV part of the EE subsystem, as it does not really seem to have any global configuration options
[04:37:03] <stuartdouglas> they all seem to be per deployment
[04:37:57] *** FordPrefect has joined #jboss-as7
[04:38:09] <smarlow> stuartdouglas:  I think that would be a good start.
[04:39:02] <smarlow> I don't remember any requirements about supporting multiple BV implementations either, so we shouldn't need any more than that.
[04:39:51] <smarlow> I think the BC resolver API allows for multiple implementations, so we could always support that in the future
[04:39:59] <smarlow> BC == BV
[04:40:20] <stuartdouglas> I'm just looking at that now, it does not look to hard
[04:41:53] * Nihility goes to debug module context processor
[04:43:09] <stuartdouglas> the main thing with the names is that ContextServiceName was building names like "managedbeans-example.ear"."managedbean-example.jar"
[04:43:27] <stuartdouglas> when it should have just been managedbeans-example.managedbeans-example
[04:47:20] *** miclorb_ has joined #jboss-as7
[04:53:24] <Nihility> hmm
[04:53:28] <Nihility> so i figured out the issue
[04:53:42] <Nihility> the managedbean is ran from a jmx deployment
[04:53:53] <Nihility> called from i mean
[04:54:00] <Nihility> and so there is no jndi context
[04:55:09] *** smarlow has quit IRC
[04:55:41] <Nihility> im going to try global
[05:03:01] <Nihility> ok well one problem is that @Resources are not creating jndi names
[05:03:02] <Nihility> at all
[05:03:12] <stuartdouglas> yes they are
[05:03:13] *** miclorb_ has quit IRC
[05:03:15] <Nihility> its based on the naming mode of the component
[05:03:33] <Nihility> and at least in upstream, nothing is setting it to create
[05:03:50] <stuartdouglas> it should be creating them in the module namespace
[05:04:04] <Nihility> yeah im talking about global entries
[05:04:39] <stuartdouglas> what do you mean?
[05:05:36] <Nihility> ok so if its not in module
[05:05:44] <Nihility> it looks at this flag
[05:05:53] <Nihility> AbstractComponentDescription.namingMode
[05:06:01] <Nihility> for the component with the @Resource annotaiton
[05:06:04] <Nihility> so if i say
[05:06:14] <Nihility> @Resource(name="java:global/env/blah")
[05:06:19] <Nihility> that is supposed to work
[05:07:19] <stuartdouglas> but in that case bindingDescription.isAbsoluteBinding() should return true, and skip the bit that reads the naming mode
[05:07:47] <Nihility> i guess thats not an absolute binding
[05:07:51] *** FordPrefect has quit IRC
[05:08:02] <stuartdouglas> yea, it looks like that flag is not being set
[05:09:45] <stuartdouglas> the @Resource processor should probably check the name, and if it contains a : call setAbsoluteBinding
[05:10:10] <Nihility> hmm
[05:10:16] <Nihility> i think actually it means something different
[05:10:29] <Nihility> i think what it means is that the name CAN be absolute
[05:11:06] <stuartdouglas> thats not what the javadoc says
[05:11:19] <stuartdouglas> 'Set whether this binding is an absolute name or whether it's relative to the component environment base.'
[05:12:05] *** mbg has quit IRC
[05:12:46] <Nihility> yeah i think what it means is that sometimes
[05:13:12] <Nihility> name refers to local value
[05:13:14] <Nihility> like for example
[05:13:18] <Nihility> @ManagedBean(name
[05:14:08] <Nihility> in any case
[05:14:23] <Nihility> i set the flag all the time now in the ds deployer thing im doing
[05:14:38] <Nihility> fingers crossed
[05:15:19] *** miclorb_ has joined #jboss-as7
[05:24:02] <stuartdouglas> gah, it looks like bean validation want to load everything using the TCCL
[05:25:22] <Nihility> ha! well one problem is that nothing installs the global context
[05:25:47] <stuartdouglas> that would do it :-)
[05:26:02] <Nihility> im trying to figure out what should
[05:26:17] <stuartdouglas> probably naming subsystem add
[05:28:22] <stuartdouglas> Nihility: line 98 of NamingSubsystemAdd looks like it is trying to set it up
[05:28:43] <Nihility> yes it does that
[05:28:45] <Nihility> BUT
[05:28:49] <Nihility> there is no service for it
[05:28:51] <stuartdouglas> yea
[05:29:04] <Nihility> i guess ill create a dumb one
[05:31:38] *** FordPrefect has joined #jboss-as7
[05:31:59] <Nihility>                         target.addService(ContextNames.JAVA_CONTEXT_SERVICE_NAME.append("global"), Service.NULL);
[05:32:01] <Nihility> hehehe
[05:35:21] * stuartdouglas is not loving the bean validation SPI
[05:39:17] <Nihility> is TCCL really a problem though?
[05:39:19] <Nihility> for bv?
[05:39:29] <Nihility> i mean if it only reads stuff in the user deployment
[05:40:32] <stuartdouglas> probably not to be honest, I'm still looking through it so see exactly what it needs
[05:41:07] <stuartdouglas> it looks like in as6 we had a lazy BV factory, that initialised itself on first use
[05:49:29] *** irooskov has quit IRC
[05:55:13] <Nihility> man
[05:55:25] <Nihility> this is fun
[05:55:27] <Nihility> now i have a service
[05:55:33] <Nihility> that is started
[05:55:43] <Nihility> yet one of its deps is null
[05:55:58] <stuartdouglas> huh?
[05:56:42] <Nihility> im going to have to hook up a debugger to find out why
[05:57:08] <Nihility> im seeing a service start without its injected dep being injected
[05:57:18] <stuartdouglas> It's not that service.NULL thing is it?
[05:57:23] <Nihility> haha no
[06:00:10] <stuartdouglas> I saw a MSC bug to do with this the other day
[06:00:46] <stuartdouglas> are you using ServiceBuilder.addInjection ?
[06:01:08] <stuartdouglas> (or is is being used somewhere in the background)?
[06:03:12] <stuartdouglas> sure you are not adding a dep on the Service.NULL?
[06:03:12] *** FordPrefect has quit IRC
[06:03:36] <stuartdouglas> around line 201 in ComponentInstallProcessor
[06:03:59] <stuartdouglas> where is adds a dep on the parent NamingStore
[06:05:07] <stuartdouglas> you probably need to have the global service set up as a RootContextService
[06:05:19] <Nihility> oh i see the issue
[06:05:58] <Nihility> well i dont know
[06:09:53] <Nihility> i dont understand the logic in ComponentInstallProcessor.adJndiXXX in if(isAbsoluteBinding)
[06:10:19] <Nihility> its trying to truncate everything up until the first slash
[06:10:26] <Nihility> but i have no idea why it would do that
[06:10:37] <stuartdouglas> yea, so it cuts out the java:global or java:comp bit
[06:10:55] <stuartdouglas> as that gets taken care of in ContextNames.serviceNameOfContext(applicationName, moduleName, componentName, fullBindingName)
[06:10:57] <Nihility> that doesnt make sense though
[06:11:05] <Nihility> as the other blocks add it
[06:11:23] *** pferraro has quit IRC
[06:11:23] <stuartdouglas> they add it to fullBindingNAme
[06:11:34] <stuartdouglas> so serviceBindingName is the truncated bit
[06:11:45] <stuartdouglas> and fullbindingName is the absolute jndi name
[06:12:47] <stuartdouglas> turns out the bean validation stuff actually seems really easy
[06:12:56] <Nihility> oh look is serviceNameOfContext that is wrong
[06:13:18] <Nihility> well let me double check
[06:14:04] <stuartdouglas> that one should be right, the ContextServiceNameBuilder is wrong
[06:14:30] <stuartdouglas> but it is deleted in my patch and should be
[06:14:47] <Nihility> hmm
[06:14:51] <Nihility> it is right
[06:14:53] <Nihility> so the dep is there
[06:15:28] <Nihility> it just doesnt inject
[06:15:54] <stuartdouglas> is it being added with addDependency or using addInjection ?
[06:15:59] <stuartdouglas> addInjection won't work
[06:17:04] <stuartdouglas> If you are not fully up to date ServiceBindingSourceDescription may still be adding the dep using addInjection
[06:17:11] <stuartdouglas> I am not sure when that got changed
[06:18:07] <Nihility>  .addDependency(bindingServiceName.getParent(), NamingStore.class, service.getNamingStoreInjector())
[06:18:17] <stuartdouglas> well thats not it then
[06:18:22] <Nihility> thats the global context
[06:18:48] <stuartdouglas> and you set up a RootContextService?
[06:19:20] <Nihility> jboss.naming.context.java.globa
[06:19:29] <Nihility> which i created the same as the other ones
[06:19:36] <Nihility> using an EEContextService
[06:20:07] <Nihility> oh
[06:20:11] <Nihility> maybe it is failing to rebind
[06:20:14] <stuartdouglas> that is probably a problem
[06:20:22] <Nihility> hmm but then it should fail
[06:20:25] <Nihility> the service is started
[06:20:26] <Nihility> hrm
[06:21:28] <Nihility> its got to be an msc bug
[06:21:39] <Nihility> let me see why the injector is never called
[06:21:41] <stuartdouglas> EEContextService is not right for the global context
[06:21:52] <stuartdouglas> (this is probably a different problem)
[06:22:09] <stuartdouglas> as EEContextService maps to org.jboss.as.naming.context.NamespaceObjectFactory
[06:22:29] <Nihility> right
[06:22:32] <stuartdouglas> which uses a NamespaceContextSelector to select the correct app, module and comp namespaces
[06:22:34] <Nihility> which wont find it
[06:22:56] <stuartdouglas> for global there is no need to go through that, as global never changes
[06:23:05] <Nihility> i was just trying to get the binding part to work
[06:23:11] <Nihility> this was sheer lazinesss
[06:34:29] <stuartdouglas> bean validation is actually really easy, you pretty much just give it the TCCL and it sets itself up
[06:36:45] <stuartdouglas> for stuff like UserTransaction and ValidatorFactory @Resource injections I am essentially  just using the lookup attribute to alias the env entry to comp/UserTransaction
[06:37:49] <Nihility> man
[06:37:53] <Nihility> im a moron
[06:37:55] <Nihility> blah
[06:38:16] <Nihility> cool
[06:38:21] <Nihility> does it work?
[06:38:25] <stuartdouglas> yea
[06:38:36] <stuartdouglas> well it did in a servlet
[06:39:00] <stuartdouglas> with all the other changes from my webComponents branch
[06:39:09] *** maeste has joined #jboss-as7
[06:39:10] *** ChanServ sets mode: +v maeste
[06:46:36] <stuartdouglas> So now I have UserTransaction TransactionSynchronizationRegistry Validator ValidatorFactory and BeanManager being bound properly (hopefully)
[06:46:51] <stuartdouglas> have not tested bean validation yet
[06:48:02] *** frainone has quit IRC
[07:08:15] <stuartdouglas> Nihility: Did you sort out your problem?
[07:08:25] <Nihility> yeah it was obvious
[07:08:39] <Nihility> the other contexts are independant stores
[07:08:49] <Nihility> in this case i need to reuse the java context
[07:08:52] <Nihility> and a child of that
[07:09:03] <Nihility> we dont have anything set to do that
[07:09:18] <Nihility> so either namingstore is emulated
[07:09:25] <Nihility> or the code in component install is changed
[07:09:35] <Nihility> to treat "global" as part of the name
[07:09:55] <Nihility> hmm
[07:10:02] <Nihility> i guess i could just make global be its own store
[07:10:03] <stuartdouglas> could we just add a service alias for the root naming context?
[07:10:09] <Nihility> yeah thats what i was doing
[07:10:14] <Nihility> but then you have to change the install
[07:10:29] <Nihility> else it wont bind to java:globa/blah
[07:10:34] <Nihility> it will bind to "blah"
[07:10:57] <stuartdouglas> I don't think it would hurt anything to make global it's own store
[07:11:06] <stuartdouglas> better than having special case code everywhere
[07:11:08] <Nihility> yeah ill do that now because its the least amount of work
[07:11:27] <stuartdouglas> I just tested out the @Resource Validator thing and it seems to work
[07:11:38] <stuartdouglas> its all based off my webComponent branch at the moment
[07:15:41] <Nihility> ah shit
[07:15:47] <Nihility> actually that wont work with my test
[07:15:50] <Nihility> so thats pointless
[07:17:38] <stuartdouglas> why not?
[07:18:22] <Nihility> because InitialContext().lookup("java:global/blah") will not work
[07:18:31] <Nihility> it needs to be the root service
[07:18:37] <Nihility> im hacking it though for now
[07:18:40] <Nihility> i just want ot see it work
[07:18:45] <Nihility> i told it to bind to
[07:18:55] <Nihility> "java:/globa/blah"
[07:18:56] <Nihility> :)
[07:18:56] <Nihility> hehe
[07:26:34] <stuartdouglas> I wonder how hard it will be to get you original thing going, where have an @Resources looking  up a binding created by another @Resource annotation
[07:27:49] *** miclorb_ has quit IRC
[07:29:11] <Nihility> this is the last wild goose i am chasing tonight
[07:30:02] <stuartdouglas> I think I know why it is not working anyway
[07:30:42] <stuartdouglas> at the moment the lookup code cannot handle relative references
[07:32:42] <Nihility> WOOHOO
[07:32:52] <Nihility> it fucking works
[07:33:06] <Nihility> finally!
[07:34:12] <stuartdouglas> awesome
[07:34:27] <stuartdouglas> does it make sense to use relative names in @Resource(lookup= ?
[07:34:45] <Nihility> no that should be absolute
[07:35:03] <stuartdouglas> that is what I though
[07:36:09] *** miclorb has joined #jboss-as7
[07:41:23] <Nihility> however
[07:41:38] <Nihility> i think the issue was service related
[07:41:43] <Nihility> could have been bad names though
[07:42:08] <stuartdouglas> I have it working using absolute names in the @Resource annotation
[07:42:18] <Nihility> ah so one annotation on the class
[07:42:22] <Nihility> and the other on the field
[07:42:33] <stuartdouglas> no, two different fields
[07:42:37] <stuartdouglas> kinda pointless
[07:42:46] <stuartdouglas> but I just wanted to see if it worked :-)
[07:48:55] *** miclorb has quit IRC
[07:50:34] <Nihility> ah try one on the class
[07:50:38] <Nihility> that isnt on a field
[07:50:43] <Nihility> it could be an order issue
[07:50:49] <Nihility> or reverse the fields
[07:51:42] <Nihility> woohoo
[07:53:18] <Nihility> ok ill dump whats happening here
[07:53:19] <Nihility> one sec
[07:55:44] <stuartdouglas> @Resource on the class works fine
[07:56:15] <stuartdouglas> It was probably caused by the wrong services names thing, cause I am testing in my branch that has them fixed
[07:56:16] <Nihility> @Resource(name="blah") on class
[07:56:17] *** emuckenhuber has quit IRC
[07:56:29] <Nihility> and @Resource(lookup="blah") on field?
[07:56:50] <stuartdouglas> no, lookup = "java:module/env/blah"
[07:57:01] *** emuckenhuber has joined #jboss-as7
[07:57:02] *** emuckenhuber has quit IRC
[07:57:02] *** emuckenhuber has joined #jboss-as7
[07:57:02] *** ChanServ sets mode: +v emuckenhuber
[07:57:13] <stuartdouglas> that was why I asked about the relative names thing
[07:57:33] <stuartdouglas> In my branch I have changed it to throw an exception if you use a relative name
[07:57:39] <Nihility> name="blah"
[07:57:42] <stuartdouglas> rather than just failing with a random MSC error
[07:57:49] <Nihility> oops
[07:57:57] <Nihility> name="java:module/blah"
[07:58:04] <Nihility> on both
[07:58:08] <Nihility> well
[07:58:12] <Nihility> name= that
[07:58:13] <stuartdouglas> java:module/env/blah
[07:58:16] <Nihility> lookup the same
[07:58:18] <stuartdouglas> http://pastebin.com/ssC95SMY
[07:58:44] <Nihility> ah ok
[07:58:51] <Nihility> ill have to dig into it :)
[07:59:05] <stuartdouglas> now lookup="bob" will throw an exception
[07:59:33] <stuartdouglas> I don't think this works without my service names fix anyway
[07:59:42] <Nihility> oh i see
[07:59:51] <Nihility> its mapping the wrong service name
[07:59:56] <Nihility> for an absolute name
[08:00:12] <Nihility> instead of doing @name="bob" like you do
[08:00:38] <Nihility> try doing
[08:00:42] <Nihility> java:module/blah
[08:00:51] <Nihility> oops bob
[08:01:13] <stuartdouglas> trying now
[08:01:15] <Nihility> in my case it could be the global thing
[08:01:27] <Nihility> because its treating something thats supposed to global as not
[08:01:34] <Nihility> jboss.naming.context.java.module."managedbean-example.ear"."managedbean-example.jar".my-db
[08:01:51] <stuartdouglas> see that is wrong
[08:02:05] <Nihility> its not even close
[08:02:08] <Nihility> its the wrong context
[08:02:12] <Nihility> its supposed to be :
[08:02:19] <Nihility> jboss.naming.context.java.global.my-db
[08:02:44] <stuartdouglas> it should be boss.naming.context.java.module.managedbean-example.managedbean-example.my-db for module bindings
[08:03:23] <stuartdouglas> using the absolute names hung my managed beans demo
[08:03:27] <stuartdouglas> debugging now..
[08:04:42] <stuartdouglas> it is creating the wrong service name: jboss.naming.context.java.module.managedbean-example.managedbean-example.env/java:module/bob
[08:05:22] <stuartdouglas> is name= supposed to support absolute names? I can't see anything in the spec about it either way
[08:05:28] <Nihility> oh lol
[08:05:30] <Nihility> um
[08:05:43] <Nihility> ok it didnt work for me because i had the old module name
[08:05:52] <Nihility> it broke before because the global scope was messed up
[08:06:15] <Nihility> which i fixed by mapping java:global/name to global/name
[08:06:20] <Nihility> in component install
[08:06:48] <Nihility> yes it is supposed to support them
[08:06:50] <Nihility> on resources
[08:07:14] <Nihility> search the ee spec for @resource
[08:08:23] <stuartdouglas> ah, found it
[08:08:35] <stuartdouglas> so my problem is that the dep is being set up correctly on jboss.naming.context.java.module.managedbean-example.managedbean-example.bob
[08:08:55] <stuartdouglas> however the service name is that messed up managedbean-example.env/java:module/bob
[08:09:06] <stuartdouglas> should not be to hard to fix...
[08:09:21] <Nihility> yeah its the path code in component install probably
[08:09:33] <stuartdouglas> ah, thats caused by the absolute path flag thing
[08:09:44] *** jfclere has joined #jboss-as7
[08:09:44] *** ChanServ sets mode: +v jfclere
[08:09:48] <Nihility> its messed up because of the name of the field (my guess) has a / in it
[08:10:03] <Nihility> oh yeah
[08:10:05] <Nihility> absolute
[08:10:06] <Nihility> sure
[08:10:29] <stuartdouglas> I wonder if we even need the absolute path flag, checking if it starts with java: should probably be enough
[08:11:29] <Nihility> well technically if you did @StateFull(name="java:hi")
[08:11:38] <Nihility> thats a legal bean name i think
[08:11:54] <Nihility> maybe you cant have colons in there
[08:12:03] <Nihility> but you get my point
[08:12:16] <Nihility> im off to bed now
[08:12:23] <Nihility> it 1am for me
[08:12:32] <stuartdouglas> ok
[08:13:00] <Nihility> oh btw
[08:13:08] <Nihility> our service cleanup on failure is not so good
[08:13:32] <stuartdouglas> I will look into it
[08:14:10] <stuartdouglas> I am only around tomorrow and half a day wednesday this week
[08:14:18] <stuartdouglas> due to orientation
[08:17:44] <stuartdouglas> changing the install processor to pick up java: names as absolute fixed the problem
[08:18:21] <stuartdouglas> If you call your bean something like @StateFull(name="java:hi") then I think you deserve it to not work
[08:18:36] <stuartdouglas> but in this case I don't think it will even cause problems
[08:18:45] <stuartdouglas> as because are installed via absolute names anyway
[08:19:23] <stuartdouglas> or rather, bean views are bound to absolute names anyway
[08:21:27] *** bgeorges has joined #jboss-as7
[08:21:27] *** ChanServ sets mode: +v bgeorges
[08:32:56] *** asoldano has joined #jboss-as7
[08:32:56] *** ChanServ sets mode: +v asoldano
[08:41:20] <stuartdouglas> Nihility: When you wake up, this fixes the service cleanup on failure https://github.com/stuartwdouglas/jboss-as/commit/d9ac30e07d4171eb36a5edeecdd4b82f9735e7fb
[08:41:21] <jbossbot> git [jboss-as] d9ac30e.. Stuart Douglas Remove services when a deployment fails
[08:50:49] *** opalka has joined #jboss-as7
[08:50:50] *** opalka has joined #jboss-as7
[08:50:50] *** ChanServ sets mode: +v opalka
[09:27:43] *** ALR has joined #jboss-as7
[09:27:44] *** ChanServ sets mode: +v ALR
[09:37:56] *** rmaucher has joined #jboss-as7
[09:55:27] *** bgeorges has quit IRC
[09:59:18] *** miclorb has joined #jboss-as7
[10:04:58] *** emmanuel has joined #jboss-as7
[10:04:59] *** ChanServ sets mode: +v emmanuel
[10:07:52] *** wolfc has joined #jboss-as7
[10:07:53] *** ChanServ sets mode: +v wolfc
[10:09:04] *** emuckenhuber has quit IRC
[10:23:06] *** maxandersen has joined #jboss-as7
[10:23:06] *** ChanServ sets mode: +v maxandersen
[10:34:20] *** emuckenhuber has joined #jboss-as7
[10:34:20] *** emuckenhuber has joined #jboss-as7
[10:34:20] *** ChanServ sets mode: +v emuckenhuber
[10:50:54] *** jhalliday has joined #jboss-as7
[11:19:07] *** jcosta has joined #jboss-as7
[11:19:07] *** ChanServ sets mode: +v jcosta
[11:32:07] *** Jaikiran has joined #jboss-as7
[11:32:07] *** ChanServ sets mode: +v Jaikiran
[11:33:21] *** alesj has joined #jboss-as7
[11:42:36] *** kkhan has joined #jboss-as7
[11:42:36] *** ChanServ sets mode: +v kkhan
[11:47:09] *** miclorb has quit IRC
[11:48:10] *** darranl has joined #jboss-as7
[11:48:10] *** darranl has joined #jboss-as7
[11:48:10] *** ChanServ sets mode: +v darranl
[11:58:33] *** jwulf has quit IRC
[11:59:27] *** aloubyansky has joined #jboss-as7
[11:59:28] *** ChanServ sets mode: +v aloubyansky
[12:05:37] *** maxandersen has quit IRC
[12:09:20] *** emmanuel has quit IRC
[12:14:06] *** AndyTaylor has joined #jboss-as7
[12:14:07] *** ChanServ sets mode: +v AndyTaylor
[13:04:51] <rmaucher> wolfc: hi; what's the (new ?) problem with metadata ?
[13:05:28] <wolfc> rmaucher, I don't see any problem with jboss-metadata
[13:05:54] <wolfc> it is proven and it gets the job done.
[13:07:21] <ALR> I could list its problems.
[13:07:33] <rmaucher> ah yes, of course :)
[13:07:46] <ALR> But suspect they're not enough to warrant a complete halt on development to rewrite something else immediately
[13:07:51] <ALR> When we have a replacement we should use it.
[13:08:05] <rmaucher> bah, releasing is overrated
[13:08:08] <ALR> IMO the timeframe is too aggressive to pull this bit out now.
[13:08:11] <rmaucher> you guys convinced me ;)
[13:08:44] <ALR> rmaucher: Convinced you that jboss-metadata is no good?  Really?  I thought you'd never come around :P
[13:08:52] *** epbernard has joined #jboss-as7
[13:08:52] *** epbernard is now known as emmanuel
[13:08:52] *** ChanServ sets mode: +v emmanuel
[13:09:18] <rmaucher> ALR: of course, it is more that one year old, therefore it has to be rewritten
[13:09:19] <ALR> The replacement will be nice to work with when we've got it.
[13:09:42] <ALR> rmaucher: That's not true.  Age has nothing to do with it.
[13:09:48] <ALR> rmaucher: It wasn't written by ME.
[13:09:55] <ALR> So it has to be rewritten. :D
[13:10:14] <rmaucher> ALR: ah ok, a David clone :) cool
[13:10:41] *** maxandersen has joined #jboss-as7
[13:10:42] *** ChanServ sets mode: +v maxandersen
[13:15:56] *** frainone has joined #jboss-as7
[13:15:56] *** ChanServ sets mode: +v frainone
[13:16:24] *** aloubyansky has quit IRC
[13:19:57] *** FordPrefect has joined #jboss-as7
[13:32:33] *** maxandersen has quit IRC
[13:35:50] *** asoldano is now known as asoldano_lunch
[13:41:04] <rmaucher> so about metadata and annotation processing, it is necessary to translate annotations into regular mergeable metadata (that's how the web spec works now)
[13:41:49] <rmaucher> the annotation processing part does not really belong into metadata though, all is needed is to produce the metadata objects
[13:45:05] <Jaikiran> technically, those processors can be moved to AS7 codebase and work off the index to create those metadata pojos
[13:45:58] <rmaucher> yes, indeed, the annotation processing (which will use jandex) can be moved to AS7
[13:50:44] <wolfc> the trick is whether we process into jboss-metadata or into AS Descriptors (not the end-user variant)
[13:51:01] <wolfc> right now only jboss-metadata has merging capabilities
[13:51:34] <rmaucher> this need to be equivalent to metadata produced by web.xml, for example, so ...
[14:06:52] *** jpederse has joined #jboss-as7
[14:06:57] *** jpederse has joined #jboss-as7
[14:07:07] <ALR> Bridge it.
[14:07:13] <ALR> Make a jboss-metadata backend for Descriptors.
[14:07:29] <ALR> Though that won't expose merging...
[14:07:38] <ALR> As it'll hide the whole jboss-metadata stuff...hmm..
[14:10:10] <rmaucher> ok, so Jat
[14:10:20] <rmaucher> Jaikiran will move the classes ?
[14:11:28] <Jaikiran> moving the stuff is easy, all we need to do is decide about the goal of all these projects (jbmeta, jandex integration and the descriptors)
[14:11:46] *** bgeorges has joined #jboss-as7
[14:11:48] <Jaikiran> right now, each one of us are going a separate path and ending up with nothing
[14:11:49] <Jaikiran> :)
[14:12:09] <Jaikiran> so we should really get this decided once dmlloyd and jgreene are online
[14:12:17] <rmaucher> so the jandex integration moves to AS ;)
[14:12:41] <Jaikiran> yeah, that actually does make sense. so no arguments there
[14:13:04] <wolfc> that's not the real issue. It doesn't matter much where that code lives.
[14:13:25] <Jaikiran> right. that's what i meant by moving the code is easy :)
[14:13:26] <rmaucher> there's no real issue, so ...
[14:14:11] *** slaboure has joined #jboss-as7
[14:14:19] *** asoldano_lunch is now known as asoldano
[14:14:26] <wolfc> the real issue is, do we want to processes to metadata or not? if not, what's the alternative we can use now?
[14:14:48] <rmaucher> ...
[14:15:04] <rmaucher> with that sort of issue, there's nothing to talk about really
[14:15:40] *** frainone has quit IRC
[14:15:41] <rmaucher> so yes, there's a need for POJOs that can be merged and manipulated to represent the annotations and descriptors ;)
[14:16:46] <kkhan> To me it sounds like you just need the classes/interfaces for the consumers and then a builder which understands the merging. Then AS 7 will parse stuff its way and add to the builder, and AS 5/6 does the same.
[14:17:09] * kkhan admits he knows nothing about jboss metadata
[14:17:09] <wolfc> so like ALR and I have said, hide jboss-metadata stuff so we can cut it later.
[14:18:46] <rmaucher> sigh
[14:20:08] * opalka wonders if AS7 release is doable in middle next year?
[14:20:12] <rmaucher> no ;)
[14:22:11] <rmaucher> so I am ok with moving the code that uses jandex to AS 7, and I won't be doing anything else
[14:22:13] <ALR> wolfc, rmaucher: The approach that makes most sense to me long-term is to make a separate merging layer
[14:22:26] <rmaucher> just remember to test the TCK before committing ;)
[14:22:33] <wolfc> +1 :-)
[14:22:42] <ALR> I see a few concerns which could each take their own projects.
[14:22:49] <ALR> rmaucher: TCK comes last always
[14:22:53] <rmaucher> the merge and parse code has been made separate a while ago
[14:22:55] <ALR> It's system-level integration tests
[14:22:57] *** FordPrefect has quit IRC
[14:23:00] <rmaucher> ok nice
[14:23:03] <ALR> rmaucher: No it hasn't.
[14:23:16] <ALR> rmaucher: Unless we're talking about different things.
[14:23:28] <ALR> In jboss-metadata, parsing is done by JBossXB, which is bound to the model
[14:23:38] <ALR> Same with the merge() methods, baked right into the API
[14:23:39] <wolfc> ALR, that is no longer the case
[14:23:52] <ALR> wolfc: Oh....sweeeeeeet.
[14:23:57] <ALR> wolfc: Where's that now?
[14:24:15] <wolfc> https://github.com/jfclere/metadata/
[14:24:34] <ALR> This is a fork of jboss-metadata?
[14:24:53] <wolfc> Now the merge methods are separate for web, but still baked for EJB.
[14:25:07] <ALR> https://github.com/jfclere/metadata/blob/master/ejb/src/main/java/org/jboss/metadata/merge/EjbMergeUtil.java
[14:25:19] <rmaucher> wolfc: I don't mind, I see little value add ...
[14:25:20] <ALR> That to me still says JBossMetaData.merge
[14:25:42] <wolfc> rmaucher, right. It's some implementation detail.
[14:26:46] <rmaucher> everything is always an impl detail ;)
[14:29:03] *** frainone has joined #jboss-as7
[14:29:03] *** ChanServ sets mode: +v frainone
[14:30:35] <ALR> wolfc: Or by parsing, you mean of XML?  https://github.com/jfclere/metadata/blob/master/ejb/src/main/java/org/jboss/metadata/ejb/parser/spec/AsyncMethodMetaDataParser.java
[14:30:48] <ALR> wolfc: Manually like that, instead of the XB stuff I remember?
[14:31:19] <wolfc> ALR, yes
[14:31:22] <ALR> So that's separated a bit better, but still part of the same metadata project really.
[14:31:29] <ALR> That's much nicer.
[14:31:38] <ALR> In Descriptors we have a similar construct
[14:31:55] <ALR> Only it's COM
[14:31:56] <ALR> DOM
[14:32:12] <ALR> For no reason other than that DOM is just faster to develop/prototype
[14:32:57] <ALR> I'd like to see us go Stax
[14:33:13] <rmaucher> so we would rewrite to DOM, then rewrite to STAX again when we're going to optimize
[14:33:38] <ALR> rmaucher: Well, let me show you a bit what we'd had in mind:
[14:34:28] <ALR> rmaucher: This is what the user sees: https://github.com/shrinkwrap/descriptors/blob/master/api/src/main/java/org/jboss/shrinkwrap/descriptor/api/spec/servlet/web/WebAppDescriptor.java
[14:34:41] <ALR> That thing gets locked to the spec.
[14:34:56] <ALR> The pluggable backend is where we define how stuff is made to fit that model
[14:35:02] <ALR> And it may look something like this:
[14:35:32] <ALR> https://github.com/shrinkwrap/descriptors/blob/master/api/src/main/java/org/jboss/shrinkwrap/descriptor/impl/spec/servlet/web/WebAppDescriptorImpl.java
[14:36:04] <ALR> That's a DOM impl of course.
[14:36:21] <ALR> For optimization, you rewrite it to fulfill the contract using Stax.
[14:36:34] <ALR> And then the user just would switch the runtime dependency from impl-dom to impl-stax
[14:37:45] <rmaucher> yes, I saw your big blob of code to represent a descriptor
[14:40:05] <ALR> A descriptor *is* a big blob.
[14:40:39] <wolfc> I see little in impl that says DOM to me. Unless you mean DOM as a concept.
[14:40:46] <rmaucher> let's hope no user ever gets a NPE then ...
[14:40:54] <ALR> wolfc: It's hidden behind the construct of Node
[14:41:14] <ALR> Let's talk conceptually.  This stuff is prototype-quality at best.
[14:41:31] <rmaucher> cool, so let's see about it post AS 7
[14:41:31] <wolfc> How would you ever move to stax then? It doesn't fit the API.
[14:41:49] <ALR> What'll happen is the model interfaces will probably go into some hierarchy.
[14:41:56] <wolfc> (Not that I see it as a problem though)
[14:41:59] <ALR> wolfc: The API is just the interface.
[14:42:09] <ALR> wolfc: Anything could fit that.
[14:42:30] <ALR> (And the interface is likely wrong / incorrect from the schema of web.xml, but ignore that for now) :)
[14:45:28] *** aloubyansky has joined #jboss-as7
[14:45:28] *** ChanServ sets mode: +v aloubyansky
[14:45:32] <ALR> In any case, I've nothing now to offer immediately
[14:45:41] <ALR> With a week I could get a decent model in place
[14:45:45] <ALR> But not merging
[14:45:45] <wolfc> ALR, there is no way to close an entity in the API
[14:46:00] <ALR> wolfc: We need navigation up/down levels.
[14:46:07] <ALR> XML is hierarchal
[14:46:17] <wolfc> Yeah, I would say put it out of scope
[14:46:28] <ALR> wolfc: Put what?  Merging
[14:46:28] <ALR> ?
[14:46:32] <wolfc> No, Stax
[14:46:37] <ALR> Oh, yes.
[14:46:49] <ALR> Aslak started off w/ DOM, behind Node, so that's what we have.
[14:47:07] <ALR> And Lincoln started chipping away at bits and pieces he needed too.
[14:47:13] <ALR> What this project needs is cohesion
[14:47:25] <ALR> No 5 developers all hacking away at their particular area of interest.
[14:59:03] *** smarlow has joined #jboss-as7
[14:59:03] *** ChanServ sets mode: +v smarlow
[15:04:16] *** maxandersen has joined #jboss-as7
[15:04:16] *** ChanServ sets mode: +v maxandersen
[15:15:00] *** ALR is now known as ALR|Away
[15:26:23] *** maxandersen has quit IRC
[15:32:45] *** FordPrefect has joined #jboss-as7
[15:32:45] *** ChanServ sets mode: +v FordPrefect
[15:34:37] *** pferraro has joined #jboss-as7
[15:34:37] *** ChanServ sets mode: +v pferraro
[15:35:06] *** fnasser has joined #jboss-as7
[15:41:58] *** echelog-2 has joined #jboss-as7
[15:47:31] *** aloubyansky has quit IRC
[15:49:46] *** kkhan has quit IRC
[15:51:37] <dmlloyd> good morning
[15:52:15] <opalka> morning
[15:52:58] <dmlloyd> ok so the plan for this week
[15:53:14] <dmlloyd> we're going to get EJBs deploying via annotations first
[15:54:10] <dmlloyd> long term, we're parsing descriptors into ComponentDescriptions first, then annotations
[15:54:13] <dmlloyd> but for now just annotations
[15:54:21] <smarlow> Is the stuartdouglas WEB patch coming in also?
[15:54:39] <dmlloyd> yeah he was gonna revise it a bit
[15:54:43] <dmlloyd> once he's on we'll chat about that
[15:54:57] <dmlloyd> it's about 2am there now
[15:55:38] <opalka> dmlloyd, out of topic question. I have this module definition - http://fpaste.org/HatN/ When I'm calling classLoader.getResourceAsStream("META-INF/jbossws-entities.properties") on this module it doesn't work. Do U see something wrong with this module definition?
[15:56:08] <dmlloyd> yes, the paths in <includes> only match directories, not files
[15:56:17] <dmlloyd> so you can include META-INF or not
[15:56:34] <dmlloyd> note that it won't include subdirectories of META-INF though, just META-INF itself
[15:56:59] <dmlloyd> by default META-INF is excluded though
[15:57:08] *** bstansberry has joined #jboss-as7
[15:57:09] *** ChanServ sets mode: +v bstansberry
[15:57:44] <opalka> dmlloyd, so the proper import should be <include path="META-INF"/> to include these files?
[15:58:08] <dmlloyd> yeah that should do it
[15:58:14] <opalka> dmlloyd, thanks
[15:58:17] * opalka 's trying ...
[16:02:30] *** bgeorges has quit IRC
[16:02:54] *** FordPrefect has quit IRC
[16:03:29] <wolfc> dmlloyd, Jaikiran has stopped refactoring jboss-metadata, because we first need an answer on how you want annotations to be processed.
[16:03:57] *** balunasj has joined #jboss-as7
[16:03:58] *** ChanServ sets mode: +v balunasj
[16:04:24] <dmlloyd> well we can get this off the ground today by writing simple processor similar to the MB one
[16:05:06] <wolfc> does jandex now provide a good index or not?
[16:05:21] <dmlloyd> sure
[16:05:34] <rmaucher> MB is what ?
[16:05:39] <dmlloyd> managed beans
[16:05:43] <rmaucher> ah ok
[16:05:51] <wolfc> I still don't see why we shouldn't transform metadata into descriptors for the time being.
[16:06:14] <dmlloyd> because that is a lot more work than writing a DUP which takes approx 25 minutes (at least it did for MBs)
[16:06:38] * Jaikiran checks what MB DUP does currently
[16:06:52] <wolfc> it also provides more, but you want descriptors and merging out of scope, so I guess we can move.
[16:07:21] <Jaikiran> when we say out of scope, are we talking about this week or this release?
[16:07:31] <wolfc> this release
[16:07:31] <dmlloyd> both, as it happens :)
[16:07:49] <rmaucher> ok, so I am not following
[16:08:06] <rmaucher> I suppose I have to redo metadata ?
[16:08:10] <dmlloyd> no
[16:08:15] <dmlloyd> not right now
[16:08:37] <dmlloyd> metadata shouldn't be required for this
[16:08:42] <rmaucher> hum ok, but what is the "descriptors" that carlo is talking about then ?
[16:08:48] <wolfc> xml
[16:08:59] <wolfc> we've just put xml out of scope
[16:09:05] <dmlloyd> the priority for the week/release is to get annotations working
[16:09:13] <rmaucher> ok
[16:09:41] <rmaucher> but the annotation processing is moved to AS 7 then
[16:09:49] <dmlloyd> it's always been there
[16:10:00] <wolfc> not the jboss-metadata annotation processing
[16:10:08] <rmaucher> yes
[16:10:08] *** frainone is now known as frainone_lunch
[16:10:10] <dmlloyd> that has not been used afaik
[16:10:16] <rmaucher> actually, it is
[16:10:17] <wolfc> it is used by web
[16:10:28] <dmlloyd> sure but not by EE or EJB
[16:10:38] <wolfc> well, by the ejb3 prototype
[16:10:39] <rmaucher> ok no ;)
[16:10:59] <rmaucher> ah you did annotations already then ;)
[16:11:07] <dmlloyd> as I said for EJB we need to start from the end - make sure that the EJB types are created from descriptions first
[16:11:22] <dmlloyd> then get descriptions initially populated by simple annotation processors
[16:12:30] <wolfc> that first bit is in the ejb3-domain branch
[16:12:50] <wolfc> that second bit was done by EjbComponentDeploymentUnitProcessor, but populated from jboss-metadata
[16:13:01] *** smcgowan has joined #jboss-as7
[16:13:01] *** ChanServ sets mode: +v smcgowan
[16:13:29] <Jaikiran> i might be missing something or looking at the wrong branch, but I don't see any annotation processing (except for @ManagedBean) in MB DUP
[16:13:32] *** opalka has quit IRC
[16:14:13] <wolfc> did you also go through the ee subsystem?
[16:14:50] <dmlloyd> Jaikiran: that's all the annotation processing it does
[16:15:06] <dmlloyd> @Resource is done across all component types
[16:15:48] <Jaikiran> i see, so yeah, it falls under the ee subsystem with its own set of DUPs
[16:17:14] <dmlloyd> the other injection-type annotations will be similar
[16:17:31] <dmlloyd> so all the EJB processors have to worry about are @Stateful/@Stateless/@Singleton, for now
[16:17:38] <dmlloyd> we'll worry about @EJB once that's working
[16:17:54] <wolfc> @EJB is an ee concern
[16:18:06] <wolfc> it applies to all component types
[16:18:14] <Jaikiran> infact most of it include @PersistenceContext are all ee concerns
[16:18:22] <Jaikiran> *including
[16:18:53] <dmlloyd> yes, but @EJB won't work (obviously) if you don't have the EJB subsys turned on
[16:19:01] <Jaikiran> the few EJB specific pieces are mainly class level ones like @Remote, @Local etc
[16:19:42] <smarlow> @PersistenceContext should be handled by a separate DUP (JPAAnnotationParseProcessor)
[16:20:00] <dmlloyd> yeah that's in progress in parallel
[16:25:32] <Jaikiran> so yeah, what part of this would you (wolfc, dmlloyd) like to help with?
[16:25:49] <Jaikiran> *like me
[16:26:09] <dmlloyd> well we need the three annotation processors, either separately or together
[16:26:20] *** balunasj is now known as balunasj_busy
[16:26:33] <dmlloyd> I think that component creation is still not exactly matching up with the latest EE refactor
[16:26:40] <wolfc> we possibly need to disable @Remote
[16:27:21] <wolfc> it's not a feature in web profile
[16:27:39] <wolfc> I've refactored most bits, but I've left the factories in place.
[16:27:40] <emuckenhuber> bstansberry: so can we do exploded deployments like this for M2: https://github.com/emuckenhuber/jboss-as/commit/80f8d49cf0b61a7af66c96c34940ec39ceb4c8b7, or do we want to start with adding some content information to the model?
[16:27:41] <jbossbot> git [jboss-as] 80f8d49.. Emanuel Muckenhuber exploded deployment handling
[16:27:43] <dmlloyd> that makes it a low priority but I"d only disable it if it's delaying other things from being done
[16:27:54] <dmlloyd> yeah the factories are what I am thinking of
[16:28:02] <rmaucher> I'll redo the Servlet annotations a little bit after that (they work right now)
[16:28:13] <dmlloyd> rmaucher, stuartdouglas may have some relevant work on that
[16:28:28] <dmlloyd> he was working on getting @Resource working with servlets
[16:28:31] <dmlloyd> and CDI injection
[16:28:42] <dmlloyd> and @ManagedBean per Servlet.15.5.15
[16:29:03] <bstansberry> emuckenhuber: I'll have to look later; on a security discussion w/ darran
[16:29:11] <bstansberry> but, for M2 simple is good :)
[16:30:30] <emuckenhuber> bstansberry: hehe, ok
[16:30:55] <rmaucher> only the pure Servlet annotations are done right now
[16:30:58] *** ChanServ changes topic to "JBoss AS 7 design discussion - to get started, see http://is.gd/0x6wkT - http://community.jboss.org/en/jbossas/dev/jboss_as7_development"
[16:31:04] <rmaucher> so I don't think there's any overlap
[16:31:07] <dmlloyd> okay
[16:32:15] *** davidbos has joined #jboss-as7
[16:34:44] <Jaikiran> ok, i'll work on those 3 processors
[16:36:59] *** maxandersen has joined #jboss-as7
[16:36:59] *** ChanServ sets mode: +v maxandersen
[16:38:28] *** emmanuel has quit IRC
[16:39:34] <dmlloyd> I have a rebased ejb3-domain on my git repos
[16:39:42] <dmlloyd> it should rebase on upstream cleanly
[16:42:13] <wolfc> I'm looking at the possibility of splitting up into 3 processors. dmlloyd at what point does ComponentDescription need to be complete?
[16:42:37] <dmlloyd> at INSTALL_EE_COMPONENT
[16:42:37] <wolfc> ah, never mind, we can just set the proper Phase
[16:43:51] <wolfc> Jaikiran, the code to setup the BindingDescription is in AbstractSessionComponentFactory
[16:43:55] <dmlloyd> you should finish your initial component creation before PARSE_BEAN_RESOURCE_INJECTION_ANNOTATION
[16:44:37] <wolfc> So we only need 2 processors
[16:45:08] <wolfc> 1 the @Stateless, @Stateful and @Singleton one.
[16:45:13] <wolfc> 2. the @Remote/@Local one
[16:45:53] <wolfc> I forgot @LocalBean
[16:46:26] <wolfc> Hmm, we also need to process the transaction attributes
[16:47:26] *** epbernard has joined #jboss-as7
[16:47:26] *** epbernard is now known as emmanuel
[16:47:26] *** ChanServ sets mode: +v emmanuel
[16:51:08] *** slaboure has quit IRC
[16:52:29] *** pgier has joined #jboss-as7
[16:52:29] *** ChanServ sets mode: +v pgier
[16:53:19] <Jaikiran> yep
[16:53:47] <Jaikiran> we can keep adding those as and when we introduce the functionality
[16:54:32] <Jaikiran> i think i also see a bug in how the ResourceAnnotationParsingDUP works. but i'll test it out later
[16:54:37] <Jaikiran> time for dinner now :)
[16:54:41] *** Jaikiran is now known as Jaikiran|Dinner
[16:56:58] *** pferraro has quit IRC
[17:03:49] *** kkhan has joined #jboss-as7
[17:03:49] *** ChanServ sets mode: +v kkhan
[17:06:03] *** balunasj_busy is now known as balunasj_mtg
[17:06:19] <kkhan> Some commits in my https://github.com/kabir/jboss-as/commits/master-patches. https://github.com/kabir/jboss-as/commit/dee209552ff3affdbdb2b9b79c99bd7695e96f3a (Stan is away so dunno if this will fix his issue or not, but don't want to lose the commit) and https://github.com/kabir/jboss-as/commit/89b4599ec51b69144410721da8ae701d0772b1c8 + https://github.com/kabir/jboss-as/commit/2ede34002f7e52735202bc1e62fa6c4df26de05e
[17:06:20] <jbossbot> git [jboss-as] dee2095.. kabir Make it possible to use the servlet method executor
[17:06:20] <jbossbot> git [jboss-as] 89b4599.. kabir Propagate original context to proxies
[17:06:20] <jbossbot> git [jboss-as] 2ede340.. kabir [JBAS-8922] Inherited operations should appear in read-resource-description and read-operation-names
[17:06:21] <jbossbot> jira [JBAS-8922] Inherited operations do not appear in read-resource-description and read-operation-names results [Open (Unresolved) Bug, Major, Kabir Khan] https://issues.jboss.org/browse/JBAS-8922
[17:08:49] <wolfc> dmlloyd, what's the EEModuleDescription.getAppName? Specifically to bind an EJB we need to know whether it's an ear or not.
[17:09:04] <dmlloyd> that's the EE application name
[17:10:09] <wolfc> Right, which defaults to the EE module name if it is a standalone module
[17:12:20] <wolfc> EE.8.1.2: Similarly, when a stand-alone module is deployed, the module name is used as the application name, and obeys the same rules as described above for application names.
[17:13:00] <dmlloyd> yes
[17:13:04] <wolfc> vs. EJB 3 FR 4.3.15 <app-name> only applies if the session bean is packaged within an .ear file.
[17:14:08] <dmlloyd> if the DU has a parent DU, you're inside an EAR
[17:14:15] <dmlloyd> that's the real test
[17:15:18] <wolfc> just to be sure, WEB-INF/lib/ejb.jar is attached to DU web.war, right?
[17:15:29] <dmlloyd> I'm not sure about that
[17:15:34] <dmlloyd> it might not be a separate DU from the WAR
[17:15:41] <dmlloyd> stuartdouglas would know when he's up
[17:15:50] <wolfc> yeah, that's what was the issue on AS 6 as well :-)
[17:16:54] <dmlloyd> I think the correct behavior is to have it be part of the WAR, would you agree?
[17:17:10] <dmlloyd> that way you inherit the comp=module behavior
[17:19:19] <kkhan> bstansberry: Anything you want me to look at? CLI deployments was mentioned alexey isn't around today. One of my commits above was to help Stan run his tests. Stan is on PTO, so I could take a look at that if there isn't anything more urgent
[17:20:44] <bstansberry> Stan's stuff is ok
[17:21:02] <kkhan> ok, I'll have a play
[17:22:01] <bstansberry> there's a task related to ResultHandler, but I want to chat a bit w/ emuckenhuber about where he is when this call is done
[17:27:02] *** frainone_lunch has quit IRC
[17:27:04] *** smarlow has quit IRC
[17:27:20] *** smcgowan has quit IRC
[17:28:42] *** smarlow has joined #jboss-as7
[17:28:42] *** ChanServ sets mode: +v smarlow
[17:36:57] *** maxandersen has quit IRC
[17:37:56] *** frainone has joined #jboss-as7
[17:37:56] *** ChanServ sets mode: +v frainone
[17:40:09] *** maxandersen has joined #jboss-as7
[17:40:09] *** ChanServ sets mode: +v maxandersen
[17:44:11] *** smcgowan has joined #jboss-as7
[17:44:11] *** ChanServ sets mode: +v smcgowan
[17:46:06] *** smarlow has left #jboss-as7
[17:46:17] *** smarlow has joined #jboss-as7
[17:46:17] *** ChanServ sets mode: +v smarlow
[17:46:18] <kkhan> Is anybody else using Eclipse seeing this error on master? "The attribute lookup is undefined for the annotation type Resource" @BeanWithSimpleInjected.java line 45
[17:46:26] <kkhan> works fine on cmd line
[17:46:27] *** asoldano has quit IRC
[17:46:50] <dmlloyd> yeah
[17:47:01] <dmlloyd> the JDK version of @Resource is missing that method
[17:47:19] <dmlloyd> you have to tell eclipse that the spec-annotations-thing.jar is before the JDK
[17:47:23] <dmlloyd> in class path resolution
[17:47:27] <dmlloyd> not sure how to do that in eclipse though
[17:47:34] <dmlloyd> in IDEA you just move it to the top of the list
[17:52:37] *** emuckenhuber has quit IRC
[17:52:49] <Nihility> same thing in eclipse
[17:52:53] <Nihility> build-path
[17:53:03] <Nihility> hit the up arrow on the maven devs thing
[17:53:25] <Nihility> dmlloyd: so i have @DataSourceDefinition working
[17:53:35] <dmlloyd> okay cool
[17:53:35] <Nihility> but ran into a number of issues in various spots
[17:58:11] *** emmanuel has quit IRC
[17:58:51] <Nihility> the big problem's were
[17:59:02] <Nihility> 1) no global namespace - not a big deal to implement
[17:59:12] <Nihility> 2) component installs path processing is worng
[17:59:38] <dmlloyd> I thought we fixed the global namespace thing
[17:59:38] <Nihility> service name generation is also wrong
[17:59:52] <Nihility> stuart has a fix for some of the service name stuff
[18:00:08] <Nihility> but like due to the above if you do
[18:00:16] <Nihility> @Resource(name="java:module/blah")
[18:00:19] <Nihility> and later on
[18:00:28] <Nihility> @Resource(lookup="java:module/blah_
[18:00:36] <Nihility> the resulting service names dont match
[18:00:39] <dmlloyd> hmmm
[18:00:45] <Nihility> so freeze
[18:00:45] <dmlloyd> I really thought I fixed that problem last week
[18:00:55] <Nihility> it works with relative names
[18:00:59] <dmlloyd> oh
[18:01:04] <dmlloyd> that's not a bug, that's spec
[18:01:09] <dmlloyd> oh wait
[18:01:22] <dmlloyd> no I'm thinking of @ManagedBean(name="") which must always be "relative"
[18:01:24] <Nihility> no you can use absolute names in @Resource(name)
[18:01:34] <Nihility> it can be either absolute or relative
[18:01:36] *** darranl has quit IRC
[18:01:52] <Nihility> which had me wondering about bindingdescription.setAbsolute()
[18:01:52] <dmlloyd> you have to use the absoluteBinding flag in BindingDescription
[18:02:04] <dmlloyd> if you want to bind to an absolute location
[18:02:05] <Nihility> right yeah thats done properly
[18:02:06] <bstansberry> kkhan: another thing where I could use some help...
[18:02:23] <Nihility> so the issue with global scape
[18:02:25] <Nihility> scope
[18:02:32] <Nihility> is that there is no service for it
[18:02:36] <dmlloyd> otherwise everything should be going through ContextNames.getServiceNameForContext() or whatever it's called
[18:02:43] <Nihility> and everything expects a namingstore per scope
[18:02:46] <dmlloyd> yeah there should be, that's an error
[18:02:58] <dmlloyd> it should be created by the EE subsystem init
[18:03:01] <Nihility> so i created an alias on the java: server
[18:03:04] <Nihility> service
[18:03:15] <bstansberry> maeste wanted to talk to me about avoiding what led to the "workaround" stuff in the connector extensions
[18:03:18] <Nihility> because it has to be accessable by InitialContext()
[18:03:27] <bstansberry> if you could help him out, that would be great
[18:03:34] <kkhan> ok sure
[18:03:48] <dmlloyd> yeah it should be referenced similarly to how app/module/comp works but to a naming store which is always available, as opposed to one from the selector
[18:04:03] <dmlloyd> but the service names have to be consistent with what ContextNames is looking for
[18:04:04] <Nihility> right but the naming store MUST be the java: naming store
[18:04:24] <Nihility> it cant be a separate InMemoryStore
[18:04:27] <dmlloyd> why not?
[18:04:33] <dmlloyd> that shouldn't matter
[18:04:38] <Nihility> because InitialContext() wont be able to see it
[18:04:44] <dmlloyd> why not
[18:04:57] <dmlloyd> it's just a binding under java:
[18:05:08] <Nihility> no its a separate InMemoryStore
[18:05:17] <Nihility> so it cant see it
[18:05:18] <dmlloyd> yeah but there's a reference binding
[18:05:26] <dmlloyd> just like there is for comp/module/app
[18:05:40] <dmlloyd> so initial context should see it
[18:06:25] <dmlloyd> I really thought baileyje already set that up
[18:06:29] <dmlloyd> I know we talked about it
[18:06:30] <Nihility> app, comp and module are using a thread local
[18:06:36] <Nihility> to find the InMemoryStore
[18:06:40] <Nihility> relative to the module
[18:06:43] <dmlloyd> yes that's why I said...
[18:06:47] <dmlloyd> yeah it should be referenced similarly to how app/module/comp works but to a naming store which is always available, as opposed to one from the selector
[18:06:52] <Nihility> none of that stuff is in the root InMemoryStore
[18:06:58] <dmlloyd> yes but there are bindings
[18:07:03] <dmlloyd> for app, module, and comp
[18:07:12] <dmlloyd> the bindings are references which cause the lookup in the thread local
[18:07:23] <Nihility> also managedbeans currently do not have a selector
[18:07:28] <dmlloyd> they don't need one
[18:07:30] <Nihility> since they reuse the caller
[18:07:30] <dmlloyd> you're not hearing me :)
[18:07:33] <Nihility> which doesnt exist
[18:07:38] <dmlloyd> make a reference binding for "global"
[18:07:43] <dmlloyd> one that does NOT use the selector though
[18:08:01] <dmlloyd> that way the absolute name methods are consistent between global and the other three
[18:08:09] *** mbg has joined #jboss-as7
[18:08:10] *** ChanServ sets mode: +v mbg
[18:08:21] <dmlloyd> otherwise global will be different, which might be bad
[18:09:08] <Nihility> it only matters in the install process thing
[18:09:16] <Nihility> but yeah sure thats fine
[18:09:35] <dmlloyd> that's what I thought john had already done though
[18:09:44] <dmlloyd> but then again that was a while ago
[18:09:54] <dmlloyd> and we all know how reliable my memory is
[18:10:38] <Nihility> oh yeah so interesting thing
[18:10:43] *** davidbos has quit IRC
[18:10:44] <Nihility> if the service names are wrong
[18:10:54] <Nihility> the server hangs basically
[18:11:05] <Nihility> waiting forever
[18:11:24] <Nihility> even though msc has figured out its due to missing deps
[18:11:26] <dmlloyd> yeah the deployment listener needs enhancements to detect missing dependencies and fail the deployment
[18:11:28] <dmlloyd> or at least log it
[18:11:45] <Nihility> another thing i noticed is we dont do service cleanup properly
[18:11:53] <dmlloyd> that I know we do
[18:11:57] <dmlloyd> it all uses child services
[18:11:58] <Nihility> so once this happens you cant redeploy
[18:12:03] <Nihility> ever
[18:12:09] <Nihility> you have you to abort the server
[18:12:11] <dmlloyd> so if you remove the root deployment then everything is cleaned up
[18:12:13] <Nihility> remove the deployment
[18:12:19] <Nihility> then start
[18:12:30] <Nihility> also same thing if there is an exception somewhere in a processor
[18:12:32] <dmlloyd> the deployment remove operation should be able to handle it
[18:12:42] <dmlloyd> if not then we have a bug in the management layer afaict
[18:12:48] <Nihility> yeah i know the hooks are there, just noting we arent using them
[18:12:55] <dmlloyd> all the remove op should do is set the root service to REMOVE and that's it
[18:14:15] <Nihility> i didnt merge stuarts patch btw
[18:14:46] <Nihility> he disagreed with unifying the managed ref factory stuff ultimately
[18:14:56] *** jcosta has quit IRC
[18:15:01] <Nihility> so i thought it best to let you take a look and talk to him about it
[18:16:50] <dmlloyd> okay
[18:17:08] <Nihility> ok so on isAbsolute
[18:17:13] <dmlloyd> he'll be on in a few hours
[18:17:20] <Nihility> name on resource can also be relative
[18:17:28] <dmlloyd> hm okay
[18:17:39] *** jamezp has joined #jboss-as7
[18:17:44] <dmlloyd> it's relative to comp/env by default?
[18:17:53] <dmlloyd> or module/env if there's no comp?
[18:18:02] <Nihility> ityeah either comp/env or module/env
[18:18:08] <dmlloyd> (not sure if you saw the NamingMode enum which specifies)
[18:18:16] <Nihility> yes saw that too
[18:18:36] <dmlloyd> so we could easily use that to set the default
[18:18:38] <dmlloyd> it's a simple change to
[18:18:38] <Nihility> although i was confused why it was called CREATE?
[18:18:46] <dmlloyd> org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor
[18:18:55] <Nihility> but yeah the question is
[18:18:56] <dmlloyd> because you CREATE a comp namespace for that component
[18:19:03] <dmlloyd> weak perhaps :)
[18:19:14] <Nihility> should the processor figure out
[18:19:18] <Nihility> if the name is relative or not
[18:19:22] <Nihility> and then set isAbsolute
[18:19:24] <Nihility> OR
[18:19:35] <Nihility> should we have it be isAbsoluteAllowed
[18:19:44] <dmlloyd> yeah I think the processor should figure it out
[18:19:46] <Nihility> (im not sure the behavior is uniform across components)
[18:19:55] <dmlloyd> the component install processor should do a minimum amount of thinking
[18:20:02] <dmlloyd> or so it seems to me anyway
[18:20:07] *** jfclere has quit IRC
[18:20:37] <Nihility> ah now i understand why you called it create
[18:20:56] <Nihility> i first though tit was a permission of whether or not to allow the component to create jndi entries
[18:21:45] <Nihility> ok so that will fix the name parsing issues with resource
[18:21:52] <Nihility> we will have it detect if its a qualified name
[18:22:01] <Nihility> we whould make a common thing for that
[18:22:20] <Nihility> probably on contxtnames
[18:23:26] <dmlloyd> yeah contextnames does actually have a method that detects that already
[18:23:34] <dmlloyd> it just does the wrong thing with the answer, i guess
[18:24:06] <dmlloyd> one other issue which I totally punted on was whether to support non-java: resources
[18:24:20] <dmlloyd> if not then absoulte is just a question of startsWith("java:")
[18:24:37] *** emuckenhuber has joined #jboss-as7
[18:24:37] *** emuckenhuber has joined #jboss-as7
[18:24:37] *** ChanServ sets mode: +v emuckenhuber
[18:24:41] <Nihility> thats a question i had last night
[18:24:51] <Nihility> is "java:blah" a legal compnent name
[18:24:57] <dmlloyd> no
[18:25:11] <Nihility> more specifically
[18:25:18] <dmlloyd> EE.5.2.2
[18:25:21] <Nihility> java:module/foo.jar/java:blah
[18:25:38] <dmlloyd> oh
[18:25:44] <dmlloyd> yeah I don't see why not
[18:25:49] <dmlloyd> kinda stupid though
[18:26:08] <Nihility> yeah it makes detecting relative names impossible
[18:26:37] <dmlloyd> no it just means that if you want to call your resource java:blah you have to provide an absolute name
[18:26:49] <dmlloyd> I don't know that they ever specify a syntax restriction for java:
[18:27:01] <dmlloyd> maybe there's some regex in the javaee XSD
[18:27:09] <Nihility> i thought ejb might disallow the :
[18:27:56] <Nihility> oh so stuart was on a roll
[18:27:59] *** AndyTaylor has quit IRC
[18:28:03] <Nihility> he also had beanvalidation integrated
[18:28:11] <dmlloyd> yeah the XSD doesn't restrict it
[18:28:23] <dmlloyd> anyway that's component names
[18:28:24] <wolfc> I don't see where it is disallowed, but I find it stupid anyway.
[18:28:29] <dmlloyd> which is different, they're always relative
[18:28:43] <dmlloyd> the only time it would be ambiguous would be the name attribute of @Resource
[18:28:55] <Nihility> or @DataSourceDefinition
[18:29:05] <dmlloyd> and I"d say we should treat it as absolute if it starts with java: or even [a-zA-Z0-9_]+:
[18:29:09] <Nihility> (and the WS types)
[18:29:25] <Nihility> ok yeah thats what i did
[18:29:26] <wolfc> I agree, I don't think we'll run into trouble
[18:29:34] <dmlloyd> yeah @Resource and equivalents I should say
[18:29:44] <dmlloyd> I think of all those other things as special cases of @Resource :)
[18:30:12] <Nihility> i had a question for you about injection timing
[18:30:34] <Nihility> should components that are available immediatly
[18:30:38] <Nihility> (no need for a service)
[18:30:46] <Nihility> resolve at component install
[18:31:11] <Nihility> or wait until they are referenced
[18:31:17] <Nihility> i went on the former
[18:31:24] <Nihility> (this is the non-injection case)
[18:31:55] <dmlloyd> yeah I've been doing the former
[18:32:27] <dmlloyd> though managedbean is special in that they don't really exist until you use them
[18:32:30] <dmlloyd> either way
[18:32:32] <dmlloyd> so...
[18:32:49] <Nihility> yeah it looked like everything should be available
[18:32:52] <Nihility> at that phase
[18:32:55] <Nihility> i was using classloading
[18:36:00] <dmlloyd> yeah with install phase you know everything is there
[18:36:30] <dmlloyd> so for @DSD are you just attaching a BindingDescription to whatever component it was defined on?
[18:36:52] <Nihility> yes
[18:36:54] <dmlloyd> if so you should make sure that dependency == false
[18:37:04] <dmlloyd> it'd be up to the @Resource to set up the dependency afaict
[18:37:21] <Nihility> its basically the same as @Resource on a class
[18:37:35] <dmlloyd> oh, you're right
[18:37:49] <dmlloyd> so dependency == true so that if they do a lookup() programmatically it will work
[18:37:54] <Nihility> exactly
[18:37:57] <dmlloyd> forgot about that
[18:37:59] <Nihility> so my example
[18:38:07] <Nihility> had @Resource(lookup=) on a field
[18:38:11] <Nihility> and DsD on the class
[18:38:47] <Nihility> and it just has an immediate value inject
[18:38:59] <Nihility> which grabs the module off the DU
[18:39:13] <Nihility> does a lookup for the jdbc class
[18:39:28] <Nihility> uses reflection to attempt setting propreties which may or may not be there
[18:39:44] <Nihility> and returns the instance directly
[18:39:50] <Nihility> we could in the future return a proxy
[18:39:57] <Nihility> and do stuff like connection tracking etc
[18:44:44] <dmlloyd> yeah that'd definitely be a future enhancement
[18:45:06] <dmlloyd> you're using the reflection index to get the constructor right?
[18:45:12] *** darranl has joined #jboss-as7
[18:45:19] *** darranl has joined #jboss-as7
[18:45:19] *** ChanServ sets mode: +v darranl
[18:50:29] <Nihility> dmlloyd: no i should do that though if they define the same ds in multiple places
[18:50:41] <Nihility> (in case) not if
[18:50:52] * dmlloyd is the reflection index police
[18:51:12] <dmlloyd> actually it might not be worth it if we're sure we're not likely to do much other reflection on the thing
[18:51:16] <Nihility> DataSource has to be the worst SPI ever designed
[18:51:20] <dmlloyd> if we do implement proxies though we'll definitely use it
[18:51:28] <Nihility> there is no unfirom way to get them
[18:51:38] <Nihility> and once you have them you have to use reflection to set stuff on them
[18:51:56] <Nihility> and theres no gaurantee that any of those properties will actualy be there
[18:52:36] <dmlloyd> ah
[18:52:44] <dmlloyd> so maybe the reflection index would be helpful
[18:53:11] <Nihility> certainly if you have repeated copies of the same definition
[18:53:28] <Nihility> ill change that
[19:10:47] *** pferraro has joined #jboss-as7
[19:10:47] *** ChanServ sets mode: +v pferraro
[19:13:31] *** asaldhan has joined #jboss-as7
[19:13:31] *** ChanServ sets mode: +v asaldhan
[19:14:07] <asaldhan> who handles naming in AS7?  want to communicate something...
[19:19:59] <dmlloyd> the EE subsystem does
[19:21:11] <asaldhan> dmlloyd: do u oversee it?
[19:21:15] <dmlloyd> sur
[19:21:16] <dmlloyd> sure
[19:21:23] <asaldhan> dmlloyd: ok look at pm
[19:25:04] <dmlloyd> Nihility, we'll probably have to eventually make java:global be selectable too, since on an app client it'll come from the remote server
[19:43:23] *** maeste has quit IRC
[19:46:14] *** jhalliday has quit IRC
[19:46:46] *** Jaikiran|Dinner has quit IRC
[19:55:45] *** maeste has joined #jboss-as7
[19:55:45] *** ChanServ sets mode: +v maeste
[19:59:46] *** maeste has quit IRC
[20:04:10] *** alesj has quit IRC
[20:10:37] *** smarlow has quit IRC
[20:11:11] *** smarlow has joined #jboss-as7
[20:11:11] *** ChanServ sets mode: +v smarlow
[20:12:22] <kkhan> dmlloyd: Should this parse? http://pastebin.com/6LbhdJGR
[20:22:31] *** smcgowan has quit IRC
[20:23:48] *** slaboure has joined #jboss-as7
[20:24:26] <kkhan> I think I see the problem, will check after dinner
[20:31:08] *** smcgowan has joined #jboss-as7
[20:31:08] *** ChanServ sets mode: +v smcgowan
[20:33:08] <dmlloyd> yes that should parse, kkhan, however the paths specified in the filter are directory names, not file names
[20:34:03] <dmlloyd> I do'nt see any reason offhand why that would be a parse error
[20:36:54] *** maxandersen has quit IRC
[20:41:18] <stuartdouglas> morning
[20:41:26] <dmlloyd> hey, stuartdouglas.
[20:57:51] *** stuartdouglas has quit IRC
[20:58:59] *** stuartdouglas has joined #jboss-as7
[20:58:59] *** ChanServ sets mode: +v stuartdouglas
[21:00:13] <stuartdouglas> I just lost power for 5 seconds
[21:00:31] <dmlloyd> that's annoying
[21:01:10] <dmlloyd> maybe the .au government has censored the power grid!
[21:01:16] <dmlloyd> :D
[21:02:06] <stuartdouglas> If the government was to blame it would be incompetence rather than malice
[21:11:04] <stuartdouglas> so, what changes to you want me to make to get my web component patch merged? Did you want me to revert JndiInjectable to the way it was?
[21:11:46] <dmlloyd> no, I think the idea of returning a handle is good
[21:11:50] <dmlloyd> we should make that change
[21:11:56] <dmlloyd> but we should collapse all the similar types down to one
[21:12:01] <dmlloyd> if possible
[21:12:14] <stuartdouglas> I can remove JndiInjectable and just leave ManagedObjectReference
[21:13:27] <stuartdouglas> another question, should we do an immediate undeploy on failed deployments?
[21:13:47] <dmlloyd> that's up to the deployment plan
[21:13:53] <dmlloyd> bstansberry has that spec'd out iirc
[21:13:53] <stuartdouglas> Jason noticed yesterday that our demo's weren't being cleaned up on failure
[21:13:58] <stuartdouglas> ok
[21:14:11] <dmlloyd> yeah I don't know why that is, but at the least they should be clearable via CLI or something
[21:14:35] <bstansberry> hmm, they should be removed
[21:15:18] <dmlloyd> I'm not seeing ManagedObjectReference in any of your changes in your branch, stuartdouglas
[21:15:41] <stuartdouglas> ManagedReferenceFactory
[21:15:43] <dmlloyd> then again I'm probably looking in the wrong branch
[21:15:45] <dmlloyd> oh
[21:15:48] <stuartdouglas> I just got out of bed :-)
[21:16:06] <dmlloyd> hm not seeing that either
[21:17:04] <stuartdouglas> I put it under server, because it did not belong in naming, and naming needed to use it, and it seemed like a fairly general concept that was not specific to ee
[21:17:41] <dmlloyd> it is for now though
[21:17:44] *** smcgowan has quit IRC
[21:17:50] <dmlloyd> it pertains specifically to EE injection
[21:18:03] <stuartdouglas> https://github.com/stuartwdouglas/jboss-as/commit/b528415d3e633c25d47eb535eadd29d430a7b2ef#L25R33
[21:18:04] <jbossbot> git [jboss-as] b528415.. Stuart Douglas Add web components and CDI injection
[21:19:48] <stuartdouglas> I could moving it to naming then, but naming needs to use it, so I can't put it in ee
[21:20:15] <dmlloyd> well JndiInjectable is in naming so that seems fine
[21:20:59] <dmlloyd> tbh naming is kind of ee-specific too...
[21:21:10] *** ALR|Away is now known as ALR
[21:31:45] <kkhan> dmlloyd: Is there any setting to just do a file name?
[21:31:54] <kkhan> in the exclusion
[21:35:25] <stuartdouglas> dmlloyd: were there any other changes you wanted in webComponents?
[21:35:54] <dmlloyd> kkhan: no, not presently
[21:36:16] <dmlloyd> stuartdouglas: I don't think so, you might want to do a rebase and push to be sure
[21:36:26] <dmlloyd> stuartdouglas: is all this in the "webComponents" branch?
[21:36:51] * dmlloyd was looking in master ;(
[21:40:17] <stuartdouglas> yea, i did have some changes in master
[21:40:32] <stuartdouglas> but then I did a round of refactoring and put it in adifferent branch
[21:44:13] *** alesj has joined #jboss-as7
[21:44:20] <dmlloyd> oh, just the one other change that "disinject" should be "uninject" to be consistent with other usages
[21:44:30] <dmlloyd> I think I mentioned that this weekend though
[21:45:22] <stuartdouglas> already done
[21:45:26] <stuartdouglas> and rebased
[21:45:30] <dmlloyd> coo
[21:49:51] <dmlloyd> just testing
[21:50:59] <stuartdouglas> the branch also enables quite a few other resource injection types, like UserTransaction, BeanManager and ValidatiorFactory
[21:51:35] <dmlloyd> really
[21:51:38] <dmlloyd> I don't see those at all
[21:51:44] <dmlloyd> oh wrong window
[21:51:45] <dmlloyd> god
[21:51:48] <dmlloyd> I'm bad at this
[21:52:12] <stuartdouglas> https://github.com/stuartwdouglas/jboss-as/commit/2eb185b85f9f176e428f11a67ed7c48462b7d7b6
[21:52:13] <dmlloyd> the problem with the transaction thing is that it'll break if the txn subsys isn't enabled
[21:52:14] <jbossbot> git [jboss-as] 2eb185b.. Stuart Douglas Add java:comp/UserTransaction java:comp/TransactionSynchronizationRegistry
[21:52:41] <stuartdouglas> and people will expect transactions to work if the transaction subsystem is disabled?
[21:52:51] <dmlloyd> no but they'll expect component binding to work
[21:53:20] *** balunasj_mtg is now known as balunasj_busy
[21:53:42] <dmlloyd> also will this approach allow context.lookup("java:comp/UserTransaction") to work?
[21:53:47] <stuartdouglas> yes
[21:53:57] <stuartdouglas> which bit will cause component binding to fail?
[21:54:26] <dmlloyd> I guess I'm not understanding the role of FIXED_LOCATIONS
[21:54:38] <dmlloyd> oh I see
[21:54:46] <dmlloyd> so that sets the default location based on the injection target type
[21:55:02] <dmlloyd> we need to add ORB in there too
[21:55:06] <stuartdouglas> yea
[21:55:22] <stuartdouglas> basically I bind the UserTransaction to comp:UserTransaction
[21:55:50] <stuartdouglas> and then if it is just a straight @Resource UserTransaction I change it to a @Resource(lookup="java:comp/UserTransaction")
[21:59:39] *** irooskov has joined #jboss-as7
[21:59:40] <stuartdouglas> does that approach sound ok?
[22:00:05] <dmlloyd> yeah it makes sense
[22:00:11] <dmlloyd> I just misread it
[22:00:18] <dmlloyd> it's 3pm here and apparently I'm still not awake
[22:01:02] <jbossbot> git [jboss-as] push master b528415.. Stuart Douglas Add web components and CDI injection
[22:01:02] <jbossbot> git [jboss-as] push master 2eb185b.. Stuart Douglas Add java:comp/UserTransaction java:comp/TransactionSynchronizationRegistry
[22:01:02] <jbossbot> git [jboss-as] push master 87fe954.. Stuart Douglas Bind the BM for every component
[22:01:02] <jbossbot> git [jboss-as] push master a8cea6c.. Stuart Douglas Clean up CDI based injection
[22:01:02] <jbossbot> git [jboss-as] push master a362f9f.. Stuart Douglas Add bean validation
[22:01:03] <jbossbot> git [jboss-as] push master d078441.. Stuart Douglas Throw exception lookup resources that do not use the absolute name
[22:01:03] <jbossbot> git [jboss-as] push master 2068f10.. Stuart Douglas Relax Class-Path processing
[22:01:03] <jbossbot> git [jboss-as] push master 84e6024.. Stuart Douglas If a lookup value starts with java: assume it is an absolute name
[22:01:04] <jbossbot> git [jboss-as] push master a266968.. Stuart Douglas Remove JndiInjectable, replace with ManagedReferenceFactory
[22:01:04] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/bd4461e...a266968
[22:04:10] <dmlloyd> Nihility: you should compare with your JNDI stuff to make sure you don't conflict
[22:06:56] *** emuckenhuber has quit IRC
[22:08:31] *** kkhan has quit IRC
[22:10:03] <stuartdouglas> smarlow: I have set up bean validation binding to Jndi, so you should be able to use it in your jpa stuff
[22:11:07] <smarlow> stuartdouglas:  great, I'll sync up with your BV change.  Is it included in the above changes just pushed to master?
[22:12:55] <stuartdouglas> yes, the a362f9f commit
[22:14:05] <stuartdouglas> so, what is next on the EE integration priority list?
[22:15:38] *** kkhan has joined #jboss-as7
[22:15:38] *** ChanServ sets mode: +v kkhan
[22:15:56] <Nihility> dmlloyd: should be compatible
[22:16:03] <Nihility> ejb3!
[22:16:18] <Nihility> actually i dont know
[22:16:23] <dmlloyd> EJB
[22:16:28] <Nihility> maybe there is something more generic we should do first
[22:16:44] <dmlloyd> jaikiran is working on the base EJB annotation processors afaik
[22:16:51] <Nihility> cool
[22:16:53] <dmlloyd> we need the other injection types
[22:17:20] <dmlloyd> @EJB, eventually
[22:17:37] <dmlloyd> hm well maybe that's all
[22:17:48] <dmlloyd> @Resource covers most stuff
[22:17:52] <stuartdouglas> I was thinking we should wait till we have ejb's before we add @EJB :-)
[22:17:54] <dmlloyd> esp. with stuartdouglas' latest change
[22:18:05] <dmlloyd> yeah that's still technically in the ejb3-domain branch
[22:18:23] <Nihility> i would love to see an SFSB work
[22:18:48] <dmlloyd> the ejb3-domain branch seems to compile though the deployments don't actually fire yet
[22:19:12] <dmlloyd> merge conflicts, mmm
[22:19:24] <stuartdouglas> who's fork has ejb3-domain ?
[22:19:38] <dmlloyd> mine is out of date w.r.t upstream
[22:19:49] <dmlloyd> carlo's is even more out of date w.r.t upstream
[22:21:04] <stuartdouglas> you know how you said we also need to add ORB there as well, is CORBA going to be in the next release?
[22:21:41] <Nihility> its not critical for beta1 but the TS team needs it ASAP
[22:21:46] *** emuckenhuber has joined #jboss-as7
[22:21:46] *** emuckenhuber has joined #jboss-as7
[22:21:46] *** ChanServ sets mode: +v emuckenhuber
[22:21:47] <dmlloyd> well no harm in putting it in
[22:23:39] <dmlloyd> the future IIOP subsys can do the binding when it lands
[22:25:04] *** jwulf has joined #jboss-as7
[22:28:17] *** mbg is now known as mbg|away
[22:30:38] *** miclorb_ has joined #jboss-as7
[22:32:29] <stuartdouglas> So is there anything I can help with on EJB integration, or do you want me to work on getting some of other @Resource annotations working
[22:32:36] <stuartdouglas> or something else?
[22:33:38] <kkhan> dmlloyd: Does the module loader for a deployment export services?
[22:33:40] <dmlloyd> maybe start with other injection annotations
[22:34:00] <dmlloyd> kkhan: by default everything is always exported - it's the import where services are normally excluded by default
[22:34:24] <kkhan> ok, I am looking at arquillian + jsf
[22:34:56] <dmlloyd> stuartdouglas, if you start with other injection stuff, you can hook up with wolfc and Jaikiran when they log in (your afternoon/evening) and see how they're coming and find out if they have any trouble with the stuff we've done
[22:35:23] <stuartdouglas> ok, will do
[22:35:27] <kkhan> dmlloyd: The arq servlet protocol uses the deployment classloader to try to load services, but they are not found. 
[22:35:40] *** rawblem has joined #jboss-as7
[22:35:40] *** ChanServ sets mode: +v rawblem
[22:36:04] <kkhan> I need to check if it is the structure of the war being deployed
[22:36:17] <rawblem> bstansberry,  hey so i haven't gotten to actually play with the deployment yet (was organizing my tools and planning my attack) but...  what happens if I have to copy a large large file into the deployment folder?
[22:36:20] <dmlloyd> kkhan: one effect of how the services thing works is that if one module aggregates others, services won't come across normally
[22:36:35] <rawblem> in older AS versions it would crap out and say incomplete deployment... and i'd need to start / stop the deployment scanner before and after the copy
[22:36:40] <bstansberry> nothing will happen until you put in xxx.dodeploy
[22:36:46] <stuartdouglas> although tomorrow I am going up to brisbane to be disoriented, so today is my last full work day for the week
[22:36:55] <rawblem> so what's the workflow exactly? what do i copy the file in as?
[22:37:01] <kkhan> dmlloyd: jsf  unit does things slightly differently from the normal arquillian stuff, it puts all the deps into the war
[22:37:16] <bstansberry> you copy the file in as foo.war, and then foo.war.dodeploy
[22:37:32] <rawblem> ok... and right now we only have support for archives? not exploded deployment?
[22:37:34] <bstansberry> the latter is just an empty file
[22:37:39] <rawblem> hmm
[22:38:10] <bstansberry> i'm about to push emuckenhuber's exploded deployment patch up to my branch
[22:38:50] <bstansberry> pushed
[22:38:54] <bstansberry> good timing ;)
[22:38:56] <wolfc> staurtdouglas, dmlloyd, I don't expect any trouble writing up processors that generate Descriptions.
[22:39:08] <wolfc> Maybe do some tests for the testsuite?
[22:39:50] <wolfc> Once we have the initial SessionBean up and running we can start dishing out functional bits to be incorporated into the Descriptions.
[22:44:45] <kkhan> dmlloyd: A war gets deployed, and contains a WEB-INF/lib/arquillian-jsfunit.jar which in turn contains the services. Using the war CL we don't see the services from arquillian-jsfunit.jar
[22:45:16] <dmlloyd> kkhan: that is not what I would expect
[22:45:26] <dmlloyd> something funny must be happening
[22:45:33] *** smarlow has quit IRC
[22:45:44] <bstansberry> kkhan: BTW, i'm testing your 3 commits from earlier today right now
[22:45:53] <dmlloyd> stuartdouglas, we're not making modules for WEB-INF/lib, right?  it gets folded right into the same WAR class loader?
[22:46:01] <kkhan> dmlloyd: ok, just wanted to check that the expected behaviour is that the service should be visible
[22:46:03] <stuartdouglas> no
[22:46:07] <stuartdouglas> they are just resource roots
[22:46:21] <dmlloyd> okay then it's pretty weird that the services are not visible via the war CL
[22:46:26] <dmlloyd> unless tomcat is creating its own CL somehow
[22:46:34] <kkhan> There might be some funny stuff going on in jsfunit or somewhere else
[22:46:38] <dmlloyd> kkhan, can you verify that the CL you're using is a module CL?
[22:46:44] <kkhan> Just eliminating the obvious
[22:47:09] <dmlloyd> kkhan, you can also look in jconsole at the jboss.modules mbean for the deployment module loader
[22:47:19] <dmlloyd> you'll be able to see all the paths attached to the WAR
[22:47:29] <kkhan> ModuleClassLoader for Module "deployment.test.war:main" from Service Module Loader
[22:47:30] <dmlloyd> might be helpful in figuring out what's going on
[22:47:39] <kkhan> ah ok
[22:47:41] <dmlloyd> ok that's what I'd expect
[22:51:20] <kkhan> dmlloyd: dumpModuleInformation()?
[22:51:35] <dmlloyd> yeah that works
[22:51:39] <dmlloyd> might be information overload though :)
[22:51:55] <dmlloyd> make sure you're in the deployment ML, not the filesystem ML
[22:52:57] <kkhan> I see a LocalModuleLoader, ServiceModuleLoader and a SystemCPModuleLoader, I am guessing it is the ServiceML
[22:53:10] <dmlloyd> yeah
[22:53:17] <dmlloyd> that's a really, really bad name for it though
[22:53:27] <kkhan> :-)
[22:53:50] *** smarlow has joined #jboss-as7
[22:53:50] *** ChanServ sets mode: +v smarlow
[22:55:19] <kkhan> I don't see any META-INF/services entries there so maybe that is why.
[22:56:54] <kkhan> Anyway, good to know it should work before digging it
[22:57:04] <kkhan> s/it/in
[22:57:49] <jbossbot> git [jboss-as] push master d3290c2.. kabir Make it possible to use the servlet method executor
[22:57:50] <jbossbot> git [jboss-as] push master 9026635.. kabir Propagate original context to proxies
[22:57:50] <jbossbot> git [jboss-as] push master cbe11d5.. kabir [JBAS-8922] Inherited operations should appear in read-resource-description and read-operation-names
[22:57:50] <jbossbot> jira [JBAS-8922] Inherited operations do not appear in read-resource-description and read-operation-names results [Open (Unresolved) Bug, Major, Kabir Khan] https://issues.jboss.org/browse/JBAS-8922
[22:57:50] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/a266968...cbe11d5
[22:59:21] *** kkhan has quit IRC
[23:07:15] *** mbg|away is now known as mbg
[23:07:18] <stuartdouglas> so I don't think we can really do JMS @Resource stuff until we have deployment descriptor support
[23:11:42] *** jpederse has quit IRC
[23:14:54] *** wolfc has quit IRC
[23:26:51] *** darranl has quit IRC
[23:37:15] *** mbg is now known as mbg|away
[23:38:54] *** frainone has quit IRC
[23:55:55] *** slaboure has quit IRC

   March 7, 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 | >