[00:03:54] *** cbrock has quit IRC
[00:04:38] *** alesj has quit IRC
[00:05:07] *** emmanuel has quit IRC
[00:19:05] *** rruss has joined #weld-dev
[00:19:36] *** rruss1 has joined #weld-dev
[00:19:36] *** rruss has quit IRC
[00:25:24] *** oskutka has joined #weld-dev
[00:25:30] *** oskutka has quit IRC
[01:06:42] *** johnament has joined #weld-dev
[01:09:31] *** PeteRoyle has joined #weld-dev
[01:36:32] *** rruss1 has quit IRC
[01:42:21] *** aslak has quit IRC
[02:30:16] *** mbg has quit IRC
[02:36:18] *** johnament has quit IRC
[02:37:41] *** mbg has joined #weld-dev
[06:12:51] *** rruss has joined #weld-dev
[06:13:27] *** rruss has quit IRC
[07:02:43] *** magesh has joined #weld-dev
[07:42:59] *** magesh has quit IRC
[07:43:03] *** magesh1 has joined #weld-dev
[08:41:47] *** oskutka has joined #weld-dev
[08:52:35] *** oskutka has quit IRC
[09:12:45] *** oskutka has joined #weld-dev
[09:35:07] *** epbernard has joined #weld-dev
[09:35:07] *** epbernard is now known as emmanuel
[09:35:12] *** emmanuel has joined #weld-dev
[09:54:06] *** alesj has joined #weld-dev
[11:01:54] *** pchowaniec has joined #weld-dev
[11:02:45] *** oskutka has quit IRC
[11:25:14] <alesj> stuartdouglas: ping?
[11:30:18] <stuartdouglas> alesj: hi
[11:30:39] <alesj> stuartdouglas: any luck with that servlet test failures?
[11:30:46] <stuartdouglas> nope
[11:31:27] <stuartdouglas> I am beginning to think that we may have to wait till the TCK gets moved to arquillian to move weld over
[11:32:28] <alesj> those are not TCK tests
[11:32:34] <alesj> this is plain ARQ + servlet tests
[11:33:29] <stuartdouglas> you mean weld servlet?
[11:33:48] <stuartdouglas> that seems to build fine for me
[11:34:43] <alesj> from my arq-upgrade branch?
[11:35:15] <alesj> i'm running "mvn clean install -Dincontainer" from environments/servlet/ dir
[11:35:29] <alesj> and I get a failure on first servlet container ? Tomcat in this case
[11:36:30] <stuartdouglas> ok, let me check
[11:36:48] *** cvasilak has joined #weld-dev
[11:37:43] *** cvasilak has joined #weld-dev
[11:38:27] *** cvasilak has quit IRC
[11:46:42] *** aslak has joined #weld-dev
[11:47:20] *** pmuir has joined #weld-dev
[11:47:21] *** pmuir has quit IRC
[11:47:21] *** pmuir has joined #weld-dev
[11:48:49] <nickarls> alesj: was it so that you were able to build weld (JDK6) without the istack-commons-runtime 1.1?
[11:49:45] <alesj> nickarls: i set a clean mvn repo, added Paul's mirror workaround
[11:49:47] <alesj> and it worked
[11:49:58] <alesj> dunno if i excluded istak
[11:50:32] <nickarls> I didn't even see the istack in the deprectated repo
[11:50:58] <alesj> it has to be somewhere ...
[11:51:23] <nickarls> did it end up in your local repo?
[11:56:40] <alesj> hmmm, i would have to check
[11:56:52] *** maschmid has joined #weld-dev
[11:56:55] <alesj> stuartdouglas: does it work for you?
[11:57:35] <stuartdouglas> alesj: nope, and I can't get any info on whats wrong either
[11:57:52] <alesj> aslak: ^
[11:58:08] <alesj> for me it simply says cannot invoke that test method
[11:58:10] <pmuir> this is istack being included in the build? I could never track down what pulled it in
[11:58:13] <alesj> stuartdouglas: for you?
[11:58:30] <alesj> pmuir: yeah, me neither
[11:58:41] <alesj> if i added exclude, it was gone
[11:58:44] <pmuir> as really we should replace the artifact that pulls it in entirely
[11:58:47] <alesj> but dep:tree didn't show it
[11:58:52] <stuartdouglas> Error launching request at http://localhost:8080/test/ArquillianServletRunner?outputMode=serializedObject&className=org.jboss.weld.environment.servlet.test.injection.LookupTest&methodName=testResource. No result returned
[11:59:00] <stuartdouglas> dep:tree lies
[11:59:01] <alesj> stuartdouglas: yup, same here
[11:59:07] <pmuir> yeah, it's already been excluded somewhere, but maven still wants to get the pom for it I think
[12:00:34] <aslak> alesj, didn't get to it last night. give me a few and i'll have a look
[12:00:34] <nickarls> something in ws-commons?
[12:00:54] <pmuir> what does istack do?
[12:01:22] <alesj> aslak: ok, thanks
[12:01:40] <alesj> pmuir: imo, it's harness that pulls it in
[12:01:51] <alesj> if it's as6 harness
[12:01:57] <pmuir> alesj: ah ok
[12:02:10] <pmuir> so probably as6 that does it?
[12:02:10] <alesj> then we're good, as we're just about to change things to run against AS7
[12:02:19] <pmuir> yeah
[12:02:27] <alesj> pmuir: i'm not 100%, but 99% ? :-)
[12:02:56] <pmuir> alesj: :-)
[12:03:05] <alesj> nickarls: once aslak fixes servlet tests, you could try building it again
[12:03:10] <alesj> as it should use AS7
[12:03:17] <alesj> and not as6-harnes
[12:03:18] <nickarls> alesj: where did you exclude? bom/pom.xml?
[12:03:33] <alesj> where as7 harness is axctually an ARQ adapter
[12:03:57] <alesj> nickarls: hmmm ? i think ity was tests/pom.xml
[12:07:03] <nickarls> alesj: tried excluding it from jboss-test-harness in tests but still no-go
[12:10:03] <alesj> nickarls: hmmm, no idea then ...
[12:11:05] <nickarls> hard one to compile if downgrading JDK, -DskipTests, commenting out code and excluding deps don't work ;-)
[12:18:41] *** aslak has quit IRC
[12:31:27] <pmuir> alesj: i just ran a clean build with empty deps and it fails on the test harness as you said
[12:39:33] *** aslak has joined #weld-dev
[12:54:39] <nickarls> pmuir: but it never tried to pull down istack?
[13:07:32] <aslak> alesj, hmm.. 'something' is leaking between deployment it seems, or not being cleaned up properly. Seems like the second deployment is not being exposed on the http listener in tomcat or similar. running the tomcat test suite with forkMode always works fine
[13:11:47] <alesj> aslak: any more exact idea what or where is this leak?
[13:13:15] <pmuir> istack no, trive yes
[13:13:18] <pmuir> trove even
[13:13:22] <pmuir> it failed at that point
[13:15:07] <aslak> alesj, not currently.. debugging
[13:15:29] <alesj> pmuir: i guess we can wait to fix that after we move to AS7
[13:15:37] <alesj> pmuir: if it's still gonna be there ...
[13:15:38] <pmuir> alesj: sounds good
[13:16:15] <alesj> pmuir: apart from servlet tests, all other things look good ? so, once aslak fixes that, we're all good :-)
[13:22:58] <pmuir> alesj: woot
[13:39:02] *** rmartinelli has joined #weld-dev
[13:39:45] <pmuir> alesj: what is your main branch for weld atm
[13:39:48] <pmuir> i need to write you a test
[13:40:49] *** rmartinelli has quit IRC
[13:42:36] <alesj> pmuir: master == 1.1.2.Final
[13:42:45] <alesj> pmuir: where i work on arq-upgrade
[13:43:01] <alesj> to get AS7 + new ARQ working with Weld
[13:49:19] *** rmartinelli has joined #weld-dev
[13:53:00] <pmuir> alesj: gotcha
[14:13:31] *** lincolnthree has joined #weld-dev
[14:13:38] <lincolnthree> hey alesj, around?
[14:17:07] <alesj> lincolnthree: sure, wazup?
[14:17:16] <lincolnthree> ah hey
[14:17:21] <lincolnthree> got a weld issue
[14:17:32] <lincolnthree> kind of fundamental one, I think, not sure if it's a bug or a "feature"
[14:17:47] <lincolnthree> So, in Forge I use Weld SE
[14:17:51] <alesj> it must be a feature ;-)
[14:17:57] <lincolnthree> Haha, just wait
[14:18:11] <lincolnthree> Are you familiar with forge plugins?
[14:18:18] <lincolnthree> or the concept
[14:18:38] <alesj> sort of, i listened to your talk a few times ;-)
[14:18:43] <lincolnthree> Ok cool
[14:18:53] <lincolnthree> So basically, each plugin is represented by its own JBoss Module
[14:19:07] <lincolnthree> And they are loaded up at runtime (weld boot time) into the weld container
[14:19:18] <lincolnthree> Weld sees all 1st level plugin classpaths
[14:19:42] <lincolnthree> This is required in order for weld to be able to satisfy dependencies in the plugin beans
[14:19:46] <lincolnthree> however
[14:19:54] <lincolnthree> it presents a problem regarding modularity
[14:20:13] <lincolnthree> Right now things are basically 1/2 modular/isolated
[14:20:26] <lincolnthree> Plugin dependencies are isolated from each other
[14:20:42] <lincolnthree> But if, say, Forge includes Seam Render
[14:20:47] <lincolnthree> and a Plugin includes Seam Render
[14:21:07] <lincolnthree> Weld complains with "Unsatisfied injection point"
[14:21:24] <lincolnthree> Most likely due to the separate classloader for plugin dependencies
[14:21:28] <pmuir> lincolnthree: I don't think Weld SE has any notion of modularity in it at all
[14:21:34] <pmuir> it was written totally flat
[14:21:36] <alesj> PeteRoyle: ^
[14:21:56] <lincolnthree> When the plugin does not include Seam Render (e.g. Provided scope dependency)
[14:22:04] <pmuir> you would need to rewrite all the scanner stuff to properly set up the relationships between each module as a bean archive
[14:22:14] <lincolnthree> I get ClassDefNotFound error from weld, which is more correct but still not what I need
[14:22:43] <alesj> lincolnthree: you can see what needds to be done, as AS7 Weld integration had to do the same
[14:22:55] <lincolnthree> pmuir: but it is doable? how would that impact performance? level of complexity required?
[14:23:32] <pmuir> lincolnthree: yes it's doable - it's been done for AS7, OSGi, GlassFish, it shouldn't impact performance, complexity required to impl? It's not too bad, allow a week or so
[14:23:45] <lincolnthree> a week for *you* lol ;)
[14:23:49] <pmuir> it will slow down startup a bit
[14:24:01] <pmuir> no, i could do it in a day or two ;-)
[14:24:04] <pmuir> as I know the ins and outs
[14:24:12] <lincolnthree> How much $$ do you want?
[14:24:12] <lincolnthree> lol
[14:24:15] <pmuir> as it has to resolve across transitive deps
[14:24:26] <pmuir> but once the deps are established (remember we cache all resolutions at startup)
[14:24:31] <pmuir> then there is no impact on perf
[14:24:31] <lincolnthree> how are we doing on the weld meta-cache, btw?
[14:24:39] <lincolnthree> the bootstrap cache
[14:25:17] <pmuir> esp with jboss modiules should be ok
[14:25:22] <pmuir> as stuart did it already once for as7
[14:25:29] <pmuir> so all the hard work of working out how to do it is done
[14:25:52] <lincolnthree> so stuartdouglas already modularized weld for AS7?
[14:26:03] <pmuir> lincolnthree: weld is inherantly modular
[14:26:25] <pmuir> it just reads the metadata you feed it on the module structure
[14:26:29] <pmuir> and acts on it
[14:26:40] <pmuir> weld se currently just passes everyone as one module effectively
[14:26:45] <lincolnthree> ah ha
[14:26:46] <pmuir> so the problem is purely in weld se
[14:27:00] <lincolnthree> I see. So is there a way to "inform" weld SE how you want it to behave?
[14:27:12] <pmuir> lincolnthree: yes, edit the source code
[14:27:16] <lincolnthree> okay :)
[14:27:20] <pmuir> so no
[14:27:32] <pmuir> weld se is pretty basic, i doubt it's more than 1500 LOC
[14:27:37] <lincolnthree> Next question, sort of a conceptual one
[14:27:45] <pmuir> it just dumps everything on the classpath into one module and tells weld to start
[14:27:59] <pmuir> but obviously the jboss modules stuff would be an add on to weld se
[14:28:04] <lincolnthree> right
[14:28:10] <lincolnthree> so interesting question
[14:28:12] <pmuir> but i suspect we can rip out what stuart did for as7
[14:28:22] <lincolnthree> what about the concept of bean-sharing between modules?
[14:28:25] <lincolnthree> like services
[14:29:05] <pmuir> beans can be injected from module a to module b assuming a is visible to b
[14:29:40] <lincolnthree> Ok excellent.
[14:30:01] <pmuir> weld doesn't define any visibility semantics, it assumes the underling modularity takes care of that
[14:30:24] <lincolnthree> Ahh okay.
[14:30:32] <lincolnthree> I may need some help getting started with this at some point.
[14:30:33] <pmuir> which i believe is sufficient
[14:31:10] <nickarls> and AS7 makes AS6 a little more modular than before since AS6 did some merging of the modules
[14:31:23] <nickarls> s/AS6/weld
[14:31:34] <pmuir> I have a feeling that perhaps we should add in the concept of beans which are visible for export in an archive as opposed to all beans in the archive
[14:31:36] <pmuir> alesj: ^^
[14:31:50] <pmuir> lincolnthree: sure, start by reading the integration appendix in the weld ref guide
[14:31:56] <pmuir> and also the javadoc of weld-spi
[14:32:00] <alesj> pmuir: could be
[14:32:16] <alesj> but, imo, it could also just confuse users even more ...
[14:32:18] <lincolnthree> pmuir: ok
[14:32:20] <pmuir> it should be fairly ok by now as flavia, stuart, gf team, etc. all used it to understand how to do all of the above
[14:32:35] <pmuir> alesj: yeah, but it's not many people to confuse - maybe 10 ;-)
[14:32:40] <pmuir> as it's not user facing
[14:32:49] <pmuir> we need to talk to mathieu about that
[14:33:15] <alesj> yes, imo, it shouldn't be too much of a problem to add it
[14:33:23] <alesj> mostly a concept of filter to BDA
[14:33:30] <pmuir> yes excatly
[14:33:42] *** pchowaniec has quit IRC
[14:33:45] <pmuir> i think to properly reflect the underlying module structure we need it
[14:34:04] *** magesh1 has quit IRC
[14:35:13] *** pchowaniec has joined #weld-dev
[14:35:57] *** pchowaniec has left #weld-dev
[14:36:19] <alesj> why would we need to to reflect the modul structure?
[14:36:33] <alesj> the BDA atructure itself should just be the same as CL hierarchy
[14:36:38] *** pchowaniec has joined #weld-dev
[14:36:42] <alesj> either parenty-child ? as in AS6
[14:36:48] <alesj> or modular as in AS7/GF
[14:38:27] <pmuir> alesj: i mean the underlying module system really
[14:38:50] <lincolnthree> ah here's an interesting question
[14:39:04] <alesj> pmuir: you mean, module's filtering == BDA filtering?
[14:39:31] <lincolnthree> is there a way to get weld (in a modular or other environment) to load BDAs and *not* fail? But to simply mark a Beans Archive as not successfully loading, but still continuing to load others?
[14:39:39] <lincolnthree> I assume this would take code changes
[14:39:49] <lincolnthree> just wondering if it's something that's architecturally possible
[14:40:11] <pmuir> alesj: what is the repo workaround again, it's not on the jira
[14:40:21] <alesj> it should be there
[14:40:24] <pmuir> lincolnthree: no, that doesn't exist today
[14:40:24] <alesj> WELD-952
[14:40:26] <jbossbot> jira [WELD-952] Fix deprecated dependencies in jboss test harness [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/WELD-952
[14:40:41] <alesj> pmuir: you need to add that xml snippet to settings.xml
[14:40:46] <pmuir> alesj: aha another issue i didn't look at ;-)
[14:41:01] <pmuir> lincolnthree: there could be a mode to do that for sure
[14:44:38] <lincolnthree> pmuir: it would be incredibly valuable for forge plugins atm
[14:44:45] <lincolnthree> right now a single bad plugin crashes the entire system
[14:45:03] <lincolnthree> which is? difficult? to debug and clean up without blowing away all plugins
[14:45:28] <pmuir> lincolnthree: file a feature request as a start
[14:45:35] <lincolnthree> you got it.
[14:45:39] <lincolnthree> i'll put in features for all of these
[14:45:42] <lincolnthree> and then go from there
[14:45:47] <pmuir> alesj and i are working on getting someone to help with weld work
[14:46:09] <lincolnthree> pmuir: if they did this, they could claim to be helping both weld and forge ;)
[14:47:37] <pmuir> lincolnthree: yeah, we have the slot, just managing the logistics atm
[14:47:52] <lincolnthree> I need a slot
[14:57:54] *** oskutka has joined #weld-dev
[14:59:37] <alesj> lincolnthree: we'll take your slot as well ? muhauahaha .. :-)
[14:59:50] <lincolnthree> alesj: never!
[15:00:16] <lincolnthree> BTW. As far as CDI spec goes
[15:00:22] <alesj> lincolnthree: as fast as you say forge ? :)
[15:01:18] <lincolnthree> for CDI 1.2, any chance of pushing the request/session/conversation scope into servlet spec instead?
[15:19:19] *** emmanuel has quit IRC
[15:21:41] *** magesh has joined #weld-dev
[15:25:29] *** epbernard has joined #weld-dev
[15:25:29] *** epbernard is now known as emmanuel
[15:25:35] *** mbg has quit IRC
[15:29:52] *** emmanuel has quit IRC
[15:31:05] <pmuir> lincolnthree: why?
[15:34:11] *** epbernard has joined #weld-dev
[15:34:11] *** epbernard is now known as emmanuel
[15:35:57] *** ge0ffrey has joined #weld-dev
[15:36:16] <aslak> alesj, update: using unique deployment names works as well, deploying two different testclasses with a deployment with the same name cause problems
[15:37:18] *** lincolnthree has quit IRC
[15:40:59] *** emmanuel has quit IRC
[15:41:35] <alesj> aslak: you mean, all my servlet tests use "default?"
[15:42:23] <aslak> alesj, all your testclasses use a deployment called "test.war"
[15:42:47] <alesj> why is this a problem?
[15:42:51] *** epbernard has joined #weld-dev
[15:42:51] *** epbernard is now known as emmanuel
[15:42:52] <alesj> aslak: ^
[15:43:03] <aslak> alesj, if you remove "test.war" altogether from Deployments line 21, a default generated UUID name will be created for you..
[15:43:26] <aslak> alesj, not sure why it is yet, it's not suppose to be.. just saying that that's a possible fix
[15:43:37] <aslak> or, workaround
[15:44:10] <alesj> ok, let me see if it helps for me as well ...
[15:45:33] <aslak> alesj, BootstrapOrderingTestBase.testContextInitializedCalledBeforeBeanValidation fail here tho, only 1 event is fired
[15:47:05] *** emmanuel has quit IRC
[15:48:52] <alesj>  testContextInitializedCalledBeforeBeanValidation(org.jboss.weld.environment.servlet.test.bootstrap.BootstrapOrderingTest)
[15:48:54] <alesj> yup, same here
[15:50:20] <aslak> alesj, aa, that's a issue with the packaging
[15:50:55] <aslak> war.addAsManifestResource will add to /META-INF, you need to use addAsResource(EXTENSION, "META-INF/services/" + javax.....)
[15:51:40] <aslak> return baseDeployment(WEB_XML).addPackage(BootstrapOrderingTestBase.class.getPackage()).addAsResource(EXTENSION, "META-INF/services/" + Extension.class.getName());
[15:51:51] <alesj> why is that?
[15:52:02] <aslak> change in shrinkwrap
[15:52:16] <alesj> so, /META-INF != META-INF?
[15:52:32] <aslak> META-INF != WEB-INF/classes/META-INF
[15:53:38] <alesj> ic
[16:01:07] <ge0ffrey> aslak: which one is the officially correct one in a jar?
[16:01:09] <ge0ffrey> in a war
[16:02:24] <aslak> officially i would say addAsWebInfResource(asset, "classes/META-INF/name")
[16:02:47] <aslak> or addAsResource(aset, "META-INF/name")
[16:03:17] <aslak> Resource are Assets on your ClassPath, so that is basically what you want
[16:03:43] <alesj> Failed tests:
[16:03:43] <alesj>   testBeansXmlMerged(org.jboss.weld.environment.servlet.test.deployment.structure.DeploymentOrderingTest)
[16:03:44] <alesj>   testELWithParameters(org.jboss.weld.environment.servlet.test.el.JsfTest)
[16:03:44] <alesj> Tests in error:
[16:03:44] <alesj>   testProcessAnnotatedTypeCalledOnceOnlyPerType(org.jboss.weld.environment.servlet.test.deployment.structure.DeploymentOrderingTest)
[16:03:48] <alesj> with Jetty env
[16:06:53] <ge0ffrey> aslak: so what does that mean outside arq, with just weld? do I use .war!/META-INF/beans.xml or .war!/WEB-INF/classes/META-INF/beans.xml ?
[16:07:41] <alesj> ge0ffrey: in .war it should go to WEB-INF
[16:07:57] <ge0ffrey> alesj: tnx
[16:08:21] *** epbernard has joined #weld-dev
[16:08:21] *** epbernard is now known as emmanuel
[16:15:09] <aslak> alesj, jetty JsfTestBase.deployment use addAsWebResource instead of addAsWebInfResource for faces-config
[16:15:51] <alesj> yes, fixed that
[16:15:59] <alesj> only Deploy,entOrdering is failing now ...
[16:16:17] <alesj>   testBeansXmlMerged(org.jboss.weld.environment.servlet.test.deployment.structure.DeploymentOrderingTest)
[16:16:19] <alesj> in jetty
[16:16:31] <alesj>             .addAsWebInfResource(new BeansXml().alternatives(Bar.class), "beans.xml")
[16:16:31] <alesj>             .addAsWebInfResource(new BeansXml().alternatives(Garply.class), "classes/META-INF/beans.xml")
[16:16:43] <alesj> as there is a dup beans.xml in same deployment ...
[16:16:54] <alesj> perhaps this is what's bothering it ...
[16:17:29] <alesj>       assertEquals(Bar.class, beanManager.resolve(beanManager.getBeans(Foo.class)).getBeanClass());
[16:17:53] <aslak> alesj, DeploymentOrderingTestBase.deployment use addAsManifestResource on the war, should be addAsResource META-INF/services...
[16:18:04] <aslak> alesj, and not sure why it adds two beans.xml ?
[16:18:47] <alesj> yeah, looks weird
[16:19:57] <maschmid> well, the test is called "testBeansXmlMerged", so maybe it is testing the behavior of two beans.xml?
[16:20:13] <aslak> the test is called testBeansXmlMerged
[16:20:50] <aslak> aa, WEB-INF/beans.xml and WEB-INF/classes/META-INF/beans.xml
[16:21:26] <ge0ffrey> alesj: "in .war it should go to WEB-IN" => you mean in WEB-INF/classes/META-INF right, instead of META_INF. Using WEB-INF/beans.xml doesn't work on jetty 6 and gwt hosted mode last time I and Toni tried.
[16:21:31] <aslak> alesj, yea, those addAsWebResource should be addAsWebInfResource
[16:21:33] *** mbg has joined #weld-dev
[16:23:35] <alesj> aslak: i think i have that
[16:23:44] <alesj> but might be hitting the issue ge0ffrey is mentyioning
[16:23:45] <aslak> aa, shrinkwrap silently ignore overwrite of existing assets
[16:23:55] <alesj> that for jetty WEB-INF/ is not picked up
[16:24:36] <ge0ffrey> alesj: https://issues.jboss.org/browse/WELD-953
[16:24:37] <jbossbot> jira [WELD-953] WEB-INF/beans.xml is ignored  on jetty 6 (and GWT hosted mode) [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/WELD-953
[16:25:06] *** rruss has joined #weld-dev
[16:25:32] <ge0ffrey> alesj: I 'll have a pull request made for this one in a minute (almost done): https://issues.jboss.org/browse/WELD-958
[16:25:33] <jbossbot> jira [WELD-958] URLScanner parses the wrong META-INF/beans.xml files if the parent classloader has a META-INF/beans.xml file [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/WELD-958
[16:26:08] <aslak> alesj, http://pastebin.com/uybFxfc4
[16:26:49] <alesj> aslak: wow, a delete ?
[16:27:28] <aslak> alesj, yea, you always add a empty beans.xml, and overwriting it is not possible, it's silently ignored.. a security 'feature' of the latest shrinkwrap.. hehe
[16:34:41] *** lincolnthree1 has joined #weld-dev
[16:36:59] *** emmanuel has quit IRC
[16:41:01] <alesj> aslak: yey, finally all test pass :-)
[16:41:21] <aslak> :)
[16:42:46] <ge0ffrey> Pull request made for WELD-958: https://github.com/weld/core/pull/130 - Can anyone review it? alesj?
[16:42:47] <jbossbot> jira [WELD-958] URLScanner parses the wrong META-INF/beans.xml files if the parent classloader has a META-INF/beans.xml file [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/WELD-958
[16:43:06] *** epbernard has joined #weld-dev
[16:43:06] *** epbernard is now known as emmanuel
[16:47:43] *** lincolnthree1 has quit IRC
[16:48:41] <alesj> ge0ffrey: i'll have a look tomorrow, ok?
[16:48:47] <ge0ffrey> alesj: k, tnx
[16:50:15] <ge0ffrey> aslak: Is there any news for the tomcat6 managed pull request you spoke about?
[16:50:24] <ge0ffrey> I am running into the limits of tomcat6 embedded
[16:50:58] <ge0ffrey> WELD-001416 Enabled interceptor class [<class>org.jboss.seam.transaction.TransactionInterceptor</class> in jar:file:/home/gdesmet/.m2/repository/org/jboss/seam/security/seam-security/3.1.0.Beta2/seam-security-3.1.0.Beta2.jar!/META-INF/beans.xml@8, <class>org.jboss.seam.transaction.TransactionInterceptor</class> in jar:file:/tmp/tomcat-embedded-6/work/arquillian-tomcat-embedded-6/localhost/guvnor-webapp-5.3.0-SNAPSHOT/WEB-INF/l
[16:50:58] <ge0ffrey> ib/seam-security-3.1.0.Beta2.jar!/META-INF/beans.xml@8] specified twice
[16:51:55] <ge0ffrey> that's because the junit test classpath has the jar from the m2 repo and the war which I deploy has the same jar from the war web-inf/lib
[16:53:54] *** emmanuel has quit IRC
[16:54:03] <aslak> ge0ffrey, it's in review
[16:56:08] <ge0ffrey> aslak: great, I don't think there's any way for me to avoid the above issue with tomcat-embedded, so I 'll have to wait for tomcat-managed?
[17:00:46] *** pchowaniec has quit IRC
[17:02:41] *** epbernard has joined #weld-dev
[17:02:41] *** epbernard is now known as emmanuel
[17:02:54] *** mbg has quit IRC
[17:11:16] <aslak> ge0ffrey, same named archive you mean? you can import your deployment under a different name, but depends how much your app handles it
[17:12:56] <ge0ffrey> aslak: it's actually the same jar: the first time is in the unit classpath, coming for m2 repository
[17:13:06] <ge0ffrey> the second time is in the war that I deploy to arquillian
[17:16:25] <ge0ffrey> aslak: here my @Deployment and the error message: https://gist.github.com/1181137
[17:16:44] *** oskutka has quit IRC
[17:17:04] <ge0ffrey> without tomcat6-managed or jetty6-managed, I don't see a way around it
[17:17:17] <ge0ffrey> maybe if I get jboss as 6 managed to work
[17:18:48] <aslak> ge0ffrey, and if you remove seam-security-3.1.0.beta2 from your projects classpath ?
[17:19:06] <ge0ffrey> then I can't compile
[17:19:28] <ge0ffrey> and it doesn't automatically add it in the war no more
[17:20:48] <ge0ffrey> also, some of my client tests might actually use seam-security (I 'll see that once my prototype test works and I 'll start migrating the existing real testcases from seam 2)
[17:20:51] <aslak> automatically add it in the war+
[17:20:52] <aslak> ?
[17:21:16] *** pmuir has quit IRC
[17:21:45] <ge0ffrey> when I remove it from my guvnor-webapp pom.xml, it will dissappear from that's compilation classpath, but also it won't add it in the war that's being build no more
[17:22:00] <ge0ffrey> and my testcases use that exploded war directory
[17:22:04] <aslak> aa yes.. it's the same project
[17:22:54] <ge0ffrey> I tried splitting it up the other day.. forgot why I didn't proceed with that (didn't note it in my log either https://docs.google.com/document/d/1_BDIGj_kgbKwVYv9FudrTAND4JHfoAiWWM02w3iLG9U/edit?hl=nl# )
[17:23:13] *** mbg has joined #weld-dev
[17:23:19] <ge0ffrey> aslak: but I guess I could try splitting the arq test in it's own module again?
[17:23:53] <aslak> it's safer with a managed container
[17:23:56] <ge0ffrey> but even then, there might be tests that need seam-security in the classpath
[17:24:03] <ge0ffrey> because they do "new Identity" or something
[17:24:23] <ge0ffrey> aslak: yea, I agree, managed container will probably fix this problem. But meanwhile, I am stuck?
[17:24:35] <aslak> jboss managed
[17:25:14] <ge0ffrey> yep, trouble is I need to remove specific jars from the war to get it to work on jboss 6. Jboss 7 managed isn't out yet?
[17:25:27] <aslak> 7 managed is out
[17:25:51] <aslak> https://github.com/jbossas/jboss-as/tree/master/arquillian/container-managed
[17:26:13] <ge0ffrey> aslak: can I use seam-security 1.1.3-SNAPSHOT on that or should I somehow hook in 1.1.2.AS7 with my patches?
[17:26:27] <aslak> no idea
[17:26:43] *** magesh has quit IRC
[17:26:58] *** alesj has quit IRC
[17:27:02] <aslak> ge0ffrey, your all client tests right ?
[17:27:07] <ge0ffrey> ok, I 'll try that. Bleeding edge its better than nothing :)
[17:27:45] <ge0ffrey> alsak: no idea tbh... probably not. But right now I am focussing on getting an @Inject different from null in a Test working
[17:28:01] <aslak> that would be incontainer test..
[17:28:10] <ge0ffrey> aslak: which rules out managed?
[17:28:18] <aslak> not at all
[17:28:36] <ge0ffrey> ah, good :)
[17:28:50] <aslak> but you probably want to swap the protocol used for communication from the default jmx based that as7 use, to the Servlet 3.0 protocol
[17:30:00] <ge0ffrey> aslak: here's what I am trying to get to run in arq: https://github.com/ge0ffrey/guvnor/blob/upgradeToSeam3/guvnor-webapp/src/test/prototype-test/org/drools/guvnor/WebappPrototypeArqTest.java
[17:30:02] <aslak> ge0ffrey, http://community.jboss.org/message/622672#622672
[17:30:16] <aslak> no sorry, wrong post
[17:30:28] <aslak> http://community.jboss.org/message/622637#622637
[17:31:07] <aslak> ge0ffrey, should be doable.. :)
[17:31:15] <ge0ffrey> yep, tnx! :)
[17:31:32] <ge0ffrey> I 'll find out in the manual where the arq.xml goes
[17:31:55] <aslak> root of your cp somewhere.. often src/test/resources/arquillian.xml
[17:33:22] <ge0ffrey> aslak: one thing I don't understand in the design of weld, is why beans.xml files aren't namespaced and can import other (namespaced) beans.xml files?
[17:34:10] <ge0ffrey> having non namespaced files in jars just seem more trouble than it's worth
[17:34:58] <aslak> ge0ffrey, you'll have to ask alesj about that one..
[17:35:41] <ge0ffrey> too late to change probably anyway
[17:36:08] <aslak> it's based on the CDI spec so.. i guess it's in there somewhere..
[17:36:13] <aslak> ask pete about it for 1.1
[17:36:32] *** cbrock has joined #weld-dev
[17:36:39] <aslak> there is a whole config discussion going on for ee7
[17:38:44] <ge0ffrey> intresting. I got a lot of experience in spring, and although cdi/weld is definitly better designed on @Qualifier and scopes and type-safe injections etc, it's pretty hard to start with because the non-namespaced beans.xml are so unreliable
[17:40:22] <ge0ffrey> forget a jar in your classpath (dependency in maven) and you get some wierd error instead of a very early fail-fast "org/seam/security/beans.xml is missing"
[17:47:59] *** maschmid has quit IRC
[17:49:01] <ge0ffrey> aslak: btw, just to get an idea, how long can the tomcat6 managed review take?
[18:03:30] *** lincolnthree has joined #weld-dev
[18:05:56] *** ge0ffrey has quit IRC
[18:28:31] *** rruss has quit IRC
[18:30:10] *** alesj has joined #weld-dev
[18:45:13] *** alesj has quit IRC
[19:31:08] *** lincolnthree has quit IRC
[20:01:05] *** lincolnthree has joined #weld-dev
[20:10:47] *** maschmid has joined #weld-dev
[20:26:07] *** aslak has quit IRC
[20:32:31] *** aslak has joined #weld-dev
[20:55:00] *** kevinpollet has joined #weld-dev
[21:02:53] *** kevinpollet has quit IRC
[21:07:23] *** rruss has joined #weld-dev
[21:39:39] *** emmanuel has quit IRC
[21:57:55] *** maschmid has quit IRC
[22:35:59] *** rmartinelli has quit IRC
[23:12:20] *** jbott has quit IRC
[23:13:03] *** jbott has joined #weld-dev
[23:23:38] *** jbott has quit IRC
[23:29:42] *** jbott has joined #weld-dev
[23:31:59] *** lincolnthree has left #weld-dev
[23:43:14] *** jbott has quit IRC
[23:44:34] *** jbott has joined #weld-dev





top