July 13, 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

[00:00:35] *** galderz has quit IRC
[00:22:28] *** jose_freitas has joined #jbosstesting
[00:23:14] *** rruss has quit IRC
[00:26:27] *** mhuniewicz has quit IRC
[00:42:14] <jose_freitas> aslak: ping
[00:42:18] <aslak> jose_freitas, hey
[00:48:53] <jose_freitas> Im writting the blog about jacoco extension
[00:49:05] <jose_freitas> are we going to release an alpha version of it?
[00:49:17] <jose_freitas> cause I was thinking to make the blog with an alpha version
[00:49:22] <jose_freitas> and arquillian needs a final too
[00:49:29] <jose_freitas> or an RC2
[00:51:27] <aslak> jose_freitas, rc2 is tagged and pushed to nexus staging. waiting for alesj to verify it with weld-core :)
[00:51:35] <aslak> rc2/cr2
[00:51:50] <alesj> aslak: will do asap, thanks!
[00:52:01] <aslak> alesj, you got the url =?
[00:53:39] <alesj> aslak: url?
[00:54:27] <aslak> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-034/
[00:54:36] <aslak> alesj, you need weld-ee-container as well right?
[00:55:09] <alesj> aslak: yes,
[00:55:24] <alesj> to replace weld-core weld-ee-container, right?
[01:00:23] <aslak> alesj, well for the sake of the test yes..
[01:02:27] <aslak> alesj, here is weld 1.0.0o.CR2 https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-060/
[01:03:07] <aslak> alesj, you'll need to update the arq-tests weld-ee-container group id to use the arq one
[01:03:29] <jose_freitas> nice
[01:03:30] <jose_freitas> :)
[01:03:33] <jose_freitas> thanks
[01:03:41] <aslak> that should be ok for this release, since there are no api changes (i think)
[01:04:56] <aslak> alesj, but weld-core should suck in the new version when aki changes come so you can still test your self  :)
[01:05:03] <aslak> aki/api
[01:06:08] *** ldimaggi has joined #jbosstesting
[01:07:20] <aslak> alesj, it's late and bedtime here.. mail me and i can push them in the morning,  (or press release in nexus when it's tested your self :)
[01:09:50] *** aslak has quit IRC
[01:17:33] *** alesj has quit IRC
[01:19:34] *** alesj has joined #jbosstesting
[01:21:29] *** rruss has joined #jbosstesting
[01:25:03] *** alesj has quit IRC
[01:29:33] *** aaronwalker has joined #jbosstesting
[01:34:44] *** rruss has quit IRC
[01:46:19] *** johnament has joined #jbosstesting
[01:50:42] *** ianbrandt has quit IRC
[14:10:09] *** echelog-2 has joined #jbosstesting
[14:10:43] <aslak> i assume some data flow issue between client and server, havn't figured out what / why tho
[14:14:00] <aslak> stuartdouglas, jbossas7-remote: Tests run: 272, Failures: 1, Errors: 6, Skipped: 3
[14:14:02] <aslak> sound ok =?
[14:14:05] <stuartdouglas> have you got it to run more than 18 tests against AS7
[14:14:15] <stuartdouglas> oh, apparently yes :-)
[14:14:19] <aslak> :)
[14:14:43] <stuartdouglas> looks good, send it back to me and I will look into the failures
[14:14:57] <stuartdouglas> probably tomorrow though
[14:15:12] <stuartdouglas> I have had some after AS7 final celebratory beers :-)
[14:17:08] *** aaronwalker has quit IRC
[14:17:42] <aslak> stuartdouglas, https://github.com/aslakknutsen/weld-core/commits/arq-upgrade
[14:18:16] <stuartdouglas> aslak: thanks :-)
[14:18:34] <aslak> stuartdouglas, i had a few last night.. :)
[14:19:37] <stuartdouglas> I'm glad it's done, although I am already looking forward to getting into the remaining EE stuff for 7.1
[14:19:46] <stuartdouglas> well some of it anyway
[14:20:43] <aslak> stuartdouglas, hehe, yea got a few arq related things to fix up for 7.0.1
[14:21:21] <stuartdouglas> yea, I have 1 for 7.0.1 already, @EJB injection into CDI beans is broken
[14:21:40] <stuartdouglas> but on the up side no one uses it anyway :-)
[14:21:50] <aslak> stuartdouglas, aa, related ? http://community.jboss.org/message/614855#614855
[14:22:53] <aslak> :)
[14:23:32] <stuartdouglas> damn, apparently people do use it :-(
[14:23:37] <aslak> hehe
[14:24:03] <aslak> that is the workaround to get relyable @EJB injection in the arq testcases, since CDI has the hooks into as core
[14:24:20] <aslak> add a beans.xml and it all works (in stead of the guessing game done in the EJBEnricher)
[14:25:12] <aslak> stuartdouglas, mind adding a jira ref to the post ?
[14:25:24] <aslak> did already.. :)
[14:25:52] <stuartdouglas> I just responded, the JIRA has already been closed, and fixed upstream
[14:26:09] <aslak> aa goodie
[14:26:31] <stuartdouglas> Is there an EJB enricher for AS7?
[14:30:09] <stuartdouglas> cause if not I can write one for you
[14:30:29] <aslak> there is the standard one
[14:30:47] <aslak> but non that actaully hooks into the ejb container i believe
[14:30:47] <stuartdouglas> standard one?
[14:31:23] <aslak> stuartdouglas, https://github.com/arquillian/arquillian-core/blob/master/testenrichers/ejb/src/main/java/org/jboss/arquillian/testenricher/ejb/EJBInjectionEnricher.java#L161
[14:31:31] <aslak> stuartdouglas, uses mappedName or guesses
[14:31:48] <stuartdouglas> ah
[14:32:30] <stuartdouglas> If I get time I will do a proper AS7 one, and one for @Resource injection as well
[14:33:06] <stuartdouglas> incidentally, those guesses should be in a different order
[14:33:20] <aslak> stuartdouglas, i 'think' the standard @Resource injector should work fairly well: https://github.com/arquillian/arquillian-core/blob/master/testenrichers/resource/src/main/java/org/jboss/arquillian/testenricher/resource/ResourceInjectionEnricher.java
[14:33:26] <stuartdouglas> you should start with java:module/SimpleClassName
[14:34:41] <aslak> but one for as7 that can actually forward to injection to the ejb subsystem would be great
[14:35:02] <aslak> well, actually same goes for @Resource really
[14:35:03] <stuartdouglas> hmm, I am not sure if that will work
[14:35:25] <stuartdouglas> actually it will work for some stuff
[14:35:38] <aslak> stuartdouglas, the problem is, there is no portable mapping between Interface and JNDI name
[14:35:45] <stuartdouglas> but you can;t inject container provided stuff like UserTransaction with it
[14:36:27] <stuartdouglas> true, but your only guessing anyway
[14:36:30] <aslak> stuartdouglas, you could in as6, i have a report saying it's not working fo r7
[14:36:41] <stuartdouglas> you should guess java:module first
[14:36:49] <stuartdouglas> as the app name may not be "test"
[14:37:04] <stuartdouglas> and it is defiantly not "test.ear"
[14:37:14] <aslak> stuartdouglas, no i mean, unless you talk to the ejb subsystem, there is no portable way. if we can't talk to the sub system.. then we can only guess. or is there a 3. option?
[14:37:39] <stuartdouglas> I am just saying that your guess could be slightly better :-0
[14:37:45] <stuartdouglas> I mean :-)
[14:37:49] <aslak> test.ear is in there for a reason. some as6 v. i believe did that. m2 or similar.. ehhe
[14:38:06] <stuartdouglas> "java:global/test.ear/test/" is always wrong according to the spec
[14:38:12] <stuartdouglas> ah, ok
[14:39:53] <stuartdouglas> I will have a look at doing an AS7 resolver for both of them, but you may have to remind me :-)
[14:40:15] <aslak> module is bound only in context of the module right? is a ejb jar in a war part of the war module context?
[14:40:20] <stuartdouglas> it should not be to hard, but the arq service may have to hook into the deployment somehow
[14:40:53] <stuartdouglas> yea, a war with ejb's has it's own java:module context
[14:41:02] <stuartdouglas> that is aliased to java:comp
[14:41:15] <stuartdouglas> so java:comp and java:module are the same in a war
[14:41:40] <stuartdouglas> which means that EJB's in a war behave differently to EJBs in an ejb-jar
[14:41:49] <stuartdouglas> with regard to naming
[14:41:55] <aslak> so war/lib/ejb/MyBean == war/classes/MyBean ?
[14:42:23] *** ge0ffrey has joined #jbosstesting
[14:43:14] <aslak> and ear/war & ear/ejb, request coming from war, java:module is the war
[14:43:26] <stuartdouglas> yes
[14:44:21] <aslak> but it's java:module/BeanName right? still doesn't help when i have BeanInterface
[14:49:47] <stuartdouglas> true
[14:50:04] <stuartdouglas> you really need one that hooks into the container
[14:51:08] <aslak> yea
[15:00:26] *** rruss has joined #jbosstesting
[15:01:19] *** jharting has left #jbosstesting
[15:02:33] *** jharting has joined #jbosstesting
[15:02:41] *** ldimaggi has joined #jbosstesting
[15:09:39] *** gastaldi has joined #jbosstesting
[15:10:05] *** gastaldi is now known as Guest99857
[15:10:32] *** Guest99857 has quit IRC
[15:38:33] *** k4ffee has quit IRC
[15:38:41] *** k4ffee has joined #jbosstesting
[16:02:50] *** jharting1 has joined #jbosstesting
[16:03:26] *** jharting has quit IRC
[16:25:19] *** mumilove has joined #jbosstesting
[16:25:25] <mumilove> Yo.. Running a Seam 2.2/jboss 5.1 project. Just made a webservice client which connects tohttps port. I added the server to the truststore and everything is working except one problem... i have like 30-70 secresponse time! When i run the client as standalone jar, i have 3-5 sec response time... can anybody help me out? I also get this waring: [WSDLDefinitions] Multiple WSDL bindings referrence the same interface:
[16:27:43] <mumilove> If anybody can help, i will send him naked pictures!!
[16:27:44] <mumilove> :0)
[16:38:03] *** jose_freitas has joined #jbosstesting
[16:39:04] *** jharting1 has quit IRC
[16:40:40] *** Jaikiran has joined #jbosstesting
[16:42:26] *** bleathem has joined #jbosstesting
[16:58:24] *** mbg has joined #jbosstesting
[17:02:14] *** jganoff has joined #jbosstesting
[17:11:17] *** alesj has quit IRC
[17:13:37] *** oskutka has quit IRC
[17:18:07] *** ge0ffrey has quit IRC
[17:26:03] *** torben has quit IRC
[17:32:52] *** maschmid has quit IRC
[17:40:54] *** bleathem has left #jbosstesting
[17:55:05] *** oskutka has joined #jbosstesting
[17:57:30] *** oskutka has quit IRC
[17:58:24] *** maeste has quit IRC
[18:09:48] *** pilhuhn is now known as pil-dinner
[18:17:27] *** aslak has quit IRC
[18:18:05] *** aslak has joined #jbosstesting
[18:39:21] *** mgoldmann has quit IRC
[18:46:36] *** ianbrandt has joined #jbosstesting
[19:18:02] *** ALR has joined #jbosstesting
[19:18:58] <aslak> stuartdouglas, all tests in error seems related to the EJB lookup issue, http://pastebin.com/LCG73JMH
[19:19:14] <aslak> stuartdouglas, weld core as7 btw..
[19:19:27] <aslak> stuartdouglas, we assume arq CR2 is ok, and i can push them out for weld 1.2  ?
[19:20:42] *** ianbrandt has quit IRC
[19:21:48] *** ianbrandt has joined #jbosstesting
[19:22:51] *** lfryc has quit IRC
[19:24:25] *** lightguard_jp has joined #jbosstesting
[19:35:48] *** bgeorges has quit IRC
[19:48:34] <jose_freitas> aslak: ping
[19:49:22] <jbossbot> git [shrinkwrap] push master ef87c99.. Karel Piwko SHRINKWRAP-294 @Override annotations regenerated for all classes
[19:49:23] <jbossbot> jira [SHRINKWRAP-294] Honor proxy and other settings from settings.xml [Pull Request Sent (Unresolved) Feature Request, Major, Karel Piwko] https://issues.jboss.org/browse/SHRINKWRAP-294
[19:49:24] <jbossbot> git [shrinkwrap] push master URL: http://github.com/shrinkwrap/shrinkwrap/compare/3526baa...ef87c99
[19:52:44] *** galderz has quit IRC
[19:57:59] *** bleathem has joined #jbosstesting
[19:59:09] *** Jaikiran has quit IRC
[20:01:35] *** bleathem has quit IRC
[20:06:40] *** lfryc has joined #jbosstesting
[20:09:31] *** bleathem has joined #jbosstesting
[20:12:47] <aslak> jose_freitas, pong
[20:13:42] <bleathem> did someone ping me?
[20:14:05] <jose_freitas> hey aslak, to "activate" testEnricher, do I have to do something?
[20:14:12] <aslak> bleathem, not that i know.. :)
[20:14:15] <jose_freitas> or .addAsServiceProvider(TestEnricher.class, JSFUnitTestEnricher.class); should be enough?
[20:14:21] <bleathem> not quite sure how to interpret these piggin alers
[20:14:24] <bleathem> ^alerts
[20:14:43] <aslak> jose_freitas, that is in JSFUnitExtension ?
[20:14:46] <jose_freitas> yes
[20:15:27] <aslak> jose_freitas, arq has two sides right, client and server
[20:15:57] <jose_freitas> ok
[20:15:58] <aslak> jose_freitas, JSFUnitExtension you have registed via a SPI file in the jsfunit arq modules META-INF/services i assume, so that will be the 'client' side
[20:16:04] <aslak> what the client can see
[20:16:10] <jose_freitas> done it
[20:16:41] <aslak> you need to add a AuxiliaryArchiveAppender to the client Extension that packages the server side v. of the extension.
[20:16:48] <jose_freitas> done it too
[20:18:00] <aslak> so in the auxiliaryarchiveappender you need to register a RemoteLoadableExtension SPI, e.g. JSFUnitRemoteExtension implements RemoteLoadableExtension
[20:18:39] <aslak> in the JSFUnitRemoteExtension is where you register the TestEnricher, which will be found server side
[20:19:10] <jose_freitas> ok
[20:19:16] <jose_freitas> didn't registered it
[20:19:44] <jose_freitas> thanks
[20:19:53] <aslak> jose_freitas, e.g. https://github.com/arquillian/arquillian-core/blob/master/testenrichers/cdi/src/main/java/org/jboss/arquillian/testenricher/cdi/client/CDIEnricherArchiveAppender.java#L46
[20:20:12] <aslak> https://github.com/arquillian/arquillian-core/blob/master/testenrichers/cdi/src/main/java/org/jboss/arquillian/testenricher/cdi/container/CDIEnricherRemoteExtension.java
[20:20:25] <jose_freitas> thanks :)
[20:21:40] <jose_freitas> it worked
[20:21:41] <jose_freitas> :)
[20:23:54] <aslak> jose_freitas, you mind signing a CLA for JSFUnit ? cla.jboss.org
[20:25:28] <jose_freitas> nope, but it not worked completely yet
[20:25:34] <jose_freitas> just the testenrichment
[20:25:35] <jose_freitas> hehehe
[20:26:27] <jose_freitas> I'll do this cla thing when I finish it
[20:26:36] <aslak> jose_freitas, sure
[20:27:15] <jose_freitas> :)
[20:39:32] *** rruss has quit IRC
[21:10:17] *** lfryc has quit IRC
[21:28:25] <ianbrandt> aslak: I'm stuck on an @Inject issue with the embedded Tomcat 7 container.  Initially the BeanManager wasn't registering in JNDI, but I got that sorted.  Now the issue is the BeanManager isn't resolving MyBean when trying to inject it into the in container test case: http://pastebin.com/31QTSf9P.  I checked and MyBean.class is under WEB-INF/classes in the deployed test archive.  Is there anything special about how beans ar
[21:28:26] <ianbrandt> resolved with Arquillian + Weld?  It works with Tomcat 6 so maybe this is a Weld + Tomcat 7 issue.
[21:29:38] <aslak> ianbrandt, you have a beans.xml in the war right ?
[21:29:52] <aslak> addAsWebInfResource ?
[21:30:32] <ianbrandt> I do, but it's empty as with Tomcat 6.
[21:34:48] <jose_freitas> aslak: what's this cla about? never signed
[21:36:03] <aslak> jose_freitas, community contributor agreement.. basically stating that you wrote the code and give red hat access to use it
[21:36:21] <jose_freitas> hnm
[21:36:37] <jose_freitas> is there a jira for this integration?
[21:38:40] <jose_freitas> I mean, for this integration update
[21:39:21] <aslak> jose_freitas, this is part of it: JSFUNIT-276
[21:39:22] <jbossbot> jira [JSFUNIT-276] Fully remove all CDI dependencies [Open (Unresolved) Task, Major, Stan Silvert] https://issues.jboss.org/browse/JSFUNIT-276
[21:39:51] <aslak> jose_freitas, you can create one for the update to CR1
[21:40:05] <aslak> jose_freitas, put it on the Arquillian Integration component
[21:41:36] <aslak> ianbrandt, aa! are you deploying as unpackaged?
[21:42:13] <aslak> ianbrandt, weld has a issue scanning inside packaged deployments on Tomcat
[21:42:36] <aslak> ianbrandt, there is a config option
[21:43:03] <aslak> ianbrandt, https://github.com/arquillian/arquillian-container-tomcat/blob/master/tomcat-embedded-6/src/test/resources/arquillian.xml#L11
[21:43:57] <ianbrandt> aslak, Hmm, not sure.  I don't believe I've changed anything related to that from the working Tomcat 6 equivalent, but let me check.
[21:45:58] <ianbrandt> aslak, I have unpackArchive as true: https://github.com/ianbrandt/arquillian-container-tomcat/blob/master/tomcat-embedded-7/src/test/resources/arquillian.xml
[21:46:32] <aslak> ianbrandt, yea, but is the container doing what it is suppose to regarding it ?
[21:46:46] <aslak> https://github.com/ianbrandt/arquillian-container-tomcat/blob/master/tomcat-embedded-7/src/main/java/org/jboss/arquillian/container/tomcat/embedded_7/TomcatContainer.java#L183
[21:47:05] <aslak> is that still there? and does it work ?
[21:49:49] <ianbrandt> aslak, It's still there, but I'll debug it now and see if it's working.
[21:51:13] *** jhuska has quit IRC
[22:00:31] *** ldimaggi has quit IRC
[22:12:12] <ianbrandt> aslak, It's expanded into webapps after standardHost.addChild(standardContext) for Tomcat 6, but not Tomcat 7.  Glad I asked because that was _not_ my next guess! ;)  I'll look into what's going on.  Thanks.
[22:15:20] <aslak> ianbrandt, your welcome.. :)
[22:18:09] *** alesj has joined #jbosstesting
[22:27:12] *** rruss has joined #jbosstesting
[22:51:44] *** mhuniewicz has joined #jbosstesting
[22:53:35] <mhuniewicz> aslak, hi
[22:54:31] <mhuniewicz> aslak, the persistence context thing is going quite well. It's now capable of injecting @PersistenceContext annotated entity managers in right amounts per test.
[22:55:01] <aslak> mhuniewicz, you reading the PersistenceCOntext annotation etc ?
[22:55:10] <mhuniewicz> aslak, yes
[22:55:22] <mhuniewicz> One thing that is left, though, is handling default @PersistenceUnit without explicitly declared unitName.
[22:55:33] <mhuniewicz> So somehow via Aruillian I must tell it what the default is.
[22:56:36] <aslak> hmm
[23:03:33] *** ALR has quit IRC
[23:14:26] <mhuniewicz> aslak, I don't know Arquillian very well, but I would suggest passing this info to MockJpaInjectionServices as a constructor argument in BeanDeploymentArchive,
[23:14:44] <mhuniewicz> and then I believe it could be given in the @Deployment method.
[23:15:48] <aslak> mhuniewicz, what are the default rules around that? default = the one defined if only one?
[23:16:48] <mhuniewicz> aslak, when instantiating via Persistence you MUST provide a name.
[23:16:53] *** PeteRoyle has joined #jbosstesting
[23:17:04] <mhuniewicz> With Spring you had to define it too, let me see...
[23:17:31] <aslak> mhuniewicz, parse persistence.xml during deploy ? :)
[23:17:48] <mhuniewicz> Yeah, you gotta give it to entityManagerFactory bean, in Spring.
[23:18:14] <mhuniewicz> aslak, you can have many of them in that file.
[23:18:18] <mhuniewicz> It won't know which one
[23:19:22] <aslak> mhuniewicz, you can, but how does the defaulting rules work in a normal jpa env ?
[23:19:46] <mhuniewicz> aslak, that's a brilliant question.
[23:19:57] <jose_freitas> aslak: finished the post about jacoco extension
[23:19:58] <jose_freitas> http://techblog.joserodolfo.com/2011/07/arquillian-coverage-tests-reported-with-sonar-howto/
[23:21:07] <mhuniewicz> aslak, http://seamframework.org/Documentation/WhenDoIUseInVsPersistenceContextToInjectAnEntityManager
[23:21:18] <mhuniewicz> "If there is only one persistence unit in the application, the unitName attribute is not required."
[23:26:32] <mhuniewicz> That's what it is.
[23:26:55] <mhuniewicz> aslak, so it seems you're right. If there is just one PU in persistence.xml, then it is the default one.
[23:27:26] <mhuniewicz> aslak, where and how should I then parse persistence.xml, as it might be provided in the @Deployment method?
[23:27:31] <aslak> mhuniewicz, can you pass null to Persistence.getEntityManager... ?
[23:28:58] <mhuniewicz> So it seems, but I just ran it and it gave me a javax.persistence.PersistenceException.
[23:29:19] <mhuniewicz> Which says "no name provided and several persistence units found", but I'm not aware of declaring more than one...
[23:29:59] <mhuniewicz> I don't understand why this is.
[23:30:01] *** mumilove has quit IRC
[23:39:28] <mhuniewicz> aslak, I guess I will have to parse the XML?
[23:44:01] <aslak> mhuniewicz, can you debug to figure out why it finds several ?
[23:44:30] <aslak> mhuniewicz, maybe both the persistence.xml in the deployment and the ont in your file system is found, so you have two of the same
[23:44:52] <mhuniewicz> aslak, I'm on it...
[23:46:10] *** mbg has quit IRC
[23:47:48] *** jeand has quit IRC
[23:49:25] <mhuniewicz> It's Hibernate EJB that throws this.
[23:49:29] <mhuniewicz> aslak, this line.
[23:49:30] <mhuniewicz> if ( persistenceUnitName == null && xmls.hasMoreElements() ) {
[23:49:49] <mhuniewicz> Because xmls.hasMoreElements() is true.
[23:50:34] <mhuniewicz> That is Thread.currentThread().getContextClassLoaded().getResources("META-INF/persistence.xml");
[23:51:54] <aslak> mhuniewicz, yea, it probably fines the same file twice
[23:52:33] <aslak> mhuniewicz, try moving the file on disk, META-INF/persistence.xml to persistence-test.xml or similar. and only add it as META-INF/persistence.xml in the Deployment
[23:53:00] <mhuniewicz> Well, I don't understand it because the two elements in that xmls is a URL and our archive.
[23:53:09] <mhuniewicz> OK I will.
[23:54:47] *** jose_freitas has quit IRC
[23:55:28] <mhuniewicz> So, that passed, but I got this instead:
[23:55:30] <mhuniewicz> Caused by: java.lang.IllegalArgumentException: Unable to determine JAR Url from archive:JpaDogRepositoryExplicitSetTest.jar/META-INF/persistence.xml. Cause: unknown protocol: archive
[23:57:01] <aslak> mhuniewicz, oh yea, that issue
[23:58:04] <aslak> it's how classscanning is done in hibernate, not liking our shrinkwrap archive classloader
[23:58:26] <aslak> mhuniewicz, can you create a issue on this in arq
[23:59:52] <mhuniewicz> Sure. What should it say?

top