[01:07:20] *** struberg has quit IRC
[01:07:20] *** alesj has joined #weld-dev
[01:29:50] *** alesj has quit IRC
[01:41:44] *** alesj has joined #weld-dev
[02:09:16] *** alesj has quit IRC
[02:26:15] *** struberg has joined #weld-dev
[02:28:56] *** struberg has quit IRC
[03:39:24] *** rruss has joined #weld-dev
[05:10:10] *** mbg has joined #weld-dev
[05:41:21] *** mbg is now known as mbg|away
[05:53:24] *** mbg|away is now known as mbg
[06:18:21] *** PeteRoyle has quit IRC
[06:19:21] *** PeteRoyle has joined #weld-dev
[06:38:17] *** magesh has joined #weld-dev
[08:07:00] *** magesh1 has joined #weld-dev
[08:09:19] *** magesh has quit IRC
[08:30:24] *** struberg has joined #weld-dev
[08:34:46] *** sbryzak has quit IRC
[08:40:06] *** ge0ffrey has joined #weld-dev
[08:43:29] *** mkouba has joined #weld-dev
[08:55:28] *** sbryzak has joined #weld-dev
[09:00:37] *** stuartdouglas has quit IRC
[09:01:37] *** stuartdouglas has joined #weld-dev
[09:03:51] *** mathieuancelin has joined #weld-dev
[09:06:17] *** magesh1 has quit IRC
[09:20:10] *** rruss has quit IRC
[09:27:31] *** emmanuel has joined #weld-dev
[09:28:50] *** jharting has joined #weld-dev
[09:32:12] *** maschmid has joined #weld-dev
[09:35:26] *** oskutka has joined #weld-dev
[09:38:34] *** magesh has joined #weld-dev
[11:21:55] *** aslak has joined #weld-dev
[11:23:58] *** magesh has quit IRC
[11:39:40] *** alesj has joined #weld-dev
[11:52:46] *** magesh has joined #weld-dev
[12:44:30] *** alesj has quit IRC
[12:53:35] *** alesj has joined #weld-dev
[13:10:34] *** pmuir has joined #weld-dev
[13:30:01] <ge0ffrey> alesj, pmuir: checking tomcat
[13:30:09] <pmuir> ge0ffrey: thanks
[13:32:59] <alesj> ge0ffrey: cool
[13:33:16] <alesj> we should have fixed this location issues long ago ...
[13:33:47] <alesj> Tomcat might be strange ? as they have their own weird "VFS" afair
[13:37:37] <ge0ffrey> there's some complex irony between what works and what not, writing a compatiblity table down in the email :)
[13:39:58] <stuartdouglas> I probably should just make AS7 pickup WEB-INF/classes/META-INF/beans.xml
[13:40:05] <stuartdouglas> and log a warning
[13:42:36] <ge0ffrey> alesj: tomcat fails too
[13:42:37] <alesj> pmuir said that the code looks OK, but suspects some weird Jetty behavior
[13:42:57] <pmuir> ge0ffrey: i think this used to work, but idk
[13:43:03] <pmuir> alesj: we should make sure we add tests for this
[13:43:16] <ge0ffrey> pmuir: weld excludes fail
[13:43:17] <pmuir> stuartdouglas: yes, that would prevent about 30% of user error on as7 in this case ;-)
[13:43:25] <ge0ffrey> pmuir: so it woudl be nice if the test would test a weld exclude there
[13:43:36] <pmuir> alesj: ^^^
[13:44:05] <ge0ffrey> stuartdouglas: +1, just log a warning. But maybe you want to fail-fast if both beans.xml are in the war?
[13:44:25] <stuartdouglas> if both are present then I think we should just use the spec one
[13:45:12] <alesj> pmuir: we don't have any Weld:exclude tests yet?
[13:47:48] <ge0ffrey> pmuir, alesj: Summary: the tests probably just check if welds boots up and CDI happens. It does. But the excludes don't work (and probably the rest of the content neither).
[13:48:10] <pmuir> alesj: we do in core
[13:48:16] <pmuir> very extensive ones
[13:48:30] <pmuir> but not specifically for jetty tomcat etc.
[13:51:10] <alesj> ok, while i'll check why the oddity, i'l ltry to add some tests for that as well
[13:51:44] <alesj> ge0ffrey: or, can you wrap your use case (of excludes) into some ARQ test?
[13:54:17] <ge0ffrey> Can't we just run the existing weld excludes tests on jetty?
[13:54:21] <ge0ffrey> it's an arq test no?
[13:55:21] <ge0ffrey> Isn't there some sort of hudson compatibility job that runs all tests on all appservers?
[13:55:28] <alesj> ge0ffrey: why the ? in Jetty6 seam config matrix?
[13:55:46] <ge0ffrey> in the weld matrix?
[13:55:59] <ge0ffrey> idunno, just thinking :)
[13:56:01] <alesj> yeah, the latest email
[13:56:27] <ge0ffrey> ah
[13:56:32] <ge0ffrey> the ? is because I haven't tested it
[13:56:51] <ge0ffrey> it's hard because of the way gwt hosted mode is setup
[13:57:22] <ge0ffrey> and in any case, fixing the weld issue should be done first. I wouldn't be suprised it it automatically fixes the seam issue
[13:57:46] <ge0ffrey> imho of course :)
[13:58:05] <ge0ffrey> alesj: we got thing to check drools vs all database: https://hudson.qa.jboss.com/hudson/view/Drools%20jBPM/job/drools-persistence-db-matrix/
[13:58:26] <ge0ffrey> alesj: Cant something similar be setup so weld-core is testsed vs all appservers with arquillian?
[13:58:49] <stuartdouglas> ge0ffrey: pmuir http://github.com/jbossas/jboss-as/compare/9ff61c6...20b8155
[13:59:15] <stuartdouglas> next release of AS7 web-inf/classes/meta-inf/beans.xml will work
[13:59:34] <ge0ffrey> stuartdouglas: what happens if we got both? :)
[13:59:48] <stuartdouglas> it uses the standard location
[13:59:52] <alesj> stuartdouglas: yeah, try to log that as well
[14:00:00] <pmuir> ge0ffrey: yes, we could run the weld core tests on other containers, just needs some work on the POMs etc and also defining which tests should pass, there are some EJB tests etc. in there
[14:00:06] <ge0ffrey> stuartdouglas: and the other one gets ignored? I can live with that
[14:00:20] <stuartdouglas> the other one is ignored
[14:00:38] <ge0ffrey> stuartdouglas: great, tnx for fixing that :)
[14:01:04] <stuartdouglas> pmuir: as long as other containers only run the ones that are run in the standalone container it should be fine, as they don't need ejb's
[14:04:20] *** emmanuel has quit IRC
[14:08:37] <alesj> stuartdouglas: a JPA + Seam Persistence q for you
[14:08:55] <stuartdouglas> yes?
[14:09:11] <alesj> how does one get to use Extended PC
[14:09:19] <alesj> i think i always get Tx bound one
[14:09:30] <alesj> even if i use @PC(Extyended)
[14:09:39] <alesj> where my bean is request scoped
[14:10:06] <alesj> what's actually the deal with Extended, wasn't that only bound to SFSB?
[14:10:53] <struberg> hmm if you call Persistence#getEntityManagerFactory you always will get an Extended EM in the end
[14:11:05] <pmuir> stuartdouglas: we fake EJBs a bit in the standalone container
[14:11:14] <pmuir> maybe that got fixed up though?
[14:11:21] <pmuir> but yeah, we should def do thius
[14:11:44] <pmuir> actually not sure how many integration tests I wrote for include/exclude, it's possible I mainly wrote unit tests
[14:11:49] <stuartdouglas> alesj: if you use @PsersistenceContext you can only get extended if it is a SFSB
[14:11:51] <alesj> struberg: i simply do @PC(Extended) in my bean
[14:12:08] <stuartdouglas> the SMPC is actually an application managed persistence context
[14:12:18] <stuartdouglas> alesj: that is dictated by the JPA spec
[14:12:36] <alesj> SMPC?
[14:12:37] <stuartdouglas> technically we should throw a deployment exception for @PC(EXTENDED) on a non SFSB
[14:12:44] <stuartdouglas> seam managed persistence context
[14:13:14] <struberg> alesj there is no way to _manually_ create a manged PC
[14:13:23] <struberg> this is just provided by the EJB container
[14:13:36] <struberg> which does the auto-transactional stuff for you as a facade
[14:13:59] <struberg> quite as our @TransactionScoped EntityManager proposal
[14:18:32] *** epbernard has joined #weld-dev
[14:18:32] *** epbernard is now known as emmanuel
[14:28:13] <pmuir> we are looking at ways to improve this for Java EE 7
[14:28:17] <pmuir> not sure of the details yet
[14:29:17] <struberg> pmuir are you talking about creating managed EMs?
[14:29:31] <pmuir> struberg: yeah
[14:29:32] <struberg> I think this is exactly what Rick is working on with @TransactionScoped
[14:29:45] <pmuir> that's somewhat different
[14:30:00] <struberg> I have implemented this in CODI already (but not bound to the TransactionManager, but our @Transactional)
[14:30:05] <pmuir> i'm talking about unsynchronized (manual flush mode) EM + how this ties to various CDI scopes
[14:30:05] <struberg> not really
[14:30:12] <pmuir> it
[14:30:13] <pmuir> is
[14:30:19] <pmuir> i know what i'm talking about ;-)
[14:30:50] <pmuir> since the EM anyway is bound to the system TX
[14:31:05] <struberg> hmm isn't manual #flush() EM and #detach() already part of JPA-2.0?
[14:31:14] <pmuir> detach is
[14:31:19] <struberg> flush too
[14:31:26] <pmuir> manual flush mode is different to em.flush()
[14:31:32] <struberg> but not sure how this is bound to TX ^^
[14:31:35] <pmuir> the EM will always flush at a TX boundary
[14:31:40] <pmuir> in JPA2
[14:31:44] <struberg> kk
[14:31:57] <pmuir> what this is, is the ability to keep an entity attached
[14:32:05] <pmuir> but not have the EM flush at the TX boundary
[14:32:06] <pmuir> basically
[14:32:07] <struberg> oh kk, thats new
[14:32:20] <pmuir> now, not 100% sure of the exact proposal
[14:32:29] <struberg> but this will only work with entities having optimistic locking
[14:32:31] <pmuir> linda told me the outline, but not sure how it differs to what I know well
[14:32:37] <struberg> eBean just does it that way already
[14:32:50] <pmuir> yeah, seam has always done this
[14:32:52] <struberg> they are _not_ JPA conform but almost the same API
[14:33:00] <pmuir> it was one of the reasons for seam in the first place ;-)
[14:33:09] <pmuir> well not always
[14:33:10] <struberg> didnt seam just use hibernate?
[14:33:16] <pmuir> but since 2007 IIRC
[14:33:17] <struberg> which doesnt provide that in JPA mode?
[14:33:30] <pmuir> yeah, seam just wrapped the hibernate calls here
[14:33:38] <pmuir> hibernate offered this as an extension to jpa
[14:33:45] <pmuir> you had to use a hibernate api to set it
[14:33:49] <pmuir> (which seam made easier)
[14:33:55] <pmuir> but from then on could use JPA
[14:33:59] <struberg> yes, and you lost state on serialisation if I remember
[14:34:18] <pmuir> of the entity?
[14:34:21] <struberg> yup
[14:34:25] <pmuir> not sure about that
[14:34:35] <struberg> check your seam cluster docs almost last paragraph
[14:34:38] <pmuir> serialization to a client?
[14:34:41] <struberg> works only 98%...
[14:34:45] <struberg> other cluster node
[14:34:47] <pmuir> ah, passivation
[14:34:57] <pmuir> yeah, there were a lot of problems with that
[14:35:05] <pmuir> i think that is now fixed properly in jboss clustering
[14:35:16] <struberg> yup, and with having pessimistic locking it is imo impossible to solve
[14:35:25] <struberg> at least I dont know how
[14:35:51] <struberg> because the server where your on atm holding a lock cannot just get its state transferred to another node
[14:35:57] <struberg> happens if you do
[14:36:01] <struberg> "select for update"
[14:36:11] <struberg> em#lock() (new in JPA-2)
[14:36:23] <struberg> and if your entities use pessimistic locking
[14:36:27] <struberg> (no version field)
[14:37:01] <pmuir> you would need to talk to emmanuel about it, he is the persistence expert ;-)
[14:37:40] <struberg> eBean just dropped all these features ;)
[14:37:50] <struberg> thus all entities are always serializable
[14:38:12] <struberg> and they have the _dirty and _loaded info in their interfaces which they generate at enhancement time
[14:38:18] <struberg> or you can even annotate them i think
[14:38:29] <struberg> Version+id is mandatory too of course
[14:38:44] <struberg> so you dont even need to transfere the EM itself
[14:39:06] <struberg> because the entities contain all the info (which they also do in JPA when being attached)
[14:39:42] <struberg> One big fail is that the spec doesnt even mention _loaded and dirty, thus no portable serialization can be done :(
[14:39:49] <struberg> (JPA spec that is)
[14:42:06] <struberg> http://www.avaje.org/
[15:15:11] *** aslak has quit IRC
[15:30:22] *** mbg has joined #weld-dev
[15:30:43] *** stalep has joined #weld-dev
[15:34:27] *** aslak has joined #weld-dev
[15:39:22] *** rruss has joined #weld-dev
[16:21:27] <alesj> ge0ffrey, pmuir: so, what exactly is Jetty issue?
[16:21:48] <alesj> excluded from WEB-INF/beans.xml doesn't work?
[16:21:54] <ge0ffrey> alesj: weld:excludes doesn't work on jetty6 in WEB-INF/beans.xml
[16:21:58] <alesj> or, beans.xml in WEB-INF/ doesn't work?
[16:22:01] <ge0ffrey> alesj: and on tomcat either
[16:22:17] <alesj> aha, only excluded in WEB-INF?
[16:22:36] <alesj> since I see all test have beans.xml in WEB-INF ...
[16:22:39] <ge0ffrey> an empty WEB-INF/beans.xml works
[16:22:50] <ge0ffrey> not sure if the other content works or doesn't work
[16:23:03] <alesj> you mean alt, icepotr, etc ? ?
[16:23:03] <ge0ffrey> although nothing of seam-config works either, that's the seam related issue
[16:23:18] <ge0ffrey> alesj: yes, haven't tried alt, icepotr, etc yet
[16:24:00] <alesj> how do you see that excluded doesn;t work?
[16:24:07] <alesj> ge0ffrey: ^
[16:25:18] <ge0ffrey> alesj: the seam-drools-security thing activates
[16:25:29] <ge0ffrey> which crashes as it's not compatible with our latest drools
[16:26:01] <ge0ffrey> and putting the beans.xml in WEB-INF/classes/META-INF/beans.xml does exclude it and it works fine
[16:27:12] *** magesh has left #weld-dev
[17:06:26] <alesj> ge0ffrey: weld:exclude works for me in Jetty6 ...
[17:07:00] <alesj> pmuir: ^
[17:07:56] <ge0ffrey> alesj: it does?
[17:08:03] <ge0ffrey> alesj: any way I can run that test here locally too?
[17:08:20] <alesj> let me commit my test
[17:08:22] <ge0ffrey> alesj: so I can tweak it and proves it doesn't ;)
[17:08:26] <ge0ffrey> tnx
[17:08:28] <alesj> hehe, sure
[17:08:30] <alesj> 1sec
[17:10:05] <alesj> ge0ffrey: https://github.com/alesj/core/tree/servlet-config
[17:10:56] <ge0ffrey> alesj: what's the class name of the test?
[17:11:05] <alesj> ConfigTest
[17:11:13] <alesj> in jetty6 tests
[17:11:23] <alesj> or check ConfigtestBase
[17:12:25] <ge0ffrey> tnx
[17:17:05] <ge0ffrey> alesj: mind pushing those changes to master or is there something that makes that hard?
[17:17:13] <ge0ffrey> I forked blessed
[17:17:56] <alesj> i'll push it once you test it ;-)
[17:18:12] <alesj> configrming if it works
[17:18:23] <alesj> or it it doesn;t ? i'll put some more work into it
[17:18:24] <ge0ffrey> k, it's a good time as any to learn to juggle git repo's :)
[17:18:36] <alesj> yup
[17:18:39] <alesj> it's simple
[17:18:43] <alesj> just add my repo as remote
[17:18:57] <alesj> and then create a new branch, off master
[17:19:03] <alesj> up master
[17:19:19] <alesj> and then simply rebase that new branch with my servlet-config branch
[17:19:20] <alesj> simple
[17:19:21] <alesj> ;-)
[17:22:52] <ge0ffrey> I 've done it slightly different: add it as a remote, hard reset my master to alesj/servlet-config and then checkout -b my fork from that
[17:22:59] <ge0ffrey> should work too?
[17:23:20] <alesj> i guess so ? not git expert as well :-)
[17:23:33] <alesj> we'll soon see ...
[17:28:42] <alesj> jharting: so, what's the conclusion on that generic Event payload issue?
[17:28:49] <alesj> WELD-973?
[17:28:50] <jbossbot> jira [WELD-973] @Specializes is not compatible with seam-config because of a problem in weld's BeanDeployerEnvironment [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/WELD-973
[17:29:00] <alesj> WELD-978?
[17:29:01] <jbossbot> jira [WELD-978] Cannot fire event with parameterized type as a payload [Open (Unresolved) Bug, Major, Jozef Hartinger] https://issues.jboss.org/browse/WELD-978
[17:29:11] <alesj> yes, this one ? jharting ^
[17:29:19] <ge0ffrey> alesj: your test succeeds here too, looking into what's different
[17:29:20] <alesj> cannot be done?
[17:29:28] <alesj> ge0ffrey: ;-)
[17:31:25] <jharting> alesj: I discussed with pete. We tried to find a contradiction in the spec that would let us ignore the conflicting statements in the spec. Unfortunatelly, it seems that the spec is pretty consistent in ignoring the specified type and restricting the Java type of the event object all the time.
[17:32:02] *** mkouba has quit IRC
[17:32:56] <jharting> alesj: Thus we should probably leave it as it is in weld ATM
[17:35:02] <ge0ffrey> alesj: the test is valid. The only different I see so far is that it's weld 1.1.3-SNAPSHOT instead of weld 1.1.2.Final
[17:37:10] <alesj> ge0ffrey: then try your stuff with 1.1.3-SNAPSHOT?
[17:37:43] <ge0ffrey> alesj: yep, building your fork and I plugging it in
[17:45:28] *** jharting has quit IRC
[17:56:32] *** mathieuancelin has quit IRC
[18:24:39] *** alesj has quit IRC
[18:37:16] *** alesj has joined #weld-dev
[18:54:27] *** stalep has quit IRC
[18:54:53] *** oskutka has quit IRC
[19:02:29] *** maschmid has quit IRC
[19:06:35] *** mbg is now known as mbg|away
[19:18:11] *** mbg|away is now known as mbg
[19:31:08] <ge0ffrey> alesj: my stuff with weld 1.1.3-SNAPSHOT and WEB-INF/beans.xml location gives https://gist.github.com/1309575
[19:31:55] <ge0ffrey> alesj: that's probably because of SOLDER-220, so that would mean the weld issue is solved in 1.1.3-SNAPSHOT
[19:31:57] <jbossbot> jira [SOLDER-220] Seam-config ignores WEB-INF/beans.xml (and WEB-INF/seam-beans.xml) in jboss 7 and tomcat 6 for seam-config configuration (but not weld configuration) [Open (Unresolved) Bug, Critical, Stuart Douglas] https://issues.jboss.org/browse/SOLDER-220
[19:33:41] *** mbg is now known as mbg|away
[19:36:20] *** stalep has joined #weld-dev
[19:39:19] *** mbg|away is now known as mbg
[19:39:52] <ge0ffrey> alesj: I 've marked WELD-953 as "cannot reproduce bug" as debugging + your test has lead me to believe it's all due to SOLDER-220.
[19:39:54] <jbossbot> jira [WELD-953] WEB-INF/beans.xml is ignored  on jetty 6 (and GWT hosted mode) [Resolved (Cannot Reproduce Bug) Bug, Major, Unassigned] https://issues.jboss.org/browse/WELD-953
[19:39:55] <jbossbot> jira [SOLDER-220] Seam-config ignores WEB-INF/beans.xml (and WEB-INF/seam-beans.xml) in jboss 7 and tomcat 6 for seam-config configuration (but not weld configuration) [Open (Unresolved) Bug, Critical, Stuart Douglas] https://issues.jboss.org/browse/SOLDER-220
[19:44:58] <ge0ffrey> pmuir, stuartdouglas: when I created SOLDER-220, I only knew stuart and I wrongly(?) assigned it to him (I see now he's weld-as7 mostly). I 've unassigned it so someone can pick it up.
[19:45:00] <jbossbot> jira [SOLDER-220] Seam-config ignores WEB-INF/beans.xml (and WEB-INF/seam-beans.xml) in jboss 7 and tomcat 6 for seam-config configuration (but not weld configuration) [Open (Unresolved) Bug, Critical, Unassigned] https://issues.jboss.org/browse/SOLDER-220
[19:51:13] <pmuir> ge0ffrey: yeah, talk to shane about getting some attention on that
[19:51:35] *** ge0ffrey has quit IRC
[19:55:49] *** mbg is now known as mbg|away
[19:57:00] *** jharting has joined #weld-dev
[20:01:50] <alesj> Note: jetty7 needs PlusConfiguration enabled for JNDi BM lookup to work
[20:09:42] *** mbg|away is now known as mbg
[20:25:14] *** jharting has quit IRC
[20:32:10] *** emmanuel has quit IRC
[21:11:30] *** lincolnthree has joined #weld-dev
[21:11:35] <lincolnthree> hey alesj
[21:12:41] <lincolnthree> https://issues.jboss.org/browse/WELD-877
[21:12:43] <jbossbot> jira [WELD-877] "IllegalStateException: Context is already active" when error-page of exception-type com.sun.faces.context.FacesFileNotFoundException [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/WELD-877
[21:12:55] <lincolnthree> This is causing downstream bugs in AS7 deployments
[21:13:13] <alesj> lincolnthree: fix it ;-)
[21:13:19] <alesj> and send a pull-request
[21:14:45] <lincolnthree> alesj: only if you list me as a weld contributor :)
[21:15:26] <alesj> hmmm, will think about it ? once you add a pull request ;-)
[21:36:27] <lincolnthree> alesj: ok, im in the source, where are the JSF tests?
[21:49:37] <alesj> lincolnthree: should be in env/servlet/tests
[21:49:52] <lincolnthree> found it i think
[21:50:05] <lincolnthree> was confused, didn't see JSF packages under tests
[21:50:07] <lincolnthree> they're hidden
[21:50:13] <lincolnthree> and also actually
[21:50:16] <lincolnthree> they are all @Ignored ATM
[21:50:19] <lincolnthree> problem? ;)
[21:54:18] *** oskutka1 has joined #weld-dev
[22:16:29] *** pmuir has quit IRC
[22:20:20] <alesj> lincolnthree: hmmm ...
[22:20:26] <lincolnthree> alesj: nm
[22:20:31] <lincolnthree> found them
[22:20:35] <alesj> what happens in you un-ignore them?
[22:20:45] <lincolnthree> alesj: they fail ;)
[22:21:09] <alesj> what's the cause?
[22:21:16] <lincolnthree> not goign to look into them right now
[22:21:21] <lincolnthree> going to get this test working first
[22:21:39] <lincolnthree> look at JsfTestBase if and find references if you want to see what I'm talking about
[22:21:54] <lincolnthree> there are a few servlet tests that reference that
[22:21:57] <lincolnthree> and they are all @Ignored
[22:23:47] <alesj> JsfTest for jetty7 works
[22:23:53] <alesj> in my latest branch :-)
[22:23:55] *** mbg has quit IRC
[22:23:58] <lincolnthree> hm, i think i ran tomcat
[22:24:10] <lincolnthree> alesj: how should i run these tests?
[22:24:13] <lincolnthree> the arq-tests
[22:24:17] <lincolnthree> which container?
[22:24:24] <lincolnthree> aka, which maven profile?
[22:24:37] <alesj> so does jetty6
[22:24:47] <lincolnthree> ok
[22:24:52] <lincolnthree> even the arq-tests?
[22:24:57] <lincolnthree> I'm not talking about the servlet ones
[22:26:06] <lincolnthree> alesj: looks like it's trying to run on as6
[22:26:20] <lincolnthree> org.jboss.arquillian.container.spi.ConfigurationException: jbossHome '~/Development/jboss7' must exist
[22:26:20] <lincolnthree> 	at org.jboss.arquillian.container.spi.client.deployment.Validate.configurationDirectoryExists(Validate.java:93)
[22:26:39] <lincolnthree> doesn't like that my JBOSS_HOME is set to AS7 location
[22:29:11] <alesj> hmmm, see build.properties
[22:30:00] <lincolnthree> alesj: which one?
[22:30:48] <alesj> jboss-as/as7
[22:31:30] <alesj> lincolnthree: which tests are you running now?
[22:31:41] <lincolnthree> alesj: the weld-core-test-arquilliahn
[22:31:59] <lincolnthree> nothing special in that build.properties file
[22:33:12] <alesj> lincolnthree: #jboss.home=/Users/alesj/projects/as7/as/build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT ;-)
[22:33:20] <alesj> it's commented out
[22:33:32] <lincolnthree> i dont see that, ah, source view
[22:36:57] <lincolnthree> alesj: same issue
[22:37:15] *** rruss has quit IRC
[22:37:16] <lincolnthree> ~/Development/jboss7
[22:37:17] <lincolnthree> must exist
[22:37:20] <lincolnthree> and it does exist
[22:42:24] <lincolnthree> alesj: ideas?
[22:42:48] <alesj> what's the exact issue?
[22:43:00] <lincolnthree> alesj: I can't run the tests
[22:43:15] <lincolnthree> http://fpaste.org/X0BO/
[22:43:23] <alesj> i usually set the jboss.home in build.propreties
[22:43:30] <lincolnthree> i did
[22:43:30] <alesj> then it should just work
[22:43:33] <lincolnthree> it does not
[22:44:02] <lincolnthree> jboss.home=/home/lb3/Development/jboss7
[22:44:06] <lincolnthree> still same error
[22:44:32] <alesj> weird
[22:44:42] <alesj> debug?
[22:44:56] <lincolnthree> nothing to debug really
[22:45:01] <lincolnthree> the tests don't launch
[22:45:33] <alesj>       if (string == null || string.length() == 0 || new File(string).isDirectory() == false)
[22:45:42] <lincolnthree> ?
[22:45:44] <alesj> check this line, if you can ...
[22:45:49] <lincolnthree> where is that?
[22:45:51] <alesj> in Validate class of ARQ
[22:46:03] <alesj> see last line of your stack trace
[22:46:17] <lincolnthree> ok
[22:46:53] <lincolnthree> looks correct
[22:46:57] <lincolnthree> then it prints the error
[22:47:03] <lincolnthree> ~/Development/jboss7
[22:47:07] <lincolnthree> same as in the message
[22:47:39] <lincolnthree> ah
[22:47:40] <lincolnthree> heh
[22:47:43] <lincolnthree> it's a symlink
[22:47:49] <lincolnthree> i guess Arquillian doesn't like that
[22:48:03] <alesj> FS of JDK is crap ...
[22:48:12] <alesj> the new one fixes these things
[22:48:52] <aslak> lincolnthree, new File(string).isDirectory()
[22:49:04] <lincolnthree> yea, that's annoying
[22:49:58] <lincolnthree> it also doesn't like the ~
[22:49:59] <lincolnthree> heh
[22:51:00] <lincolnthree> gotta restart my X session to fix
[22:51:56] *** rruss has joined #weld-dev
[22:52:10] <lincolnthree> ty
[22:52:50] *** lincolnthree has quit IRC
[22:53:33] *** oskutka1 has quit IRC
[22:55:27] *** lincolnthree has joined #weld-dev
[22:55:35] <lincolnthree> alright lets try this again
[22:55:47] <lincolnthree> now that my environment is more "java friendly" ;)
[22:56:48] <aslak> i wonder who's going to create the first File IO abstraction that support JDK/ with Pre 7 fallback.. :)
[22:56:58] <aslak> JDK7 even
[22:58:22] <lincolnthree> aslak: you mean who will re-introduce the bugs into JDK 7 as a compatability layer?
[22:59:30] <lincolnthree> alesj: success
[22:59:39] <lincolnthree> i proved that weld crashes if you forward from one JSF view to another
[22:59:48] *** stalep has quit IRC
[23:00:32] *** oskutka has joined #weld-dev
[23:01:25] <lincolnthree> alesj: is this really deploying and replacing weld into the container?
[23:01:31] <lincolnthree> or is it just using whatever is in as7?
[23:02:34] <aslak> lincolnthree, that as well :)
[23:03:19] <lincolnthree> ?
[23:03:32] <lincolnthree> oh
[23:03:34] <lincolnthree> you're not ales
[23:03:35] <lincolnthree> lol
[23:03:48] <lincolnthree> aslak: but maybe you can answer my question
[23:03:55] <lincolnthree> do you know?
[23:04:36] <alesj> lincolnthree: it's just using what's there
[23:04:42] <alesj> you need to run this to change it
[23:05:32] <alesj> mvn clean install -Pupdate-jboss-as
[23:05:34] <alesj> and then
[23:05:41] <alesj> mvn verify -Dincontainer
[23:05:57] <lincolnthree> from the root/ directory of weld?
[23:06:12] <alesj> yes
[23:06:19] <alesj> weld/core
[23:06:26] <lincolnthree> ok, running
[23:06:56] <lincolnthree>  Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.5:checkstyle (check-style) on project weld-core: An error has occurred in Checkstyle report generation. Failed during checkstyle execution: There are 8 checkstyle errors
[23:06:57] <lincolnthree> hmm
[23:07:49] <alesj> your ugly code :-)
[23:07:59] <lincolnthree> I wrote a test!
[23:08:00] <lincolnthree> lol
[23:08:03] <lincolnthree> I haven't touched the code yet :)
[23:08:18] <alesj> test are code as well ;-)
[23:08:34] <lincolnthree> alesj: how do i view the reports?
[23:12:05] <alesj> text editor?
[23:12:31] <lincolnthree> ales, yes but where is the file?
[23:13:24] <alesj> it depends which test
[23:13:33] <alesj> in which dir
[23:13:42] <alesj> it should be under the dir it was run
[23:14:15] <lincolnthree> hmm
[23:14:26] <lincolnthree> alesj: jboss community formatting?
[23:15:47] <lincolnthree> alesj: ok i got the reports, but it's complaining about things that are not true
[23:15:51] <lincolnthree> /home/lb3/Projects/jboss/weld-core/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java:69: Line has trailing spaces.
[23:15:51] <lincolnthree> /home/lb3/Projects/jboss/weld-core/impl/src/main/java/org/jboss/weld/jsf/WeldPhaseListener.java:138: Line has trailing spaces.
[23:15:51] <lincolnthree> Audit done.
[23:16:18] <lincolnthree> ok, eclipse sucks
[23:16:19] <lincolnthree> it is true
[23:24:48] <lincolnthree> ok alesj:
[23:24:48] <lincolnthree> INFO: XNIO NIO Implementation Version 3.0.0.Beta2
[23:24:48] <lincolnthree> 17:12:47,110 INFO  [org.jboss.modules] JBoss Modules version 1.0.2.GA
[23:24:48] <lincolnthree> 17:12:47,359 ERROR [stderr] java.lang.IllegalArgumentException: Neither /home/lb3/Development/jboss7/standalone/configuration/standalone-preview.xml nor /home/lb3/Projects/jboss/weld-core/jboss-tck-runner/standalone-preview.xml exist
[23:24:55] <lincolnthree> weird one
[23:51:32] *** oskutka has quit IRC
[23:53:08] *** alesj has quit IRC





top