March 24, 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:01:15] <Tashtego> have to go to bed :( trying tomorrow again. thx so far @all
[00:01:57] *** Tashtego has quit IRC
[00:04:14] *** bleathem has quit IRC
[00:14:12] *** lightguard_jp has quit IRC
[00:17:41] *** ldimaggi has joined #jbosstesting
[00:39:04] *** jganoff has joined #jbosstesting
[00:52:24] *** jganoff has quit IRC
[01:37:25] *** michaelschuetz has quit IRC
[02:15:51] *** aslak has quit IRC
[02:43:34] *** johnament has joined #jbosstesting
[03:00:47] *** bleathem has joined #jbosstesting
[04:18:54] *** ldimaggi has quit IRC
[04:31:23] *** johnament has quit IRC
[06:49:09] *** Elisha has quit IRC
[06:49:43] *** Elisha has joined #jbosstesting
[07:12:54] *** stuartdouglas has quit IRC
[07:14:43] *** stuartdouglas has joined #jbosstesting
[07:22:01] *** stuartdouglas has quit IRC
[07:26:29] *** stuartdouglas has joined #jbosstesting
[07:27:02] *** bleathem has quit IRC
[07:28:03] *** jharting has joined #jbosstesting
[08:09:48] *** bleathem has joined #jbosstesting
[08:28:05] *** Jaikiran has joined #jbosstesting
[08:31:35] *** ge0ffrey has joined #jbosstesting
[08:42:20] *** kpiwko has joined #jbosstesting
[08:48:25] *** oskutka has joined #jbosstesting
[08:51:55] *** jeand has joined #jbosstesting
[08:54:43] *** jeand has quit IRC
[08:58:12] *** jeand has joined #jbosstesting
[09:04:28] *** mgoldmann has joined #jbosstesting
[09:19:38] *** bleathem has quit IRC
[09:43:20] *** aslak has joined #jbosstesting
[09:43:20] *** aslak has quit IRC
[09:43:20] *** aslak has joined #jbosstesting
[09:57:59] *** wolfc has joined #jbosstesting
[10:01:41] *** aslak has quit IRC
[10:02:39] *** aslak has joined #jbosstesting
[10:04:11] *** vtunka_wfh has joined #jbosstesting
[10:05:14] *** michaelschuetz has joined #jbosstesting
[10:09:04] <aslak> ge0ffrey, ping
[10:13:23] <ge0ffrey> aslak: hi
[10:13:49] <aslak> ge0ffrey, you did the drools repo split right?
[10:13:56] <ge0ffrey> yep :)
[10:14:05] <aslak> ge0ffrey, how is it working?
[10:14:07] <ge0ffrey> the gory details are in a mail on our dev list
[10:14:13] <aslak> ge0ffrey, yea, reading it
[10:14:31] <ge0ffrey> it's good, in my opinion
[10:14:50] <ge0ffrey> we do have a big problem: there's not workign snapshot of one of the lower dependencies since the split-up
[10:15:01] <ge0ffrey> so that's been causing a lot of havoc
[10:16:05] <ge0ffrey> 2 developers were working on topic branches for that depedency (drools-core/compiler) and the work was understestimated so it wasn't ready af the time of the split-up
[10:16:38] <ge0ffrey> so the just merged that as is (it compiled, but no tests) into master, so it could be split-off
[10:16:48] <aslak> cherry picking should fix that right ?
[10:16:50] <ge0ffrey> we'll have it working soon
[10:17:36] <ge0ffrey> no, the problem is that when you split-off a bunch of modules into it's own repository, you have to have everything pushed and everyone so delete their working directory
[10:17:43] <ge0ffrey> (for those modules)
[10:17:53] <aslak> yes of course..
[10:18:03] <aslak> true..
[10:18:19] <aslak> about to start the same job for Arquillian. splitting out all the containers and extensions
[10:18:37] <ge0ffrey> we communicated it, but the size of the topic branches were really big. you probably won't have that problem
[10:18:58] <ge0ffrey> aslak: I did on new repo at a time
[10:19:59] <ge0ffrey> so I said "freeze module C, D, E from Friday" and on Friday, I started migrating them, and immedialy git rm them on master
[10:21:07] <aslak> ge0ffrey, right, you left the 'old' repo as is, no rebase/filtering. just simple rm
[10:21:57] <aslak> or is the old one replaced with a new as well..
[10:22:24] <ge0ffrey> no, I left the old one as is
[10:22:28] <ge0ffrey> it's still there atm
[10:22:45] <ge0ffrey> I 'll remove on it 1-APR to avoid confusion
[10:22:58] <aslak> ge0ffrey, is it used, or technically replaced bu "drools-core" ?
[10:23:04] <ge0ffrey> https://github.com/droolsjbpm/droolsjbpm
[10:23:14] <ge0ffrey> it's unused
[10:23:27] <aslak> aa, ok
[10:23:39] <ge0ffrey> but during the split-up, it was used: so people working on drools could continue working while I split up guvnor on Wednesday
[10:23:59] <ge0ffrey> depends how big your team is. Maybe you can just say "freeze everything for a week"
[10:24:05] <aslak> so end result is, X number of new repos, with no comperable history besides the commits message ?
[10:25:04] <ge0ffrey> yes
[10:25:32] <ge0ffrey> and snapshots comes from nexus which gets them from hudson
[10:25:39] <aslak> you left tags in old repo, delete and starting from scratch in the new ?
[10:25:55] <ge0ffrey> yes, but I am not sure now that that was really neded
[10:26:17] <ge0ffrey> I would suggest to try to keep tags and branches
[10:26:26] <ge0ffrey> experiment and see if it works
[10:26:32] <aslak> in the new ?
[10:26:38] <ge0ffrey> the problem is: those tags/branches won't build in the new repos
[10:27:00] <aslak> yea, and they are pointing to a complete different history then the original
[10:27:13] <ge0ffrey> as your build will need to be split-off too, and you're not going to go do that for all old tags/branches maybe
[10:27:39] <ge0ffrey> the git command can copy tags and branches
[10:27:47] <ge0ffrey> use "-- all" or something
[10:28:15] <aslak> sure, but a tag is a mark in history. if you rewrite history i'm not sure that tag makes any sense anymore
[10:28:20] <ge0ffrey> so no prob, from a scm perspective. But you if checkout an old branch in a sub repository, that build script won't be able to handle that situation
[10:28:30] <ge0ffrey> good point
[10:28:42] <ge0ffrey> maybe just to be able to compare with "what's in production)
[10:29:38] <aslak> well yea. it still represent what this code looked like at that point, the surrounding code and the complete picture is gone, but
[10:47:04] *** Tashtego has joined #jbosstesting
[10:50:36] *** alesj has joined #jbosstesting
[10:58:54] *** michaelschuetz has quit IRC
[10:59:37] *** michaelschuetz has joined #jbosstesting
[11:25:46] *** maeste has joined #jbosstesting
[11:30:04] *** michaelschuetz has quit IRC
[11:30:48] *** michaelschuetz has joined #jbosstesting
[11:45:01] *** maeste has quit IRC
[11:48:15] <Tashtego> aslak your tip with the external domain.xml finally worked. thanks again for your help yesterday. the only thing i will have to check is my transactions not being rollbacked now ;) but the unit tests run ;)
[11:48:34] <aslak> Tashtego, excellent
[12:03:33] *** maeste has joined #jbosstesting
[12:24:28] *** pmuir has joined #jbosstesting
[12:27:01] *** Jaikiran has quit IRC
[12:50:01] <aslak> ge0ffrey, right, prune-empty was the one i was missing from my first attempt. was stuck with all revisions that had nothing to do with the extraction.. :)
[12:50:56] <ge0ffrey> aslak: there's a couple of pitfalls :) I 've based myself on several stackoverlfow questions and blogs
[12:51:17] <ge0ffrey> one big is on that you need to know all the names of the dictories now and in the past
[12:51:59] <aslak> ge0ffrey, right..
[12:52:01] <ge0ffrey> for example, I first extracted "drools-planner" only. But a year ago it was named "drools-solver" instead, so the git split-off needs to filter on both
[12:52:16] <ge0ffrey> that's very annoying, but it makes sense, git can't know that
[12:52:36] <aslak> ge0ffrey, well, it could, butthe filtering is to based on rename so
[12:52:50] <aslak> but the filtering is based on names i mean, not logic
[12:53:56] <aslak> ge0ffrey, the result is only missing history right ?
[12:54:08] <ge0ffrey> yes
[12:54:19] <ge0ffrey> the last revision is the same
[12:54:25] <aslak> mm
[12:54:28] <ge0ffrey> the snapshot is "intact"
[12:54:36] <ge0ffrey> but you do loose history
[12:55:06] <aslak> hmm, do you know if sub-directory handles that ?
[12:55:41] <ge0ffrey> it can't really
[12:55:55] <ge0ffrey> it doesn't
[12:56:06] <ge0ffrey> that's even more resistricted
[12:56:36] <ge0ffrey> if I do drools-planner as subsdirectory-filter, it's impossible to have the history of drools-solver: where would it put it? it can't go ../drools-solver
[12:57:01] <ge0ffrey> that's why the other way is better (but a lot slower!)
[12:57:20] <aslak> good point
[12:57:36] <ge0ffrey> and you need to know the old directory names. but the trick is to have one module "that gets everything else, drools in my case"
[12:57:42] <ge0ffrey> * one repo
[12:57:51] <ge0ffrey> so nothing is lost
[12:59:18] <aslak> well, it does know drools-solver was renamed drools-planner. putting them both a root / and rewriting the rename should work ?
[12:59:57] <aslak> but of course, there are more tricky rewrites then a simple rename in the mix i guess
[13:00:53] <aslak> right, but you filter drools as well, just the inverted filtering form the others ?
[13:00:58] <aslak> from
[13:02:04] *** Jaikiran has joined #jbosstesting
[13:21:38] *** bobmcw has joined #jbosstesting
[13:21:52] *** ldimaggi has joined #jbosstesting
[13:32:07] *** timte has joined #jbosstesting
[13:34:05] *** lincolnthree1 has joined #jbosstesting
[13:35:44] *** jharting has quit IRC
[14:08:41] *** maeste has quit IRC
[14:13:52] *** maeste has joined #jbosstesting
[14:17:20] *** ldimaggi has quit IRC
[14:51:17] *** kpiwko has quit IRC
[15:04:28] *** ldimaggi has joined #jbosstesting
[15:04:57] *** Jaikiran is now known as Jaikiran|AFk
[15:13:39] *** lightguard_jp has joined #jbosstesting
[15:30:58] <Tashtego> *&$$%*!!! damn transactions. cant fix that. tried to set auto-commit in domain.xml to false, no effect. tried transaction.begin() and transaction.rollback(), no effect. and when i try transaction.setRollBackonly() the ssb call throws an exception. why isnt my transaction extended by the called ssb?
[15:31:41] <Tashtego> shouldnt the ssb use the transaction i started in my arquillian test class?
[15:32:03] <Tashtego> i dont see a reason why this isnt working anymore after that update. the begin and rollback solution worked fine before
[15:32:15] <Tashtego> why should transaction handling have changed?
[15:35:53] <aslak> you using @Inject now?
[15:36:08] <jdlee> so you injected the SSB, start a txn, call the SSB, then try to rollback in the unit test?
[15:36:32] <jdlee> doesn't the call to the SSB commit the txn upon successful completion?
[15:37:45] <aslak> jdlee, shouldn't the SSB join the UserTransaction if there is one by default?
[15:38:19] <jdlee> i think that's right, but I don't know if it will commit the txn even if it joined an existing one
[15:38:41] <jdlee> that was more of a "how is it supposed to work" more than "here's how it works" question :P
[15:38:49] <aslak> it shouldn't commit it..  it's joining a existing transaction outside of it's control
[15:38:57] <Tashtego> aslak yes i use inject now
[15:39:13] <jdlee> right. that's what I would expect, but I'm curious if that's how it's actually behaving
[15:39:17] <Tashtego> jdlee right (transaction,begin, ssb call... rollback)
[15:39:39] <Tashtego> thats what i thought aslak
[15:39:45] <Tashtego> it should continue the transaction
[15:39:48] <Tashtego> but it doesnt
[15:39:50] <aslak> Tashtego, you don't have the SSB annotated with REQUIRES_NEW ?
[15:39:51] <jdlee> Tashtego: can debug the test and see if the commit is happening after the return from the SSB?
[15:39:59] <jdlee> aslak: good question :)
[15:40:05] <Tashtego> because as soon as i do a transaction.setRollbackonly there comes an exception
[15:40:08] <Tashtego> after the ssb call
[15:40:16] <Tashtego> because the ssb call tried to commit
[15:41:08] <Tashtego> no i dont use "requires new"
[15:41:18] *** ALR has joined #jbosstesting
[15:41:37] <aslak> Tashtego, can you pastebin the whole testcase
[15:41:45] <aslak> Tashtego, and the ssb
[15:43:28] <aslak> ALR, ping
[15:43:35] <aslak> ALR, also known as good morning
[15:43:40] <aslak> :)
[15:43:42] <ALR> aslak: Afternoon.
[15:44:01] <aslak> ALR, any comments on the meeting ref i sent over ?
[15:44:01] <Tashtego> jdlee the exception rises right after the ssb call
[15:44:08] <Tashtego> but only when i do the setrollbackonly
[15:44:12] <Tashtego> else no exception arises
[15:44:34] <Tashtego> ok pasting... second
[15:45:00] <ALR> aslak: Ah, sorry.  Let me pull that up now.
[15:45:37] <Tashtego> unit test: http://pastebin.com/sjbWFaHD
[15:46:54] <ALR> aslak: Where was that sent to?  I'm not finding it?
[15:46:55] <aslak> Tashtego, can you pastebin the whole one
[15:47:15] *** lincolnthree1 has left #jbosstesting
[15:47:30] <Tashtego> ssb: http://pastebin.com/R9qV6jSY
[15:48:12] <aslak> ALR, alrubinger.com, it's in the arq release thread
[15:48:35] <ALR> Ah thanks
[15:48:38] <Tashtego> http://pastebin.com/CA5Mqhzs
[15:48:41] <Tashtego> thats the whole one
[15:48:51] <ALR> aslak: Will reply inline to the Thread
[15:49:01] <aslak> ALR, thanks
[15:50:28] <aslak> Tashtego, your persistence unit it JTA based?
[15:50:31] <aslak> is
[15:50:34] <Tashtego> yes
[15:50:39] *** michaelschuetz has quit IRC
[15:53:29] <aslak> Tashtego, what happens if you change @Inject with @Resource
[15:53:42] <Tashtego> trying...
[15:53:51] <aslak> on UserTransaction that is
[15:54:48] <Tashtego> resourece doesnt change anything, commit happens anyways
[15:56:21] <aslak> Tashtego, hmm, your deployment only defines NewsServiceDAOJpa, can you add the super classes as well ?
[15:56:56] <aslak> AbstractServiceDaoJpa and what ever that has a superclass if any
[15:57:10] <Tashtego> sshouldnt instantiation of ssb fail when its superclass is missing?
[15:57:19] <Tashtego> but i can try
[15:57:36] <aslak> Tashtego, well.. it should, but it's not missing, it's on your app classpath..
[15:58:53] <Tashtego> no effect
[15:58:59] <Tashtego> still the commit happens
[15:59:54] <Tashtego> could it have anything to do with the properties inside domain.xml ? resource-pool...?
[16:00:02] <aslak> jdlee, ^
[16:00:14] <Tashtego> i am using org.postgresql.ds.PGSimpleDataSource
[16:00:33] <Tashtego> is-isolation-level-guaranteed="false"  <-- is taht correct?
[16:01:09] <jdlee> Tashtego: on what line are getting an exception, and what exception is it?
[16:01:46] <Tashtego> no exception, the unit test runs through and does a commit. i only get an exception when i try it with setRollbackonly. the exact error is:...
[16:02:39] <Tashtego> right after the call of dao.createNewsCategory(newsCategory); the exception rises:
[16:02:45] <Tashtego> javax.ejb.TransactionRolledbackLocalException: Client's transaction aborted
[16:03:24] <jdlee> you get that error before line 78 executes?
[16:03:57] <Tashtego> line 78 is the transaction.setRollbackonly() line
[16:04:05] <Tashtego> 79 would be the dao call method
[16:04:17] <jdlee> ok...your code has changed, then. hehe
[16:04:24] <Tashtego> just the line with the rollback
[16:04:31] <Tashtego> else no changes
[16:05:01] <jdlee> so dao.createNewsCategory(newsCategory); throws the exception, or the next line does?
[16:05:11] <jdlee> that is, does that call return successfully?
[16:05:18] <jdlee> can you paste the stack trace?
[16:06:44] <jdlee> another, slightly related question: why are you monkeying with the transactions at all?
[16:06:55] <Tashtego> when i set a breakpoint into the first line after the dao call (query = ...) the breakpoint is never reached
[16:07:03] <Tashtego> means the exception happens at the end of the dao call
[16:07:21] <Tashtego> but the dao works, becuase when no rollbackonly is set, it persists the news category to database
[16:07:24] <jdlee> ok
[16:08:28] <Tashtego> stacktrace follows...
[16:08:40] <Tashtego> i am just testing my session bean, i dont want to change data on the database
[16:08:47] <Tashtego> therefore the transaction handling
[16:08:53] <Tashtego> else the unit test would just work one time
[16:09:04] <Tashtego> i would have to fix every delete and update after i did. a rollback is easier
[16:09:15] <jdlee> in theory ;)
[16:09:16] <jdlee> hehe
[16:09:20] <aslak> :)
[16:09:52] <jdlee> fwiw, i usually have a @BeforeTest that preps my test DB, if need be, before each test to make sure the data is as expected for the test
[16:10:03] <jdlee> s/BeforeTest/Before/
[16:10:09] <jdlee> or...whatever :P hehe
[16:11:19] <Tashtego> http://pastebin.com/Cw52WXYr
[16:12:50] <aslak> hmm, it does seem to try to use the client tx, useClientTx
[16:12:56] <aslak>  com.sun.ejb.containers.BaseContainer.useClientTx(BaseContainer.java:4700)
[16:13:47] <Tashtego> ?
[16:16:13] <aslak> Tashtego, it does seem like the SSB enlist with your UserTransaction.
[16:17:14] <Tashtego> i am not sure what this means :( whats wrong in my code ^^
[16:17:38] <aslak> Tashtego, try instead of addAsManifestResource(.. "persistence.xml"), do addAsResource(.., "META-INF/persistence.xml")
[16:18:25] *** bleathem has joined #jbosstesting
[16:18:33] <aslak> Tashtego, and add a System.out.println(war.toString(Formatters.VERBOSE)) before you return the archive.. so we can see how the deployment strcuture is
[16:18:35] *** lfryc has quit IRC
[16:19:51] <aslak> hmm, where does persistence.xml go in a war again? WEB-INF/ or WEB-INF/classes/META-INF ?
[16:20:57] <jdlee> aslak: the latter, i think
[16:21:40] <Tashtego> no effect
[16:21:47] <Tashtego> commit happens
[16:22:14] <Tashtego> should i use the webinf....meta path?
[16:22:16] <Tashtego> testing..
[16:22:30] *** vtunka_wfh has quit IRC
[16:23:40] <aslak> addAsResource(.., "META-INF/) should end up in WEB-INF/classes/META-INF
[16:23:59] <Tashtego> testing that right now
[16:24:16] <Tashtego> still commits
[16:24:38] <Tashtego> testing this one with rollbackonly...
[16:26:15] <Tashtego> same behasviour
[16:28:40] <Tashtego> is my approach not how arquillian is meant to be used? ;) or would it be ok that way?
[16:30:34] <jdlee> personally, i'm not a big fan of manual txn mgmt like that :P
[16:30:43] <jdlee> might be easier to change how you're testing
[16:31:28] <Tashtego> i dont handle transactions in my app, only in the tests. if i dont find another way i will perhaps have to use your @Before solution ;)
[16:31:42] <aslak> Tashtego, there is nothing strictly speaking wrong with what you are doing as far as i can tell
[16:32:25] <aslak> Tashtego, the SSB seems to join in in the tx you started, but it might be that the the EntityManager used in the SSB is outside the transaction
[16:34:25] <Tashtego> hm i see. but i dont know how i could change that.  using an entity manager inside my test class would make my ssb unneccesary. thats what the session bean should do, persist the changes ;)
[16:35:46] *** oskutka has quit IRC
[16:40:05] *** pmuir has quit IRC
[16:40:26] <jdlee> Tashtego: that's what I meant.  in the tests
[16:41:10] <Tashtego> hm
[16:41:21] <jdlee> i wonder if the EM in the test and the EM in the SSB are the same instance
[16:41:37] <Tashtego> right now there is no em in the test
[16:41:39] <jdlee> and if you can have two EMs participating in the same UserTransaction
[16:41:59] <jdlee>     @PersistenceContext(unitName = "memphisPU")
[16:41:59] <jdlee>     private EntityManager entityManager;
[16:42:18] <jdlee> query = entityManager.createQuery("SELECT n FROM NewsCategory n", NewsCategory.class);
[16:45:37] <Tashtego> hm
[16:57:22] <Tashtego> entitymanager.jointransaction in my ssb didnt work either
[16:57:25] <Tashtego> i am taking a break
[16:57:33] <Tashtego> dont have any ideas left
[16:57:41] <Tashtego> thanks anyways for your help so far guys!
[16:58:32] * jdlee nods
[17:03:54] *** Tashtego has quit IRC
[17:11:32] <ALR> aslak: "addDirectory" in SW
[17:11:43] <ALR> > addAsDirectory() ?
[17:11:47] <ALR> WDYT?
[17:13:20] *** alesj has quit IRC
[17:16:01] <aslak> ALR, your talking about the one that adds empty directory Assets right?
[17:16:25] <ALR> aslak: yeah
[17:17:10] <aslak> that's one of the cases where the as actually makes sense
[17:17:41] <aslak> but maybe Directory is not enough..  EmptyDirectory, DirectoryMarker, DirectoryPath
[17:18:19] <aslak> ALR, how is the api for adding directory content now?
[17:19:11] <ALR> addDirectory
[17:19:27] <ALR> Accepts String, ArchivePath...
[17:19:30] <ALR> Should be "as"
[17:19:33] <ALR> I think so too,
[17:20:45] <aslak> ALR, no i mean the upcoming api for adding the content of a directory.
[17:21:28] <ALR> aslak: Oh.  No API changes are needed there.
[17:21:33] <ALR> If it's a directory, recurse in.
[17:21:46] <ALR> aslak: https://issues.jboss.org/browse/SHRINKWRAP-249
[17:21:52] <ALR> @see Davide's comments.
[17:21:58] <jbossbot> jira [SHRINKWRAP-249] Support add directory content [Open (Unresolved) Feature Request, Major, Davide D'Alto] https://issues.jboss.org/browse/SHRINKWRAP-249
[17:26:07] <aslak> ALR, hmm..  string becomes TCCL lookup .getFile..  won't that behavior change depending on how the other arhcive is packaged
[17:27:07] <aslak> if your in your own project, adding "META-INF/" would resolve to a File on your disk, but if you try the same on a packaged jar, it will be a ref to inside the jar somewhere and not behave as a Directory ? or does it ?
[17:28:16] *** lfryc has joined #jbosstesting
[17:31:23] <ALR> aslak: TCCL stuff is all going out the window
[17:31:33] <ALR> aslak: I have patches here for OSGi-ing SW
[17:31:40] <ALR> So I've killed TCCL entirely
[17:31:57] <ALR> And given each Configuration an immutable ClassLoader
[17:32:06] <ALR> Archives are associated w/ a Configuration as it is
[17:32:09] <ALR> So that's used.
[17:32:30] <aslak> TCCL or some other CL doesn't matter.. i meant CL
[17:32:33] <ALR> Ah
[17:32:55] <ALR> Yeah, String does CL lookup.  What do you mean by "other archive"?
[17:33:43] <aslak> we operate on the ClassPath right, adding META-INF would actually add ALL META-INF found in CP
[17:33:52] <aslak> but, ignore that
[17:35:07] *** maeste has quit IRC
[17:35:28] <aslak> say you have a META-INF/test you want to add recursivly.. when META-INF/test is in one of your source folders, CL will reutrn that as a File pointing to Disk. if on the other hand META-INF/test is in another jar you include in your app, META-INF/test loaded from the CL and fetched as File would represent a File inside the jar, jar://. does that then still follow the normal File rules and return isDirectory and listFiles ?
[17:35:48] <ALR> Ummmmmmmmmmmmmmmmmmmmmmmmmmmmmm
[17:36:21] <ALR> I'm not sure the behaviour when operating on CL resources like that
[17:36:35] <aslak> me either
[17:36:39] <ALR> I'd need to dig to see if we call getResource or getResources()
[17:36:43] <ALR> And if we're iterating over all.
[17:36:52] <ALR> And what to do in case of conflicts....
[17:36:55] <aslak> basically URLPackageScanner
[17:37:19] <ALR> IMO if there's more than one CL match for the requested thing to add, we should throw an IllegalArgumentException
[17:37:35] <ALR> addAsDirectory should add one thing.
[17:37:47] <ALR> And if there are many CL matches, IMO, throw up
[17:37:58] <ALR> I think that's the most deterministic behaviour.
[17:38:24] <aslak> so we're extending this to addAsDirectory as well? i thought addAsDirectory was only to add empty directories in the archive, not to import Assets
[17:38:28] *** jdlee has quit IRC
[17:39:33] <ALR> Not to addAsDirectory
[17:39:36] <ALR> That adds an empty dir
[17:39:41] <ALR> Not adding content
[17:40:07] <aslak> right
[17:40:24] <ALR> But I noted to Davide in the issue that he doesn't need to do this for addDirectory
[17:40:35] <ALR> I just wanted to see if we should open a new issue for renaming.
[17:40:38] <ALR> Which we should.
[17:40:39] <ALR> :)
[17:40:56] <aslak> :)
[17:41:36] <ALR> https://issues.jboss.org/browse/SHRINKWRAP-263
[17:41:37] <jbossbot> jira [SHRINKWRAP-263] API rename addDirectory to addAsDirectory [Open (Unresolved) Task, Critical, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-263
[17:53:19] *** rruss has joined #jbosstesting
[17:55:42] *** alesj has joined #jbosstesting
[17:56:36] <aslak> ALR, ARQ-402
[17:56:37] <jbossbot> jira [ARQ-402] Arquillian no long works on Java 1.5 [Open (Unresolved) Bug, Major, Unassigned] https://issues.jboss.org/browse/ARQ-402
[17:56:45] <ALR> aslak: Saw that
[17:56:55] <ALR> Is there even an JRE 1.5 requirement?
[17:57:12] <ALR> Oooh, Descriptors.
[17:57:15] <aslak> yea
[17:57:17] <ALR> That could be a problem
[17:57:25] <ALR> I think Descriptors requires 1.6 runtime.
[17:57:35] <aslak> why?
[17:57:36] <ALR> I didn't realize ARQ was 1.5 as well.
[17:57:43] <ALR> I'm not sure about the XML parsing stuff
[17:57:51] <ALR> If it's in the 1.5 libraries
[17:57:59] <ALR> Though I think it's mostly straight DOM
[17:58:05] <ALR> No JAXB or anything
[17:58:10] <ALR> I just haven't checked
[17:58:43] <aslak> yea, it's just w3c dom
[17:59:13] <aslak> when did DOM level 3 come?
[17:59:24] <aslak> 2004
[17:59:42] <ALR> OK, I can set up Descriptors to be 1.5
[17:59:48] <ALR> But you also gotta open an ARQ issue:
[17:59:56] <ALR> "Test in JRE5 runtime" :)
[18:00:04] <aslak> yea
[18:00:06] <ALR> You can look to SW for examples how
[18:00:19] <ALR> Surefire runs in JRE5 for impl-base
[18:00:21] <aslak> yea i know how SW doe sit.. bugs me every time.. hehe
[18:00:35] <ALR> Hehe.
[18:00:39] <ALR> Why every time?
[18:00:54] <ALR> (I set JAVA5_HOME in my basrc or bash_profile)
[18:01:06] <aslak> yea i never did
[18:01:11] <aslak> nor do i hvae a 1.5 runtime
[18:01:19] <ALR> Seriously?
[18:01:25] <ALR> You don't have one?
[18:01:40] <aslak> not in the ubuntu repos from 10.10 or so
[18:01:54] <aslak> probably in some custom repo somewhere, but i havn't bothered
[18:02:32] *** lfryc has quit IRC
[18:02:33] <aslak> or i could install a runtime from sun download of course..  but
[18:03:30] <ALR> aslak: Oh yeah, all my JDKs (except OpenJDK) I have binary installs from Sun and put 'em in /opt
[18:06:56] *** jdlee has joined #jbosstesting
[18:06:56] *** jdlee has joined #jbosstesting
[18:13:38] <aslak> bobmcw, as a Arquillian supporter, want to pimp up the TorqueBox site with a "Tested with Arquillian" badge like IronJcamar ? http://www.jboss.org/ironjacamar/ (under the JSR logos)  :)
[18:14:36] <bobmcw> aslak: sure thing
[18:15:17] <aslak> ALR, Jesper is taking our Arquillian build status idea to IronJacamar as well now. got a new set of colored icons made, ready for next release.. :)
[18:15:39] <aslak> colored birds
[18:15:42] <ALR> aslak: Yay jpederse
[18:16:20] <ALR> bobmcw: As I mentioned: pick out anything here: http://www.cafepress.com/jbossorg/7125835
[18:16:53] <ALR> (Mugs we'll send in pairs) :)
[18:17:25] <bobmcw> ALR: large mug!
[18:17:31] <bobmcw> for my large hands
[18:17:32] <ALR> bobmcw: Cool, mail me your addy.
[18:17:45] <ALR> aslak: ^ For domain name.
[18:18:02] <aslak> ohh yes! brilliant
[18:18:03] <bobmcw> mauled
[18:48:32] *** Jaikiran|AFk has quit IRC
[19:13:47] *** rruss has quit IRC
[19:14:59] *** rruss has joined #jbosstesting
[19:16:06] *** rruss has quit IRC
[20:03:41] *** michaelschuetz has joined #jbosstesting
[20:13:31] *** alesj has quit IRC
[20:24:20] *** mgoldmann has quit IRC
[21:29:51] *** jharting has joined #jbosstesting
[21:36:37] *** alesj has joined #jbosstesting
[21:37:01] *** alesj has left #jbosstesting
[21:45:10] *** ldimaggi has quit IRC
[21:46:53] *** ge0ffrey has quit IRC
[22:00:33] *** Tashtego has joined #jbosstesting
[22:05:02] *** Tashtego has quit IRC
[22:06:53] *** alesj has joined #jbosstesting
[22:13:35] *** oskutka has joined #jbosstesting
[22:23:26] *** jdlee has quit IRC
[22:23:32] *** ALR has quit IRC
[22:29:56] *** jdlee has joined #jbosstesting
[22:29:56] *** jdlee has joined #jbosstesting
[22:33:00] *** jharting has left #jbosstesting
[22:33:24] *** jharting has joined #jbosstesting
[22:39:55] *** lincolnthree1 has joined #jbosstesting
[22:40:15] <lincolnthree1> hey aslak, do you by any chance know the reason why org.jboss.shrinkwrap.descriptor.example.AnotherInterceptorExample exists?
[22:40:41] <lincolnthree1> well. i see it's for the example
[22:40:46] <lincolnthree1> but it's breaking deployment:
[22:40:58] <lincolnthree1> when I see it shouldn't...
[22:40:59] <lincolnthree1> hmmm
[22:41:20] <lincolnthree1> WELD-000069 An interceptor must have at least one binding, but org.jboss.shrinkwrap.descriptor.example.AnotherInterceptorExample  has none
[22:42:06] <lincolnthree1> there's no beans.xml in SWD
[22:42:11] <lincolnthree1> this shouldn't even be loaded
[22:42:26] <aslak> lincolnthree1, oh, your deploying descriptors.. hmm
[22:43:29] <aslak> lincolnthree1,  the whole example package should be removed really
[22:43:32] <aslak> lincolnthree1, jira
[22:43:52] <lincolnthree1> no. i see the problem
[22:44:01] <lincolnthree1> i shaded it in to an archive that DOES have beans.xml
[22:45:32] *** oskutka has quit IRC
[22:49:19] <aslak> lincolnthree1, well, it still shouldn't be there.. :)
[22:49:40] <lincolnthree1> aslak: ok, ill issue it
[22:49:53] <aslak> lincolnthree1, thanks :)
[22:54:05] <lincolnthree1> SHRINKDESC-46
[22:54:16] <jbossbot> jira [SHRINKDESC-46] Remove examples from Shrinkwrap Descriptors codebase [Open (Unresolved) Task, Major, Unassigned] https://issues.jboss.org/browse/SHRINKDESC-46
[23:04:14] *** alesj has left #jbosstesting
[23:09:20] *** wolfc has quit IRC
[23:12:17] *** ldimaggi has joined #jbosstesting
[23:12:29] *** jharting has quit IRC
[23:13:17] *** vtunka has joined #jbosstesting
[23:44:22] *** vtunka has quit IRC

top