[00:09:18] *** adietisheim has quit IRC
[00:15:45] *** maxandersen has quit IRC
[00:32:38] *** jwulf has joined #jboss-as7
[00:35:48] *** misty has joined #jboss-as7
[00:39:01] *** jwulf has quit IRC
[00:51:11] *** misty has quit IRC
[01:03:19] *** jwulf has joined #jboss-as7
[01:19:54] <bobmcw> dmlloyd: I need some classpath help
[01:20:05] <bobmcw> I have a Structure processor that finds *.jar in various locations
[01:20:18] <bobmcw> adds them to the RESOURCE_ROOTS, marks as root modules (I guess?)
[01:20:36] <bobmcw> from the unit's Module->ClassLoader, I can't find classes from inside them.
[01:20:40] <bobmcw> how do I fix that?
[01:21:13] <bobmcw> this is in POST_MODULE
[01:21:33] <stuartdouglas> you are trying to load them in POST_MODULE or set them up in POST_MODULE?
[01:21:46] <bobmcw> I add to RESOURCE_ROOT in STRUCTURE
[01:21:51] <bobmcw> I try to access them in POST_MODULE
[01:22:16] <bobmcw> I've also played with ADDITIONAL_MODULES and that didn't help
[01:22:26] <bobmcw> https://gist.github.com/c407fe423c1313beb0f7
[01:22:32] <bobmcw> that's in my structure
[01:22:33] <stuartdouglas> you need to actually mark them as module roots, as not all resource roots are on the CP
[01:22:39] <stuartdouglas> e.g. the root of a war
[01:22:44] <bobmcw>                     ModuleRootMarker.mark(childResource);
[01:22:50] <bobmcw> like that?
[01:22:53] <bobmcw> I'm doing that.
[01:23:44] <bobmcw> can you point me near the code that adds RESOURCE_ROOTS to the classpath?
[01:24:06] <bobmcw> should I mark them a sub-deployments?
[01:24:26] <stuartdouglas> ModuleSpecProcessor
[01:24:31] <stuartdouglas> no, they should not be sub deployments
[01:26:01] <stuartdouglas> is your code in a github branch?
[01:26:16] <bobmcw> one moment, I can push yah
[01:26:20] <bobmcw> I'm trying use it like this:
[01:26:22] <bobmcw>         Module module = unit.getAttachment( Attachments.MODULE );
[01:26:22] <bobmcw>         Class<?> injectionType = module.getClassLoader().loadClass( getName() );
[01:26:37] <bobmcw> for a type to feed to beanManager.getBeans(...)
[01:27:11] <stuartdouglas> that should work
[01:27:52] <bobmcw> https://github.com/torquebox/torquebox/blob/as7/modules/core/src/main/java/org/torquebox/core/as/KnobStructureProcessor.java
[01:28:15] <bobmcw> line 45+
[01:28:39] <bobmcw> lots of useless code in there not accomplishing what I want :)
[01:28:56] <bobmcw> I *think* weld is scanning stuff, since I end up with a .WeldService (but no .beanmanager) Service
[01:29:26] <bobmcw> hah, ya know what
[01:29:31] <bobmcw> my jar is in the wrong place
[01:29:33] <bobmcw> lemme try again
[01:29:41] <stuartdouglas> That would explain it
[01:29:49] <stuartdouglas> cause that all looks like it should work
[01:31:58] <bobmcw> yay!  getting closer.
[01:31:58] <bobmcw> Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null
[01:32:08] <bobmcw> found my type, but not my bean, I guess
[01:32:54] <stuartdouglas> where is your bean lookup code?
[01:33:23] <bobmcw> https://github.com/torquebox/torquebox/blob/as7/modules/cdi/src/main/java/org/torquebox/cdi/injection/CDIInjectableService.java
[01:33:31] <bobmcw> stolen from resteasy
[01:33:39] *** misty has joined #jboss-as7
[01:33:57] <stuartdouglas> it looks like you are missing a qualifier
[01:34:18] <stuartdouglas> beanManager.getBeans( this.type ); should probably be beanManager.getBeans( this.type, AllLiteral.INSTANCE );
[01:34:43] <bobmcw> where is this AllLiteral class?
[01:34:46] <bobmcw> eclipse isn't finding it
[01:35:15] <stuartdouglas> sorry, should be AnyLiteral
[01:35:39] <stuartdouglas> it's just an AnnotationLiteral for the @Any qualifier
[01:35:44] <stuartdouglas> that all beans have
[01:35:45] <bobmcw> 'k
[01:37:02] <stuartdouglas> looking at the code there, where you remove the sub classes, the more CDI-ish way to do it would be to use qualifiers
[01:37:22] *** stansilvert has joined #jboss-as7
[01:37:23] <bobmcw> we don't support qualifiers yet, but that's hopefully soon
[01:37:47] <bobmcw> new error: https://gist.github.com/330ea70d44ab9907ede9
[01:38:02] <stansilvert> bstansberry: are you around?
[01:38:03] <stuartdouglas> gah
[01:38:07] <bobmcw> I guess we're not jogging enough stuff to ge tthe TCCL set
[01:38:10] <stuartdouglas> you need to set the TCCL
[01:38:21] <bstansberry> yep. hi stan
[01:38:21] <bobmcw> some processor I can trigger with a marker?  or just in my own?
[01:38:36] <stuartdouglas> just your own
[01:38:46] <stuartdouglas> Most of the weld processors do it
[01:38:48] <bobmcw> 'k, reasonable to set it to the unit's module CL?
[01:38:57] <stuartdouglas> yes
[01:39:04] <stansilvert> So it's easy enough to hide file-based deployments in the console.  And I'm sure that the CLI could pretend that they're not there.
[01:39:14] <stuartdouglas> weld does not work at all if the TCCL is not set correctly
[01:39:15] <stansilvert> But do we want to go that far?
[01:39:59] <bstansberry> stansilvert: the problem is there is legit stuff to do with them; e.g. read-only stuff
[01:40:23] <stansilvert> What would that be?
[01:40:41] <bobmcw> stansilvert: are you talking about files-not-in-archives, as root deployments?
[01:40:46] <bobmcw> iff so, that's a feature I really would like
[01:41:26] <bstansberry> emuckenhuber is working on exposing runtime details; e.g. the stuff exposed via mbean in 5.x/6.x, e.g. the web session manager
[01:41:31] <stansilvert> No, the background is JBAS-784
[01:41:33] <jbossbot> jira [JBAS-784] ResourceBundle classloader errors [Closed (Done) Bug, Major, Scott Stark] https://issues.jboss.org/browse/JBAS-784
[01:41:52] <stansilvert> Oops, I meant AS7-784
[01:41:54] <jbossbot> jira [AS7-784] Remove deployment doesn't really remove it [Open (Unresolved) Bug, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-784
[01:42:07] <bobmcw> stuartdouglas: okay, back to that null error
[01:42:10] <bobmcw> my current lookup code: https://github.com/torquebox/torquebox/blob/as7/modules/cdi/src/main/java/org/torquebox/cdi/injection/CDIInjectableService.java
[01:42:18] <bobmcw> getBeans() returns an empty list
[01:42:57] <bobmcw> my jar of CDI stuff has a beans.xml, and this class: https://github.com/torquebox/torquebox/blob/master/integration-tests/annex-apps/cdi-annex/src/main/java/org/torquebox/ThingOne.java
[01:43:11] <bstansberry> stansilvert: it's probably not so bad to have the scanner detect changes made via CLI/console and reflect that in the deployments/ dir
[01:44:15] <bobmcw> stuartdouglas: all of this injection is trying to occur, I guess, in POST_MODULE.  Should I push it back towards INSTALL?
[01:44:41] <stuartdouglas> nope, the WeldContainer services does not start until install
[01:44:54] <stansilvert> bstansberry: How does this work in domain?  Carlo was saying we would support file-based deployments in a domain.
[01:44:56] <stuartdouglas> and as your injector has a dep on it, it will not start until it is up
[01:44:59] <bobmcw> mbean to poke around and see what it thinks it found?
[01:45:39] <stuartdouglas> we don't actually have any CDI MBeans yet
[01:46:04] <bstansberry> stansilvert: not scanner based deployments. just unmanaged content, like <fs-archive .../> where the user is responsible for propagating it around the domain
[01:46:25] <bstansberry> more useful is <fs-exploded>
[01:47:15] <bstansberry> but the scanner that reads a directory analyzes changes and makes management calls to deploy -- that's standalone only
[01:47:49] <stuartdouglas> bobmcw: I am pretty sure the BeanManagers toString() will show you all it's beans
[01:47:50] <bstansberry> because with a domain it's not clear what server group is relevant
[01:48:08] <stansilvert> So the user has to manually specify it in domain.xml?
[01:48:18] <bstansberry> or via a command
[01:49:15] <bobmcw> https://gist.github.com/516496b0183e90902fee
[01:49:24] <stansilvert> OK.  I'm trying to figure out the requirements for console.  What would you expect to be there?
[01:51:11] <stuartdouglas> damn
[01:51:12] <stansilvert> How would that even work in the CLI?  I don't see how it would make sense to remotely specify and <fs-archive> or <fs-exploded>
[01:51:19] <bobmcw> casting to Impl and using getBeans()
[01:51:34] <bstansberry> stansilvert: the list of content. the domain root deployment list would look like the standalone one
[01:51:36] <stansilvert> Once it's there I can see assigning to server groups.
[01:52:04] <stuartdouglas> bobmcw: I think I know what the issue is
[01:52:13] <bobmcw> yah, getBeans() shows my bean not present
[01:52:14] <bstansberry> for the CLI, I think the convenience deploy command can be restricted to managed content, i.e. <content sha1="aaaaa"/>
[01:52:23] <stuartdouglas> actually no I don't
[01:52:54] <bstansberry> if people want to mess with unmanaged content, they can use low level commands
[01:53:04] <stansilvert> I think that makes sense.
[01:53:38] <stuartdouglas> bobmcw: Is your structure processor running after STRUCTURE_ANNOTATION_INDEX
[01:53:48] <stuartdouglas> if so, that would explain it
[01:53:58] <stansilvert> So we restrict console/CLI to "enable", "disable", "assign to group", and (maybe) "remove"
[01:54:07] <stuartdouglas> as the annotation index would not be build, and weld would not see anything in the deployment
[01:54:14] <bobmcw> stuartdouglas: yah, I'll move it earlier
[01:54:22] <stansilvert> Does that sound right?
[01:54:52] <bstansberry> stansilvert: that and the ability to deal with managed content like it does now
[01:55:36] <stansilvert> Well, for console, that's all you can do.  Am I missing a feature?
[01:56:44] <bstansberry> I don't think so, no
[01:56:45] <bobmcw> stuartdouglas: yay!
[01:56:48] <bobmcw> more beer for you
[01:57:00] <stansilvert> One might be to change the runtime name.  But as of now, I don't see that it has any effect.
[01:57:01] <bobmcw> I just CDI'd into my ruby application
[01:57:47] <stuartdouglas> awesome
[01:58:02] <bstansberry> stansilvert: it doesn't?
[01:58:05] <bobmcw> so, ~1 week to move from AS6 -> AS7
[01:58:10] <bobmcw> pretty pleased
[01:58:16] <stansilvert> AS7-785
[01:58:18] <jbossbot> jira [AS7-785] Setting runtime-name seems to have no effect [Open (Unresolved) Bug, Major, Alexey Loubyansky] https://issues.jboss.org/browse/AS7-785
[01:59:09] <stansilvert> What is runtime-name supossed to be?  Maybe I don't understand what it is for.
[01:59:26] <bstansberry> it's the EE application/module name
[01:59:55] <bstansberry> the "name" attribute is relevant to the management layer; it has to be unique across the domain
[02:00:12] <bstansberry> so name = foo.war.v1 runtime-name = foo.war
[02:00:37] <bstansberry> then you could also have foo.war.v2 runtime-name = foo.war deployed on different server groups
[02:02:30] <stansilvert> OK.  So changing runtime-name from the console might be something you want to do?  Right now I'm pretty sure it is a read only attribute.
[02:03:57] <bstansberry> that could add a fair bit of complexity. typically you'd know the runtime-name when you add it and it wouldn't change
[02:04:08] <bstansberry> problem with changing it is what if it's deployed?
[02:04:16] <bstansberry> that would require a redeploy
[02:05:38] <bstansberry> BTW, looking at the CLI code I see it's looking for --runtime-name
[02:05:56] <bstansberry> maybe there's a doc problem? i.e. a typo?
[02:06:18] <stansilvert> I guess so.  I found runtime_name in the help doc.
[02:06:34] <stansilvert> But it accepted the command OK, so there was no indication that it was wrong.
[02:06:42] <bstansberry> I just did a quick look at code, so not sure
[02:09:11] <stansilvert> Tried again, runtime-name works properly.  So he just needs to update the doc and throw an error on runtime_name.
[02:09:50] <stansilvert> I'm not anxious to implement changing the name if you think it's not that useful.  I'm happy to wait for user feedback on that one.
[02:10:00] <bstansberry> +100
[02:10:26] <bstansberry> it's important to set it when doing an add, but that's all
[02:15:01] <stansilvert> OK.  So I think the only thing left to resolve is how to deal with "remove" from console or CLI.
[02:15:07] *** lgao has joined #jboss-as7
[02:16:12] <bstansberry> I think your .removed idea is what I'll have to do -- the scanner detects that stuff it thinks is deployed no longer exists in the model, so it puts down that file
[02:16:23] <bstansberry> same with .undeployed
[02:17:38] <bstansberry> BTW, we're thinking about adding a boolean "persistent" attribute to deployment resources
[02:17:57] <bstansberry> is kind of clunky; not something the console would deal with
[02:17:58] <stansilvert> What would it do?
[02:18:12] <bstansberry> the idea is the scanner would set that to "false" when it adds stuff
[02:18:25] <bstansberry> then the xml marshalling code would ignore that deployment
[02:18:36] <bstansberry> so it wouldn't persist back to standalone.xml
[02:18:47] *** misty has quit IRC
[02:19:01] <bstansberry> the concept is the persistent state for stuff controlled by the scanner is the deployments/ dir
[02:19:06] <bstansberry> markers etc
[02:19:24] <stansilvert> Something needs to keep track of enabled/disabled state.
[02:19:30] <bstansberry> this is the solution to the problem of deleting stuff from deployments/ when the server is down
[02:20:08] <bstansberry> yeah, so if you disable via the console, etc, the scanner needs to put down an .undeployed marker
[02:20:15] <stansilvert> And something has to keep track of server group assignments.
[02:20:39] <bstansberry> but there is no scanner for domain mode
[02:20:52] <stansilvert> enable/disable happens at the server group level
[02:21:25] <stansilvert> Ah, we're not talking about domain at all.
[02:21:34] <bstansberry> right, this "persistent" is only relevant to the FS scanner
[02:22:10] <bstansberry> but your question points at the clunky thing about it; there's this attribute in the model that has an internal-only purpose
[02:23:40] <bstansberry> if I can think of a better idea, i'll be happy, but just wanted to give you an FYI
[02:24:03] <stansilvert> Thanks.  I like knowing that I can safely ignore it.
[02:24:15] <bstansberry> exactly :)
[02:25:11] <stansilvert> I think I'm set.
[02:28:36] *** misty has joined #jboss-as7
[03:29:13] *** Binbin has joined #jboss-as7
[03:44:12] *** mbg has joined #jboss-as7
[03:45:20] *** stliu has joined #jboss-as7
[03:45:20] *** ChanServ sets mode: +v stliu
[03:54:16] *** jwulf has quit IRC
[03:55:48] *** tcrawley_ is now known as tcrawley
[05:08:36] *** JimMa has joined #jboss-as7
[05:39:10] *** jc3 has joined #jboss-as7
[05:39:10] *** ChanServ sets mode: +v jc3
[05:47:04] *** bstansberry is now known as bstans_afk
[06:05:22] *** dmison has joined #jboss-as7
[06:05:29] *** liweinan has joined #jboss-as7
[06:43:29] *** magesh has joined #jboss-as7
[06:55:37] *** stliu has quit IRC
[07:01:09] *** stliu has joined #jboss-as7
[07:01:10] *** ChanServ sets mode: +v stliu
[07:01:18] *** tcrawley_ has joined #jboss-as7
[07:01:18] *** ChanServ sets mode: +v tcrawley_
[07:03:33] *** tcrawley has quit IRC
[07:35:45] *** maxandersen has joined #jboss-as7
[07:35:45] *** ChanServ sets mode: +v maxandersen
[07:57:49] *** maxandersen has quit IRC
[08:05:24] *** jwulf has joined #jboss-as7
[08:10:07] *** jfclere has joined #jboss-as7
[08:10:07] *** ChanServ sets mode: +v jfclere
[08:13:12] *** lazarotti has quit IRC
[08:14:41] *** irooskov has joined #jboss-as7
[08:14:41] *** ChanServ sets mode: +v irooskov
[08:25:51] *** irooskov has quit IRC
[08:26:20] *** maxandersen has joined #jboss-as7
[08:26:20] *** ChanServ sets mode: +v maxandersen
[08:26:50] *** jwulf has quit IRC
[08:28:56] *** irooskov has joined #jboss-as7
[08:28:56] *** ChanServ sets mode: +v irooskov
[08:29:59] *** tdiesler has joined #jboss-as7
[08:29:59] *** ChanServ sets mode: +v tdiesler
[08:33:56] *** maxandersen has left #jboss-as7
[08:37:28] *** opalka has joined #jboss-as7
[08:37:32] *** opalka has joined #jboss-as7
[08:37:33] *** ChanServ sets mode: +v opalka
[08:38:14] *** pilhuhn has joined #jboss-as7
[08:38:14] *** ChanServ sets mode: +v pilhuhn
[08:56:21] *** galderz has joined #jboss-as7
[08:56:21] *** ChanServ sets mode: +v galderz
[08:56:58] *** galderz has quit IRC
[08:58:32] *** galderz has joined #jboss-as7
[08:58:32] *** ChanServ sets mode: +v galderz
[08:59:35] *** galderz has quit IRC
[09:08:30] *** galderz has joined #jboss-as7
[09:08:30] *** ChanServ sets mode: +v galderz
[09:12:56] *** rmaucher has joined #jboss-as7
[09:14:03] *** mgoldmann has joined #jboss-as7
[09:14:03] *** ChanServ sets mode: +v mgoldmann
[09:20:03] *** liweinan has quit IRC
[09:20:10] *** bgeorges has joined #jboss-as7
[09:20:46] *** rawbdor has joined #jboss-as7
[09:20:46] *** ChanServ sets mode: +v rawbdor
[09:22:38] *** dmison has quit IRC
[09:23:49] *** adietisheim has joined #jboss-as7
[09:23:49] *** ChanServ sets mode: +v adietisheim
[09:24:07] *** misty has quit IRC
[09:24:15] *** pilhuhn has quit IRC
[09:24:43] *** pilhuhn has joined #jboss-as7
[09:24:43] *** ChanServ sets mode: +v pilhuhn
[09:34:55] *** tdiesler has quit IRC
[09:35:09] *** tdiesler has joined #jboss-as7
[09:35:09] *** ChanServ sets mode: +v tdiesler
[09:37:02] *** tdiesler has quit IRC
[09:52:01] *** magesh has quit IRC
[10:02:55] *** tdiesler has joined #jboss-as7
[10:02:55] *** ChanServ sets mode: +v tdiesler
[10:06:14] *** wolfc has joined #jboss-as7
[10:06:14] *** ChanServ sets mode: +v wolfc
[10:13:57] *** opalka has quit IRC
[10:14:05] *** opalka has joined #jboss-as7
[10:14:05] *** opalka has joined #jboss-as7
[10:14:05] *** ChanServ sets mode: +v opalka
[10:36:58] *** mlinhard has joined #jboss-as7
[10:36:58] *** ChanServ sets mode: +v mlinhard
[10:37:48] *** Binbin has quit IRC
[10:40:00] *** jcosta has joined #jboss-as7
[10:40:00] *** ChanServ sets mode: +v jcosta
[10:53:57] *** Binbin has joined #jboss-as7
[10:54:33] *** galderz has quit IRC
[11:14:14] *** kkhan has joined #jboss-as7
[11:14:14] *** ChanServ sets mode: +v kkhan
[11:21:10] <opalka> pilhuhn, ping
[11:21:16] <pilhuhn> hey
[11:21:39] <opalka> pilhuhn, I've got a question you might be able to answer ;)
[11:21:51] <opalka> pilhuhn, when I display webservices model I see:
[11:22:19] <opalka> pilhuhn, http://fpaste.org/dBDc/
[11:22:29] *** pmuir has joined #jboss-as7
[11:22:30] *** pmuir has joined #jboss-as7
[11:22:30] *** ChanServ sets mode: +v pmuir
[11:22:37] <opalka> pilhuhn, I don't understand why
[11:22:38] <opalka>  * "operation" => "add",
[11:22:46] <opalka>  * "operation-headers" => {"rollback-on-runtime-failure" => false}
[11:23:00] <opalka> pilhuhn, are in the response. I'm trying to debug but I'm not able to find it :(
[11:23:20] *** stalep has joined #jboss-as7
[11:23:47] <pilhuhn> yeah, that makes no sense to me either. But unfortunately I don't know enough of the internals to answer your question on why.
[11:23:49] *** AndyTaylor has joined #jboss-as7
[11:23:49] *** ChanServ sets mode: +v AndyTaylor
[11:24:14] <opalka> pilhuhn, ok
[11:24:21] <opalka> pilhuhn, I'll continue to investigate ...
[11:38:59] *** sannegrinovero has joined #jboss-as7
[11:38:59] *** sannegrinovero has quit IRC
[11:38:59] *** sannegrinovero has joined #jboss-as7
[11:38:59] *** ChanServ sets mode: +v sannegrinovero
[11:45:31] *** maeste has joined #jboss-as7
[11:45:31] *** ChanServ sets mode: +v maeste
[11:47:49] *** magesh has joined #jboss-as7
[11:49:02] *** galderz has joined #jboss-as7
[11:49:02] *** ChanServ sets mode: +v galderz
[11:57:09] *** adietisheim has quit IRC
[11:58:48] *** stliu has quit IRC
[12:00:28] *** darranl has joined #jboss-as7
[12:00:28] *** darranl has joined #jboss-as7
[12:00:28] *** ChanServ sets mode: +v darranl
[12:06:43] *** adietisheim has joined #jboss-as7
[12:06:43] *** ChanServ sets mode: +v adietisheim
[12:09:29] <kkhan> opalka: What exactly did you run? 'read-resource' should not be returning operations
[12:09:52] <opalka> kkhan, yep, read-resource :(
[12:09:55] *** magesh1 has joined #jboss-as7
[12:10:05] <opalka> kkhan, I'm debugging this issue for hours - no idea why it's there :(
[12:10:19] <kkhan> For me it looks like http://pastebin.com/2YL55ybd
[12:10:34] *** magesh has quit IRC
[12:10:50] <opalka> kkhan, I'm doing some refactorings
[12:11:00] <opalka> kkhan, let me publish the my local branch to github ...
[12:11:18] <kkhan> And read-r-d: http://pastebin.com/aYBPBxSu
[12:12:49] <opalka> kkhan, do you see something suspicious in this branch - https://github.com/ropalka/jboss-as/tree/wsintegration ?
[12:13:06] <opalka> kkhan, please review my refactoring steps if I didn't violate some DMR contract
[12:13:14] <kkhan> looking
[12:14:02] <opalka> kkhan, especially this commit - https://github.com/ropalka/jboss-as/commit/718acd1ad0c9fc7f3a8889979dd066677313ddae
[12:14:03] <jbossbot> git [jboss-as] 718acd1.. Richard Opalka fixing webservices configuration - removing confusing 'configuration' element from both XML config & DMR
[12:15:03] <kkhan> opalka: This looks weird: https://github.com/ropalka/jboss-as/commit/718acd1ad0c9fc7f3a8889979dd066677313ddae#L6R83
[12:15:04] <jbossbot> git [jboss-as] 718acd1.. Richard Opalka fixing webservices configuration - removing confusing 'configuration' element from both XML config & DMR
[12:15:36] <kkhan> You should be getting the reply-properties and use those to populate the model, not use the whole operation itself
[12:15:59] <opalka> kkhan, aha
[12:16:24] *** magesh1 has quit IRC
[12:16:30] <opalka> kkhan, thanks, fixing ...
[12:17:50] *** dmison has joined #jboss-as7
[12:21:04] *** magesh has joined #jboss-as7
[12:21:04] *** magesh has quit IRC
[12:21:39] *** JimMa has quit IRC
[12:28:10] *** galderz has quit IRC
[12:31:55] *** sannegrinovero has quit IRC
[12:32:03] *** Binbin has quit IRC
[12:32:25] *** torben has joined #jboss-as7
[12:32:30] *** torben has quit IRC
[12:32:30] *** torben has joined #jboss-as7
[12:32:30] *** ChanServ sets mode: +v torben
[12:34:06] <AndyTaylor> wolfc: ping
[12:35:01] <AndyTaylor> wolfc: its ok, ive sussed it, i guess i need to add a messagelistenerinterface annotation  to my mdb (// TODO: if messageListenerInterface is not set use the implemented interface)
[12:36:36] *** magesh has joined #jboss-as7
[12:36:46] *** Binbin has joined #jboss-as7
[12:39:19] *** galderz has joined #jboss-as7
[12:39:19] *** ChanServ sets mode: +v galderz
[12:45:19] *** alesj has joined #jboss-as7
[12:47:37] <AndyTaylor> wolfc: do i now need to set the ResourceAdapter annotation on the MDB now?
[12:49:51] *** sannegrinovero has joined #jboss-as7
[12:49:51] *** ChanServ sets mode: +v sannegrinovero
[12:50:53] *** rawbdor has quit IRC
[12:55:45] <wolfc> AndyTaylor: at the moment, yes, we have no default
[12:56:11] <AndyTaylor> wolfc, cheers, i thought so
[13:03:02] *** magesh1 has joined #jboss-as7
[13:04:36] *** magesh has quit IRC
[13:05:39] *** vtunka has joined #jboss-as7
[13:05:40] *** ChanServ sets mode: +v vtunka
[13:31:25] *** jpederse has joined #jboss-as7
[13:31:25] *** ChanServ sets mode: +v jpederse
[13:31:33] *** jpederse has quit IRC
[13:31:33] *** jpederse has joined #jboss-as7
[13:31:33] *** calvino.freenode.net sets mode: +v jpederse
[13:32:32] *** sgilda has joined #jboss-as7
[13:35:24] *** bbrowning has joined #jboss-as7
[13:35:24] *** ChanServ sets mode: +v bbrowning
[13:35:41] *** hbraun has joined #jboss-as7
[13:37:29] *** hbraun_ has joined #jboss-as7
[13:40:48] *** hbraun has quit IRC
[13:42:51] *** aloubyansky has joined #jboss-as7
[13:45:01] *** sguilhen has joined #jboss-as7
[13:45:06] *** rawbdor has joined #jboss-as7
[13:45:07] *** ChanServ sets mode: +v rawbdor
[13:45:31] <aloubyansky> stansilvert: ping
[13:45:41] <stansilvert> pong
[13:46:46] <stansilvert> aloubyansky: Hi Alex
[13:48:22] <aloubyansky> stansilvert: i saw the issues you opened... about the arguments i agree, i'll make sure only those that are valid can go through
[13:48:27] <aloubyansky> and about the path...
[13:48:46] <aloubyansky> i've been struggling with escaping last week
[13:49:07] <aloubyansky> and decided to go with one separator for all the platforms
[13:49:19] <aloubyansky> would that be a problem?
[13:49:34] *** magesh has joined #jboss-as7
[13:49:43] *** magesh has left #jboss-as7
[13:50:10] <aloubyansky> i actually agree, it'd make more sense to support native paths
[13:50:29] <stansilvert> I think it's a problem for Windows users.
[13:50:43] *** magesh1 has quit IRC
[13:50:46] *** tcrawley_ has quit IRC
[13:51:02] <stansilvert> I want to be able to cut and paste a path to my deployment
[13:51:02] <aloubyansky> but then if i want to support escaping (to e.g. allow whitespaces) for windows i'd have to escape the separator \
[13:51:16] <aloubyansky> so, it'd be like \\
[13:51:22] <aloubyansky> which isn't nice neither
[13:51:25] <aloubyansky> imo
[13:51:40] <stansilvert> For Windows, users are used to using quotes when there is a space in the path.
[13:51:54] <aloubyansky> yes, that would work
[13:52:03] <stansilvert> "c:\my path with white space"
[13:52:06] <aloubyansky> but that's not gonna work for tab-completion
[13:52:34] <aloubyansky> that's why i chose to go with escaping
[13:53:34] <stansilvert> what is the problem with tab completion?
[13:54:21] <aloubyansky> the problem is that the whitespace is considered a separator between the command line arguments
[13:54:30] <aloubyansky> so, yes, quotes seem to work
[13:54:38] <aloubyansky> but if i have a few choices
[13:54:49] <aloubyansky> like "dir a", "dir b"
[13:55:06] <aloubyansky> then tab completion will stop at "dir "
[13:55:24] <aloubyansky> and if the quote is closed, it's kind of the end of the argument value
[13:55:51] <aloubyansky> you see what i mean?
[13:56:56] <stansilvert> I'll admit.  I don't see it.
[13:57:44] <aloubyansky> ok, the problem is to complete "dir a" or "dir b"
[13:57:53] <aloubyansky> the common part is "dir "
[13:58:04] <aloubyansky> so i have to put quotes around it
[13:58:13] <stansilvert> oh, I see now
[13:58:30] <aloubyansky> but if i put the quotes around it it's a complete valid value
[13:58:57] <aloubyansky> with escaping it's different...
[13:59:08] <stansilvert> I think it's ok if you don't close the quote.  Just let the user do it.
[13:59:59] <aloubyansky> that's a possibility... but gonna be annoying
[14:00:24] *** tcrawley has joined #jboss-as7
[14:00:24] *** ChanServ sets mode: +v tcrawley
[14:00:40] <stansilvert> Personally, I think it's more important to accept Windows paths than to have tab completion be perfect.
[14:02:23] <aloubyansky> ok, i'll think about it... perhaps i could find some trick with a cursor position. thanks for the feedback
[14:02:55] <stansilvert> You're welcome.  Opinions are easy to give.  :-)
[14:03:44] <aloubyansky> well, if they are i have some other stuff for you to look at ;)
[14:03:56] <stansilvert> sure
[14:05:15] <aloubyansky> it's deploy and undeploy. i had only Jaikiran's comments on that. i really need more, cause i just implement what comes to mind quickly
[14:05:46] <aloubyansky> so, if when you have time http://community.jboss.org/wiki/DeployAndUndeployWithTheCLI
[14:06:06] <aloubyansky> i'm not sure the options and defaults are the best
[14:06:26] <stansilvert> looking at it now
[14:06:31] <aloubyansky> thanks
[14:09:24] *** magesh has joined #jboss-as7
[14:11:35] <stansilvert> aloubyansky: There is a long conversation that we need to have with Brian and maybe a few others.
[14:12:08] <stansilvert> aloubyansky: We first need to standarize what all the terms mean.
[14:12:40] <stansilvert> aloubyansky: Then we can talk about what operations and defaults need to be.  I'm having the exact same problem with console.
[14:13:27] <aloubyansky> stansilvert: sure, no problem
[14:14:52] <stansilvert> aloubyansky: Just one example.  Redeploy usually means to disable and then enable something that is already deployed.  But here it can also mean upload new bits and restart the app.
[14:16:05] <aloubyansky> yes, it's the old jboss way
[14:16:39] <stansilvert> Anyway, there are lots of little things like that.
[14:17:03] <aloubyansky> that's why i ask for opinions
[14:17:12] <stansilvert> I'll write something up and we can discuss it.
[14:17:23] <aloubyansky> cool, thanks
[14:20:51] *** sguilhen is now known as sguilhen_
[14:21:56] *** sguilhen_ is now known as sguilhen
[14:22:33] *** sguilhen has left #jboss-as7
[14:25:33] *** mbg has quit IRC
[14:31:37] *** Jaikiran has joined #jboss-as7
[14:31:37] *** ChanServ sets mode: +v Jaikiran
[14:31:52] <Jaikiran> dmlloyd: stuartdouglas: one of you around?
[14:32:02] <stuartdouglas> I am
[14:32:39] *** magesh has left #jboss-as7
[14:32:41] <Jaikiran> i had a question about the ClassReflectionIndex and what it's getMethods() is supposed to be semantically
[14:32:52] <Jaikiran> the javadocs contradicts to what it is currently behaving
[14:33:07] <Jaikiran> i see that the docs mention that it's supposed to return all declared methods of a class
[14:33:31] <Jaikiran> but looking at the implementation in the constructor of that class it even returns the public methods declared by the super classes
[14:34:02] <Jaikiran> as a background on what i am working on - i've been fixing some of the interceptor processing logic in the components
[14:34:11] <Jaikiran> after going through some of the tck tests
[14:34:33] <Jaikiran> so the question - what's the expected behaviour of ClassReflectionIndex.getMethods()?
[14:35:38] <stuartdouglas> hmm, I would say that the javadoc is wrong
[14:35:40] <wolfc> Jaikiran: I changed it sometime ago to match the JDK stuff
[14:35:47] <stuartdouglas> and that it should correspond to the JDK
[14:36:00] *** aloubyansky has quit IRC
[14:36:18] <wolfc> I probably forgot about the javadocs, let me check my patch
[14:36:44] <stuartdouglas> but it probably also needs a getDeclaredMethods
[14:36:51] <Jaikiran> wolfc: hmm, it isn't behaving like the JDK too
[14:37:08] <Jaikiran> it's a combination of private, protected, public on the class + public of super class
[14:37:13] <Jaikiran> in it's current form
[14:37:52] <wolfc> hmm, yeah, icky
[14:40:25] <wolfc> Jaikiran: as I recall I did it because the overloading of methods did not function perfectly. It is a bitch to get that right.
[14:41:34] <Jaikiran> wolfc: i think having getmethods and getdeclaredmethods similar to jdk should get us past it. isn't it?
[14:42:20] <wolfc> Jaikiran: I'm not sure of all the use cases
[14:42:37] <wolfc> Jaikiran: concurrency management is a per view method afair by the way
[14:42:56] *** lgao has quit IRC
[14:43:01] <Jaikiran> wolfc: for stateful it would be per instance isn't it?
[14:43:35] <wolfc> yeah, SFSB is pretty simple a per instance thing
[14:45:24] *** mmoyses has joined #jboss-as7
[14:45:25] *** ChanServ sets mode: +v mmoyses
[14:47:45] <Jaikiran> i think some time back dmlloyd had mentioned that the ClassReflectionIndex isn't supposed to cache the super class stuff (don't remember the reason)
[14:47:53] <Jaikiran> so let's wait for him to see what needs to be done
[14:48:05] <Jaikiran> i'll workaround this issue for now in the interceptor processing logic
[14:48:28] <hbraun_> maeste: ping+
[14:48:43] <maeste> hbraun_: pong
[14:48:50] <hbraun_> maeste: https://issues.jboss.org/browse/AS7-724
[14:48:52] <jbossbot> jira [AS7-724] XA Datasource get removed from XML when booted in domain mode [Open (Unresolved) Bug, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-724
[14:49:02] <hbraun_> sorry, but I cannot remember if we need the driver or not?
[14:49:03] <kkhan> Jaikiran: Probably to keep it as small as possible - calling Class.getSuperClass() is cheap
[14:49:04] <maeste> hbraun_: fixed in my branch
[14:49:21] <maeste> hbraun_: well
[14:49:30] <hbraun_> maeste: does the result mean: we need the driver when confugring the XA DS?
[14:49:42] <maeste> hbraun_: it needs driver
[14:49:59] <maeste> hbraun_: but XA DS connection are not working in master
[14:50:10] <maeste> hbraun_: there is a bug in IronJacamar fixed in CR1
[14:50:32] <hbraun_> i don't care if the connection works
[14:50:37] <hbraun_> i only care about the config
[14:50:38] <maeste> hbraun_: and it's already integrated in my branch, but needs an IJ release to be merged
[14:50:46] <maeste> hbraun_: oki perfect
[14:50:54] <maeste> hbraun_: so just add driver
[14:51:03] <hbraun_> ok, that means in the end we need the driver but it will be reference to named driver declration?
[14:51:06] <kkhan> Jaikiran: While calling getMethod() etc. is expensive, reflection creates a new Method object every time
[14:51:08] <maeste> hbraun_: have you had time to get a look to my branch and mail on ML
[14:51:19] <hbraun_> maeste: not yet
[14:51:25] <hbraun_> just going throug the open issues
[14:51:26] <maeste> hbraun_: I've changed as discussed the config and services for drivers
[14:51:52] <maeste> hbraun_: let me know if you have any thoughts about, when you will look at this
[14:51:53] <Jaikiran> kkhan: ah I see!
[14:52:31] <hbraun_> maeste: k
[14:53:48] <wolfc> Jaikiran, kkhan: I would say the underlying problem is conflicting requirements. Views are only interested in public methods, everything else wants to know the full deal.
[14:57:55] <wolfc> Jaikiran, https://github.com/wolfc/jboss-as/commit/b6f60c054dd16c5e42a0bc54efd752d6fe43e2b9#L1R45
[14:57:56] <jbossbot> git [jboss-as] b6f60c0.. Carlo de Wolf Bridging the gap between spec and invocation interceptors
[14:58:12] <wolfc> if I want to know the ComponentInstance instance I should implement a post construct interceptor
[14:59:26] <wolfc> this should basically be the blueprint to get such a construct although I don't like the LifecycleAwareInterceptorComponentConfigurator too much.
[15:00:25] *** pferraro has joined #jboss-as7
[15:00:25] *** ChanServ sets mode: +v pferraro
[15:02:26] <Jaikiran> that should work from what I see
[15:02:41] <Jaikiran> although it probably would make it a lot easier if this was built in within the ComponentDescription
[15:04:46] *** stliu has joined #jboss-as7
[15:04:46] *** ChanServ sets mode: +v stliu
[15:06:26] *** Nihility has joined #jboss-as7
[15:06:27] *** Nihility has joined #jboss-as7
[15:06:27] *** ChanServ sets mode: +v Nihility
[15:08:03] *** vtunka has quit IRC
[15:09:18] *** aloubyansky has joined #jboss-as7
[15:09:19] *** ChanServ sets mode: +v aloubyansky
[15:10:05] *** frainone has joined #jboss-as7
[15:10:05] *** ChanServ sets mode: +v frainone
[15:10:32] *** smarlow has joined #jboss-as7
[15:10:33] *** ChanServ sets mode: +v smarlow
[15:18:57] <kkhan> Can someone please give me some input on maven picking up the following circular dependency? http://pastebin.com/YRq7mzsh
[15:19:45] <hbraun_> bstans_afk: https://issues.jboss.org/browse/AS7-702
[15:19:46] <jbossbot> jira [AS7-702] Expose server VM metrics through domain model [Open (Unresolved) Feature Request, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-702
[15:19:48] <kkhan> It looks like it thinks org.jboss.as:jboss-as-remoting is bringing in org.jboss.as:jboss-as-server despite me excluding that
[15:19:52] *** vtunka has joined #jboss-as7
[15:19:53] *** ChanServ sets mode: +v vtunka
[15:19:58] *** slaboure has joined #jboss-as7
[15:20:55] <Nihility> jfclere: rmaucher: https://github.com/n1hility/jboss-as/commit/e3bd6fd031022ec038559c73cc30bc86a03557c5
[15:20:56] <jbossbot> git [jboss-as] e3bd6fd.. Jason T. Greene Add support for a static welcome root
[15:21:27] <Nihility> jfclere: rmaucher any objections? it makes the welcome app deploy instantly (no additional time to boot)
[15:21:34] <hbraun_> dmlloyd: good morning
[15:28:18] <rmaucher> Nihility: so much code for something so useless ;) I feel bad for you now
[15:28:52] <Nihility> hahahaha
[15:28:59] <jfclere> yep but it is need :-(
[15:29:11] <jfclere> otherwise MAx complains :D
[15:29:25] <rmaucher> but I like it since we're going to be able to use that as an exemple on how to deploy a webapp with anything using the API
[15:29:31] <alesj> jfclere: when doesn't he complain?
[15:29:32] <rmaucher> (some people say it's impossible)
[15:30:07] <jfclere> alesj: hm... good point: never?
[15:30:16] <alesj> jfclere: exactly :-)
[15:30:27] *** kkhan is now known as kabir_lunch
[15:30:57] <Nihility> yeah not impossible, although you have to be willing to read the code :)
[15:31:45] <Nihility> alesj: yes the problem is sometimes i listen a little bit less
[15:32:10] <alesj> Nihility: i see you're getting old :-) … as this was super fast to code based on Max' complaints … :-)
[15:34:24] <wolfc> would it not be better to add the welcome service from a new subsystem?
[15:34:29] <rmaucher> so, nice hack, I guess ;)
[15:35:38] <Nihility> rmaucher: interesting side effect, is that the auto-gen 404 pages show up once there is a context, i never realized that
[15:35:45] <wolfc> dmlloyd: I got custom provider ejbemb passing
[15:36:13] <rmaucher> Nihility, yes, of course
[15:37:13] <pilhuhn> Nihility Hey, can you tell me when is the next release planned? I can't find the roadmap doc
[15:37:27] <wolfc> dmlloyd: either you consider it another horrendous hack, or a brilliant solution https://github.com/wolfc/jboss-modules/commit/18dc399f1420661a88ade360c2ab123aa666ef80 :-P
[15:37:29] <jbossbot> git [jboss-modules] 18dc399.. Carlo de Wolf Run main in its module class loader
[15:37:32] *** aslak has joined #jboss-as7
[15:37:32] *** ChanServ sets mode: +v aslak
[15:39:03] *** mbg has joined #jboss-as7
[15:39:59] *** mbg has quit IRC
[15:39:59] *** mbg has joined #jboss-as7
[15:41:00] <Nihility> wolfc: yes it could be it's own subsystem, although I think people would look for it in the web config area, it's an interesting idea though
[15:43:40] *** fnasser has joined #jboss-as7
[15:44:03] <hbraun_> maeste: what#s the estimate for the next IJ release?
[15:46:19] <maeste> hbraun_: around the end of the month
[15:47:04] <rmaucher> hbraun_: your "web/http" service is the servlet one ?
[15:47:22] <hbraun_> rmaucher: yes, we can change the name if want
[15:47:50] <hbraun_> rmaucher: not sure if HTTP is obvious
[15:48:17] <rmaucher> not so good IMO
[15:48:25] <hbraun_> rmaucher: what would you suggest?
[15:48:37] <hbraun_> JSP Container?
[15:48:43] <hbraun_> Servlet Engine?
[15:48:47] <hbraun_> JBoss Web?
[15:49:11] *** bstans_afk is now known as bstansberry
[15:49:13] <hbraun_> maybe a name that#s not branded
[15:49:17] <rmaucher> Servlet I think, you have web services next to it
[15:49:29] <hbraun_> ok
[15:49:32] <hbraun_> i can change that
[15:49:54] <bstansberry> hbraun_: AS7-702 ?
[15:49:55] <rmaucher> ok :)
[15:49:56] <jbossbot> jira [AS7-702] Expose server VM metrics through domain model [Open (Unresolved) Feature Request, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-702
[15:50:10] *** kabir_lunch is now known as kkhan
[15:50:13] <hbraun_> rmaucher: thanks for the feedback
[15:50:13] <Nihility> yeah its a good point
[15:50:18] <Nihility> http might not even be used
[15:50:21] <Nihility> it could be AJP
[15:50:46] <Nihility> oh which reminds me
[15:50:51] <hbraun_> rmaucher, Nihility: what about the categories in general?
[15:50:54] <Nihility> we need to figure out what to do about mod_cluster
[15:51:03] <hbraun_> does it make sense to you?
[15:51:03] <hbraun_> +
[15:51:27] <rmaucher> the subsystem is not integrated yet
[15:52:11] <dmlloyd> wolfc: looks great... in fact I thought we were already doing that :)
[15:52:26] <Nihility> hbraun_: Container and Integration im not sure about
[15:52:37] <hbraun_> bstansberry: just asking for a quick status update?
[15:52:40] <wolfc> dmlloyd: I was under the same impression :-)
[15:52:54] <wolfc> I just stumbled over it while debugging the setup
[15:53:07] <bstansberry> hbraun_: in a pile of TODOs
[15:53:10] <hbraun_> Nihility: i can understand that
[15:53:38] *** ALR has joined #jboss-as7
[15:53:39] *** ChanServ sets mode: +v ALR
[15:53:51] <hbraun_> Nihility: integration aslo has resource-adapter and connector
[15:54:09] <hbraun_> Nihility: container also has ejb3 , weld, jpa
[15:55:01] <hbraun_> Nihility: but I am  open for suggestions
[15:55:09] <hbraun_> that's why I posted send a picture
[15:55:30] <hbraun_> integration as in EIS
[15:55:39] <hbraun_> but it#s an overloaded term
[15:57:17] <hbraun_> bstansberry: are you saying you are overloaded with work?
[15:57:19] <Nihility> hbraun_: yeah like technically web services is an integration technology, and Servlet is a container as well
[15:57:45] <Nihility> hbraun_: i am having trouble coming up with better names though
[15:57:51] <bstansberry> hbraun_: nah, just going to be a mad scramble :-)
[15:57:51] <rmaucher> me too ;)
[15:57:52] <hbraun_> Nihility: yes, i was looking for terms people usually refer to
[15:58:09] <hbraun_> but there is difference between us and germany for instance
[15:58:18] <hbraun_> prpobably even between france and germany
[15:58:29] <Nihility> hbraun_: some of these things could be lumped into an EE categora
[15:58:39] <bstansberry> that's what I was thinking
[15:58:43] <hbraun_> yes, I had that one too
[15:58:45] *** vtunka has quit IRC
[15:58:50] <hbraun_> btu then dropped the idea
[15:59:01] <hbraun_> Container was the repacement for EE
[15:59:59] <hbraun_> but if you guys come up with a reasonable set of categories i am more then happy to update the list
[16:00:04] <Jaikiran> dmlloyd: stuartdouglas: what's your thoughts on merging to upstream?
[16:00:08] <Nihility> yeah ill have to think about it
[16:00:24] <hbraun_> we could also localize it
[16:00:26] <dmlloyd> Jaikiran: I'm strongly in favor
[16:00:41] <hbraun_> Nihility: take your time, my shop is open 24/7
[16:00:44] <Jaikiran> me too. technically, the smoke tests and spec tests are passing
[16:00:58] <Jaikiran> as for tck, that's WIP as with the upstream branch
[16:01:12] <dmlloyd> yeah and upstream isn't going to be making any progress
[16:01:22] <Jaikiran> just need to check with stuartdouglas about weld, whether he's OK with that
[16:01:28] <Jaikiran> right
[16:01:30] <dmlloyd> and tdiesler really needs the new modules (even though it's still missing part of his requested patch :()
[16:01:47] <dmlloyd> I'm sure stuartdouglas is already in bed
[16:01:52] *** maeste2 has joined #jboss-as7
[16:01:52] *** maeste2 has joined #jboss-as7
[16:01:52] *** ChanServ sets mode: +v maeste2
[16:01:54] <dmlloyd> but if he gives the OK when he comes on, I"ll do it
[16:02:00] <Jaikiran> cool!
[16:02:02] *** maeste2 has quit IRC
[16:02:05] <dmlloyd> probably about 6 hours is when he usually checks in
[16:02:22] <dmlloyd> he gets up insanely early to go to something called the "gym"
[16:02:29] <dmlloyd> I'm sure I've heard of it :)
[16:02:29] <Jaikiran> ha ha :D
[16:02:48] *** pilhuhn is now known as pil-espresso
[16:03:39] <Nihility> ah i miss the gym
[16:03:48] *** sebersole has joined #jboss-as7
[16:03:48] *** ChanServ sets mode: +v sebersole
[16:04:02] <Nihility> the days of no beer gut!
[16:04:06] <dmlloyd> guys, AS7-782 - should we have a URL handler for jndi?  what does it do?
[16:04:08] <jbossbot> jira [AS7-782] Hudson/Jenkins won't work in AS7b3 [Open (Unresolved) Bug, Major, Jason Greene] https://issues.jboss.org/browse/AS7-782
[16:05:22] <Nihility> i think its a tomcat thing
[16:05:30] <Nihility> rmaucher probably knows what it is
[16:06:20] <Nihility> "Warning: Community will be disabled on 06/30/2011 ("
[16:06:25] <Nihility> wow thats very unprofessional
[16:07:09] <rmaucher> no, we shouldn't probably: the app is likely constructing URLs using string concatenation
[16:07:26] <rmaucher> unless you really don't mind setting the URL stream handler ;)
[16:08:03] <rmaucher> Nihility: "Warning: Community will be disabled on 06/30/2011 (" ?
[16:08:08] <dmlloyd> well just wondering if it's something we should support
[16:08:24] <Nihility> rmaucher: on the jbos.org site, i was looking at a forum
[16:08:24] <dmlloyd> like if tomcat supports it or something
[16:08:26] <rmaucher> we can support it by setting the URL stream handler
[16:08:36] *** ccrouch has joined #jboss-as7
[16:08:36] *** ChanServ sets mode: +v ccrouch
[16:08:37] <dmlloyd> setting the URL stream handler to something else
[16:09:15] <wolfc> Jaikiran, is StatefulSessionSyncInt working?
[16:09:18] <dmlloyd> ?
[16:09:36] <Jaikiran> wolfc: I haven't tried it against tck yet, will do later tonight
[16:10:02] <wolfc> Jaikiran: did you merge or code anything in that enables it?
[16:10:47] <Jaikiran> wolfc: i picked up your latest code in one of my local branches
[16:10:52] <Jaikiran> it hasn't yet been tested though
[16:11:03] <Jaikiran> latest == the one which uses those adapters
[16:11:11] <wolfc> me neither :-D I need to write up a test case for this bit.
[16:11:17] <Jaikiran> :)
[16:11:32] <wolfc> you mean the Lifecycle... thingy?
[16:12:14] <wolfc> that was just experimental test code :-) It doesn't do anything.
[16:12:44] <Jaikiran> the code is experimental but i can use that to setup the sessionsync interceptor and see how it goes
[16:12:48] *** vtunka has joined #jboss-as7
[16:12:48] *** ChanServ sets mode: +v vtunka
[16:12:53] <wolfc> right, that's the idea
[16:12:56] <Jaikiran> yep
[16:13:25] *** dmison has quit IRC
[16:13:38] <Nihility> hmm
[16:13:45] <Nihility> it looks like that hudson url is coming from:        URL url = getServletContext().getResource(resourcePath);
[16:14:21] *** pgier has joined #jboss-as7
[16:14:21] *** ChanServ sets mode: +v pgier
[16:14:52] *** hbraun_ has quit IRC
[16:15:38] *** hbraun has joined #jboss-as7
[16:15:52] <rmaucher> with no manipulation of any sort ? individual URLs have the stream handler set
[16:16:42] *** hbraun has quit IRC
[16:19:14] <Nihility> rmaucher: yes you are correct that is what is happening
[16:19:26] <Nihility> rmaucher: they take that url and add locale shit to it
[16:19:32] <Nihility> which loses the stream handler
[16:19:39] <rmaucher> right, that's the problem
[16:21:18] <rmaucher> but I can try to change that to a file URL if file based (it should be the case in AS)
[16:23:30] <Jaikiran> Nihility: apparently that Warning: Community will be disabled on 06/30/2011 (" is only shown to space admins and not normal users.
[16:23:38] <Nihility> it seems like file, or vfs url if its a vfs resource would be better
[16:24:05] <Nihility> rmaucher: but we can register a custom protocol handler for jbossweb if that makes the code better
[16:26:11] *** smcgowan has joined #jboss-as7
[16:26:12] *** ChanServ sets mode: +v smcgowan
[16:26:27] <rmaucher> ok
[16:30:08] <rmaucher> if there already a stream handler in AS handling all the custom URL protocols ?
[16:30:19] <rmaucher> stream handler factory, rather
[16:33:44] *** hbraun has joined #jboss-as7
[16:34:10] *** ALR has quit IRC
[16:37:42] *** aslak has quit IRC
[16:38:57] *** aslak has joined #jboss-as7
[16:38:57] *** ChanServ sets mode: +v aslak
[16:39:52] *** aslak has quit IRC
[16:42:07] *** clebert has joined #jboss-as7
[16:42:08] *** ChanServ sets mode: +v clebert
[16:42:49] <dmlloyd> yeah rmaucher
[16:42:59] <dmlloyd> jboss modules has a sort of thing to do that
[16:43:36] <dmlloyd> you can add them with org.jboss.modules.Module#registerURLStreamHandlerFactoryModule()
[16:44:05] <dmlloyd> er, well you will once we upgrade to CR1 which will be in about 5-6 hours I think
[16:44:19] <dmlloyd> or maybe CR2 given wolfc's patch & report
[16:44:56] <dmlloyd> wolfc: do you think I should tag CR2 or do you think we should do more testing with it?
[16:45:27] <wolfc> I would like to have another ejbemb test passing, but first I need to sort out my current branch
[16:46:05] <dmlloyd> okay, well I'll ask shelly to do another run with the new stuff and see how far we get
[16:46:31] <rmaucher> dmlloyd: ok that looks nice :)
[16:46:43] <wolfc> my ejbemb isn't merged anywhere
[16:47:25] <wolfc> I need to fish out the hacky bits and keep the real bits
[16:47:34] <dmlloyd> okay
[16:49:25] *** emmanuel has joined #jboss-as7
[16:49:25] *** ChanServ sets mode: +v emmanuel
[16:49:55] *** pil-espresso is now known as pilhuhn
[16:50:21] <Nihility> are those intermittent ejb failures gone in the ejb branch
[16:50:22] <Nihility> ?
[16:50:39] <wolfc> no, that's a ServerController issue
[16:52:56] <Nihility> wolfc: whats the issue?
[16:53:32] <bstansberry> stuartdouglas had a good explanation on a dev thread message last Thur
[16:53:58] <hbraun> maeste: ping
[16:54:16] <maeste> hbraun: pong
[16:54:20] *** emmanuel has quit IRC
[16:54:25] <hbraun> maeste: i know i am annyoing
[16:54:26] <bstansberry> basically races in the JBAS-9010 stuff leading to the ServiceController thinking the service container is settled (and thus safe to return) when it's really not settled
[16:54:28] <wolfc> well, it's a thesis to which I subscribe as well. We haven't been able to prove or disprove it
[16:54:28] <jbossbot> jira [JBAS-9010] Redirected to: https://issues.jboss.org/si/jira.issueviews:issue-xml/AS7-527/AS7-527.xml
[16:54:29] <jbossbot> jira [AS7-527] Provide more comprehensive error messages for missing dependencies [Resolved (Done) Task, Blocker, David Lloyd] https://issues.jboss.org/browse/AS7-527
[16:54:38] <hbraun> maeste: quick question
[16:54:52] <hbraun> maeste: currently looking at your branch
[16:54:57] <maeste> hbraun: shot
[16:55:00] <hbraun> maeste: https://issues.jboss.org/browse/AS7-726
[16:55:02] <jbossbot> jira [AS7-726] create a driver repository service [Reopened (Unresolved) Task, Major, Stefano Maestri] https://issues.jboss.org/browse/AS7-726
[16:55:22] <maeste> hbraun: yup, we already have one
[16:55:25] <hbraun> maeste: i deployed a driver, but it doesn't show up
[16:55:44] <maeste> hbraun: jdbc4 compliant?
[16:55:50] <hbraun> maeste: we already have one? or do your changes incorporate the other one
[16:55:53] <hbraun> maeste: yes
[16:55:57] *** aslak has joined #jboss-as7
[16:55:57] *** ChanServ sets mode: +v aslak
[16:56:06] *** AndyTaylor is now known as Andy_brb
[16:56:12] *** irooskov has quit IRC
[16:56:16] <maeste> hbraun: we already had, but I've added some operations to access it
[16:56:17] *** irooskov has joined #jboss-as7
[16:56:17] *** ChanServ sets mode: +v irooskov
[16:56:28] <maeste> doesn't show up where?
[16:56:36] <hbraun> maeste: like described here: https://issues.jboss.org/browse/AS7-328
[16:56:38] <jbossbot> jira [AS7-328] Provide an operation to retrieve JDBC drivers that are installed as deployments [Resolved (Done) Feature Request, Major, Brian Stansberry] https://issues.jboss.org/browse/AS7-328
[16:56:51] <maeste> hbraun: yup
[16:57:02] <maeste> hbraun: have a look to my mail on ML
[16:57:14] <maeste> hbraun: I've tryied to explain there what I'm adding
[16:57:26] <maeste> hbraun: let me get the subject
[16:57:34] <hbraun> maeste: oh, sorry
[16:57:41] <hbraun> maeste: your are right. I missed that one
[16:57:49] <hbraun> maeste: thanks
[16:57:58] <maeste> hbraun: New xsd and management....
[16:58:06] <maeste> hbraun: that's the subject
[16:58:21] <maeste> hbraun: what driver are you deployng anyway?
[16:58:38] <hbraun> maeste: mysql, but it doesn't show up through your op either
[16:59:00] <hbraun> did deploy it though
[16:59:13] *** jamezp_afk has quit IRC
[16:59:20] <maeste> hbraun: I've tryioed with oracle
[16:59:23] *** hardy_ has joined #jboss-as7
[16:59:27] <hbraun> [Server:server-two] 16:32:14,075 INFO  [org.jboss.as.osgi] (MSC service thread 1-4) Installing deployment: [com.mysql.jdbc:5.1.15,location=mysql-connector-java-5.1.15.jar]
[16:59:30] <maeste> hbraun: mysql version?
[16:59:56] <maeste> hbraun: hmm it seems is not deployng the jdbc driver
[17:00:03] <maeste> let me download that jar
[17:00:36] <hbraun> could it be the osgi subsystem interfering?
[17:00:45] <jbossbot> git [jboss-as] push master 52150c0.. Jason T. Greene Add support for a static welcome root
[17:00:45] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/8646037...52150c0
[17:00:49] <hbraun> i can see this: [Server:server-one] 16:32:14,046 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-2) Install bundle: com.mysql.jdbc:5.1.15
[17:01:08] <hbraun> Nihility: would be nice to have the same feature for the http API endpoint
[17:01:45] <Nihility> hbraun: a welcome page dir?
[17:02:31] <Nihility> hbraun: do you have a splash page you want, or do you want it to just redirect to the console?
[17:02:45] <rmaucher> dmlloyd: ok, so if I add a /META-INF/services/java.net.URLStreamHandlerFactory file in one of the JARs of the web module, containing the classname of my URL stream handler factory, and register the web module, it will work just fine and should fix the "URL concatenation" use case
[17:02:56] <dmlloyd> yeah should
[17:03:15] <hbraun> Nihility: IMO a splash page with a short explanation and a link to the console would be nice
[17:03:45] *** vtunka has quit IRC
[17:03:49] <hbraun> Nihility: but I don't have anything available
[17:04:12] <maeste> hbraun: it seems fine...I have my code a bit messed up. I'll try myself tomortrow
[17:04:33] <hbraun> maeste: it works for you?
[17:05:09] <Nihility> hbraun: i could reuse the same spash
[17:05:13] <maeste> hbraun: no I'm saying it seems fine as jar at first look. I can't try it because I can't compile my branch atm
[17:05:24] <hbraun> Nihility: fine as long as we something there
[17:05:27] <maeste> hbraun: I'll try it tomorrow morning
[17:05:33] <hbraun> maeste: fine
[17:05:34] *** jamezp has joined #jboss-as7
[17:05:40] *** epbernard has joined #jboss-as7
[17:05:40] *** epbernard is now known as emmanuel
[17:05:40] *** ChanServ sets mode: +v emmanuel
[17:05:42] <Nihility> hbraun: im going to ask james cobb for help with out splash page
[17:05:48] <Nihility> ill CC you
[17:05:57] <hbraun> Nihility: +1
[17:07:03] *** pmuir has quit IRC
[17:07:05] <hbraun> maeste: could you send me the oracle driver? then I'll try that one
[17:08:01] *** pmuir has joined #jboss-as7
[17:08:01] *** pmuir has joined #jboss-as7
[17:08:01] *** ChanServ sets mode: +v pmuir
[17:08:22] <maeste> hbraun: sure, sending
[17:08:44] <hbraun> maeste: thanks
[17:10:34] <maeste> hbraun: sent
[17:10:44] <maeste> hbraun: taking a break now ttyl
[17:10:54] <hbraun> maeste: have a nice evening
[17:11:35] *** aloubyansky has quit IRC
[17:14:19] *** adietisheim has quit IRC
[17:15:17] <Nihility> hbraun: yeah osgi breaks jdbc drivers
[17:15:27] <Nihility> hbraun: and well any ee deployment which is a major problem
[17:15:44] <hbraun> Nihility: why don't we move it to a cusotm profiel?
[17:15:46] <hbraun> profile
[17:15:52] <Nihility> dmlloyd: do we have a jira somewhere on this?
[17:16:04] <Nihility> hbraun: we should disable osgi until this is fixed
[17:16:05] *** vtunka has joined #jboss-as7
[17:16:05] *** ChanServ sets mode: +v vtunka
[17:16:05] *** opalka has quit IRC
[17:16:07] <hbraun> Nihility: i thought the problem is fixed already
[17:16:24] <hbraun> i remember it being reported several weeks ago
[17:16:34] <Nihility> yeah its been around for ages
[17:16:40] <Nihility> at least since beta1
[17:16:42] <hbraun> what's the best way to disable it?
[17:16:50] <hbraun> commeting will remove it from xml
[17:17:05] <Nihility> you just remove the subsystem that will do it for sure
[17:17:20] *** irooskov has quit IRC
[17:17:29] <Nihility> yeah ill see if i can find the bug
[17:17:34] <hbraun> yes, but i thought we a proper way to "disable" subsystems, no=?
[17:17:55] <Nihility> hmm not sure
[17:17:59] <Nihility> bstansberry: do we?
[17:18:06] <hbraun> wasn't that part of the requirements?
[17:18:15] <Nihility> probably
[17:18:22] <bstansberry> remove == disable
[17:18:35] <bstansberry> that was my interpretation of the requirement
[17:18:36] *** frainone has quit IRC
[17:18:45] <hbraun> but then it's gone
[17:18:54] <hbraun> how do you "enable" it?
[17:18:59] <bstansberry> you add it
[17:19:02] <hbraun> lol
[17:19:09] <hbraun> that's convinient
[17:19:35] <hbraun> it's like to park your car, just sell it
[17:19:35] <hbraun> +
[17:19:43] <Nihility> hahahaha
[17:19:47] <hbraun> then buy a new one next morning
[17:19:48] <bstansberry> :)
[17:20:11] <Nihility> we should think about that
[17:20:17] <bstansberry> true, but maybe more like, I live in NYC and am moving to LA and I have this car that I need to get there....
[17:20:36] <hbraun> haha
[17:20:51] <dmlloyd> well we could allow disabling subsystems however the subsystem would still have to be loaded
[17:20:54] <dmlloyd> in that case
[17:20:58] <dmlloyd> the extension I mean
[17:21:24] <bstansberry> basically every subsystem would have to have an "enabled" attribute and handle it consistently
[17:21:32] <dmlloyd> yeah
[17:21:57] <hbraun> but generally speaking, why don't we move osgi to a custom profile?
[17:22:08] <Nihility> yeah that is what i was going to do
[17:22:12] <Nihility> if the bug is not fixed
[17:22:15] <dmlloyd> because we don't have custom profiles!
[17:22:19] <dmlloyd> we just have the default
[17:22:21] <Nihility> it becomes osgi.xml
[17:22:30] <hbraun> i mean that's what build profile in the first place
[17:22:46] <Nihility> and to use it you have to have -server-config osgi.xml
[17:22:47] <Nihility> to get it
[17:22:56] <Nihility> until the bug is fixed
[17:23:01] <jpederse> if we are going to allow that from the UI, the dependencies between the subsystems should be displayed somehow
[17:23:23] <hbraun> jpederse: what do you mean? disabling of subsystems?
[17:23:25] <jpederse> "I don't need JCA => Disable", "Eh, what ? My datasources are gone"
[17:23:57] <hbraun> jpederse: yeah, that#s a general problem
[17:24:00] <jpederse> hbraun: removing them at run-time
[17:24:45] <hbraun> i didn't refer to runtime. but even disabling it when everything is stopped, will actually remove the commented parts
[17:24:58] <hbraun> it's hard to add it later on
[17:25:03] <jpederse> hbraun: we can use the services dependecies though to give a good idea
[17:25:04] <hbraun> if you don't have a copy
[17:25:21] <jpederse> hbraun: ah, that case
[17:25:34] <hbraun> your example is more sophisticated
[17:25:42] <hbraun> i don't think we need that atm
[17:26:15] <Nihility> the general goal for subsystems is to make the as independent as possible, so that you don't have many interdeps
[17:26:19] <jpederse> just something to keep in mind...
[17:26:20] <Nihility> and support more optional configs
[17:26:35] <Nihility> its not always possible though
[17:26:40] <Nihility> like EE has to have naming
[17:27:10] <jpederse> an install wizard with the overall rules would help a lot
[17:27:21] *** maeste has quit IRC
[17:27:27] <jpederse> if people really wants custom profiles
[17:28:32] <Nihility> btw there is a requirement
[17:28:39] <Nihility> to have basic validation of this issue
[17:28:54] <Nihility> preventing a user from picking an invalid profile
[17:29:42] <hbraun> Nihility: you are right about the osgi issue
[17:29:55] <hbraun> Nihility: it does still mess with the driver deployment
[17:30:04] <hbraun> Nihility: can we raise it to blocking?
[17:30:32] <Nihility> need to find the jira
[17:30:36] <hbraun> i.e. the mysql driver doesn't deploy because it contains a bundle descriptor
[17:30:44] <hbraun> not sure if it's the same issue
[17:31:22] <hbraun> it get's picked up by the OSGI subsystem, but it#s not deplyoed as a service
[17:31:50] <Nihility> yeah hq had the same issue
[17:31:54] <Nihility> very annoying
[17:32:08] <Nihility> ultimately the problem is that osgi should not "take over"
[17:32:16] <Nihility> it should only be augmenting our module definitions
[17:37:06] <dmlloyd> naming arguably shouldn't be a subsys
[17:37:11] <dmlloyd> everything needs it, everything uses it
[17:37:15] <dmlloyd> and there's basically no config for it
[17:37:22] <dmlloyd> should just bake it in
[17:38:03] *** smarlow has quit IRC
[17:38:19] <hbraun> dmlloyd: on a related note: the only thing I do require is a way to list the JNDI tree
[17:38:30] <hbraun> not sure if that requires it to be a subsystem
[17:39:13] <jpederse> hbraun: a cool thing would be to be able to list the JNDI view of a deployment too
[17:39:26] <jpederse> hbraun: if the overall one would just list the general stuff
[17:40:27] <dmlloyd> how would the tree even look
[17:40:34] <dmlloyd> I mean we've got five namespaces
[17:40:52] <hbraun> jpederse: there is this one: https://issues.jboss.org/browse/AS7-367
[17:40:54] <jbossbot> jira [AS7-367] Expose deployment details via the domain management API [Open (Unresolved) Feature Request, Critical, Emanuel Muckenhuber] https://issues.jboss.org/browse/AS7-367
[17:41:10] <hbraun> jpederse: you may want to comment on it
[17:41:15] <dmlloyd> jboss is AS-wide, global is probably AS-wide but might not be, app pertains to TLDs, module pertains to deployments and subdeployments, and comp pertains to individual components
[17:41:28] <dmlloyd> you'd need a tree for namespaces which includes deployments
[17:41:45] <bstansberry> IIRC that's the way it works in AS 4/5/6
[17:42:19] <bstansberry> not visually a tree; separate sections for global vs various deploymetns
[17:44:14] *** mlinhard has quit IRC
[17:46:38] <jpederse> yeah, just a multi-root'ed tree
[17:47:17] <jpederse> for each of the "categories" that makes sense in that context
[17:48:46] *** rawbdor has quit IRC
[17:55:07] <Jaikiran> dmlloyd: btw, you might want to pull these fixes to your branch against which the tck runs https://github.com/jaikiran/jboss-as/commits/new-ee-framework
[17:57:41] <dmlloyd> got it, thanks
[18:00:21] *** ccrouch has quit IRC
[18:00:46] *** hardy_ has quit IRC
[18:01:20] *** torben has quit IRC
[18:01:25] *** mmoyses is now known as mmoyses_
[18:01:50] *** vtunka has quit IRC
[18:04:07] *** pilhuhn is now known as pil-dinner
[18:04:48] *** Andy_brb is now known as AndyTaylor
[18:05:39] *** alesj has quit IRC
[18:14:16] *** jcosta has quit IRC
[18:24:07] *** alexsmirnov has joined #jboss-as7
[18:26:34] *** jfclere has quit IRC
[18:26:58] <Nihility> AS7-796
[18:26:59] <jbossbot> jira [AS7-796] OSGi bypasses other DUPs when osgi metadata is found [Open (Unresolved) Bug, Blocker, Thomas Diesler] https://issues.jboss.org/browse/AS7-796
[18:27:05] <Nihility> there i have a master issue now
[18:27:20] <hbraun> +1
[18:27:59] *** smarlow has joined #jboss-as7
[18:27:59] *** ChanServ sets mode: +v smarlow
[18:32:58] <rmaucher> dmlloyd: so AS 7 does not have a recent jboss-modules in yet
[18:34:29] <dmlloyd> yeah in a few hours it will
[18:34:51] <dmlloyd> waiting for stuartdouglas to wake up first to chat about a couple things
[18:35:47] <rmaucher> ok :)
[18:37:38] *** slaboure has quit IRC
[18:42:19] <rmaucher> where do you recommend I place the call to register ? (calling it more than once would be bad)
[18:43:29] <dmlloyd> some static init block is probably best
[18:43:29] *** jamezp has quit IRC
[18:44:31] <rmaucher> ok
[18:46:31] *** jamezp has joined #jboss-as7
[18:53:03] *** mmoyses_ is now known as mmoyses
[18:54:32] *** stliu has quit IRC
[19:02:09] *** ccrouch has joined #jboss-as7
[19:02:09] *** ChanServ sets mode: +v ccrouch
[19:03:01] *** miclorb_ has joined #jboss-as7
[19:04:46] *** frainone has joined #jboss-as7
[19:04:46] *** ChanServ sets mode: +v frainone
[19:11:19] <mmoyses> aslak: ping
[19:11:36] *** galderz has quit IRC
[19:12:17] *** galderz has joined #jboss-as7
[19:12:17] *** ChanServ sets mode: +v galderz
[19:21:11] *** ccrouch has quit IRC
[19:25:32] *** hbraun has quit IRC
[19:26:31] *** clebert has quit IRC
[19:30:28] *** pmuir has quit IRC
[19:39:57] *** asaldhan has joined #jboss-as7
[19:39:58] *** ChanServ sets mode: +v asaldhan
[19:41:37] *** clebert has joined #jboss-as7
[19:41:37] *** ChanServ sets mode: +v clebert
[19:42:55] *** ALR has joined #jboss-as7
[19:42:55] *** ChanServ sets mode: +v ALR
[19:48:06] *** alexsmirnov has quit IRC
[19:49:00] <aslak> mmoyses, heya
[19:49:30] <mmoyses> aslak: hi. do you a few minutes to talk about arquillian?
[19:49:48] <aslak> mmoyses, sure, join #jbosstesting :)
[19:50:50] *** alexsmirnov has joined #jboss-as7
[19:52:08] <bobmcw> would it be wrong to ask for JMS{Queue,Topic}Service to be consistently public?
[19:52:22] <bobmcw> I copied sources into my tree for now
[19:52:33] <bobmcw> but I'd like to be able to use them from jboss-as-messaging
[19:52:46] <bobmcw> JMSTopicService is mostly public, JMSQueueService is pkg-protected
[19:52:56] <dmlloyd> to create your own you mean?
[19:53:00] <bobmcw> yah
[19:53:14] <dmlloyd> I guess that's reasonable, though they'll be unmanaged
[19:53:20] <bobmcw> right, that's cool
[19:53:28] <dmlloyd> in which case their service namespace should be made to not conflict
[19:53:32] <dmlloyd> with anything
[19:53:45] <bobmcw> can a deployment manipulate the ModelNode stuff to do a QueueAdd?
[19:53:58] <bobmcw> from a Service or a DeploymentUnitProcessor?
[19:53:58] <dmlloyd> no, deployment processors cannot initiate management changes
[19:54:05] <dmlloyd> nor can services
[19:54:11] <dmlloyd> that's the two places you can't do it :)
[19:54:21] <dmlloyd> (DUPs are actually part of Service.start())
[19:54:24] <bobmcw> yah, we allow apps to stand up topics/queues for themselves
[19:54:51] <bobmcw> when you say un-managed, meaning you won't be able to find them in JON/console?
[19:55:07] <dmlloyd> right
[19:55:14] <dmlloyd> well sort of
[19:55:27] <dmlloyd> you might be able to find it in the console but you won't be able to do much with them
[19:55:46] <bobmcw> basic operations, like start/stop?
[19:55:49] <bobmcw> mbean-esque?
[19:56:02] <bobmcw> queries of attributes?
[19:56:09] <dmlloyd> just queries probably
[19:56:13] <bobmcw> k
[19:56:23] <dmlloyd> some operations maybe but runtime-only, not configuration-affecting
[19:56:33] <bobmcw> 'k
[19:56:38] <bobmcw> that's fine by me
[19:59:42] <bobmcw> 'k, prefixing unit.getServiceName() to a regular naming scheme
[20:00:21] *** slaboure has joined #jboss-as7
[20:01:15] *** AndyTaylor has quit IRC
[20:05:01] *** Jaikiran has quit IRC
[20:06:17] *** jpederse has quit IRC
[20:18:12] <mmoyses> bstansberry: kkhan: please pull https://github.com/mmoyses/jboss-as/commit/6ac93d55ba177053ba9b385fa8d1210d307d3bf4 when possible
[20:18:13] <jbossbot> git [jboss-as] 6ac93d5.. Marcus Moyses test case for custom login module
[20:19:14] *** sguilhen has joined #jboss-as7
[20:22:19] <bobmcw> AS7-798
[20:22:21] <jbossbot> jira [AS7-798] JMSTopicService and JMSQueueService made public for use outside of jboss-as-messaging [Open (Unresolved) Bug, Major, Jason Greene] https://issues.jboss.org/browse/AS7-798
[20:25:37] *** kkhan has quit IRC
[20:27:56] <bobmcw> dmlloyd: does Beta3 export JNDI that I can connect with some client outside of AS?
[20:28:08] <bobmcw> I used to use the ancient jnp-client or somesuch
[20:28:41] *** miclorb_ has quit IRC
[20:28:52] *** sannegrinovero has quit IRC
[20:29:11] <dmlloyd> no, there is no remote JNDI right now
[20:29:20] <dmlloyd> you looking for some RMI-ish kind of hook?
[20:29:49] <bobmcw> my specific use-case is a unit test trying to grab a javax.jms.Queue from the running AS's JNDI yeah
[20:30:24] <bobmcw> jms client outside of the AS environment
[20:30:41] <bobmcw> seems... useful?
[20:31:40] *** galderz has quit IRC
[20:32:17] <dmlloyd> well there's a problem there
[20:32:22] <dmlloyd> well a complication really
[20:32:27] <dmlloyd> HQ has a remote access protocol
[20:32:50] <dmlloyd> so like if you want to remotely access a queue there's a way to do it, by adding a server and having the remote side act as a client
[20:32:53] <dmlloyd> outside of JNDI
[20:33:12] <dmlloyd> if you did it RMI-style though, instead you'd be making RMI-style calls into the server and then relaying the request to HQ
[20:33:17] <bobmcw> that's really what we're going to tell people to do?
[20:33:18] <dmlloyd> it's considerably more fragile
[20:33:24] <dmlloyd> no, not necessarily
[20:33:35] <dmlloyd> but we're also not necessarily going to just give them a remote interface either
[20:33:56] <dmlloyd> implementation-wise the HQ client connection is the best thing we can end up with
[20:34:10] <bobmcw> isn't there this whole ConnectionFactory dealio that's part of the spec?
[20:34:22] <dmlloyd> realistically maybe a Remoting-based tunnel is better, but not necessarily via method call RPC
[20:34:23] <bobmcw> look it up in JNDi?
[20:34:36] <bobmcw> or do we constrain that to be JNDI-only-within-the-AS
[20:34:36] <dmlloyd> yeah but you're assuming that the client will have the same JNDI as the server
[20:34:51] <bobmcw> yes, exactly, I'd like to point my client at the server's JNDI
[20:35:14] <bobmcw> it's the whole way I hook my client into that environment, no?
[20:35:17] <dmlloyd> JNDI, despite how it may appear from previous ASes, is not a network protocol
[20:35:31] <dmlloyd> think of it as an in-memory hashmap
[20:35:47] <dmlloyd> for remote clients we Do Stuff to copy certain entries from server to client upon request
[20:35:50] <bobmcw> sure, but there's still an unsatified use-case here, no?
[20:35:56] <bobmcw> especially given JMS is about integrating stuff
[20:36:08] <bobmcw> trapping it within the island of a cluster (or even just a single AS?) seems goofy
[20:36:28] <dmlloyd> yeah but it's really fragile to just stick all of JNDI in some RMI registry
[20:37:10] <bobmcw> so, is this something that will eventually be solved, or do I drop STOMP into HornetQ, and just assume that's my entry point from The Real World?
[20:38:00] <dmlloyd> the "what" of getting remote client access to an in-server queue - that's a "maybe", with the qualifier that JNDI might not be the way to do that (or it might be, just not exactly the same way as before)
[20:38:20] <dmlloyd> the "what" of having remote JNDI - that's a "definitely" but also definitely not the same as before
[20:38:48] <bobmcw> I don't feel like I know what your answer means. :)
[20:39:07] <dmlloyd> probably because you're looking for something you can do immediately, and there is no such thing yet
[20:39:28] <dmlloyd> whereas for us, what we are going to do is more or less the same as what we are doing now :)
[20:39:43] <bobmcw> I get that.  It's more, I'm not sure if "grabbing a queue from outside the AS" is something that will be solved, however you solve it.
[20:39:55] <bobmcw> or if we're theoretically explaining to users "you don't really want to do that"
[20:40:22] <bobmcw> I don't really care about naming, specifically, that's just how I did it in the past
[20:40:22] <dmlloyd> well it hasn't really been discussed much.  But I'd be inclined to say "yeah we should probably do that", pending smarter minds like Nihility to lend some color to that viewpoint
[20:40:37] <bobmcw> I just want to be able to grab a destination, and publish/receive stuf from outside the AS
[20:41:06] <bobmcw> or some other explanation as to how people should interact with messaging from outside the utopia of the AS environment
[20:41:12] <dmlloyd> also folks like clebert or AndyTaylor should probably weigh in on the expected client usage patterns
[20:43:04] <Nihility> im not sure it can work
[20:43:09] *** pferraro has quit IRC
[20:43:43] <clebert> ?
[20:43:56] <Nihility> stuffing a jms queue into jndi
[20:43:57] <bobmcw> am I wrong thinking that messaging is about integration?  going outside the boundaries of the AS?
[20:44:00] <Nihility> and then accessing it remotely
[20:44:05] <Nihility> and expecting it to work
[20:44:12] <bobmcw> it works in AS6.  It worked in hornetq-standalone.
[20:44:17] <dmlloyd> via RMI or RMI-like mech is a definite no
[20:44:30] <Nihility> it grabbed configuration
[20:44:34] <Nihility> from jndi
[20:44:40] <Nihility> and used that to constuct a local hq connection
[20:44:57] <Nihility> the server isnt an intermediary
[20:45:02] <dmlloyd> but, it could maybe work if we have an SPI for remote JNDI and we stuff a special HQ connection factory thing which knows to either (1) grab a remote connection to the server or (2) use the existing R3 connection to tunnel HQ protocol back
[20:45:22] <Nihility> weve never tunneled stuff like that
[20:45:31] <dmlloyd> well we've never had R3 before either
[20:45:37] <Nihility> actually the funny thing is its an incredibly slow way
[20:45:41] <Nihility> to talk to a remote service
[20:45:44] <dmlloyd> over method calls sure
[20:45:45] <clebert> JNDI remote? we just have clients connecting to JNDI and downloads CFs, Topic, Queues... what's the issue?
[20:45:45] <Nihility> rmi invocation to jndi
[20:45:47] <bobmcw> okay, instead of JNDI lookups, is this something I should be using org.hornetq.Client or somesuch, and ...directly pointing at the HQ inside AS?
[20:45:49] <dmlloyd> but R3 isn't method calls, it's byte streams
[20:45:50] <Nihility> then lookup config
[20:45:57] <Nihility> then do a different remote call to the server
[20:46:29] <bobmcw> I dont care about wire, honestly.  I just have a script that wants to get a connection to the HQ, and send some messages
[20:46:44] <bobmcw> what's the answer to that?  I'm surely not the only person who wants this.
[20:47:01] <bobmcw> "you don't" is a goofy-ass answer
[20:47:04] <clebert> Nihility: Clients can just lookup to JNDI and download the factories, right?
[20:47:09] <clebert> Nihility: We have to support this...
[20:47:11] <dmlloyd> no clebert
[20:47:13] <bobmcw> clebert: dmlloyd says no
[20:47:17] <dmlloyd> not exactly
[20:47:21] <clebert> dmlloyd: that's a major issue then
[20:47:23] <dmlloyd> we don't stuff JNDI with serializable stuff
[20:47:25] <dmlloyd> well just stop
[20:47:30] <dmlloyd> you're all jumping to conclusions
[20:47:35] <dmlloyd> you're mixing up "what" with "how"
[20:47:44] <clebert> dmlloyd:  we have requirements from customers on EAP
[20:47:50] <clebert> that will have to use JNDI for at least X years
[20:47:51] <dmlloyd> just stop for a moment
[20:47:54] <dmlloyd> you're getting confused!
[20:48:05] * bobmcw stops
[20:48:07] <dmlloyd> okay so we're not stuffing factories into JNDI and expecting them to be exactly serialized on the server and deserialized on the client
[20:48:23] <dmlloyd> however we WILL have remote JNDI obviously, else we'll never pass TCK
[20:48:29] <dmlloyd> it's just going to work differently
[20:48:39] *** stansilvert has quit IRC
[20:48:45] <dmlloyd> client JNDI isn't an RMI mirror of the server JNDI
[20:49:06] <dmlloyd> it's a separate, in-memory-only naming store which is populated via a JNDI client mechanism that talks over R3
[20:49:19] <dmlloyd> that said it's populated with whatever we want
[20:49:20] *** galderz has joined #jboss-as7
[20:49:20] *** ChanServ sets mode: +v galderz
[20:49:28] <bobmcw> allowing my client code to still get an InitialContext, and lookup, and work?
[20:49:32] <dmlloyd> yes
[20:49:37] <bobmcw> CR1?
[20:49:42] <dmlloyd> hmmmm maybe
[20:49:47] <Nihility> probably not
[20:49:58] <clebert> dmlloyd:  a separate note on that... we still need to support the old format...  old clients should be able to connect to AS7.. even if we add extra config for that
[20:50:10] *** miclorb has joined #jboss-as7
[20:50:22] <dmlloyd> that's a separate issue clebert, and it's in PM's court right now
[20:50:52] <clebert> dmlloyd: Yes.. it's a separate note as I said.. just wanted to mention
[20:51:01] <dmlloyd> so if we create a local queue on the server and bind it into JNDI, we can also tell the remote JNDI thing that at *this* name you should create a remote queue pointing at this server instance (or, maybe, tunneled over R3)
[20:52:01] <bobmcw> yeah, that's cool, sounds preferable, even, from my rubyist POV
[20:52:10] <bobmcw> now, just trying to figure roadmap/timing/schedule
[20:52:27] <bobmcw> plus we have a boatload of integration tests that relied on it, so hard to verify we actually work on AS7
[20:52:43] <Nihility> we are shooting for web profile compliance (and beyond ) for 7.0
[20:52:44] *** galderz has quit IRC
[20:53:01] <bobmcw> that doesn't include this naming magic, or does?
[20:53:28] <bobmcw> and iff not, what sorta month should I look forward to it
[20:53:37] <Nihility> directly remote connectivity is something we plan to support (direct access to EJB3), the jndi case falls more to the realm of application client
[20:53:40] * bobmcw is wearing his own TDM hat now, apparently
[20:53:43] <Nihility> whch is a full profile thing
[20:53:52] <bobmcw> Nihility: dates!
[20:54:59] <Nihility> if we dont have it in 7.0 (which is tight enough as it is), it would be in one of the early 7.1 builds
[20:55:20] <Nihility> 7.1 is fall timeframe
[20:55:39] <Nihility> 7.0 Cr1 iwas moved to June 15
[20:56:55] <Nihility> anyway the problem with the passed client approach
[20:57:18] <Nihility> is that we just serialize whatever it is
[20:57:21] <Nihility> and hope it works
[20:57:24] <Nihility> passed/past
[20:57:26] <bobmcw> I trust you guys to have the right approach, I only have use-cases
[20:57:36] <Nihility> thats why minor vers break compat
[20:57:46] <Nihility> all it takes is for someone to add a field
[20:58:35] <Nihility> the majority of the stuff on the server
[20:58:47] <Nihility> is not really accessible to the client
[20:59:05] <Nihility> like i cant remotely access the servers TransactionManager
[20:59:11] <Nihility> etc etc
[20:59:17] <bobmcw> fucking type-safety!
[20:59:26] <Nihility> in fact TransactionManager should point to the clients manager
[20:59:27] * bobmcw goes back to his ruby
[20:59:32] <jc3> bobmcw: amen, bro
[20:59:36] <Nihility> hahaha
[20:59:46] *** miclorb has quit IRC
[21:00:00] <Nihility> yeah so basically we want to move more towards a snapshot/replicated model
[21:00:08] <Nihility> and thats why its not there yet
[21:00:22] <Nihility> we could stick rmi ontop of jndi and have that done in like 3 days
[21:00:31] <Nihility> but we would still have the same issues
[21:01:16] <Nihility> so anyway the best approach for now is to just configure hq to talk to the queue
[21:01:22] <Nihility> then you save a network round trop
[21:01:33] *** jpederse has joined #jboss-as7
[21:01:39] *** jpederse has joined #jboss-as7
[21:03:41] *** hardy_ has joined #jboss-as7
[21:06:18] *** jamezp is now known as jamezp_afk
[21:08:22] *** hardy_ has left #jboss-as7
[21:13:54] *** darranl has quit IRC
[21:25:24] *** mbg has quit IRC
[21:33:29] *** jamezp_afk has quit IRC
[21:39:14] *** slaboure has quit IRC
[21:41:25] *** mgoldmann has quit IRC
[21:41:54] *** sannegrinovero has joined #jboss-as7
[21:41:54] *** ChanServ sets mode: +v sannegrinovero
[21:54:42] *** pferraro has joined #jboss-as7
[21:54:42] *** ChanServ sets mode: +v pferraro
[21:57:06] *** opalka has joined #jboss-as7
[21:57:06] *** opalka has joined #jboss-as7
[21:57:06] *** ChanServ sets mode: +v opalka
[21:59:34] *** slaboure has joined #jboss-as7
[22:01:12] *** jamezp has joined #jboss-as7
[22:03:50] <tdiesler> Nihility, I commented on AS7-796
[22:03:52] <jbossbot> jira [AS7-796] OSGi bypasses other DUPs when osgi metadata is found [Open (Unresolved) Bug, Blocker, Thomas Diesler] https://issues.jboss.org/browse/AS7-796
[22:03:55] *** slaboure has quit IRC
[22:10:24] <Nihility> tdiesler: does your new branch register a module attachement?
[22:13:33] *** slaboure has joined #jboss-as7
[22:14:19] *** opalka has quit IRC
[22:14:51] <tdiesler> Nihility, the thing is that a "module" only comes into life when a Bundle reaches RESOLVED state
[22:15:14] <tdiesler> Nihility, many Bundles can be INSTALLED without having an associated "module"
[22:15:34] *** slaboure has quit IRC
[22:15:56] <jbossbot> git [jboss-as] push master 1caa2a6.. bstansberry at jboss dot com Control testsuite execution with -DskipTests
[22:15:56] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/52150c0...1caa2a6
[22:16:03] <tdiesler> Nihility, a DUP that needs to access a Bundle's module should somehow wait for this dependency to get resolved
[22:16:52] <Nihility> tdiesler: ah yeah so the issue is that many of the deployers are looking for a Attachments.MODULE, which wont be there, even though its supposed to be by the time POST_MODULE comes around
[22:17:02] *** pferraro has quit IRC
[22:17:18] <tdiesler> Nihility, which might not happen because of some resolver error. I feel that this does not play with the notion of "all processing done at deploy time"
[22:19:08] <tdiesler> Nihility, I thinks DUPs cannot be ignorant of the fact that they may be dealing with a Bundle, which has its module created a the discrtion of the OSGi framework. i.e. as a result of a class load or some other resolution trigger
[22:19:40] <Nihility> tdiesler: Can the osgi phases align with our phases, thats why we have deps between them like that
[22:19:41] <Nihility> ?
[22:20:17] <Nihility> or is it the reverse problem
[22:20:35] <jpederse> tdiesler: did you try the MySQL JDBC driver ? otherwise there is a use-case...
[22:21:16] *** sannegrinovero has quit IRC
[22:21:21] <Nihility> like i guess what im asking is can the osgi bundle install phase be in POST_MODULE then
[22:21:26] <Nihility> ?
[22:21:47] <jpederse> Nihility: ah, you beat me to it...
[22:22:02] <tdiesler> jpederse, I solved the general problem of using just one ModuleLoader such that it is possible to create dependencies beteen OSGi deployments and others
[22:22:21] <tdiesler> The MySQL driver I did not test explicitly
[22:23:02] <dmlloyd> yeah this does violate various deployer contracts
[22:23:22] <tdiesler> Nihility, it would be wrong to create a module from an OSGi Bundle.
[22:23:40] <dmlloyd> does OSGi not create a module once everything is resolved?
[22:23:53] <dmlloyd> note that deployment doesn't have to be a one-time thing
[22:23:57] <Nihility> tdiesler: these things are using a module they arent changing them
[22:24:02] <dmlloyd> you can rewind deployment to eallier phases at any time
[22:24:06] <tdiesler> in the "normal way". the OSGi metadata determins the dependencies and scope of visible resources
[22:24:30] <Nihility> basically anything POST_MODULE and after needs to do classloading
[22:24:42] <Nihility> so if we dont have a classloader all kinds of things will fail
[22:25:39] <dmlloyd> yeah if you depend on something external before proceeding, you can do that via phase dependencies
[22:25:51] <dmlloyd> that'll prevent the deployment from progressing until the external condition (service) is satisfied
[22:26:11] <Nihility> thats why im wondering if its just a phase alignment thing
[22:26:17] <Nihility> like bundle install could happen before
[22:26:17] <tdiesler> Nihility, when you (hot)deploy an OSGi Bundle you will not have a classloader. Possibly much later, the framework decides to resolve the Bundle. At that time the classloader (and in our case the module) will be created
[22:26:19] <Nihility> oops
[22:26:22] *** miclorb has joined #jboss-as7
[22:26:38] <dmlloyd> tdiesler: then resolution should be tied to POST_MODULE
[22:26:53] <dmlloyd> in other words, the deployment for an OSGi bundle doesn't proceed past POST_MODULE until after resolution
[22:27:07] <Nihility> then deployment will never complete though
[22:27:10] <Nihility> thats the issue
[22:27:11] <dmlloyd> and if a bundle is de-resolved for whatever reason, then the deployment should be rolled back
[22:27:16] <dmlloyd> to the earlier phase
[22:27:24] <dmlloyd> yeah but if that's how it works, then that's how it works
[22:27:36] <dmlloyd> if there's a resolver error then presumably OSGi will report it
[22:27:47] <dmlloyd> and container stability detection will still work
[22:27:58] <Nihility> if a user deploys a bundle it will block forever
[22:28:06] <Nihility> until it hits a timeout
[22:28:12] <dmlloyd> no it won't
[22:28:22] <dmlloyd> if the bundle can't be resolved, the container will become stable
[22:28:37] <dmlloyd> because the deployer would use dependencies to sync with OSGi
[22:28:40] <dmlloyd> (not blocking)
[22:28:45] <dmlloyd> (which is not allowed)
[22:28:46] <Nihility> oh i see what you are saying
[22:28:49] <Nihility> an unresolved dep
[22:28:55] <Nihility> to allow it to move on
[22:28:58] <Nihility> that might rollback though
[22:29:01] <dmlloyd> right, but normally the bundle would be resolved
[22:29:08] <Nihility> actually in the default case it would rollback
[22:29:23] <dmlloyd> yeah well if the user is deploying an unresolved OSGi bundle, then...
[22:29:23] <Nihility> well it sounded like tdiesler is saying bundles "lazily" resolve
[22:29:43] <Nihility> tdiesler: when a deploy is completed is the bundle installed "normally"
[22:29:44] <dmlloyd> if it's lazy, in the service sense, then it won't prevent things from returning
[22:29:46] <tdiesler> dmlloyd, actually not. In the normal case a bundle would only resolve when triggered to do so
[22:30:04] <Nihility> ah ok that answers my question
[22:30:06] <dmlloyd> we could easily make the latter deployment phases LAZY or ON_DEMAND
[22:30:19] <tdiesler> A user would typically deploy a set of bundles. One or more BundleActivators would trigger the resolve
[22:30:29] <dmlloyd> I mean if we're going to align this at all, this is the way to do it
[22:31:03] <tdiesler> Bbut only when the Bundle is explicitly started. If not started it won;t have a classloader for a long time
[22:31:15] <Nihility> tdiesler: to give a concrete use case here, weld has to see class instances before it can install services
[22:31:19] <jpederse> as long as the MySQL use-case is covered I'm happy
[22:31:49] <Nihility> hmm interesting problem then
[22:31:56] <Nihility> that means if i deploy mysql as a bundle
[22:31:59] <Nihility> i have to start it
[22:32:14] <Nihility> (which it is a bundle because they included osgi manifest stuff in there)
[22:32:16] <tdiesler> or load a class from irt
[22:32:55] <jpederse> tdiesler: yeah, but we need to load classes from JBoss Modules
[22:33:01] <dmlloyd> well presumably if we deploy a driver, our requirement will cause it to become resolved
[22:33:05] <tdiesler> if you declare a dependency on the mysql bundle and subsequently try to load a class from it - you trigger the bundle resolution
[22:33:09] <dmlloyd> or, it should
[22:33:09] <Nihility> hmmm
[22:33:10] <jpederse> tdiesler: the deployment is under modules/ - not bundles/
[22:33:26] <Nihility> i think the problem is our deployer chain might unintentionally activate every deployment
[22:33:31] <Nihility> which is a problem as well
[22:33:54] <Nihility> in the driver case we can at least only trigerr if the service file is present
[22:34:00] <dmlloyd> we could make the latter phases be LAZY/ON_DEMAND
[22:34:14] <Nihility> but other things need to look at classes let me see
[22:34:18] <dmlloyd> and move the SPI service(s) stuff earlier in the chain, making it LAZY/ON_DEMAND as well
[22:34:49] <tdiesler> Nihility, a resource load would also trigger bundle resolution
[22:34:56] <jpederse> tdiesler: our branch is here if you want to try - https://github.com/maeste/jboss-as/tree/IJ-CR1
[22:37:15] <Nihility> yeah like bean validation for example
[22:38:09] <Nihility> hmm
[22:38:22] <Nihility> that one might not happen since its lazy
[22:38:41] <tdiesler> Nihility, would it be possible to do stuff that requires a classloader and is expected to work with bundles does this in a clallback as a result of the classloader becomming available?
[22:39:17] <dmlloyd> we should do this via dependencies, not a callback
[22:39:43] <tdiesler> i.e. the DUP does not trigger the resolution but gets called back as a result of a successful resolution at some point in time
[22:39:44] <dmlloyd> if the class loader is produced outside of the deployer chain then it should be a service upon which the module phase depends
[22:39:58] <dmlloyd> sure, then it could be a service
[22:40:30] <dmlloyd> it could be ON_DEMAND or LAZY
[22:40:30] <tdiesler> dmllyd, sure as a service dependency but same thing
[22:40:34] <Nihility> well here is the issue though
[22:40:40] *** wolfc has quit IRC
[22:40:47] <Nihility> in some cases we want to force the bundle to start
[22:40:57] <Nihility> like the driver is a good example
[22:41:01] <dmlloyd> yeah, if it were a service then the service start could trigger it
[22:41:13] *** rmaucher has quit IRC
[22:41:14] <dmlloyd> async service start would give the callback that thomas needs
[22:41:42] <Nihility> if its a jdbc driver it needs to be started so that it can be available to jca right
[22:41:54] <jpederse> Nihility: there is no Bundle-Activator in the MySQL JDBC driver...
[22:41:56] <dmlloyd> it needs to be installed, not necessarily started
[22:42:01] <dmlloyd> it could be lazy as well
[22:42:11] <Nihility> ok installed
[22:42:21] <jpederse> Nihility: it is only metadata for classloading...
[22:42:33] <dmlloyd> so we just make sure those services are created early in processing, with a dependency on the later phases
[22:42:36] <dmlloyd> INSTALLED or whatever
[22:42:42] <dmlloyd> then they can be LAZY
[22:42:45] <tdiesler> jca would simply need to do a classload from the driver
[22:43:03] <dmlloyd> so if nothing uses it, it would never be installed, but if something uses it, it would trigger the bundle install
[22:43:11] <dmlloyd> without any special knowledge of OSGi
[22:44:02] <dmlloyd> the only remaining question would be how to implement that bundle resolver service's stop() method, to force "unresolution"...
[22:45:27] <jpederse> tdiesler: drivers are loaded based on their services/...Driver definition - and linked with the datasource deployment based on the JBoss Modules definition
[22:45:35] <tdiesler> I think it slightly different. Jca gets INSTALLED the driver (bundle) gets INSTALLED. Jca has a classlaoder associated, the driver not. At some point Jca tries to load a class of resource from the driver. This will trigger the driver to get RESOLVED. The module and the classloader become available
[22:46:05] *** sannegrinovero has joined #jboss-as7
[22:46:05] *** sannegrinovero has joined #jboss-as7
[22:46:05] *** ChanServ sets mode: +v sannegrinovero
[22:46:26] *** asaldhan has quit IRC
[22:46:31] <Nihility> what happens though in the case of a war
[22:46:32] <dmlloyd> you can't load a class without the classloader, tdiesler
[22:46:42] <dmlloyd> not unless we convert everything internally to OSGi APIs, which is unlikely
[22:47:25] <Nihility> is that code using jandex ?
[22:47:27] <Nihility> let me see
[22:47:30] <dmlloyd> module deps and MSC deps are the two mechanisms we have available to tie everything together
[22:47:47] <Nihility> im worried that we have some stuff that has to scan calssloading
[22:47:55] <Nihility> which will force every osgi bundle on
[22:48:07] <dmlloyd> every referenced OSGI bundle sure
[22:48:51] <Nihility> yeah it does it right
[22:49:01] <Nihility> im talking about a war IS a bundle
[22:49:09] <Nihility> or jar is a bundle
[22:49:48] <Nihility> iit seems so far
[22:49:51] <Nihility> that just bean validation
[22:50:01] <Nihility> the driver thing
[22:50:22] <Nihility> are not doing identification in advance
[22:50:50] <Nihility> lets take the ejb case
[22:50:55] <Nihility> if its an ejb deployment
[22:51:02] <Nihility> we need it to start right away
[22:51:03] <tdiesler> The mechanism that we currently have is that you can declare a dependency on a RESOLVED bundle like 'deployment.some-symbolic-name:1.0.0'. We could perhaps do some modules trick the registers a dummy module with the module loader that represents an INSTALLED bundle. When you try to load a class or resource from that dummy, you trigger bundle resolution and the "real" module becomes available
[22:51:55] <Nihility> so basically the ejb parse phase
[22:52:07] <Nihility> would set something that either prevented the service from being lazy
[22:52:15] <Nihility> or it added a dep to force it to start
[22:52:49] <Nihility> oh
[22:52:55] <Nihility> im confusing INSTALLED with RESOLVED
[22:53:33] <Nihility> i think the service dep approach could work though
[22:53:51] *** tcrawley is now known as tcrawley_away
[22:54:18] <Nihility> basically a bundle would require that everything POST_MODULE and after would be lazy
[22:54:33] <Nihility> and then deployers would be responsible for adding a dep to make them start
[22:54:41] <Nihility> which would transition to resolved
[22:55:00] <Nihility> in the cases where it is necessary
[22:55:06] <Nihility> (its a war or its an ejb)
[22:55:07] <tdiesler> Nihility, just for clarity: You have INSTALLED, RESOLVED, ACTIVE. At INSTALLED the Bundle is known to the framework and has valid OSGi metadata. A class/resource load or some other trigger may move the bundle to RESOLVED if possible. At that state a classloader is available. An explicit start() with call the BundleActivator and the bundle becomes ACTIVE
[22:55:39] <dmlloyd> let's say "INSTALLED(osgi)" and "INSTALLED(as7)" to be unambiguous :)
[22:55:53] <tdiesler> A subsequent stop() will go back to state RESOLVED
[22:56:06] <Nihility> got it
[22:56:25] <Nihility> so like if a bundle is an ejb deployent
[22:56:31] <Nihility> it actually needs to be ACTIVE
[22:56:47] <Nihility> else the services are not available
[22:56:47] *** smarlow has quit IRC
[22:57:00] <dmlloyd> so an EJB deployment would try to actively enable itself
[22:57:23] *** smcgowan has quit IRC
[22:57:35] <tdiesler> Nihility, why would a bundle be an ejb3 deployment. Currently we don't support EJB3s in bundle deployments
[22:58:07] <dmlloyd> you shouldn't have to support it afaict, it should just work
[22:58:09] <tdiesler> An EJB may have a dependency on a bundle and such call an OSGi service
[22:58:22] <dmlloyd> along with JDBC drivers or any other deployment which has OSGi dependencies on it
[22:58:23] *** emmanuel has quit IRC
[22:58:28] <dmlloyd> or metadata
[22:58:39] <Nihility> tdiesler: thats what our problem is, someone adds osgi manifest stuff ot their jar to make it work in an osgi environment, and that in turn breaks it in as7
[22:59:11] <Nihility> tdiesler: granted we have only seen this with jdbc drivers so far
[22:59:41] <tdiesler> sure, because then you deal with an OSGi bundle and hence have the properties of bundle lifecycle with their associated classloader availability
[22:59:53] <dmlloyd> right but that should be the *only* effect
[23:00:18] <dmlloyd> if I take some JAR and stick OSGi stuff on it, it should just tie some stuff into the deployment phases but otherwise work identically
[23:00:19] <tdiesler> all subject of the OSGi resolver doing its non-trivial work to figure out the dependencies
[23:01:03] <Nihility> i can appreciate though that doing that with ejbs is hard because you have to blend osgi imports with EE ones
[23:01:09] <tdiesler> How about this ...
[23:01:33] <dmlloyd> well, it should be simple though, we should be able to add our static deps to the OSGi-generated ones if it's integrated into the deployment chain
[23:02:13] <Nihility> yeah it would just mean though that a bundle would see more classes than it thinks its supposed to
[23:02:25] <Nihility> no idea what the ramnifications of that are
[23:02:29] <dmlloyd> sure
[23:02:47] <tdiesler> Currently every RESOLVED OSGi bundle is also a module, but *not* vice versa. If we moved the Resolver down a level, every EJB3 deployment would also be an OSGi bundle export everything semantic
[23:02:52] <Nihility> some things would probably be broken like osgi type injection and so on
[23:03:13] <dmlloyd> yeah but we can't do that
[23:03:16] <dmlloyd> that'd murder performance
[23:03:20] <dmlloyd> among other problems
[23:03:36] <dmlloyd> and I don't want to rely on OSGi being around forever in any case
[23:03:48] <dmlloyd> it's a spec body and we know how those are
[23:03:50] <tdiesler> dmlloyd, no you can't modify the result the the resolver gives you. This would break the class space consistency gurantee
[23:04:10] <dmlloyd> sure but the user would be aware of that going in
[23:04:24] <dmlloyd> they'd have to be
[23:04:58] <Nihility> i wonder if anyone has ever put osgi stuff in ejb jars
[23:05:07] <Nihility> like maybe glassfish does something with it
[23:05:20] <Nihility> since they are osgi based
[23:05:30] <dmlloyd> well presumably they'd express their deps on the EJB APIs in that case
[23:05:35] <tdiesler> you mean nested?
[23:05:36] <dmlloyd> but that violates javaee
[23:06:03] <Nihility> tdiesler: no i am just wondering if the jdbc problem applies to the ejb one
[23:06:25] <Nihility> tdiesler: like someone adds nice osgi declarations instead of Class-Path and other EE style ways
[23:06:40] <tdiesler> If we step back a little, we only need to get the driver bundle to be resolved before jca uses it, right?
[23:06:57] <Nihility> tdiesler: right
[23:07:02] <dmlloyd> sure, this time around
[23:07:10] <dmlloyd> next time it'll be some other deployment type
[23:07:30] <jpederse> Nihility: that is how OSGi/JCA works
[23:07:57] <tdiesler> Nihility, In that case the use transforms his ejb deployment to a bundle. there is currently no ejb support inside an osgi framework
[23:09:57] <tdiesler> dmlloyd, would it be possible to detach all CL stuff from the deployment install process. For non-osgi deployments it may happen as part of it. For OSGi deployments it may happen at the discrtion of the OSGi Framework
[23:10:58] <dmlloyd> no
[23:11:16] <dmlloyd> we can however make the deployment install process contingent on the OSGi framework, for those deployments
[23:11:38] <dmlloyd> the contract of deployment is, in large part, simply to provide the class loader
[23:12:14] <Nihility> yeah its still at its discretion then
[23:12:15] <tdiesler> LOL, that pretty much contradicts what Bundle install means
[23:12:18] <dmlloyd> doing it via services still seems right to me - the part I don't like is that if you deploy an EE deployment with OSGi stuff on it, you choose between breaking javaee spec rules and breaking osgi spec rules
[23:13:12] <Nihility> how is it the opposite?
[23:13:28] <Nihility> if the bundle is installed before POST_MODULE
[23:13:34] <Nihility> and everything POST_MODULE and after is lazy
[23:13:38] <Nihility> resolution does not happen yet
[23:13:46] <Nihility> until the osgi framework tells it to
[23:13:52] <Nihility> OR
[23:14:02] <tdiesler> yes, buts not to bad. You can argue with proper separation of concerns you have you ejb functionallity with may call into OSGi to make use of some services
[23:14:07] <Nihility> some deployer asks it to be start
[23:14:20] <tdiesler> OSGi services may call into OSGi to do some other work
[23:14:44] <tdiesler> but with the metadata you decide what type of deployment it is. It cant be both
[23:15:17] <tdiesler> Unless, your ejb container is also the one that handles EJBs in Bundles
[23:15:47] <tdiesler> We have this for WebApp. You can stick OSgi metadata in a WAR and make a WAB out of it.
[23:15:51] <dmlloyd> (when OSGi)
[23:17:01] <tdiesler> folks, shall we setup a call to agree on some plan for CR1?
[23:17:09] <Nihility> yes great idea
[23:17:16] <Nihility> i think we at least though have a solution
[23:17:40] <Nihility> which is to make our phases match osgis delayed/lazy lifefycle
[23:18:29] <Nihility> making osgi deployments support ejb is step 2 (or maybe 3) not as critical
[23:18:35] *** ccrouch has joined #jboss-as7
[23:18:35] *** ChanServ sets mode: +v ccrouch
[23:18:41] <Nihility> (sorry i mean ejbs in an osgi deployment)
[23:18:46] <Nihility> i need to be more descriptive
[23:19:25] <dmlloyd> yeah not sure that'll hit CR1 though, it's a bit of a change
[23:19:47] <tdiesler> how about tomorrow?
[23:19:48] <Nihility> well in that case we have another shorter term potion
[23:19:56] *** mmoyses has quit IRC
[23:19:58] <Nihility> which is like tdiesler sai
[23:20:03] <Nihility> force the bundle to resolved
[23:20:19] <Nihility> sure i can do tommorow
[23:21:07] <jpederse> +1
[23:21:15] <tdiesler> 14:00 UTC
[23:21:54] <tdiesler> ?
[23:22:01] *** misty has joined #jboss-as7
[23:22:16] <Nihility> that works for me
[23:22:20] <Nihility> im -5
[23:23:00] <tdiesler> Conference code:
[23:23:01] <tdiesler> 6624229975
[23:23:29] <tdiesler> dmlloyd, jpederse, how about you?
[23:23:49] <tdiesler> tomorrow 14:00 UTC ?
[23:23:52] <jpederse> tdiesler: yup
[23:24:11] <dmlloyd> yeah works for me
[23:24:27] <Nihility> thanks tdiesler for the short notice
[23:24:30] <tdiesler> perfect, TTYT
[23:24:35] <Nihility> sorry i mean setting it up
[23:24:38] <Nihility> on short notice
[23:24:44] <jpederse> tdiesler: have a good one
[23:24:46] <tdiesler> Nihility, you're welcome
[23:24:59] *** mbg has joined #jboss-as7
[23:24:59] *** ChanServ sets mode: +v mbg
[23:25:03] <tdiesler> merci, U2
[23:25:09] *** tdiesler has quit IRC
[23:27:39] *** jpederse has quit IRC
[23:37:14] *** jc3` has joined #jboss-as7
[23:45:12] <jbossbot> git [jboss-as] push master 48d0064.. bstansberry at jboss dot com Support setting management interface bindings via command line...
[23:45:12] <jbossbot> git [jboss-as] push master 560205c.. bstansberry at jboss dot com [AS7-794] Temporary workaround
[23:45:12] <jbossbot> jira [AS7-794] Booting slave host controller only makes a single attempt to contact master [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/AS7-794
[23:45:13] <jbossbot> git [jboss-as] push master 4413d1e.. bstansberry at jboss dot com Add domain mode tests
[23:45:13] <jbossbot> git [jboss-as] push master URL: http://github.com/jbossas/jboss-as/compare/1caa2a6...4413d1e
[23:46:05] *** jwulf has joined #jboss-as7
[23:49:18] *** jc3` has quit IRC
[23:49:41] *** jc3 has quit IRC
[23:50:59] *** jc3 has joined #jboss-as7
[23:50:59] *** ChanServ sets mode: +v jc3
[23:58:22] *** ccrouch has quit IRC

   May 16, 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 | >