Re: [VOTE] Name change resolution
+1 Jon Sent from my iPad On 14 Dec 2012, at 03:40, David Blevins david.blev...@gmail.com wrote: Discussion concluded some time ago on changing the name of the project to Apache TomEE. The consensus is clear to move ahead with the name change and in the weeks since the discussion, no other views have been expressed, it's time for an official vote. To do this we need a resolution to: a) Rename the TLP from OpenEJB to TomEE and since our official changes[1] give room for going beyond EJB, it would be good to update them to explicitly mention the Java Enterprise Edition: b) enterprise application containers and services based on, but not limited to the Enterprise JavaBeans Specification and Java Enterprise Edition Specifications Consider the vote for these two items a and b above. The resolution for which will look something like, if not identical to: WHEREAS, the Project Management Committee of the Apache OpenEJB Project has chosen by vote to recommend a change of name to Apache TomEE and revision of its charges to include implementation of the Java Enterprise Edition, and WHEREAS, the Board of Directors is receipt of this and deems it to be in the best interests of the Foundation and consistent with the Foundation's propose; NOW, THEREFORE, BE IT RESOLVED, that the Project Management Committee (PMC), heretofore known as The Apache OpenEJB Project be hereby known as the The Apache TomEE Project, and BE IT FURHER RESOLVED, that the Apache TomEE Project be and hereby is responsible for enterprise application containers and services based on, but not limited to the Enterprise JavaBeans Specification and Java Enterprise Edition Specifications. Let's give this 72 hours to vote, then I'll put it to the board for inclusion in the board meeting on the 19th. They'll likely adjust the legal wording, but not the intent. And, of course, it's never too late for someone to say stop the show. There's a meeting every month. -David [1] http://svn.apache.org/repos/asf/openejb/trunk/graduation-resolution.txt
Re: [VOTE] OpenEJB 4.5.1/TomEE 1.5.1 (staging-132)
+1 Jon On Mon, Dec 10, 2012 at 1:48 PM, Jean-Louis MONTEIRO jeano...@gmail.comwrote: [generated email] SVN Tag: https://svn.apache.org/repos/asf/openejb/tags/openejb-4.5.1/ Maven Repo: https://repository.apache.org/content/repositories/orgapacheopenejb-132 Binaries Source: http://people.apache.org/~jlmonteiro/staging-132/openejb-4.5.1/ Legal: http://people.apache.org/~jlmonteiro/staging-132/legal/archives.html Vote will be open for 72 hours or as needed.
Re: DISCUSS - Wait or not OWB 1.1.7
I'm sure you're correct. Out of curiosity, when will OWB 1.1.7 be out and what are the benefits? Cheers Jon Sent from my iPad On 26 Nov 2012, at 22:16, Romain Manni-Bucau rmannibu...@gmail.com wrote: yes *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/26 Jean-Louis MONTEIRO jeano...@gmail.com Hi, do we really want to wait OWB 1.1.7? -- Jean-Louis
Re: DISCUSS - Wait or not OWB 1.1.7
They sound like good fixes that would be great to get in. My view is that if its coming soon (= a week) it's probably worth waiting for. Otherwise we could go for a release now, and roll another when OWB 1.1.7 is out. I don't see any harm in more regular releases and I'm happy to roll the releases or he out in other way if that helps. Its been nearly 2 months since the last release, so we're probably due the next one. I had a look at OWB's mailing list archive - I didn't spot any chatter about a release, but I may have missed it. Had their release process started? Jon Sent from my iPad On 26 Nov 2012, at 22:44, Romain Manni-Bucau rmannibu...@gmail.com wrote: you know your answer is wrong by itself and btw not only users are waiting ;) just my thoughts :p we can have a look if we cannot release owb 1.1.7 as it is today since fixes are here and wait 1.1.8 for cleanups that's how i'd go *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/*http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/26 Jean-Louis MONTEIRO jeano...@gmail.com +1, what is so important we cannot afford? No idea of when, but our users are waiting for a long time. If we always wait for something, we will never get more frequent releases out. Just my thoughts. I even prefer more frequent releases when necessary that always waiting to have a perfect release (which never occurs actually). JLouis 2012/11/26 Jonathan Gallimore jonathan.gallim...@gmail.com I'm sure you're correct. Out of curiosity, when will OWB 1.1.7 be out and what are the benefits? Cheers Jon Sent from my iPad On 26 Nov 2012, at 22:16, Romain Manni-Bucau rmannibu...@gmail.com wrote: yes *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/26 Jean-Louis MONTEIRO jeano...@gmail.com Hi, do we really want to wait OWB 1.1.7? -- Jean-Louis -- Jean-Louis
Re: [DISCUSS] - Project name
I agree. I don't think we should rename TomEE - its well known and renaming has the potential to cause confusion. I do think, however, that changing TomEE to be the top level project, with OpenEJB as the subproject makes sense. Jon On Nov 13, 2012 10:42 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote: The discussion thread is pretty accurate actually. Regarding the name, TomEE seems to be definietly the name we wanna keep. But, that bring the question: should OPENEJB be renamed to TomEE as the TLP at Apache? That's the question I guess, and I'm for it. JLouis 2012/11/13 Mohammad Nour El-Din nour.moham...@gmail.com Hi... On Tue, Nov 13, 2012 at 11:34 AM, Alex The Rocker alex.m3...@gmail.com wrote: I agree with Romain : I work in a major software company, about to release products with dependency on Tomcat replaced by TomEE. It would be annoying to change the prerequisite name at the last minute. If the name changes, then please consider a deprecation period during which both TomEE and *whatevernewname* will cohexist. Perfect :) No worries, there is no prior intention to rename, thats why I marked the e-mail thread [DISCUSS] so it is now only for discussing the validity of renaming in general and the name *in case* there is enough consensus to rename Thanks, Alex. On Tue, Nov 13, 2012 at 11:30 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi Mohammad, i think TomEE just starts to be a bit known so i don't think we can (should) change this name even if you are right. *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/13 Mohammad Nour El-Din nour.moham...@gmail.com Hi OEJBers 1st of all it was so great to see most of you in ACEU. As a side discussion initiated by David about renaming the project, he can give more details about that here :), I thought it might be the right time to re-discuss the project name, I know we depend on Tomcat right now but I thought it might be better to think about a name that does not tight couple of with Tomcat who knows whats going to change in the future To be honest I don't have a name in mind atm but out of my mind I would start the discussion by suggesting: BeanEE - Which indicates the direction into which the JEE technology is going which is to make things as simple as just writing simple Java Beans Thoughts ? -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [DISCUSS] TomEE as the TLP name
+1. I definitely agree with that. TomEE seems to be the main project project now and identifying it as the top level project makes sense to me. Jon On Nov 13, 2012 3:05 PM, David Blevins david.blev...@gmail.com wrote: Since it came up in the other thread, good time to officially raise the discussion on how we want to identify ourselves as a TLP. There have been concerns raised on how we identify to the public in terms of our primary identity -- the website says TomEE in letters as big as my hand was one quote. This was many months ago and my feedback then was we're still experimenting and we need time to figure ourselves out. It's been a year since TomEE has been released and officially certified. The popularity is skyrocketing with no signs of slowing. As TomEE eclipses OpenEJB it becomes more and more strange to call the TLP OpenEJB given our website says TomEE all over it and that's all we present at conferences. What do people think about renaming this TLP from OpenEJB to TomEE? -David
Re: [DISCUSS] TomEE as the TLP name
I don't think any modules need changing as they stand at the moment as the core code is clearly labelled as openejb, and TomEE specific code sits within a TomEE module. I guess the top level svn URL may change, but that should only need an 'svn switch' if that's the case. I think renaming the TLP makes sense as TomEE is getting a lot of attention from the public now, and having it under OpenEJB has the potential to be a little confusing unless you're aware of the history of the project. It sounds like renaming the top level project will have a minimal impact - so if it add clarity and removes confusion I think it is worthwhile. Jon On Nov 13, 2012 6:12 PM, Mohammad Nour El-Din mn...@apache.org wrote: +1 on the idea but Romain pointed to a main point which is the technical implications when it comes to stg like module names and package names, etc I would say core code should still be openejb and code solely related to tomee should be renamed another point that is raised on the other thread of project renaming which raised by some one who is using and heavily depending on tomee wouldn't that affect them ? Sent from my Samsung Galaxy S3 Apologies for any typos On Nov 13, 2012 4:11 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: +0 since OpenEJB stays OpenEJB as it is today (i wouldn't rename all openejb module for that!) *Romain Manni-Bucau* *Twitter: @rmannibucau https://twitter.com/rmannibucau* *Blog: **http://rmannibucau.wordpress.com/* http://rmannibucau.wordpress.com/ *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2012/11/13 David Blevins david.blev...@gmail.com Since it came up in the other thread, good time to officially raise the discussion on how we want to identify ourselves as a TLP. There have been concerns raised on how we identify to the public in terms of our primary identity -- the website says TomEE in letters as big as my hand was one quote. This was many months ago and my feedback then was we're still experimenting and we need time to figure ourselves out. It's been a year since TomEE has been released and officially certified. The popularity is skyrocketing with no signs of slowing. As TomEE eclipses OpenEJB it becomes more and more strange to call the TLP OpenEJB given our website says TomEE all over it and that's all we present at conferences. What do people think about renaming this TLP from OpenEJB to TomEE? -David
Re: tomee tuning
Hi Mark, That's nice! Thanks for the tip! Jon On Tue, Nov 13, 2012 at 10:40 PM, Mark Struberg strub...@yahoo.de wrote: Hi folks! A quick note about getting tomee a bit faster in big real world scenarios. Tomcat 7.0.23 introduced a parallel start feature. Please change to the following in your conf/server.xml: Host name=localhost appBase=webapps unpackWARs=true autoDeploy=true startStopThreads=4 The startStopThreads will cause parallel boot and shutdown. Massively cutting down boot time if you have multiple webapps. LieGrue, strub
Re: Blog: Intellij support
Nice! Good idea putting links to the other announcements in, I hadn't spotted the JRebel TomEE support, so I'll be giving that a go as well grabbing the latest Intellij EAP. Jon On Tue, Oct 9, 2012 at 9:56 PM, David Blevins david.blev...@gmail.comwrote: Noticed the Intellij Blog post on TomEE support figured we should feature it. Entry queued up for tomorrow to give at least a little time for review: https://blogs.apache.org/preview/openejb/?previewEntry=intellij_idea_12_eap_available Note the bad formatting is the preview script -- needs to be fixed. Comments, edits, and stop the presses welcome :) -David
Re: [VOTE] OpenEJB 4.5.0/TomEE 1.5.0 (staging-060)
+1 On Fri, Sep 28, 2012 at 10:40 PM, dblev...@apache.org wrote: [generated email] SVN Tag: https://svn.apache.org/repos/asf/openejb/tags/openejb-4.5.0/ Maven Repo: https://repository.apache.org/content/repositories/orgapacheopenejb-060 Binaries Source: http://people.apache.org/~dblevins/staging-060/openejb-4.5.0/ Legal: http://people.apache.org/~dblevins/staging-060/legal/archives.html Vote will be open for 72 hours or as needed.
Re: OpenEJB 2012 Meetup - EU or USA
Hi guys, I'm hoping I will be able to join you, but unfortunately I won't be able to come to the conference as I won't be able to get the time off work. I'm hoping to come out for one of the weekends, most likely the one after the conference (Munich?). Has anyone picked a hotel for Munich? Jon Sent from my iPad On 10 Sep 2012, at 08:44, Jean-Louis MONTEIRO jeano...@gmail.com wrote: Common guys, Time to book hotels, trains, etc. Would better/easier to get the same hotel if possible. BTW, thanks Daniel for the tip. JLouis 2012/9/8 dsh daniel.hais...@gmail.com It's September! Btw, if you plan to travel by ICE (train), you ought to reserve seats or otherwise you won't have any in the worst case until arriving in Munich. Cheers Daniel On Tue, Aug 28, 2012 at 12:04 PM, Jean-Louis MONTEIRO jeano...@gmail.com wrote: Hi all, Time to re activate that topic. Which option would you prefer? In regards to Daniel's comment, we can minimize cost avoiding many trips between the conference and Munich. Please vote on options. My preference is C). Start at ApacheCon on Monday, then get together for coding and touring on Friday, and the following weekend. I will be in another country the week before so unable to be there the weekend before. For the organization, did someone already book the hotel? Or maybe had a look to a list of hotels? Any suggestions? I'd like to get it booked by September. Jean-Louis 2012/6/25 dsh daniel.hais...@googlemail.com Probably 4 hours from Sinsheim to Munich city and you should take in account that you would spend about 70 - 80 euros for a single ride. Maybe there's a cheaper group ticket for all of us... try using this site to plan the trip or get any more information: - http://www.bahn.de/i/view/USA/en/index.shtml ICE = high speed train (whatever highspeed meens) IC = intercity (ICE minus express) EC - euro city - http://www.bahn.com/i/view/GBR/en/trains/overview/ic_and_ec.shtml Cheers Daniel On Sun, Jun 24, 2012 at 10:29 PM, David Blevins david.blev...@gmail.com wrote: On May 29, 2012, at 11:59 AM, David Blevins wrote: On May 29, 2012, at 1:48 AM, Jean-Louis MONTEIRO wrote: Ok guys, seems like Apache Con EU is the winner, isn't it? ApacheCon will be from 5th to 9th of November. The main question is how short nights will be to let us have some coding sessions ;-) That seems to be the case and that's definitely the question :) From experience, it's very hard to get everyone in one place at one time at conferences. We'll probably want to pick a day or two that are ours Nudging this forward a little. There's talk of doing a 'ApachEE' track at ApacheCon. Not sure what day that will be. Maybe Mark can comment. Mark will be speaking at W-JAX in Munich a few hours away later in the same week. They've asked me to speak as well and I think it would be great for the project. That would mean I'd have to split ApacheCon by Wednesday sometime as Thursday is the last day of W-JAX We have options. A We could have our time a few days before ApacheCon, like the preceeding weekend. B We could just do the week of ApacheCon -- I'll just only be able to hang out for three of the days. C We could move the fun over to Munich and continue our get-together there and use the subsequent weekend for hacking and touring. D Other? If we did option C, maybe we could do one day of hacking on say Sunday before the conference, the hacking again on Friday in Munich. Then touring in Munich Saturday. Seems like it's a three hour train ride from the ApacheCon location to Munic. Thoughts? -David
Re: [VOTE] javaee-api 6.0-4 (take 1 - repo 155)
+1 Sent from my iPad On 30 May 2012, at 23:52, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi, to prepare next release i think we need to release javaee-api. Changes since last vote: TOMEE-201 JAXB ContextFinder is not available in correct version TOMEE-202 UriBuilder badly implements fromPath SVN Tag: http://svn.apache.org/repos/asf/openejb/tags/javaee-api-6.0-4/ Maven Repo: https://repository.apache.org/content/repositories/orgapacheopenejb-155/ Legal: http://people.apache.org/~rmannibucau/orgapacheopenejb-155/archives.html Vote will be open for 72 hours or as needed. Hope i didnt forget something ;) Here is my +1 BTW - Romain
Re: [jira] [Updated] (TOMEE-197) When running TomEE embedded in Eclipse jsp files do not hot deploy
That's all committed. Many thanks for the patch Andy! Cheers Jon On Fri, May 25, 2012 at 10:55 PM, David Blevins david.blev...@gmail.comwrote: On May 25, 2012, at 2:27 PM, Jonathan Gallimore wrote: Hi, I recommended TomEE to my friend Andy who has been taking a look at using it where he works. He spotted that jsp hot deployment didn't work when using TomEE in Eclipse via the standard WTP adaptor. I suggested that he update the TomEE and Eclipse page. I'll get this committed unless there's any objection. That's fantastic! I was rather surprised to see a JIRA for a doc update at all let alone with a patch. This note explains it :) Commit away. That tomee-and-eclipse.mdtext doc is actually outdated again. As of the hacking right before the release, no special steps are required to setup TomEE in Eclipse. You just say add a Apache Tomcat 7.0 server, point to the Apache TomEE install, then done. Specifically, that image stating special options must be selected is no longer applicable. If you get the urge to clean that doc up, great. Maybe link to the Getting Started with Apache TomEE video. -David On 25 May 2012, at 22:02, Andy White (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/TOMEE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Andy White updated TOMEE-197: - Attachment: tomee-and-eclipse.mdtext.diff Diff file for suggested update to the tomee-and-eclipse.html page to explain what to change if the jsp hot deploy isn't working. When running TomEE embedded in Eclipse jsp files do not hot deploy -- Key: TOMEE-197 URL: https://issues.apache.org/jira/browse/TOMEE-197 Project: TomEE Issue Type: Bug Affects Versions: 1.0.0 Environment: Eclipse Indigo running on Windows7 but is an issue with the web.xml Reporter: Andy White Priority: Minor Attachments: tomee-and-eclipse.mdtext.diff Running TomEE as an embedded server in Eclipse will not hot deploy jsp files. This is because jspservlet is set to development = false. A documentation update to the tomee-and-eclipse.html should clarify this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Updated] (TOMEE-197) When running TomEE embedded in Eclipse jsp files do not hot deploy
Its an update to the website, just in case any one else runs into it ;-) The idea of an openejb/tomee.dev property sounds like a good idea though :) Jon On Fri, May 25, 2012 at 11:27 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: If it breaks tcks i think we should introduce openejb.dev property Le 26 mai 2012 00:25, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : That's all committed. Many thanks for the patch Andy! Cheers Jon On Fri, May 25, 2012 at 10:55 PM, David Blevins david.blev...@gmail.com wrote: On May 25, 2012, at 2:27 PM, Jonathan Gallimore wrote: Hi, I recommended TomEE to my friend Andy who has been taking a look at using it where he works. He spotted that jsp hot deployment didn't work when using TomEE in Eclipse via the standard WTP adaptor. I suggested that he update the TomEE and Eclipse page. I'll get this committed unless there's any objection. That's fantastic! I was rather surprised to see a JIRA for a doc update at all let alone with a patch. This note explains it :) Commit away. That tomee-and-eclipse.mdtext doc is actually outdated again. As of the hacking right before the release, no special steps are required to setup TomEE in Eclipse. You just say add a Apache Tomcat 7.0 server, point to the Apache TomEE install, then done. Specifically, that image stating special options must be selected is no longer applicable. If you get the urge to clean that doc up, great. Maybe link to the Getting Started with Apache TomEE video. -David On 25 May 2012, at 22:02, Andy White (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/TOMEE-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy White updated TOMEE-197: - Attachment: tomee-and-eclipse.mdtext.diff Diff file for suggested update to the tomee-and-eclipse.html page to explain what to change if the jsp hot deploy isn't working. When running TomEE embedded in Eclipse jsp files do not hot deploy -- Key: TOMEE-197 URL: https://issues.apache.org/jira/browse/TOMEE-197 Project: TomEE Issue Type: Bug Affects Versions: 1.0.0 Environment: Eclipse Indigo running on Windows7 but is an issue with the web.xml Reporter: Andy White Priority: Minor Attachments: tomee-and-eclipse.mdtext.diff Running TomEE as an embedded server in Eclipse will not hot deploy jsp files. This is because jspservlet is set to development = false. A documentation update to the tomee-and-eclipse.html should clarify this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Getting Started video
There isn't a TomEE Eclipse plugin, but there is an OpenEJB one, which includes a WTP server for OpenEJB, and a wizard to migrate from EJB2.1 to EJB3, generating the relevant annotations. I'm no expert but I do have some experience of doing Eclipse plugins, and did a fair amount of work on the OpenEJB one. I'd love to get back into some of that stuff. The big question is, how should a TomEE plugin work, and how would it be different from a Tomcat one? I've always found the Tomcat one works really well for TomEE - I've presented this a couple of times at JAX London, and one of the things people liked was that the existing Tomcat tools worked with TomEE. I'm quite happy to try and see if we can come up with a TomEE adaptor based on the Tomcat plugin and make it a bit easier to get TomEE going (there were a couple of options you have to fiddle with on the Tomcat WTP plugin) - are there any other ideas that people have? Jon On Mon, Apr 30, 2012 at 5:25 PM, Neale Rudd ne...@metawerx.net wrote: Is there an Eclipse plugin for TomEE yet? Does anyone have experience with building Eclipse plugins? I personally don't use Eclipse either but a lot of our customers do. Now that TomEE is officially released, it would be great to have that as an option in the main eclipse build, especially since other distros like Glassfish have one. It's probably exactly the same as the Tomcat one - but adding it as an explicit option would boost recognition. Best Regards, Neale - Original Message - From: dsh daniel.hais...@googlemail.com** To: dev@openejb.apache.org Sent: Tuesday, May 01, 2012 1:42 AM Subject: Re: Getting Started video On Mon, Apr 30, 2012 at 2:51 PM, David Blevins david.blev...@gmail.com wrote: Seems like a lot of these suggestions involve having TomEE support already in the Eclipse binary that people download from eclipse.org. That sounds great. Do you know how to do that? In the first place a downloadable plug-in containing the WTP adapter for TomEE would be enough. A second step would be pushing the whole thing upstreams to the Eclipse project like it is the case for Tomcat or WAS CE. I could have a look at that. If I misunderstand it's because I don't really like Eclipse and I don't know what I'm doing :) I'd say in that particular case you are more like a generalist who just knows enought to operate any IDE :) Console messages we can control. Stop button out of our control unless we write a TomEE adapter. I noticed that Tomcat, for whatever reason prints out info and warning messages to stderr instead of stdout too. Now idea why. Thus the red instead of normal, black messages. Btw, which screencasting program did you use to do the webcast recording? Cheers Daniel
Re: [VOTE] OpenEJB 4.0.0/TomEE 1.0.0 (staging-001)
+1 On Fri, Apr 27, 2012 at 8:28 AM, dblev...@apache.org wrote: [generated email] Changes since last vote: - r1330642 | dblevins | Wed Apr 25 20:51:21 PDT 2012 | 22 http://svn.apache.org/viewvc?view=revisionrevision=1330642 TOMEE-127: Remote Arquillian Adapter for TomEE (related fixes for windows) TOMEE-164: Optimization on reading built-in tld files TOMEE-166: Web.xml metadata-complete effectively ignored TOMEE-168: Load OpenEJB System applications directly, without scanning TOMEE-169: Optimization scanning for tld files OPENEJB-1828: Disable hsql ServerService by default OPENEJB-1829: Plain Java to parse openejb.xml and tomee.xml files OPENEJB-1830: Omitting ejb-name from xml may result in failed deployment - r1331183 | dblevins | Thu Apr 26 19:17:22 PDT 2012 | 6 http://svn.apache.org/viewvc?view=revisionrevision=1331183 TOMEE-170: Windows AntiJarLocking broken in embedded scenarios (tmp file was being used as a tmp dir) Generally fixed the windows build. Several small issues. Successful Build: http://ci.apache.org/builders/openejb-4-empty-repo/builds/39 SVN Tag: https://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0/ Maven Repo: https://repository.apache.org/content/repositories/orgapacheopenejb-001 Binaries Source: http://people.apache.org/~dblevins/staging-001/openejb-4.0.0/ Legal: http://people.apache.org/~dblevins/staging-001/legal/archives.html Vote will be open for 72 hours or as needed.
Re: [VOTE] OpenEJB 4.0.0/TomEE 1.0.0 (staging-068)
I think for the most part, I am happy with the jar file changes since beta 2. Currently, my vote is -1, really down to the license / notice files already mentioned. I'll do some work on these tomorrow. Jon On Friday, April 20, 2012, David Blevins wrote: On Apr 19, 2012, at 4:39 PM, Jonathan Gallimore wrote: I'm running a full build from the tag with all the tests and a clean .m2 directory at the moment. I'm sure it'll be fine, but I always like to try a build when voting :). Meanwhile, I've been taking a look at the legal report. I'll do a bit more on this tomorrow, but I spotted a couple of things so far: The following modules do not have META-INF/LICENSE and META-INF/NOTICE files: openejb-karaf-commands-4.0.0.jar openejb-karaf-rebranding-4.0.0.jar openejb-provisionning-4.0.0.zip (no LICENSE, but NOTICE is present) openejb-ssh-4.0.0.zip xbean-finder-shaded-3.10.jar We should definitely add LICENSE and NOTICE files to jars. I can take care of that. The openejb-provisionning-4.0.0.zip simply has a typo in the LICENSE file. Easy fix as well. 41134 04-17-2012 20:45 openejb-provisionning-4.0.0/LICENCE 2490 04-17-2012 20:45 openejb-provisionning-4.0.0/NOTICE I hadn't noticed the openejb-ssh-4.0.0.zip. I don't have the time to create license and notice files for those. The license/notice files for the provisioning zip took 3 hours -- you can't generate these things or trust the contents of the jars in the zip. So that one will likely be deleted if left to me to fix. I really like the legal report, but I could probably use a reminder of exactly how to read it... specifically around declared and undeclared licenses/notices. Using the TomEE webprofile zip as an example ( http://people.apache.org/~dblevins/staging-068/legal/org.apache.openejb.apache-tomee.1.0.0.apache-tomee-1.0.0-webprofile.zip.licenses.html ), it looks like there are both declared and undeclared licenses. I would read an undeclared license as one that is present in one of the jars included in the zip, but has been missed in the main zips LICENSES file. Is that correct? If so, ideally we should have no undeclared licenses? That's the general idea, however the tool is very crude, so at best it's an indication of what things a human might want to investigate. Here's a list of the changes between beta-2 and the proposed final binaries. Assuming you trust your review of beta-2, you only need to focus on ensuring the changed libraries are accurately represented in the respective NOTICE and LICENSE files. apache-tomee 1.0.0 webprofile D commons-beanutils-1.8.3.jar D log4j-1.2.16.jar D openejb-javaagent-4.0.0-beta-2.jar D openjpa-2.1.1.jar D slf4j-log4j12-1.6.1.jar A commons-beanutils-core-1.8.3.jar A commons-lang3-3.1.jar A gson-2.1.jar A jaxb-api.jar A jaxb-impl.jar A openjpa-asm-shaded-2.2.0.jar A slf4j-jdk14-1.6.4.jar A tomee-myfaces-4.0.0.jar change: +2.12 MB total : 26.36 MB apache-tomee 1.0.0 plus D commons-beanutils-1.8.3.jar D log4j-1.2.16.jar D openejb-javaagent-4.0.0-beta-2.jar D openjpa-2.1.1.jar D slf4j-log4j12-1.6.1.jar A commons-beanutils-core-1.8.3.jar A commons-lang3-3.1.jar A gson-2.1.jar A jaxb-api.jar A jaxb-impl.jar A openjpa-asm-shaded-2.2.0.jar A slf4j-jdk14-1.6.4.jar A tomee-myfaces-4.0.0.jar change: +2.23 MB total : 44.01 MB openejb-standalone 4.0.0 D commons-beanutils-1.8.3.jar D log4j-1.2.16.jar D openjpa-2.1.1.jar D slf4j-log4j12-1.6.1.jar A commons-beanutils-core-1.8.3.jar A commons-lang3-3.1.jar A jaxb-impl-2.2.5.jar A openjpa-asm-shaded-2.2.0.jar A slf4j-jdk14-1.6.4.jar change: +1.41 MB total : 33.15 MB
Re: [VOTE] OpenEJB 4.0.0/TomEE 1.0.0 (staging-068)
I'm running a full build from the tag with all the tests and a clean .m2 directory at the moment. I'm sure it'll be fine, but I always like to try a build when voting :). Meanwhile, I've been taking a look at the legal report. I'll do a bit more on this tomorrow, but I spotted a couple of things so far: The following modules do not have META-INF/LICENSE and META-INF/NOTICE files: openejb-karaf-commands-4.0.0.jar openejb-karaf-rebranding-4.0.0.jar openejb-provisionning-4.0.0.zip (no LICENSE, but NOTICE is present) openejb-ssh-4.0.0.zip xbean-finder-shaded-3.10.jar I really like the legal report, but I could probably use a reminder of exactly how to read it... specifically around declared and undeclared licenses/notices. Using the TomEE webprofile zip as an example ( http://people.apache.org/~dblevins/staging-068/legal/org.apache.openejb.apache-tomee.1.0.0.apache-tomee-1.0.0-webprofile.zip.licenses.html), it looks like there are both declared and undeclared licenses. I would read an undeclared license as one that is present in one of the jars included in the zip, but has been missed in the main zips LICENSES file. Is that correct? If so, ideally we should have no undeclared licenses? Apologies if I'm missing something, or making a silly mistake, but I'd rather get this right. Jon On Wed, Apr 18, 2012 at 6:02 AM, David Blevins david.blev...@gmail.comwrote: Looks like the links were not quite right :) Need update the template. Here is what it should have listed: SVN Tag: https://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0/ Maven Repo: https://repository.apache.org/content/repositories/orgapacheopenejb-068 Binaries Source: http://people.apache.org/~dblevins/staging-068/openejb-4.0.0/ Legal: http://people.apache.org/~dblevins/staging-068/legal/archives.html -David
Re: Apache OpenEJB/TomEE Get-Together 2012
As well as location, does anyone have any thoughts on dates - I think Sept/Oct was mentioned earlier in the thread? The sooner we decide when I can get some holiday booked from work :) Location wise I'm happy to travel anywhere in Europe, I'm also happy to go out to LA as well, although I'd probably combine that with my main holiday. Cheers Jon On Wed, Apr 4, 2012 at 11:22 AM, stratwine tovishwan...@gmail.com wrote: Hi guys, I am in UK until this July. How would UK and this timeline (on or before July) suit you guys ? UK would be great but I would try my best to join in any country in Europe. -Vishwa -- View this message in context: http://openejb.979440.n4.nabble.com/Apache-OpenEJB-TomEE-Get-Together-2012-tp4313559p4531431.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Final release
+1 for a new release. Let me know if I can help with anything on the UI. Jon On Wed, Apr 4, 2012 at 11:34 AM, Thiago Veronezi thi...@veronezi.orgwrote: Yeap. I will try it tonight. Not exactly what I wanted, but I can live with that. :O) I will definitively need more time for the new interface, but we can have a quick path for the current one. []s, Thiago. On Wed, Apr 4, 2012 at 1:31 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: We can simply skin the old one and release a 1.1.0 quickly, no? - Romain Le 4 avr. 2012 04:58, David Blevins david.blev...@gmail.com a écrit : On Apr 3, 2012, at 6:34 PM, Thiago Veronezi wrote: Hmmm... the new web interface is still on its way. I didn't have much time since my last commit due to some last minute issues in my project. The new interface has no priority (we really just want to see the ejbs running :O) ). Also, I don't want this new web interface in a final release. It should pass by the beta version first. So I think we are OK for a new release. The old interface is pretty bad. Do you have any thoughts on some very stripped down version of the new interface might be good for a final? -David Here is my +1 []s, Thiago. On Tue, Apr 3, 2012 at 4:16 PM, Jean-Louis MONTEIRO jeano...@gmail.com wrote: Hehe, +1 as well for a release and of course for a TomEE 1.0.0 / OpenEJB 4.0.0 Jean-Louis Le 3 avril 2012 22:16, Neale Rudd ne...@metawerx.net a écrit : Very good point. In our tests here, especially since you added the missing WEB-INF/web.xml change, it's ready to go. So logo or not, +1 on a 1.0.0 Best Regards, Neale
Re: [VOTE] OpenEJB openejb-4.0.0-beta-2/TomEE tomee-1.0.0-beta-2 (staging-075)
+1 Jon On Thu, Jan 19, 2012 at 10:47 PM, Jean-Louis MONTEIRO jeano...@gmail.comwrote: Hi, All checked with Romain. Did not notice something wrong either in binaries or in sources. BTW, we saw a bug in JAX-RS integration. This is not a blocking reason IMO. If i'm wrong, lemme know. We can re roll a new beta by the end of January or work for a final version in February hopefully. So here is my +1. Thanks David for the release. 2012/1/17 dblev...@apache.org [generated email] SVN Tag: https://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0-beta-2/ Maven Repo: https://repository.apache.org/content/repositories/orgapacheopenejb-075 Binaries Source: http://people.apache.org/~dblevins/staging-075/openejb-4.0.0-beta-2/ Legal: http://people.apache.org/~dblevins/staging-075/legal/archives.html Vote will be open for 72 hours or as needed.
Re: [VOTE] OpenEJB 4.0.0-beta-2/TomEE 1.0.0-beta-2
Going to take a look on my Windows machine here - I'll shout if I can see what the problem is. Jon On Tue, Jan 10, 2012 at 6:45 PM, David Blevins david.blev...@gmail.comwrote: Darn. I might be able to dig in on Saturday or Sunday, but not likely sooner. If anyone out there who has the problem is able to dig a little it'd be very appreciated. -David On Jan 10, 2012, at 4:36 AM, AndyG wrote: Andy +0 Two test failures. Not dug in to the cause, so if anyone can see something in the traces that may have something to do with my setup then let me know. Using Win7 Pro 64bit --- Test set: org.apache.openejb.arquillian.TomEEContainerTest --- Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 22.845 sec FAILURE! testEjbIsNotNull(org.apache.openejb.arquillian.TomEEContainerTest) Time elapsed: 1.053 sec ERROR! java.lang.IllegalStateException: Error launching test org.apache.openejb.arquillian.TomEEContainerTest public void org.apache.openejb.arquillian.TomEEContainerTest.testEjbIsNotNull() throws java.lang.Exception at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:122) at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:130) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:82) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at
Re: [VOTE] OpenEJB 4.0.0-beta-2/TomEE 1.0.0-beta-2
I added a system property: openejb.server.debug=true to RemoteTomEEContainer, and I was then able to hook up a remote debugger to the server. Stopping in org.jboss.arquillian.container.test.spi.util.ServiceLoader, it appear that the JUnitTestRunning is being picked up from 2 jars - one in the TomEE temp directory, and the other straight from the WEB-INF/lib folder of the test.war file being tested. jar:file:/D:/tmp/arquillian-apache-tomee/apache-tomee-plus-1.0.0-beta-2/temp/arquillian-junit-4211441189472437588.jar!/META-INF/services/org.jboss.arquillian.container.test.spi.TestRunner jar:file:/C:/cygwin/tmp/2/test/WEB-INF/lib/arquillian-junit.jar!/META-INF/services/org.jboss.arquillian.container.test.spi.TestRunner Is there a potential classloader problem going on here? Currently the TomEE arquillian adapter uses the DeployerEjb. I'm just guessing here as to whether this is related to the problem, but would switching to the webapp folder based deployer be better? Jon On Tue, Jan 10, 2012 at 9:04 PM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Going to take a look on my Windows machine here - I'll shout if I can see what the problem is. Jon On Tue, Jan 10, 2012 at 6:45 PM, David Blevins david.blev...@gmail.comwrote: Darn. I might be able to dig in on Saturday or Sunday, but not likely sooner. If anyone out there who has the problem is able to dig a little it'd be very appreciated. -David On Jan 10, 2012, at 4:36 AM, AndyG wrote: Andy +0 Two test failures. Not dug in to the cause, so if anyone can see something in the traces that may have something to do with my setup then let me know. Using Win7 Pro 64bit --- Test set: org.apache.openejb.arquillian.TomEEContainerTest --- Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 22.845 sec FAILURE! testEjbIsNotNull(org.apache.openejb.arquillian.TomEEContainerTest) Time elapsed: 1.053 sec ERROR! java.lang.IllegalStateException: Error launching test org.apache.openejb.arquillian.TomEEContainerTest public void org.apache.openejb.arquillian.TomEEContainerTest.testEjbIsNotNull() throws java.lang.Exception at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:122) at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:130) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88
Re: [VOTE] OpenEJB 4.0.0-beta-2/TomEE 1.0.0-beta-2
Hi David, Did you by any chance run the legal tool you wrote around the time of the last release? I remember finding it really useful. I'm happy to give it a run and post up the results if you give me a couple of pointers. I'm just checking things over here, hope to post a vote soon. Cheers Jon On Sat, Jan 7, 2012 at 10:59 PM, David Blevins david.blev...@gmail.comwrote: Ok, binaries are ready for a vote! Have run the TCK on these and everything looks good -- will post link to the tck@ list. SVN Tag: http://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0-beta-2/ Maven Repo: https://repository.apache.org/content/repositories/orgapacheopenejb-029/ Binaries Source: http://people.apache.org/~dblevins/staging-029/4.0.0-beta-2/ Still cooking up release notes. Vote will be open for 72 hours or as needed. Here's my +1 -David
Re: [VOTE] Vishwanath Krishnamurthi as committer
+1 Jon --Original Message-- From: Jean-Louis MONTEIRO To: dev@openejb.apache.org ReplyTo: dev@openejb.apache.org Subject: [VOTE] Vishwanath Krishnamurthi as committer Sent: 30 Nov 2011 10:35 All is in the subject :) Vishwa has been very active to enhance our documentation and to create our brand new website. He also contributed some examples, etc. Vote will be open for at least 72 hours (usually more). As always anyone is welcome to vote. Here's my +1 Jean-Louis -- View this message in context: http://openejb.979440.n4.nabble.com/VOTE-Vishwanath-Krishnamurthi-as-committer-tp4122496p4122496.html Sent from the OpenEJB Dev mailing list archive at Nabble.com. Sent from my BlackBerry® smartphone on O2
Re: [DISCUSS] - OpenEJB to use Git (Fwd: [PROPOSAL] Wicket to use Git@ASF)
Thought I'd chip in my thoughts on this. Personally, I haven't encountered issues running Git on Windows lately, but I remember it being awful when I first looked at it a few years back. I agree with Romain's point though, it would be a shame for someone not to contribute to the project because they can't get the SCM system working for them. Generally speaking I'm quite a bit of a fan of Git (and I really like Github as well - I'm starting to use it to play around with new projects), and I'd be more than happy to use Git when working on OpenEJB. That said, there are a few things I think it would be good to discuss and clarify first. - Documentation I'm generally quite happy with checking out, pushing and pulling, and I know there's some really good documentation for Git out there, but I think I'd find it pretty useful to have some sort basic cheatsheet, perhaps on the source code page of the website ( http://openejb.apache.org/dev/source-code.html) showing how to clone, pull, push and contribute a patch. I think clear documentation here will definitely be key. I ran into some frustration recently with Arquillian - they show git://github.com/arquillian/arquillian.git as being the repository to clone on their page ( http://www.jboss.org/arquillian/build.html). It isn't, and it took a little while to figure out I had to checkout a number of different repositories listed under here: https://github.com/arquillian to get what I actually wanted. A number of their developers also have forks on Github, so I wasn't ever 100% convinced I was looking at the right thing. Should we decide to go ahead, I'm happy to contribute documentation and tutorials in this area. - Forking Talking of forks, I have a couple of questions in this area. I use two different machines - keeping them in sync if I have changes I haven't committed to SVN yet can be tricky. I imagine I could have a fork of OpenEJB on Github I can push and pull to as I please to get around this. I'm not quite sure how I'd push what I have on the fork back to the main repository - is this something that would work? Is that a workflow that we'd recommend? If developers (I'm not thinking of committers here) did have their own forks somewhere like Github, and they were doing very experimental work, I wonder if there's a danger that the work that happens in those forks doesn't make it back to the main codebase, and maybe binaries of these forks get distributed? Whilst I appreciate that this can already happen with the way things stand as they are, and there's not anything necessarily wrong with forking the code, I wonder whether this is something we could/should keep an eye out for, and if we see it, we can encourage people to join our team? - Features It would be good to get an idea of what features would be available with Git. For example, I don't know if this is a Git thing or a Github specific feature, but I often see 'pull requests' on Github projects. Would that be available on the Apache Git setup? Would it be integrated with JIRA somehow? If there's a link that details what will available with the Apache Git R/W setup it would be great if someone could post it. I think we still need to make sure that we have the ability to browse the source as we do with SVN now. The ability to see changes committed against JIRA issues as they are now is also necessary. I'm sure someone has already thought of all this stuff, and I'm sure the necessary hooks are already there in JIRA, just thought it would be good to make sure :) Cheers Jon On Sun, Nov 27, 2011 at 12:13 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On Sun, Nov 27, 2011 at 1:41 PM, dsh daniel.hais...@googlemail.com wrote: Mo and Romain, concerning Git - what exactly doesn't work under windows that does work under Unix-like operating systems? And btw, maybe we should first of all get down to the nitty-gritty which is whether we could imagine such a transition at all or are completely against it and afterwards talk about details such as what isn't supported on Windoze and what not. +1 Cheers Daniel On Sun, Nov 27, 2011 at 12:09 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: On Sun, Nov 27, 2011 at 1:03 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: yep don't worry i understood. but today we are already proxied on github so maybe we can wait a bit. Well i'll let others vote ;) Yeah I know, but I am talking about a read-write Git repo. Not only a proxy. - Romain 2011/11/27 Mohammad Nour El-Din nour.moham...@gmail.com On Sun, Nov 27, 2011 at 12:50 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: it can of course but compared to linux (or mac of course) it is really boring. mercurial is today better integrated, i think we should just wait a bit. Last year it was even worse. I understand your concern, but the discussion is
Re: Webapp deployer
Just a heads-up - I've expanded this and made sure it can deploy/undeploy .wars, .jars and .ears. I've also moved it to its own module, which we can add to TomEE as part of the TCK run. I'm going to try using it to run some TCK tests locally and see how it gets on. Jon
Re: Webapp deployer
Are you thinking you'd prefer the deployer to be part of the tck, or a module in its own right? I don't have a strong view either way, as long as the TCK setup is doing the right thing. Maybe our Arquillian adapters should be using this method as well? Jon On Nov 7, 2011 7:15 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: ok but the webappdeployer is not linked to the deployment at all, just to the way we deploy tcks so should we keep this ejb on trunk? - Romain 2011/11/7 David Blevins david.blev...@gmail.com On Nov 6, 2011, at 4:22 PM, Jonathan Gallimore wrote: My understanding - and this might be wrong - is that the existing DeployerEjb behaves differently to just dropping the .war file in the webapps directory. When we deploy using DeployerEjb, OpenEJB processes the .war file first, and then hands it off to Tomcat. Dropping the war in the webapps folder on the other hand, means Tomcat processes the .war file first and then OpenEJB gets its turn. I think the goal here is for the TCK to be as close to dropping the archives in the webapps folders as a user would do as possible. Right. Close as in identical :) Unless we're going to tell people don't drop apps in webapps/, we should test it. Next step is to get the VmDeploymentManager class updated so the impl can be configurable. Then update the runtests script so the implementation cab be set for a test run. Then of course to try a test or two to verify that all works. Then we can kick off an entire run with that approach and see where we land. -David
Webapp deployer
Hi I've just committed a Tomcat webapp folder style implementation of Deployer. I've only tried it with .war files so far, going to try with .ear and .jars tomorrow. For the .ear/.jar case is it sensible to invoke the usual DeployerEjb class in that case, or would it be better to take the same approach with .war files? Cheers Jon
Re: Webapp deployer
My understanding - and this might be wrong - is that the existing DeployerEjb behaves differently to just dropping the .war file in the webapps directory. When we deploy using DeployerEjb, OpenEJB processes the .war file first, and then hands it off to Tomcat. Dropping the war in the webapps folder on the other hand, means Tomcat processes the .war file first and then OpenEJB gets its turn. I think the goal here is for the TCK to be as close to dropping the archives in the webapps folders as a user would do as possible. All that this deployer is doing is exactly the same thing using Tomcat's own deployer does - upload the .war file, and invoke a check method on the Deployer mbean which returns once the app has deployed. Making this a bit more hot-deploy friendly shouldn't be difficult, a quick check to see if the app has already been deployed - if so, undeploy it first. Jon On Mon, Nov 7, 2011 at 12:10 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi, Hmm, for jar and ear DeployerEjb should work (for war too but with some tricky things abt classloadibg)...but shouldnt we manage hot deploy more than this? PS: i do not get why this deployer is useful, what is the goal? If i understand it hopes tomcat already deployed the webapp, no? - Romain Le 7 nov. 2011 00:47, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : Hi I've just committed a Tomcat webapp folder style implementation of Deployer. I've only tried it with .war files so far, going to try with .ear and .jars tomorrow. For the .ear/.jar case is it sensible to invoke the usual DeployerEjb class in that case, or would it be better to take the same approach with .war files? Cheers Jon
Re: Latest News.. from April
Yep. Beta 1 release (webprofile certified!) JAX London presentation from Tuesday + more upcoming presentations New features: JAX-RS support, Arquillian, I'm sure there's some more. I'm happy to add to these and any others. How do we edit this now - looks like its in SVN (or is that just for staging?). Jon On Thu, Nov 3, 2011 at 6:15 PM, David Blevins david.blev...@gmail.comwrote: Can anyone think of more recent news to post? -David
Re: New OpenEJB website -- do we like it?
+1. I think it looks great. On Nov 2, 2011 9:27 PM, dsh daniel.hais...@googlemail.com wrote: +1 I think we should simply give it a go and adapt over time where necessary. On Wed, Nov 2, 2011 at 8:06 AM, David Blevins david.blev...@gmail.com wrote: On Oct 26, 2011, at 11:38 PM, David Blevins wrote: Took a shot at using bootstrap in the CMS. http://openejb.staging.apache.org/index.html http://openejb.staging.apache.org/documentation.html Do we like it enough to give it try on the main site? Of course we can tweak as much as we want whenever we want. As well I think it will take a few days for infra to do their part. -David
Re: svn commit: r1195062 - in /openejb/trunk/openejb/arquillian-tomee: arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/src/main/java/org/apache/open
You beat me to it... I was about to commit something similar to cleanup
these files. :)
Thanks!
Jon
On Oct 29, 2011 11:38 PM, rmannibu...@apache.org wrote:
Author: rmannibucau
Date: Sat Oct 29 22:38:23 2011
New Revision: 1195062
URL: http://svn.apache.org/viewvc?rev=1195062view=rev
Log:
trying to cleanup a bit arquillian stuff to avoid bad deployment and issue
dur to not updated jar
Modified:
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/FileUtils.java
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEContainer.java
Modified:
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/FileUtils.java
URL:
http://svn.apache.org/viewvc/openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/FileUtils.java?rev=1195062r1=1195061r2=1195062view=diff
==
---
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/FileUtils.java
(original)
+++
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/FileUtils.java
Sat Oct 29 22:38:23 2011
@@ -35,6 +35,7 @@ public class FileUtils {
}
private FileUtils() {
+// no-op
}
// Shutdown hook for recurssive delete on tmp directories
@@ -59,7 +60,7 @@ public class FileUtils {
}
}
-private static void delete(File file) {
+public static void delete(File file) {
if (file.isDirectory()) {
for (File f : file.listFiles()) {
delete(f);
Modified:
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
URL:
http://svn.apache.org/viewvc/openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java?rev=1195062r1=1195061r2=1195062view=diff
==
---
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
(original)
+++
openejb/trunk/openejb/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
Sat Oct 29 22:38:23 2011
@@ -16,16 +16,6 @@
*/
package org.apache.openejb.arquillian.common;
-import java.io.File;
-import java.io.OutputStream;
-import java.net.Socket;
-import java.util.HashMap;
-import java.util.Map;
-import java.util.Properties;
-
-import javax.naming.Context;
-import javax.naming.InitialContext;
-
import org.apache.openejb.assembler.Deployer;
import
org.jboss.arquillian.container.spi.client.container.DeployableContainer;
import
org.jboss.arquillian.container.spi.client.container.DeploymentException;
@@ -39,11 +29,23 @@ import org.jboss.shrinkwrap.api.exporter
import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.jboss.shrinkwrap.descriptor.api.Descriptor;
+import javax.naming.Context;
+import javax.naming.InitialContext;
+import java.io.File;
+import java.io.OutputStream;
+import java.net.Socket;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.Properties;
+import java.util.logging.Logger;
+
public abstract class TomEEContainer implements
DeployableContainerTomEEConfiguration {
+protected static final Logger LOGGER =
Logger.getLogger(TomEEContainer.class.getName());
+
protected static final String LOCALHOST = localhost;
protected static final String SHUTDOWN_COMMAND = SHUTDOWN +
Character.toString((char) -1);
protected TomEEConfiguration configuration;
-protected MapString, String moduleIds = new HashMapString,
String();
+protected MapString, File moduleIds = new HashMapString, File();
public ClassTomEEConfiguration getConfigurationClass() {
return TomEEConfiguration.class;
@@ -62,6 +64,11 @@ public abstract class TomEEContainer imp
out.write(SHUTDOWN_COMMAND.getBytes());
waitForShutdown(10);
+
+File dir = new File(configuration.getDir());
+if (dir.exists()) {
+FileUtils.deleteOnExit(dir); // if we can avoid to delete
it between each test it is better
+}
} catch (Exception e) {
throw new LifecycleException(Unable to stop TomEE, e);
}
@@ -93,8 +100,15 @@ public abstract class TomEEContainer imp
public ProtocolMetaData deploy(Archive? archive) throws
DeploymentException {
Re: svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/main/
Neither the arquillian-showcase-ejb example, nor my own test in the moviefun example for testing ejbs work with the embedded adapter as it stands either - the ejb isn't getting injected. I'd be grateful if you could give it a try with the latest code. I'm afraid I don't understand your last point about @DeploymentScoped. Where does that need to go? Do I have to change the showcase code beyond referencing the adapters in the pom? I'm not sure I like that. There does seem to be an issue where the default ejbenricher with arquillian would work, except 1. it can't lookup Java:global. I've created an ear and confirmed I can't look it up from a servlet either, and 2. the global individual names it uses are slightly different to ours: Java:global/test.ear/test vs Java:global/test/test.jar. The first issue really doesn't seem right to me and I think we'll need to solve that. Jon On Oct 27, 2011 11:45 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i don't get why it doesn't work since everything is in the same webapp? Note: the ejbenricher needs the context to use to lookup, it can be set using @Inject @DeployementScoped private InstanceContext context; then context.set(new InitialContext()) (in the container) - Romain 2011/10/27 Romain Manni-Bucau rmannibu...@gmail.com Weird, it seems to work in embedded case. Le 27 oct. 2011 13:29, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : When I first saw your email, I did wonder whether the bean manager code would be enough, and maybe I was just missing the ArchiveAppender stuff to get the Enricher over to the server side. I've retested with the EJB lookup commented out, and unfortunately, It didn't work without my change for the test case I was using (arquillian-showcase-ejb). Jon On Thu, Oct 27, 2011 at 5:29 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi, Why beanmanager stuff is not enough? - Romain -- Message transféré -- De : jgallim...@apache.org Date : 27 oct. 2011 01:08 Objet : svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/ arquillian-to... À : comm...@openejb.apache.org Author: jgallimore Date: Wed Oct 26 23:08:05 2011 New Revision: 1189526 URL: http://svn.apache.org/viewvc?rev=1189526view=rev Log: Progress on supporting enriching tests with @EJB fields Added: openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEJBEnricherArchiveAppender.java openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEJBEnricherExtension.java openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/SecurityActions.java Removed: openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/resources/META-INF/services/org.jboss.arquillian.spi.TestEnricher Modified: openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEContainer.java openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEnricher.java openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEExtension.java openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/test/java/org/apache/openejb/arquillian/TomEEContainerTest.java openejb/trunk/arquillian-tomee/pom.xml Modified: openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java URL: http://svn.apache.org/viewvc/openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java?rev=1189526r1=1189525r2=1189526view=diff == --- openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java (original) +++ openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java Wed Oct 26 23:08:05 2011 @@ -36,6 +36,7 @@ import org.jboss.arquillian.container.sp import org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet
Re: svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/main/
Hi Romain, Thanks for the commit. Your test does work for me, but I still can't run the ejb tests in the Arquillian showcase, and your test doesn't work if I remove the @RunAsClient annotation (i.e. running the test in the container with the app). The tests in the showcase do (or at least should) work with other containers, so my view is that they should work with TomEE just by adding the profiles for our adapters to the pom.xml and the settings to arquillian.xml. Do you any objection if we use the EJB/CDI enricher code I put in the remote adapter the other day in both adapters? I'm presenting at JAX on Tuesday, and it would be great if this functionality works in both the Remote and Embedded adapters - I think the Arquillian demo will be a bit disappointing without it. Obviously I'm happy to carry on looking for a better long-term solution for getting the injections working with the tests running on the server. Jon On Fri, Oct 28, 2011 at 9:03 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Note: David spoke about adding the class test in the application deployed as a managed bean...it is probably the best solution from an injection point of view but the test class is not instantiated by us so the managed stuff is useless out of the box...i'm not sure how good is this solution since it can make us rewrite all (almost ;)) the arquillian stuff - Romain 2011/10/28 Romain Manni-Bucau rmannibu...@gmail.com i looked testenricher implementation from jboss and...the cdi one is almost the same than mine so i guess mine is useless i made the ejb injection for the embedded case working. i think it is just a bit more complicated for the remote case but almost the same philosophy. you can have a look, i added a test case to make it work. - Romain 2011/10/28 Jonathan Gallimore jonathan.gallim...@gmail.com Neither the arquillian-showcase-ejb example, nor my own test in the moviefun example for testing ejbs work with the embedded adapter as it stands either - the ejb isn't getting injected. I'd be grateful if you could give it a try with the latest code. I'm afraid I don't understand your last point about @DeploymentScoped. Where does that need to go? Do I have to change the showcase code beyond referencing the adapters in the pom? I'm not sure I like that. There does seem to be an issue where the default ejbenricher with arquillian would work, except 1. it can't lookup Java:global. I've created an ear and confirmed I can't look it up from a servlet either, and 2. the global individual names it uses are slightly different to ours: Java:global/test.ear/test vs Java:global/test/test.jar. The first issue really doesn't seem right to me and I think we'll need to solve that. Jon On Oct 27, 2011 11:45 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: i don't get why it doesn't work since everything is in the same webapp? Note: the ejbenricher needs the context to use to lookup, it can be set using @Inject @DeployementScoped private InstanceContext context; then context.set(new InitialContext()) (in the container) - Romain 2011/10/27 Romain Manni-Bucau rmannibu...@gmail.com Weird, it seems to work in embedded case. Le 27 oct. 2011 13:29, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : When I first saw your email, I did wonder whether the bean manager code would be enough, and maybe I was just missing the ArchiveAppender stuff to get the Enricher over to the server side. I've retested with the EJB lookup commented out, and unfortunately, It didn't work without my change for the test case I was using (arquillian-showcase-ejb). Jon On Thu, Oct 27, 2011 at 5:29 AM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Hi, Why beanmanager stuff is not enough? - Romain -- Message transféré -- De : jgallim...@apache.org Date : 27 oct. 2011 01:08 Objet : svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/ arquillian-to... À : comm...@openejb.apache.org Author: jgallimore Date: Wed Oct 26 23:08:05 2011 New Revision: 1189526 URL: http://svn.apache.org/viewvc?rev=1189526view=rev Log: Progress on supporting enriching tests with @EJB fields Added: openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEJBEnricherArchiveAppender.java openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote
Re: svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/main/
I haven't had a chance to check it out yet, but I definitely appreciate your efforts - many thanks! Not quite sure what do i let you the surprise of the solution i used? means, but I'll definitely check out your solution and make sure I understand it :-). Thanks Jon On Fri, Oct 28, 2011 at 2:09 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: your remote test case works do i let you the surprise of the solution i used? - Romain 2011/10/28 Romain Manni-Bucau rmannibu...@gmail.com i'm making it working in embedded mode now, just some minute to let me commited PS: i really would like to avoid to contribute our own enricher if it is not something directly linked to openejb - Romain 2011/10/28 Jonathan Gallimore jonathan.gallim...@gmail.com On Fri, Oct 28, 2011 at 1:27 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: @RunAsClient = @Deployment(testable = false) (personnally i prefer the first one but i don't really care ;)) if one of both is not true then the EJBInjectionEnricher is not called. One way to avoid it is to use Local protocol instead of servlet 3.0 in our container. I think we need to make sure this works for the @Deployment(testable=true) without @RunAsClient case as well. It doesn't for me at the moment - this seems to be how a lot of the tests are setup in the showcase. When I've been running this, my experience is the Arquillian EJB enricher is called, but can't inject the bean (it can't lookup java:global, and the global names we deploy are different to what it expects to see), hence the code I added to the remote adapter. I'm happy to show you this on a screen share if you like. I prefer to avoid to copy paste existing code. +1. How about moving the enricher code to the common module? i'll try to connect this evening or tmr to help you on this point. Thanks, I really appreciate it. I'm busy due to another commitment this evening, but I'll be working on this and rehearsing for JAX all weekend. Maybe we can start forking arquillian showcase on github (i think you had an account?) +1. I do have a github a/c (jgallimore) and I have a fork of this on there already. We ought to update the poms and arquillian .xml files and figure out if there's any gaps. Cheers Jon
Re: svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/main/
Hehe.. I'll go for the surprise :) - I'll give it a go as soon as I can. On Fri, Oct 28, 2011 at 2:17 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: i just tried a kind of joke (sorry ;)) and i was asking if you wanted suspense or not - Romain 2011/10/28 Jonathan Gallimore jonathan.gallim...@gmail.com I haven't had a chance to check it out yet, but I definitely appreciate your efforts - many thanks! Not quite sure what do i let you the surprise of the solution i used? means, but I'll definitely check out your solution and make sure I understand it :-). Thanks Jon On Fri, Oct 28, 2011 at 2:09 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: your remote test case works do i let you the surprise of the solution i used? - Romain 2011/10/28 Romain Manni-Bucau rmannibu...@gmail.com i'm making it working in embedded mode now, just some minute to let me commited PS: i really would like to avoid to contribute our own enricher if it is not something directly linked to openejb - Romain 2011/10/28 Jonathan Gallimore jonathan.gallim...@gmail.com On Fri, Oct 28, 2011 at 1:27 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: @RunAsClient = @Deployment(testable = false) (personnally i prefer the first one but i don't really care ;)) if one of both is not true then the EJBInjectionEnricher is not called. One way to avoid it is to use Local protocol instead of servlet 3.0 in our container. I think we need to make sure this works for the @Deployment(testable=true) without @RunAsClient case as well. It doesn't for me at the moment - this seems to be how a lot of the tests are setup in the showcase. When I've been running this, my experience is the Arquillian EJB enricher is called, but can't inject the bean (it can't lookup java:global, and the global names we deploy are different to what it expects to see), hence the code I added to the remote adapter. I'm happy to show you this on a screen share if you like. I prefer to avoid to copy paste existing code. +1. How about moving the enricher code to the common module? i'll try to connect this evening or tmr to help you on this point. Thanks, I really appreciate it. I'm busy due to another commitment this evening, but I'll be working on this and rehearsing for JAX all weekend. Maybe we can start forking arquillian showcase on github (i think you had an account?) +1. I do have a github a/c (jgallimore) and I have a fork of this on there already. We ought to update the poms and arquillian .xml files and figure out if there's any gaps. Cheers Jon
Re: Fwd: svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/
Hmm. I'll check that again... something wasn't working right for me.
On Oct 27, 2011 5:30 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:
Hi,
Why beanmanager stuff is not enough?
- Romain
-- Message transféré --
De : jgallim...@apache.org
Date : 27 oct. 2011 01:08
Objet : svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./
arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/
arquillian-tomee-remote/
arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/
arquillian-to...
À : comm...@openejb.apache.org
Author: jgallimore
Date: Wed Oct 26 23:08:05 2011
New Revision: 1189526
URL: http://svn.apache.org/viewvc?rev=1189526view=rev
Log:
Progress on supporting enriching tests with @EJB fields
Added:
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEJBEnricherArchiveAppender.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEJBEnricherExtension.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/SecurityActions.java
Removed:
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/resources/META-INF/services/org.jboss.arquillian.spi.TestEnricher
Modified:
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEContainer.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEnricher.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEExtension.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/test/java/org/apache/openejb/arquillian/TomEEContainerTest.java
openejb/trunk/arquillian-tomee/pom.xml
Modified:
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
URL:
http://svn.apache.org/viewvc/openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java?rev=1189526r1=1189525r2=1189526view=diff
==
---
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
(original)
+++
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
Wed Oct 26 23:08:05 2011
@@ -36,6 +36,7 @@ import org.jboss.arquillian.container.sp
import
org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet;
import org.jboss.shrinkwrap.api.Archive;
import org.jboss.shrinkwrap.api.exporter.ZipExporter;
+import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.jboss.shrinkwrap.descriptor.api.Descriptor;
public abstract class TomEEContainer implements
DeployableContainerTomEEConfiguration {
@@ -86,7 +87,7 @@ public abstract class TomEEContainer imp
}
public ProtocolDescription getDefaultProtocol() {
-return new ProtocolDescription(Servlet 3.0);
+return new ProtocolDescription(Servlet 2.5);
}
public ProtocolMetaData deploy(Archive? archive) throws
DeploymentException {
@@ -107,7 +108,12 @@ public abstract class TomEEContainer imp
moduleIds.put(archive.getName(), file.getAbsolutePath());
HTTPContext httpContext = new HTTPContext(0.0.0.0,
configuration.getHttpPort());
-httpContext.add(new Servlet(ArquillianServletRunner, / +
getArchiveNameWithoutExtension(archive)));
+if (archive instanceof WebArchive) {
+ httpContext.add(new Servlet(ArquillianServletRunner, /
+
getArchiveNameWithoutExtension(archive)));
+} else {
+ httpContext.add(new Servlet(ArquillianServletRunner,
/arquillian-protocol));
+}
+
// we should probably get all servlets and add them to the
context
return new ProtocolMetaData().addContext(httpContext);
} catch (Exception e) {
Modified: openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml
URL:
http://svn.apache.org/viewvc/openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml?rev=1189526r1=1189525r2=1189526view=diff
==
--- openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml
(original)
+++ openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml Wed Oct
26 23:08:05 2011
@@ -333,5 +333,12 @@
Re: svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./ arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/ arquillian-tomee-remote/ arquillian-tomee-remote/src/main/
When I first saw your email, I did wonder whether the bean manager code
would be enough, and maybe I was just missing the ArchiveAppender stuff to
get the Enricher over to the server side. I've retested with the EJB lookup
commented out, and unfortunately, It didn't work without my change for the
test case I was using (arquillian-showcase-ejb).
Jon
On Thu, Oct 27, 2011 at 5:29 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
Hi,
Why beanmanager stuff is not enough?
- Romain
-- Message transféré --
De : jgallim...@apache.org
Date : 27 oct. 2011 01:08
Objet : svn commit: r1189526 - in /openejb/trunk/arquillian-tomee: ./
arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/
arquillian-tomee-remote/
arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/
arquillian-to...
À : comm...@openejb.apache.org
Author: jgallimore
Date: Wed Oct 26 23:08:05 2011
New Revision: 1189526
URL: http://svn.apache.org/viewvc?rev=1189526view=rev
Log:
Progress on supporting enriching tests with @EJB fields
Added:
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEJBEnricherArchiveAppender.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEJBEnricherExtension.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/SecurityActions.java
Removed:
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/resources/META-INF/services/org.jboss.arquillian.spi.TestEnricher
Modified:
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEContainer.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEEnricher.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/main/java/org/apache/openejb/arquillian/remote/RemoteTomEEExtension.java
openejb/trunk/arquillian-tomee/arquillian-tomee-remote/src/test/java/org/apache/openejb/arquillian/TomEEContainerTest.java
openejb/trunk/arquillian-tomee/pom.xml
Modified:
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
URL:
http://svn.apache.org/viewvc/openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java?rev=1189526r1=1189525r2=1189526view=diff
==
---
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
(original)
+++
openejb/trunk/arquillian-tomee/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/TomEEContainer.java
Wed Oct 26 23:08:05 2011
@@ -36,6 +36,7 @@ import org.jboss.arquillian.container.sp
import
org.jboss.arquillian.container.spi.client.protocol.metadata.Servlet;
import org.jboss.shrinkwrap.api.Archive;
import org.jboss.shrinkwrap.api.exporter.ZipExporter;
+import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.jboss.shrinkwrap.descriptor.api.Descriptor;
public abstract class TomEEContainer implements
DeployableContainerTomEEConfiguration {
@@ -86,7 +87,7 @@ public abstract class TomEEContainer imp
}
public ProtocolDescription getDefaultProtocol() {
-return new ProtocolDescription(Servlet 3.0);
+return new ProtocolDescription(Servlet 2.5);
}
public ProtocolMetaData deploy(Archive? archive) throws
DeploymentException {
@@ -107,7 +108,12 @@ public abstract class TomEEContainer imp
moduleIds.put(archive.getName(), file.getAbsolutePath());
HTTPContext httpContext = new HTTPContext(0.0.0.0,
configuration.getHttpPort());
-httpContext.add(new Servlet(ArquillianServletRunner, / +
getArchiveNameWithoutExtension(archive)));
+if (archive instanceof WebArchive) {
+ httpContext.add(new Servlet(ArquillianServletRunner, /
+
getArchiveNameWithoutExtension(archive)));
+} else {
+ httpContext.add(new Servlet(ArquillianServletRunner,
/arquillian-protocol));
+}
+
// we should probably get all servlets and add them to the
context
return new ProtocolMetaData().addContext(httpContext);
} catch (Exception e) {
Modified: openejb/trunk/arquillian-tomee/arquillian-tomee-remote/pom.xml
URL:
Re: [VOTE] Apache OpenEJB 3.0.4 (3rd Try)
Are you using Maven 3? I think I had to use Maven 2 when I tried. Jon On Oct 27, 2011 7:09 PM, Kevan Miller kevan.mil...@gmail.com wrote: Building, I ran into a couple of test failures. IIRC, that wasn't too uncommon for building 3.0.x on Mac OS. Running without tests, I'm seeing: [ERROR] Failed to execute goal on project openejb-axis2: Could not resolve dependencies for project org.apache.openejb:openejb-axis2:jar:3.0.4: Failed to collect dependencies for [org.apache.openejb:openejb-webservices:jar:3.0.4 (compile), junit:junit:jar:4.4 (test), org.apache.axis2:axis2-jaxws:jar:1.3 (compile), org.apache.axis2:axis2-java2wsdl:jar:1.3 (compile), org.apache.axis2:axis2-kernel:jar:1.3 (compile), org.apache.axis2:axis2-adb:jar:1.3 (compile), org.apache.axis2:axis2-metadata:jar:1.3 (compile), org.apache.ws.commons.axiom:axiom-api:jar:1.2.5 (compile), org.apache.ws.commons.axiom:axiom-impl:jar:1.2.5 (compile), org.apache.ws.commons.schema:XmlSchema:jar:1.3.1 (compile), org.apache.neethi:neethi:jar:2.0 (compile), commons-httpclient:commons-httpclient:jar:3.0.1 (compile), commons-codec:commons-codec:jar:1.3 (compile), org.apache.xmlbeans:xmlbeans:jar:2.3.0 (compile), jaxen:jaxen:jar:1.1-beta-10 (compile), annogen:annogen:jar:0.1.0 (compile)]: Failed to read artifact descriptor for org.apache.woden:woden:jar:1.0-incubating-M7b: Could not transfer artifact org.apache.woden:woden:pom:1.0-incubating-M7b from/to java.net (http://download.java.net/maven/1/): No connector available to access repository java.net (http://download.java.net/maven/1/) of type legacy using the available factories WagonRepositoryConnectorFactory - [Help 1] Nobody else is seeing the same? --kevan
Re: Arquillian adapters
+1 On Oct 16, 2011 11:34 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: about our arquillian adapters, do we drop arquillian-tomee-embedded-with-war ? (+1 for me ;)) - Romain 2011/10/5 Jonathan Gallimore jonathan.gallim...@gmail.com Will do (will be tomorrow now, its getting late for me!), thanks for the link! Jon On Oct 5, 2011 12:02 AM, Mark Struberg strub...@yahoo.de wrote: You could take a look at what Dan and I did for native owb: https://github.com/struberg/arquillian-container-openwebbeans LieGrue, strub - Original Message - From: Jonathan Gallimore jonathan.gallim...@gmail.com To: dev@openejb.apache.org Cc: Sent: Wednesday, October 5, 2011 12:57 AM Subject: Re: Arquillian adapters On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: On Thu, Sep 29, 2011 at 12:01 AM, David Blevins david.blev...@gmail.comwrote: On Sep 28, 2011, at 3:36 PM, Jonathan Gallimore wrote: When I hacked up the Remote with zip adapter I intended to merge it into the remote adapter - along the lines of: check to see if TomEE is running on the port specified in arquillian.xml. If it is, just deploy straight to it. If not, go grab the zip and use that. Does that sound like a reasonable idea? Very reasonable. That's what the itests have done for years, the CDI TCK does and the Java EE TCK setup does. It's pretty easy to have the rule of if you don't want us to start a server, make sure a server is started Cool, I'll get that done. I've extended the remote adapter to allow this. If you specify something like (note the 1.0.0-beta-1 OpenEJB version and no Tomcat version): arquillian xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd; container qualifier=tomee default=true configuration property name=dir/tmp/arquillian-apache-tomee/property property name=httpPort9080/property property name=stopPort9005/property property name=tomcatVersion/property property name=openejbVersion1.0.0-beta-1/property /configuration /container /arquillian if nothing is running on port 9080 we'll download TomEE, unzip it, start it and use that for the test. If you changed the OpenEJB and Tomcat versions to, say: property name=tomcatVersion7.0.21/property property name=openejbVersion4.0.0-beta-1/property We'd download Tomcat and the OpenEJB.war, set that up, and use that instead. So we should be able to use this to test against Tomcat 5.5/6 with OpenEJB. I quite like this, but it would be great to get any feedback. That leaves the embedded-with-war adapter as something that might seem a bit odd. Currently I can't get it to run correctly, but that might be something wrong with my machine. What's people's opinion of this method? Should we drop this, or is it a useful adapter to hang on to? My impression is I would never ever advise a user to use it. That said, it's an absolutely fabulous way for us to test the drop-in-war functionality. Well, almost fabulous... the real world scenario is an existing Tomcat install, not an embedded one. Either way, if we say to people you can do this and it works! having an adapter for it us a must. Especially if we get things to the point where we can easily reuse the full set of tests on each adapter. At that point we just need to hook up each adapter with a buildbot builder and suddenly we have a dreamlike level of testing for the various features we offer. We shouldn't have any issues getting the tests to run on all the adapters. Worst case we can use Maven profiles and run the tests against the embedded adapter by default, and you just switch profile to use the other modes. The buildbot builders can then presumably be setup with the necessary profile switch in their build. I was thinking it would be cool to try and extend either the test suite or the Arquillian test runner somehow so the test then runs against all the adapters in one go. I was going to do the Maven profile bit first, as that should be reasonably straightforward, and then take it from there. I've done some refactoring around the Arquillian test suite, so the tests now run against both adapters. Currently we have ~6 failures and 2 errors for both adapters, and it should be the same tests in both cases. We currently run 82 tests. This was a pretty bug refactor - it seemed like things worked well
Re: Arquillian Showcase
Hi Romain, How's this looking? Is there anything I can do to help? I'm keen to show both adapters (although I'm happy to do that with the example app) at JAX. I'm keen to help out so if there's something specific you can point me at, that would be cool. If not, I notice the remote adapter is currently commented out of the build. I could take a look at that. Jon On Wed, Oct 12, 2011 at 9:33 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: not so far (we are in alpha 5 and showcase uses CR1) but it needs some modifications - Romain 2011/10/12 Jonathan Gallimore jonathan.gallim...@gmail.com Sweet. Are we far behind version-wise? Jon On Wed, Oct 12, 2011 at 9:27 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: i'm upgrading arquillian-tomee-embedded (and common) versions - Romain 2011/10/12 Jonathan Gallimore jonathan.gallim...@gmail.com I'm happy to have a go at getting some of these working. I've done a bit of work on our Arquillian adapters so I'm happy to try and help out anyone else who wants to have a look as well. I've also got our moviefun sample working with both adapters, and got it running a test with Selenium. This is checked in alongside our adapters. I'm planning to demonstrate this at JAX London in a couple of weeks time. Jon On Wed, Oct 12, 2011 at 8:08 PM, David Blevins david.blev...@gmail.com wrote: So one of the things I think would be really excellent for the 1.0.0-beta-2 is to get our Arquillian support polished and released. I showed our Arquillian support at the JavaOne TomEE talk to demonstrate that a) it works embeddable and b) yes it runs in 2-3 seconds. I wasn't able to show too many examples though. The Arquillian Showcase is the trove of examples we really need to show off TomEE. I tried to get some of them to run the night before the TomEE talk, but our adapter uses an old API and overall I just had too many issues. The minutes of the clock ticked away and I eventually went back to focusing on the old Arquillian support. If we can get this running, the Arquillian guys are of course happy to show off TomEE a little. As well it would make great content for screencasts and technical articles. https://github.com/arquillian/arquillian-showcase Not only is there a lot of content there in terms of examples, but many of them run on the other vendors too, so it's also a good way to do comparisons. Who knows, maybe we're faster than everyone or the same speed? Or slower and we need to do some tuning? Plenty of growth for us there. Here's the current code: http://svn.apache.org/repos/asf/openejb/trunk/arquillian-tomee/ The 'arquillian-tomee-embedded' adapter is the primary one we'd want to get tuned and oiled. The 'arquillian-tomee-remote' would be the next one. -David
Re: Arquillian Showcase
I've done that - thanks for the tip! Jon On Sat, Oct 15, 2011 at 2:59 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Just take care to be up to date on both openejb trunk and arquillian adapters otherwise tests will fail. - Romain Le 15 oct. 2011 15:49, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : Thanks. I'm having a go with that now. Cheers Jon On Sat, Oct 15, 2011 at 2:44 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Yep, it just need to upgrade api, copy paste from embedded one should be enough. - Romain Le 15 oct. 2011 15:35, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : Hi Romain, How's this looking? Is there anything I can do to help? I'm keen to show both adapters (although I'm happy to do that with the example app) at JAX. I'm keen to help out so if there's something specific you can point me at, that would be cool. If not, I notice the remote adapter is currently commented out of the build. I could take a look at that. Jon On Wed, Oct 12, 2011 at 9:33 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: not so far (we are in alpha 5 and showcase uses CR1) but it needs some modifications - Romain 2011/10/12 Jonathan Gallimore jonathan.gallim...@gmail.com Sweet. Are we far behind version-wise? Jon On Wed, Oct 12, 2011 at 9:27 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: i'm upgrading arquillian-tomee-embedded (and common) versions - Romain 2011/10/12 Jonathan Gallimore jonathan.gallim...@gmail.com I'm happy to have a go at getting some of these working. I've done a bit of work on our Arquillian adapters so I'm happy to try and help out anyone else who wants to have a look as well. I've also got our moviefun sample working with both adapters, and got it running a test with Selenium. This is checked in alongside our adapters. I'm planning to demonstrate this at JAX London in a couple of weeks time. Jon On Wed, Oct 12, 2011 at 8:08 PM, David Blevins david.blev...@gmail.com wrote: So one of the things I think would be really excellent for the 1.0.0-beta-2 is to get our Arquillian support polished and released. I showed our Arquillian support at the JavaOne TomEE talk to demonstrate that a) it works embeddable and b) yes it runs in 2-3 seconds. I wasn't able to show too many examples though. The Arquillian Showcase is the trove of examples we really need to show off TomEE. I tried to get some of them to run the night before the TomEE talk, but our adapter uses an old API and overall I just had too many issues. The minutes of the clock ticked away and I eventually went back to focusing on the old Arquillian support. If we can get this running, the Arquillian guys are of course happy to show off TomEE a little. As well it would make great content for screencasts and technical articles. https://github.com/arquillian/arquillian-showcase Not only is there a lot of content there in terms of examples, but many of them run on the other vendors too, so it's also a good way to do comparisons. Who knows, maybe we're faster than everyone or the same speed? Or slower and we need to do some tuning? Plenty of growth for us there. Here's the current code: http://svn.apache.org/repos/asf/openejb/trunk/arquillian-tomee/ The 'arquillian-tomee-embedded' adapter is the primary one we'd want to get tuned and oiled. The 'arquillian-tomee-remote' would be the next one. -David
Re: svn commit: r1180717 - in /openejb/trunk/arquillian-tomee: arquillian-tomee-moviefun-example/ arquillian-tomee-moviefun-example/src/main/resources/META-INF/ arquillian-tomee-moviefun-example/src/t
Sorry, committing that was a mistake. I'll change it back. For info, I did that because the schema on oracle's site was unavailable. The effect was that TomEE would take 70 seconds to deploy this app, and it would then fail as soon as any persistence method was called. I havent dug too deep, but it looks like OpenJPA relies on the xsd being available. Jon On Oct 13, 2011 7:18 PM, Jacek Laskowski ja...@japila.pl wrote: On Sun, Oct 9, 2011 at 11:18 PM, jgallim...@apache.org wrote: Author: jgallimore Date: Sun Oct 9 21:18:38 2011 New Revision: 1180717 URL: http://svn.apache.org/viewvc?rev=1180717view=rev Log: TOMEE-4 added Selenium test to Moviefun example ... Modified: openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml URL: http://svn.apache.org/viewvc/openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml?rev=1180717r1=1180716r2=1180717view=diff == --- openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml (original) +++ openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml Sun Oct 9 21:18:38 2011 @@ -18,7 +18,7 @@ -- persistence version=2.0 xmlns= http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation=http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd; + xsi:schemaLocation=http://java.sun.com/xml/ns/persistence http://www.jrg.me.uk/persistence_2_0.xsd; That scares me. Can we get back to the previous schemaLocation? Jacek -- Jacek Laskowski Java EE, functional languages and IBM WebSphere - http://blog.japila.pl Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl Hoping to save time by spending it by David Blevins (Apache OpenEJB)
Re: svn commit: r1180717 - in /openejb/trunk/arquillian-tomee: arquillian-tomee-moviefun-example/ arquillian-tomee-moviefun-example/src/main/resources/META-INF/ arquillian-tomee-moviefun-example/src/t
Reverted in revision 1183085. Jon On Thu, Oct 13, 2011 at 7:40 PM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Sorry, committing that was a mistake. I'll change it back. For info, I did that because the schema on oracle's site was unavailable. The effect was that TomEE would take 70 seconds to deploy this app, and it would then fail as soon as any persistence method was called. I havent dug too deep, but it looks like OpenJPA relies on the xsd being available. Jon On Oct 13, 2011 7:18 PM, Jacek Laskowski ja...@japila.pl wrote: On Sun, Oct 9, 2011 at 11:18 PM, jgallim...@apache.org wrote: Author: jgallimore Date: Sun Oct 9 21:18:38 2011 New Revision: 1180717 URL: http://svn.apache.org/viewvc?rev=1180717view=rev Log: TOMEE-4 added Selenium test to Moviefun example ... Modified: openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml URL: http://svn.apache.org/viewvc/openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml?rev=1180717r1=1180716r2=1180717view=diff == --- openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml (original) +++ openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml Sun Oct 9 21:18:38 2011 @@ -18,7 +18,7 @@ -- persistence version=2.0 xmlns= http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation= http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd; + xsi:schemaLocation= http://java.sun.com/xml/ns/persistence http://www.jrg.me.uk/persistence_2_0.xsd; That scares me. Can we get back to the previous schemaLocation? Jacek -- Jacek Laskowski Java EE, functional languages and IBM WebSphere - http://blog.japila.pl Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl Hoping to save time by spending it by David Blevins (Apache OpenEJB)
Re: svn commit: r1180717 - in /openejb/trunk/arquillian-tomee: arquillian-tomee-moviefun-example/ arquillian-tomee-moviefun-example/src/main/resources/META-INF/ arquillian-tomee-moviefun-example/src/t
I hadn't realised that before... and I didn't like it when I realised what was going on. Glad I don't have a proxy at work. Jon On Thu, Oct 13, 2011 at 8:53 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: +1, in a proxy environment applications are not deployed without the proxy :( - Romain 2011/10/13 Jonathan Gallimore jonathan.gallim...@gmail.com Sorry, committing that was a mistake. I'll change it back. For info, I did that because the schema on oracle's site was unavailable. The effect was that TomEE would take 70 seconds to deploy this app, and it would then fail as soon as any persistence method was called. I havent dug too deep, but it looks like OpenJPA relies on the xsd being available. Jon On Oct 13, 2011 7:18 PM, Jacek Laskowski ja...@japila.pl wrote: On Sun, Oct 9, 2011 at 11:18 PM, jgallim...@apache.org wrote: Author: jgallimore Date: Sun Oct 9 21:18:38 2011 New Revision: 1180717 URL: http://svn.apache.org/viewvc?rev=1180717view=rev Log: TOMEE-4 added Selenium test to Moviefun example ... Modified: openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml URL: http://svn.apache.org/viewvc/openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml?rev=1180717r1=1180716r2=1180717view=diff == --- openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml (original) +++ openejb/trunk/arquillian-tomee/arquillian-tomee-moviefun-example/src/main/resources/META-INF/persistence.xml Sun Oct 9 21:18:38 2011 @@ -18,7 +18,7 @@ -- persistence version=2.0 xmlns= http://java.sun.com/xml/ns/persistence; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation= http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd; + xsi:schemaLocation= http://java.sun.com/xml/ns/persistence http://www.jrg.me.uk/persistence_2_0.xsd; That scares me. Can we get back to the previous schemaLocation? Jacek -- Jacek Laskowski Java EE, functional languages and IBM WebSphere - http://blog.japila.pl Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl Hoping to save time by spending it by David Blevins (Apache OpenEJB)
Re: Arquillian Showcase
I'm happy to have a go at getting some of these working. I've done a bit of work on our Arquillian adapters so I'm happy to try and help out anyone else who wants to have a look as well. I've also got our moviefun sample working with both adapters, and got it running a test with Selenium. This is checked in alongside our adapters. I'm planning to demonstrate this at JAX London in a couple of weeks time. Jon On Wed, Oct 12, 2011 at 8:08 PM, David Blevins david.blev...@gmail.comwrote: So one of the things I think would be really excellent for the 1.0.0-beta-2 is to get our Arquillian support polished and released. I showed our Arquillian support at the JavaOne TomEE talk to demonstrate that a) it works embeddable and b) yes it runs in 2-3 seconds. I wasn't able to show too many examples though. The Arquillian Showcase is the trove of examples we really need to show off TomEE. I tried to get some of them to run the night before the TomEE talk, but our adapter uses an old API and overall I just had too many issues. The minutes of the clock ticked away and I eventually went back to focusing on the old Arquillian support. If we can get this running, the Arquillian guys are of course happy to show off TomEE a little. As well it would make great content for screencasts and technical articles. https://github.com/arquillian/arquillian-showcase Not only is there a lot of content there in terms of examples, but many of them run on the other vendors too, so it's also a good way to do comparisons. Who knows, maybe we're faster than everyone or the same speed? Or slower and we need to do some tuning? Plenty of growth for us there. Here's the current code: http://svn.apache.org/repos/asf/openejb/trunk/arquillian-tomee/ The 'arquillian-tomee-embedded' adapter is the primary one we'd want to get tuned and oiled. The 'arquillian-tomee-remote' would be the next one. -David
Re: Arquillian Showcase
Sweet. Are we far behind version-wise? Jon On Wed, Oct 12, 2011 at 9:27 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: i'm upgrading arquillian-tomee-embedded (and common) versions - Romain 2011/10/12 Jonathan Gallimore jonathan.gallim...@gmail.com I'm happy to have a go at getting some of these working. I've done a bit of work on our Arquillian adapters so I'm happy to try and help out anyone else who wants to have a look as well. I've also got our moviefun sample working with both adapters, and got it running a test with Selenium. This is checked in alongside our adapters. I'm planning to demonstrate this at JAX London in a couple of weeks time. Jon On Wed, Oct 12, 2011 at 8:08 PM, David Blevins david.blev...@gmail.com wrote: So one of the things I think would be really excellent for the 1.0.0-beta-2 is to get our Arquillian support polished and released. I showed our Arquillian support at the JavaOne TomEE talk to demonstrate that a) it works embeddable and b) yes it runs in 2-3 seconds. I wasn't able to show too many examples though. The Arquillian Showcase is the trove of examples we really need to show off TomEE. I tried to get some of them to run the night before the TomEE talk, but our adapter uses an old API and overall I just had too many issues. The minutes of the clock ticked away and I eventually went back to focusing on the old Arquillian support. If we can get this running, the Arquillian guys are of course happy to show off TomEE a little. As well it would make great content for screencasts and technical articles. https://github.com/arquillian/arquillian-showcase Not only is there a lot of content there in terms of examples, but many of them run on the other vendors too, so it's also a good way to do comparisons. Who knows, maybe we're faster than everyone or the same speed? Or slower and we need to do some tuning? Plenty of growth for us there. Here's the current code: http://svn.apache.org/repos/asf/openejb/trunk/arquillian-tomee/ The 'arquillian-tomee-embedded' adapter is the primary one we'd want to get tuned and oiled. The 'arquillian-tomee-remote' would be the next one. -David
Re: Strange application deploy issue
On Sun, Oct 9, 2011 at 9:36 PM, Jacek Laskowski ja...@japila.pl wrote: On Sun, Oct 9, 2011 at 10:33 PM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Just a heads-up - I don't know if anyone else has seen this, but I've noticed some odd behaviour with TomEE. When it finishes starting on my machine, every application then refreshes/redeploys. In my case my app fails to deploy second time around. I dug a bit deeper and this seems to happen when Tomcat detects a change to conf/web.xml which it checks for by monitoring its timestamp. We always seem to delete this file in the Installers class which is called by the Tomcat hook. I've changed this so this file only gets overwritten if its content has actually changed. Hopefully this won't cause any problems, but please say if it does. You're the man! While debugging tomee I faced it a couple of times and didn't know why it happened this way. Thanks for the fix. It was one of the very few lately so much awaited and ultimately appreciated. No problem, I'm glad it wasn't just me seeing it :) Jon
Re: We did it!!!
Absolutely fantastic!! Well done and big thanks to everyone, this is an amazing achievement! And I just also wanted to echo what others have said here - a big thank you to you David, for the direction, guidance, help and ideas you've given us and all the work you put in! I'm looking forward to the party at the next meetup! :) Cheers Jon On Wed, Oct 5, 2011 at 6:38 AM, David Blevins david.blev...@gmail.comwrote: Back at the computer for a moment and then... I think sleep (and up early to write slides). Couldn't let launch day go by without saying ... HELL YEAH! WE DID IT! We all should take a moment over the next few days to really just enjoy the victory. Things like this don't happen but a few times a lifetime. Don't take it for granted because you never know if or when it might happen again. Whenever we have our get-together next year we're going to have to have a special celebration for this outstanding accomplishment. We have absolutely earned it. Few groups could pull off what we have done in spare hours here and there. Time taken away from wives and children and hobbies and friends. It's such a testament to the character of this community that we're able to work so closely and passionately with each other and all the while we all come from different jobs, time zones and different everything really. It's a treasure to be sure. I know that everyone here cares so much they wish they could do more. It may surprise you to learn I feel like that pretty much all the time too. It just comes with working on something you love. When one is looking out so far ahead all the time and focusing on how far there is yet to go, it can be really easy to lose track of how far you've come and how many steps you've taken to get there. Doing something like this is like a game of jenga. You may look at the few bricks you've added and wish you could have added more. You might think they barely amount to anything compared to the tall structure you see before you. But imagine the devastation that would become of that structure if everyone who felt that way removed their bricks. That's how utterly important every contribution is. Appreciate the bricks you've added and the bricks others have added. We did this together and there is no one person who could have ever done it alone. I sooo can't wait for our get-together cause we're going to have one bg party :) Very excellent work everyone. Truly... outstanding. -David
Re: Please send me a link to the tool that converts EJB 2.0 to 3.0
Hi there, We have an Eclipse plugin that has this feature. The update site is at: http://apache.org/dist/openejb/eclipse-plugin/update-site/ - it would great to know how you get on with it. I think there's an issue with Eclipse 3.7, but previous versions work ok. There's also a blog entry here https://blogs.apache.org/openejb/entry/openejb_eclipse_plugin_alpha_releasewith some more information, and also a video demonstrating it here: http://vimeo.com/7393498 This worked well when I used it to convert all the EJB projects at work a while back. Please do let us know how you get on with it, any suggestions for improvements or additional features we could add would be great! Cheers Jon On Wed, Oct 5, 2011 at 10:14 PM, Skriloff, Nicholas skrilo...@darden.virginia.edu wrote: I saw your talk at JavaOne and you mentioned that there is a tool that will insert the annotations into a EJB 2.0 to EJB 3.0 application. Please send me the link to it. Sincerely, Nick Skriloff , ME , MCP, SCJP Information Technology Specialist Darden Information Services Voice 434 243 5025 Fax 434 243 2279 skrilo...@darden.virginia.edumailto:skrilo...@darden.virginia.edu PS Remember, the difference between a fresh salad and garbage is timing.
Re: svn commit: r1178742 - /openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
You beat me to it - I had just noticed they were missing! Will this pick up
the css and images as well?
Jon
On Tue, Oct 4, 2011 at 10:44 AM, rmannibu...@apache.org wrote:
Author: rmannibucau
Date: Tue Oct 4 09:44:10 2011
New Revision: 1178742
URL: http://svn.apache.org/viewvc?rev=1178742view=rev
Log:
jsp were missing in plus webapp
Modified:
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
Modified:
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
URL:
http://svn.apache.org/viewvc/openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml?rev=1178742r1=1178741r2=1178742view=diff
==
---
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
(original)
+++
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
Tue Oct 4 09:44:10 2011
@@ -61,6 +61,13 @@
directory${project.build.directory}/${project.artifactId}-${project.version}/lib/directory
outputDirectorylib/outputDirectory
/fileSet
+fileSet
+
directory${project.build.directory}/${project.artifactId}-${project.version}//directory
+ outputDirectory//outputDirectory
+ includes
+include**/*.jsp/include
+ /includes
+/fileSet
/fileSets
dependencySets
dependencySet
@@ -81,8 +88,8 @@
outputDirectoryWEB-INF/lib/outputDirectory
scoperuntime/scope
includes
- includeorg.apache.openejb:openejb-tomcat-loader/include
- includeorg.codehaus.swizzle:swizzle-stream/include
+includeorg.apache.openejb:openejb-tomcat-loader/include
+includeorg.codehaus.swizzle:swizzle-stream/include
/includes
/dependencySet
/dependencySets
Re: svn commit: r1178742 - /openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
Thanks, I'll grab that and try it out when that goes in.
Cheers
Jon
On Tue, Oct 4, 2011 at 11:02 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
no, i've just saw it, the next commit will bring back css, html and images
too
- Romain
2011/10/4 Jonathan Gallimore jonathan.gallim...@gmail.com
You beat me to it - I had just noticed they were missing! Will this pick
up
the css and images as well?
Jon
On Tue, Oct 4, 2011 at 10:44 AM, rmannibu...@apache.org wrote:
Author: rmannibucau
Date: Tue Oct 4 09:44:10 2011
New Revision: 1178742
URL: http://svn.apache.org/viewvc?rev=1178742view=rev
Log:
jsp were missing in plus webapp
Modified:
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
Modified:
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
URL:
http://svn.apache.org/viewvc/openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml?rev=1178742r1=1178741r2=1178742view=diff
==
---
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
(original)
+++
openejb/trunk/openejb/assembly/openejb-tomcat/openejb-tomcat-plus-webapp/src/main/assembly/war.xml
Tue Oct 4 09:44:10 2011
@@ -61,6 +61,13 @@
directory${project.build.directory}/${project.artifactId}-${project.version}/lib/directory
outputDirectorylib/outputDirectory
/fileSet
+fileSet
+
directory${project.build.directory}/${project.artifactId}-${project.version}//directory
+ outputDirectory//outputDirectory
+ includes
+include**/*.jsp/include
+ /includes
+/fileSet
/fileSets
dependencySets
dependencySet
@@ -81,8 +88,8 @@
outputDirectoryWEB-INF/lib/outputDirectory
scoperuntime/scope
includes
- includeorg.apache.openejb:openejb-tomcat-loader/include
- includeorg.codehaus.swizzle:swizzle-stream/include
+includeorg.apache.openejb:openejb-tomcat-loader/include
+includeorg.codehaus.swizzle:swizzle-stream/include
/includes
/dependencySet
/dependencySets
Re: Arquillian adapters
On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: On Thu, Sep 29, 2011 at 12:01 AM, David Blevins david.blev...@gmail.comwrote: On Sep 28, 2011, at 3:36 PM, Jonathan Gallimore wrote: When I hacked up the Remote with zip adapter I intended to merge it into the remote adapter - along the lines of: check to see if TomEE is running on the port specified in arquillian.xml. If it is, just deploy straight to it. If not, go grab the zip and use that. Does that sound like a reasonable idea? Very reasonable. That's what the itests have done for years, the CDI TCK does and the Java EE TCK setup does. It's pretty easy to have the rule of if you don't want us to start a server, make sure a server is started Cool, I'll get that done. I've extended the remote adapter to allow this. If you specify something like (note the 1.0.0-beta-1 OpenEJB version and no Tomcat version): arquillian xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd; container qualifier=tomee default=true configuration property name=dir/tmp/arquillian-apache-tomee/property property name=httpPort9080/property property name=stopPort9005/property property name=tomcatVersion/property property name=openejbVersion1.0.0-beta-1/property /configuration /container /arquillian if nothing is running on port 9080 we'll download TomEE, unzip it, start it and use that for the test. If you changed the OpenEJB and Tomcat versions to, say: property name=tomcatVersion7.0.21/property property name=openejbVersion4.0.0-beta-1/property We'd download Tomcat and the OpenEJB.war, set that up, and use that instead. So we should be able to use this to test against Tomcat 5.5/6 with OpenEJB. I quite like this, but it would be great to get any feedback. That leaves the embedded-with-war adapter as something that might seem a bit odd. Currently I can't get it to run correctly, but that might be something wrong with my machine. What's people's opinion of this method? Should we drop this, or is it a useful adapter to hang on to? My impression is I would never ever advise a user to use it. That said, it's an absolutely fabulous way for us to test the drop-in-war functionality. Well, almost fabulous... the real world scenario is an existing Tomcat install, not an embedded one. Either way, if we say to people you can do this and it works! having an adapter for it us a must. Especially if we get things to the point where we can easily reuse the full set of tests on each adapter. At that point we just need to hook up each adapter with a buildbot builder and suddenly we have a dreamlike level of testing for the various features we offer. We shouldn't have any issues getting the tests to run on all the adapters. Worst case we can use Maven profiles and run the tests against the embedded adapter by default, and you just switch profile to use the other modes. The buildbot builders can then presumably be setup with the necessary profile switch in their build. I was thinking it would be cool to try and extend either the test suite or the Arquillian test runner somehow so the test then runs against all the adapters in one go. I was going to do the Maven profile bit first, as that should be reasonably straightforward, and then take it from there. I've done some refactoring around the Arquillian test suite, so the tests now run against both adapters. Currently we have ~6 failures and 2 errors for both adapters, and it should be the same tests in both cases. We currently run 82 tests. This was a pretty bug refactor - it seemed like things worked well in the embedded case, because everything is right there on the classpath. Running remotely a lot of tests failed as they relied on the test or junit being available from the app being tested. I've separated the inner classes out, divided things up into packages and tried to move a couple of methods to trim what would need to be added to the Shrinkwrap archives. We still need junit in a couple of cases, so in a couple of places we add that in as a lib. Hope that's all ok. There's probably some duplicate classes we could chop out. Running the tests can be done by running the test Maven goal in the arquillian-tomee-tests module. Choosing which adapter to use is done by enabling a Maven profile. By default we run against the embedded adapter (arquillian-tomee-embedded). Doing a 'mvn -Parquillian-tomee-remote clean install' will build and test against the remote adapter. If you're using an IDE plugin such as m2e, you should be able to specify the desired Maven profile in your IDE settings and the tests should run straight from the IDE (works for me in Eclipse) - please shout if you
Re: Arquillian adapters
Will do (will be tomorrow now, its getting late for me!), thanks for the link! Jon On Oct 5, 2011 12:02 AM, Mark Struberg strub...@yahoo.de wrote: You could take a look at what Dan and I did for native owb: https://github.com/struberg/arquillian-container-openwebbeans LieGrue, strub - Original Message - From: Jonathan Gallimore jonathan.gallim...@gmail.com To: dev@openejb.apache.org Cc: Sent: Wednesday, October 5, 2011 12:57 AM Subject: Re: Arquillian adapters On Thu, Sep 29, 2011 at 12:13 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: On Thu, Sep 29, 2011 at 12:01 AM, David Blevins david.blev...@gmail.comwrote: On Sep 28, 2011, at 3:36 PM, Jonathan Gallimore wrote: When I hacked up the Remote with zip adapter I intended to merge it into the remote adapter - along the lines of: check to see if TomEE is running on the port specified in arquillian.xml. If it is, just deploy straight to it. If not, go grab the zip and use that. Does that sound like a reasonable idea? Very reasonable. That's what the itests have done for years, the CDI TCK does and the Java EE TCK setup does. It's pretty easy to have the rule of if you don't want us to start a server, make sure a server is started Cool, I'll get that done. I've extended the remote adapter to allow this. If you specify something like (note the 1.0.0-beta-1 OpenEJB version and no Tomcat version): arquillian xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd; container qualifier=tomee default=true configuration property name=dir/tmp/arquillian-apache-tomee/property property name=httpPort9080/property property name=stopPort9005/property property name=tomcatVersion/property property name=openejbVersion1.0.0-beta-1/property /configuration /container /arquillian if nothing is running on port 9080 we'll download TomEE, unzip it, start it and use that for the test. If you changed the OpenEJB and Tomcat versions to, say: property name=tomcatVersion7.0.21/property property name=openejbVersion4.0.0-beta-1/property We'd download Tomcat and the OpenEJB.war, set that up, and use that instead. So we should be able to use this to test against Tomcat 5.5/6 with OpenEJB. I quite like this, but it would be great to get any feedback. That leaves the embedded-with-war adapter as something that might seem a bit odd. Currently I can't get it to run correctly, but that might be something wrong with my machine. What's people's opinion of this method? Should we drop this, or is it a useful adapter to hang on to? My impression is I would never ever advise a user to use it. That said, it's an absolutely fabulous way for us to test the drop-in-war functionality. Well, almost fabulous... the real world scenario is an existing Tomcat install, not an embedded one. Either way, if we say to people you can do this and it works! having an adapter for it us a must. Especially if we get things to the point where we can easily reuse the full set of tests on each adapter. At that point we just need to hook up each adapter with a buildbot builder and suddenly we have a dreamlike level of testing for the various features we offer. We shouldn't have any issues getting the tests to run on all the adapters. Worst case we can use Maven profiles and run the tests against the embedded adapter by default, and you just switch profile to use the other modes. The buildbot builders can then presumably be setup with the necessary profile switch in their build. I was thinking it would be cool to try and extend either the test suite or the Arquillian test runner somehow so the test then runs against all the adapters in one go. I was going to do the Maven profile bit first, as that should be reasonably straightforward, and then take it from there. I've done some refactoring around the Arquillian test suite, so the tests now run against both adapters. Currently we have ~6 failures and 2 errors for both adapters, and it should be the same tests in both cases. We currently run 82 tests. This was a pretty bug refactor - it seemed like things worked well in the embedded case, because everything is right there on the classpath. Running remotely a lot of tests failed as they relied on the test or junit being available from the app being tested. I've separated the inner classes out, divided things up into packages and tried to move a couple of methods to trim what would need to be added to the Shrinkwrap archives. We still need junit in a couple of cases, so in a couple of places we add that in as a lib. Hope that's all ok. There's probably some duplicate classes we could chop out. Running the tests can
Re: [VOTE] Apache OpenEJB 4.0.0-beta-1 and Apache TomEE 1.0.0-beta-1 (023)
+1 Jon On Mon, Oct 3, 2011 at 2:28 AM, David Blevins david.blev...@gmail.comwrote: NOTE TO EVERYONE I know re-rolling can be very time consuming and often people vote on the first release attempt and never vote again. We want a strong turnout for this vote and it would be a shame to end it with 3, 4 or 5 votes. In an effort to save everyone a considerable amount of time, I have used rsync to compare the entire set of unpacked 019 and 024 binaries. See the output at the bottom of this email. PLEASE DO REVOTE. If you liked the previous set of binaries and trust rsync, it should only take 5 minutes to see that things are still good and revote. You can also run any comparisons you like on my directory in people. The files/directories are read-only so you can feel free to run commands without accidentally messing up something. - - - - - - - - - - - - - - - - - - - - - - - - - - Changes since last vote: - Added missing W3C and CDDL license/noticed information to openejb-jee and the source-release.zip https://repository.apache.org/content/repositories/orgapacheopenejb-023/ Src: org/apache/openejb/openejb/4.0.0-beta-1/openejb-4.0.0-beta-1-source-release.zip Bin: org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-plus.tar.gz org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-plus.zip org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-webprofile.tar.gz org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-webprofile.zip org/apache/openejb/examples/4.0.0-beta-1/examples-4.0.0-beta-1-src.tar.gz org/apache/openejb/examples/4.0.0-beta-1/examples-4.0.0-beta-1-src.zip org/apache/openejb/javaee-api/6.0-2/javaee-api-6.0-2.zip org/apache/openejb/openejb-standalone/4.0.0-beta-1/openejb-standalone-4.0.0-beta-1.tar.gz org/apache/openejb/openejb-standalone/4.0.0-beta-1/openejb-standalone-4.0.0-beta-1.zip org/apache/openejb/openejb-tomcat-plus-webapp/4.0.0-beta-1/openejb-tomcat-plus-webapp-4.0.0-beta-1.war org/apache/openejb/openejb-tomcat-webapp/4.0.0-beta-1/openejb-tomcat-webapp-4.0.0-beta-1.war Tag: http://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0-beta-1/ Report: http://people.apache.org/~dblevins//orgapacheopenejb-024/archives.html Here's my +1 -David dblevins@minotaur:~/public_html$ rsync -v -p -r --size-only --dry-run orgapacheopenejb-019/content orgapacheopenejb-023/ | grep -v 'jar$' sending incremental file list content/org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-plus.zip.contents/apache-tomee-plus-1.0.0-beta-1/webapps/openejb/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/LICENSE content/org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-plus.zip.contents/apache-tomee-plus-1.0.0-beta-1/webapps/openejb/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/NOTICE content/org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-webprofile.zip.contents/apache-tomee-webprofile-1.0.0-beta-1/webapps/openejb/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/LICENSE content/org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-webprofile.zip.contents/apache-tomee-webprofile-1.0.0-beta-1/webapps/openejb/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/NOTICE content/org/apache/openejb/openejb-jee/4.0.0-beta-1/openejb-jee-4.0.0-beta-1-javadoc.jar.contents/META-INF/LICENSE content/org/apache/openejb/openejb-jee/4.0.0-beta-1/openejb-jee-4.0.0-beta-1-javadoc.jar.contents/META-INF/NOTICE content/org/apache/openejb/openejb-jee/4.0.0-beta-1/openejb-jee-4.0.0-beta-1-sources.jar.contents/META-INF/LICENSE content/org/apache/openejb/openejb-jee/4.0.0-beta-1/openejb-jee-4.0.0-beta-1-sources.jar.contents/META-INF/NOTICE content/org/apache/openejb/openejb-jee/4.0.0-beta-1/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/LICENSE content/org/apache/openejb/openejb-jee/4.0.0-beta-1/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/NOTICE content/org/apache/openejb/openejb-standalone/4.0.0-beta-1/openejb-standalone-4.0.0-beta-1.zip.contents/apache-openejb-4.0.0-beta-1/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/LICENSE content/org/apache/openejb/openejb-standalone/4.0.0-beta-1/openejb-standalone-4.0.0-beta-1.zip.contents/apache-openejb-4.0.0-beta-1/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/NOTICE content/org/apache/openejb/openejb-tomcat-plus-webapp/4.0.0-beta-1/openejb-tomcat-plus-webapp-4.0.0-beta-1.war.contents/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/LICENSE content/org/apache/openejb/openejb-tomcat-plus-webapp/4.0.0-beta-1/openejb-tomcat-plus-webapp-4.0.0-beta-1.war.contents/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/NOTICE content/org/apache/openejb/openejb-tomcat-webapp/4.0.0-beta-1/openejb-tomcat-webapp-4.0.0-beta-1.war.contents/lib/openejb-jee-4.0.0-beta-1.jar.contents/META-INF/LICENSE
Re: [VOTE] Apache OpenEJB 4.0.0-beta-1 and Apache TomEE 1.0.0-beta-1 (2nd try)
+1 Jon On Sat, Oct 1, 2011 at 6:52 PM, dsh daniel.hais...@googlemail.com wrote: +1 Cheers Daniel On Sat, Oct 1, 2011 at 8:17 AM, David Blevins david.blev...@gmail.com wrote: Ok, the new binaries are up! Changes since last vote: - switched version number of TomEE to 1.0.0-beta-1 - fixed SNAPSHOT references in src - Added missing CDDL license to the source-release.zip https://repository.apache.org/content/repositories/orgapacheopenejb-019/ Src: org/apache/openejb/openejb/4.0.0-beta-1/openejb-4.0.0-beta-1-source-release.zip Bin: org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-plus.tar.gz org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-plus.zip org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-webprofile.tar.gz org/apache/openejb/apache-tomee/1.0.0-beta-1/apache-tomee-1.0.0-beta-1-webprofile.zip org/apache/openejb/examples/4.0.0-beta-1/examples-4.0.0-beta-1-src.tar.gz org/apache/openejb/examples/4.0.0-beta-1/examples-4.0.0-beta-1-src.zip org/apache/openejb/javaee-api/6.0-2/javaee-api-6.0-2.zip org/apache/openejb/openejb-standalone/4.0.0-beta-1/openejb-standalone-4.0.0-beta-1.tar.gz org/apache/openejb/openejb-standalone/4.0.0-beta-1/openejb-standalone-4.0.0-beta-1.zip org/apache/openejb/openejb-tomcat-plus-webapp/4.0.0-beta-1/openejb-tomcat-plus-webapp-4.0.0-beta-1.war org/apache/openejb/openejb-tomcat-webapp/4.0.0-beta-1/openejb-tomcat-webapp-4.0.0-beta-1.war Tag: http://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0-beta-1/ Report: http://people.apache.org/~dblevins//orgapacheopenejb-019/archives.html 72 hours for voting! Here's my +1 -David
Re: [VOTE] Apache OpenEJB/TomEE 4.0.0-beta-1
Are you able to access the html file on people.apache.org at the moment? Looks like I can't get a http connection to that machine either from home or work at the moment. I'm really keen to check to check that out. Thanks for rolling this, I'm going to try and get a bit of time to look at it in detail over lunch and this evening. Jon On Fri, Sep 30, 2011 at 9:49 AM, David Blevins david.blev...@gmail.comwrote: Forgot my +1! -David On Sep 30, 2011, at 1:37 AM, David Blevins wrote: Ok! I think it's voting time. I've rolled a few binaries and worked out every little license detail and finally got something I think is probably the best set of binaries we've rolled. The tag and repo: http://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0-beta-1/ https://repository.apache.org/content/repositories/orgapacheopenejb-012/ And my little report of the jars in the repo. That's all the above binaries downloaded, unpacked, and then indexed so it's easy to browse around and poke at the files. http://people.apache.org/~dblevins/orgapacheopenejb-012/archives.html Vote will be open for 72 hours! -David
Re: [VOTE] Apache OpenEJB/TomEE 4.0.0-beta-1
http://people.apache.org/~dblevins/orgapacheopenejb-012/archives.html seems to be working for me now. Nice report! Jon On Fri, Sep 30, 2011 at 11:40 AM, dsh daniel.hais...@googlemail.com wrote: p.a.o is not working for me either at the time. Cheers Daniel On Fri, Sep 30, 2011 at 10:53 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Are you able to access the html file on people.apache.org at the moment? Looks like I can't get a http connection to that machine either from home or work at the moment. I'm really keen to check to check that out. Thanks for rolling this, I'm going to try and get a bit of time to look at it in detail over lunch and this evening. Jon On Fri, Sep 30, 2011 at 9:49 AM, David Blevins david.blev...@gmail.com wrote: Forgot my +1! -David On Sep 30, 2011, at 1:37 AM, David Blevins wrote: Ok! I think it's voting time. I've rolled a few binaries and worked out every little license detail and finally got something I think is probably the best set of binaries we've rolled. The tag and repo: http://svn.apache.org/repos/asf/openejb/tags/openejb-4.0.0-beta-1/ https://repository.apache.org/content/repositories/orgapacheopenejb-012/ And my little report of the jars in the repo. That's all the above binaries downloaded, unpacked, and then indexed so it's easy to browse around and poke at the files. http://people.apache.org/~dblevins/orgapacheopenejb-012/archives.html Vote will be open for 72 hours! -David
Re: Next release
I definitely agree. Sounds great. Jon On Sep 30, 2011 8:01 PM, David Blevins david.blev...@gmail.com wrote: Was chatting with Romain and he mentioned some fixes he wanted to add that didn't make this release. I imagine that there'll be plenty of fixes that will happen over the next couple weeks. For several small reasons that add up and are totally unmeasurable, we tend to drift into long release cycles. We say we're going to release more frequently, but it hasn't happened yet. I'm thinking maybe we just need to set the date to ensure we actually do. What do people think about a next release potentially as short as 2 weeks from now? -David
Re: Arquillian adapters
On Thu, Sep 29, 2011 at 12:01 AM, David Blevins david.blev...@gmail.comwrote: On Sep 28, 2011, at 3:36 PM, Jonathan Gallimore wrote: When I hacked up the Remote with zip adapter I intended to merge it into the remote adapter - along the lines of: check to see if TomEE is running on the port specified in arquillian.xml. If it is, just deploy straight to it. If not, go grab the zip and use that. Does that sound like a reasonable idea? Very reasonable. That's what the itests have done for years, the CDI TCK does and the Java EE TCK setup does. It's pretty easy to have the rule of if you don't want us to start a server, make sure a server is started Cool, I'll get that done. That leaves the embedded-with-war adapter as something that might seem a bit odd. Currently I can't get it to run correctly, but that might be something wrong with my machine. What's people's opinion of this method? Should we drop this, or is it a useful adapter to hang on to? My impression is I would never ever advise a user to use it. That said, it's an absolutely fabulous way for us to test the drop-in-war functionality. Well, almost fabulous... the real world scenario is an existing Tomcat install, not an embedded one. Either way, if we say to people you can do this and it works! having an adapter for it us a must. Especially if we get things to the point where we can easily reuse the full set of tests on each adapter. At that point we just need to hook up each adapter with a buildbot builder and suddenly we have a dreamlike level of testing for the various features we offer. We shouldn't have any issues getting the tests to run on all the adapters. Worst case we can use Maven profiles and run the tests against the embedded adapter by default, and you just switch profile to use the other modes. The buildbot builders can then presumably be setup with the necessary profile switch in their build. I was thinking it would be cool to try and extend either the test suite or the Arquillian test runner somehow so the test then runs against all the adapters in one go. I was going to do the Maven profile bit first, as that should be reasonably straightforward, and then take it from there. This Tomcat + war approach is a great way to setup buildbot to test Tomcat 5.5 + war and Tomcat 6 + war It's hard to describe how important this stuff is. Once it's in place, we won't be able to imagine life before it. :) Glad its useful, I've certainly had a lot of fun working on it :) Jon
Re: 4.0.0-beta-1 Release tasks
I agree. Jon On Sun, Sep 25, 2011 at 10:30 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: +1 to put them in sandbox - Romain 2011/9/25 David Blevins david.blev...@gmail.com On Sep 23, 2011, at 6:21 PM, David Blevins wrote: - LICENSE/NOTICE files (likely out of date) On this note, thinking maybe we want to move the jetty assemblies out of trunk for at least this release or we'll have to spend the time to create proper LICENSE/NOTICE files for those assemblies. We can easily move them back afterwards. -David
Re: [CANCEL][VOTE] Release Apache OpenEJB 3.0.4
i think you might need to add -Dassemble to to mvn release:prepare command if you don't have it already. Jon On 9/23/11, Ivan xhh...@gmail.com wrote: Yes, but all these things should be done by release plugin, that makes me feel confusion 2011/9/23 Jeff Genender jgenen...@apache.org grep -r -l SNAPSHOT * ;-) Jeff On Sep 23, 2011, at 7:11 AM, Ivan wrote: I may miss something in the release process, there are still some SNAPSHOT not removed in the pom files. Thanks for pointing it out, Jon ! 2011/9/23 Ivan xhh...@gmail.com Thanks, Jonathan, no sure why there is still 3.0.4-SNAPSHOT in the pom.xml files. Will cancel this vote, and try it later. 2011/9/23 Kevan Miller kevan.mil...@gmail.com Where are the source distributions? What are we voting on? --kevan On Sep 21, 2011, at 11:58 AM, Ivan wrote: Hi, Let's vote for Apache OpenEJB 3.0.4, this release is mostly for the incoming Geronimo 2.1.8. Comparing with the last version, only two JIRAs are included : OPENEJB-1091: Cause of RollbackException swallowed OPENEJB-1258 Boolean conversion problem in ejb-jar.xml binary repository : https://repository.apache.org/content/repositories/orgapacheopenejb-087/ source codes : https://svn.apache.org/repos/asf/openejb/tags/openejb-3.0.4 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Ivan -- Ivan -- Ivan -- Ivan
Re: [VOTE] Release Apache OpenEJB 3.0.4
I've just had a quick look at this. I can't get a checkout of the source code to build, because some of the POMs are still referencing the version as 3.0.4-SNAPSHOT. A quick grep is showing the following pom.xml files with references to 3.0.4-SNAPSHOT. assembly/openejb-tomcat/pom.xml assembly/openejb-tomcat/openejb-tomcat-webapp/pom.xml assembly/openejb-tomcat/openejb-tomcat-loader/pom.xml assembly/openejb-tomcat/openejb-tomcat-common/pom.xml assembly/openejb-tomcat/openejb-tomcat-catalina/pom.xml assembly/openejb-standalone/pom.xml assembly/openejb-itests-standalone-client/pom.xml I'm on holiday at the moment, so I have limited capacity to play around with this too much, but if I can get a successful build then I'll check the license headers and binaries. Jon On Thu, Sep 22, 2011 at 6:21 AM, Shawn Jiang genspr...@gmail.com wrote: +1 On Wed, Sep 21, 2011 at 11:58 PM, Ivan xhh...@gmail.com wrote: Hi, Let's vote for Apache OpenEJB 3.0.4, this release is mostly for the incoming Geronimo 2.1.8. Comparing with the last version, only two JIRAs are included : OPENEJB-1091: Cause of RollbackException swallowed OPENEJB-1258 Boolean conversion problem in ejb-jar.xml binary repository : https://repository.apache.org/content/repositories/orgapacheopenejb-087/ source codes : https://svn.apache.org/repos/asf/openejb/tags/openejb-3.0.4 Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Ivan -- Shawn
Re: [VOTE] javaee-api 6.0-1 (take 3)
+1 Just one thing I spotted, the LICENSE/NOTICE files in the *-sources jars that I built from the tag didn't match up with the ones in the repository. The jars in the repository all look ok to me though, and the binaries I built from the tag match up ok. Jon On Mon, Sep 12, 2011 at 7:21 PM, Alan D. Cabrera l...@toolazydogs.comwrote: +1 Looks good to me. sig/checksum, license/notice, rat, build, jars... Regards, Alan On Sep 7, 2011, at 2:09 AM, David Blevins wrote: The staging repo binaries: https://repository.apache.org/content/repositories/orgapacheopenejb-043/org/apache/openejb/javaee-api/6.0-1/ Tag: http://svn.apache.org/repos/asf/openejb/tags/javaee-api-6.0-1 -David
Re: Trunk beta release
We currently have a vote running for javaee-api. Do we need that to be complete first? Jon On Sep 6, 2011 4:44 AM, Rex Wang rwo...@gmail.com wrote: xbean and txmanager have been released in Geronimo community. Could Openejb start release? Is there any new dependencies? thanks, -Rex 2011/8/27 Jonathan Gallimore jonathan.gallim...@gmail.com I think it would be great to get some kind of alpha/beta/milestone release out. We deliberately keep the examples on a different version number to openejb, as there shouldn't be any dependency there, but we create an examples zip at release time as well as everything else I believe. I'm not too sure about javaee-api - obviously it follows the javaee version. My guess is we could choose to push that at the same time as the everything else as well. I think we'd need xbean and geronimo connector publishing first. I'm happy to volunteer to do the release work, if that's any help. Jon On Aug 26, 2011 7:15 AM, Shawn Jiang genspr...@gmail.com wrote: Anyway, let's start to do this and figure how rough the trunk is step by step. the first step would be to clean the snapshot depencencies up: xbeanVersion3.8-SNAPSHOT/xbeanVersion org.apache.openwebbeans.version1.1.1-SNAPSHOT/org.apache.openwebbeans.version geronimo.connector.version3.1.1-SNAPSHOT/geronimo.connector.version There are also some internal compoents that are using different version then 4.0.0-SNAPSHOT. javaee-api.version6.0-SNAPSHOT/javaee-api.version some samples in trunk are using 1.1-SNAPSHOT, But I can find part of them are still 1.0-SNAPSHOT. I'm not sure what's the pratice to release javaee-api and samples when they don't share the same version with trunk. On Fri, Aug 26, 2011 at 1:58 PM, David Blevins david.blev...@gmail.com wrote: I suspect that even if we get started now, it will still be a few weeks before we see anything. It's been over a year on trunk with no release. It's going to be rough. Best case scenario, we get two releases out before October. Worst case scenario, we wait too long to start and don't get any. -David On Aug 25, 2011, at 10:49 PM, Shawn Jiang wrote: Don't know if geronimo can wait until javaone. We could release a openejb m1/beta1, and then release a m2/beta2 for javaone. On Fri, Aug 26, 2011 at 12:21 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: maybe we should wait just before javaone? - Romain 2011/8/26 Shawn Jiang genspr...@gmail.com Geronimo is going to make a beta release. Let's discuss a openejb trunk release again. On Tue, Jul 12, 2011 at 9:00 AM, David Blevins david.blev...@gmail.com wrote: Would be excellent if we could get a beta ready before this presentation on the 25th: http://www.oscon.com/oscon2011/public/schedule/detail/20105 Might be kind of tight, but ideally there would be at least something there for people to download and play with. -David -- Shawn -- Shawn -- Shawn -- Lei Wang (Rex) rwonly AT apache.org
Re: Fwd: Trunk beta release
Swapped over to Geronimo connector 3.1 - most stuff looks ok, but the TransactionRollbackCauseTest unit test fails with this earlier version. We had previously upgraded to 2.2.2-SNAPSHOT to support the rollback cause: http://svn.apache.org/viewvc?view=revisionrevision=1097964 - I then upgraded to 3.1.1-SNAPSHOT after that. What's the view here - should we go for 3.1 and change/comment out the test until a newer connector is published, or is it preferably to try and get a newer version of the connector published. Jon On Sat, Aug 27, 2011 at 8:45 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: I'll give trunk a try with connector 3.1.1 today and report back. I did a fair bit of work on the connector support in openejb, and just went for the latest snapshot of geronimo connector at the time. I think 3.1.1 will probably be fine. If everyone is happy then I'll kick of the release process for a beta once xbean is published. Please shout if there's any problem with that. Jon On Aug 27, 2011 2:13 AM, Shawn Jiang genspr...@gmail.com wrote: Thank you for volunteering ! Geronimo will publish xbean soon. But is connector 3.1.1-SNAPSHOT a must-have ? can we use connector 3.1.1 for the openejb beta for now ? -- Forwarded message -- From: Shawn Jiang genspr...@gmail.com Date: Sat, Aug 27, 2011 at 9:11 AM Subject: Re: Trunk beta release To: dev@openejb.apache.org, d...@geronimo.apache.org Thank you for volunteering ! Geronimo will publish xbean soon. But is connector 3.1.1-SNAPSHOT On Sat, Aug 27, 2011 at 3:06 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: I think it would be great to get some kind of alpha/beta/milestone release out. We deliberately keep the examples on a different version number to openejb, as there shouldn't be any dependency there, but we create an examples zip at release time as well as everything else I believe. I'm not too sure about javaee-api - obviously it follows the javaee version. My guess is we could choose to push that at the same time as the everything else as well. I think we'd need xbean and geronimo connector publishing first. I'm happy to volunteer to do the release work, if that's any help. Jon On Aug 26, 2011 7:15 AM, Shawn Jiang genspr...@gmail.com wrote: Anyway, let's start to do this and figure how rough the trunk is step by step. the first step would be to clean the snapshot depencencies up: xbeanVersion3.8-SNAPSHOT/xbeanVersion org.apache.openwebbeans.version1.1.1-SNAPSHOT/org.apache.openwebbeans.version geronimo.connector.version3.1.1-SNAPSHOT/geronimo.connector.version There are also some internal compoents that are using different version then 4.0.0-SNAPSHOT. javaee-api.version6.0-SNAPSHOT/javaee-api.version some samples in trunk are using 1.1-SNAPSHOT, But I can find part of them are still 1.0-SNAPSHOT. I'm not sure what's the pratice to release javaee-api and samples when they don't share the same version with trunk. On Fri, Aug 26, 2011 at 1:58 PM, David Blevins david.blev...@gmail.com wrote: I suspect that even if we get started now, it will still be a few weeks before we see anything. It's been over a year on trunk with no release. It's going to be rough. Best case scenario, we get two releases out before October. Worst case scenario, we wait too long to start and don't get any. -David On Aug 25, 2011, at 10:49 PM, Shawn Jiang wrote: Don't know if geronimo can wait until javaone. We could release a openejb m1/beta1, and then release a m2/beta2 for javaone. On Fri, Aug 26, 2011 at 12:21 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: maybe we should wait just before javaone? - Romain 2011/8/26 Shawn Jiang genspr...@gmail.com Geronimo is going to make a beta release. Let's discuss a openejb trunk release again. On Tue, Jul 12, 2011 at 9:00 AM, David Blevins david.blev...@gmail.com wrote: Would be excellent if we could get a beta ready before this presentation on the 25th: http://www.oscon.com/oscon2011/public/schedule/detail/20105 Might be kind of tight, but ideally there would be at least something there for people to download and play with. -David -- Shawn -- Shawn -- Shawn -- Shawn -- Shawn
Re: Fwd: Trunk beta release
I'll give trunk a try with connector 3.1.1 today and report back. I did a fair bit of work on the connector support in openejb, and just went for the latest snapshot of geronimo connector at the time. I think 3.1.1 will probably be fine. If everyone is happy then I'll kick of the release process for a beta once xbean is published. Please shout if there's any problem with that. Jon On Aug 27, 2011 2:13 AM, Shawn Jiang genspr...@gmail.com wrote: Thank you for volunteering ! Geronimo will publish xbean soon. But is connector 3.1.1-SNAPSHOT a must-have ? can we use connector 3.1.1 for the openejb beta for now ? -- Forwarded message -- From: Shawn Jiang genspr...@gmail.com Date: Sat, Aug 27, 2011 at 9:11 AM Subject: Re: Trunk beta release To: dev@openejb.apache.org, d...@geronimo.apache.org Thank you for volunteering ! Geronimo will publish xbean soon. But is connector 3.1.1-SNAPSHOT On Sat, Aug 27, 2011 at 3:06 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: I think it would be great to get some kind of alpha/beta/milestone release out. We deliberately keep the examples on a different version number to openejb, as there shouldn't be any dependency there, but we create an examples zip at release time as well as everything else I believe. I'm not too sure about javaee-api - obviously it follows the javaee version. My guess is we could choose to push that at the same time as the everything else as well. I think we'd need xbean and geronimo connector publishing first. I'm happy to volunteer to do the release work, if that's any help. Jon On Aug 26, 2011 7:15 AM, Shawn Jiang genspr...@gmail.com wrote: Anyway, let's start to do this and figure how rough the trunk is step by step. the first step would be to clean the snapshot depencencies up: xbeanVersion3.8-SNAPSHOT/xbeanVersion org.apache.openwebbeans.version1.1.1-SNAPSHOT/org.apache.openwebbeans.version geronimo.connector.version3.1.1-SNAPSHOT/geronimo.connector.version There are also some internal compoents that are using different version then 4.0.0-SNAPSHOT. javaee-api.version6.0-SNAPSHOT/javaee-api.version some samples in trunk are using 1.1-SNAPSHOT, But I can find part of them are still 1.0-SNAPSHOT. I'm not sure what's the pratice to release javaee-api and samples when they don't share the same version with trunk. On Fri, Aug 26, 2011 at 1:58 PM, David Blevins david.blev...@gmail.com wrote: I suspect that even if we get started now, it will still be a few weeks before we see anything. It's been over a year on trunk with no release. It's going to be rough. Best case scenario, we get two releases out before October. Worst case scenario, we wait too long to start and don't get any. -David On Aug 25, 2011, at 10:49 PM, Shawn Jiang wrote: Don't know if geronimo can wait until javaone. We could release a openejb m1/beta1, and then release a m2/beta2 for javaone. On Fri, Aug 26, 2011 at 12:21 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: maybe we should wait just before javaone? - Romain 2011/8/26 Shawn Jiang genspr...@gmail.com Geronimo is going to make a beta release. Let's discuss a openejb trunk release again. On Tue, Jul 12, 2011 at 9:00 AM, David Blevins david.blev...@gmail.com wrote: Would be excellent if we could get a beta ready before this presentation on the 25th: http://www.oscon.com/oscon2011/public/schedule/detail/20105 Might be kind of tight, but ideally there would be at least something there for people to download and play with. -David -- Shawn -- Shawn -- Shawn -- Shawn -- Shawn
Re: Trunk beta release
I think it would be great to get some kind of alpha/beta/milestone release out. We deliberately keep the examples on a different version number to openejb, as there shouldn't be any dependency there, but we create an examples zip at release time as well as everything else I believe. I'm not too sure about javaee-api - obviously it follows the javaee version. My guess is we could choose to push that at the same time as the everything else as well. I think we'd need xbean and geronimo connector publishing first. I'm happy to volunteer to do the release work, if that's any help. Jon On Aug 26, 2011 7:15 AM, Shawn Jiang genspr...@gmail.com wrote: Anyway, let's start to do this and figure how rough the trunk is step by step. the first step would be to clean the snapshot depencencies up: xbeanVersion3.8-SNAPSHOT/xbeanVersion org.apache.openwebbeans.version1.1.1-SNAPSHOT/org.apache.openwebbeans.version geronimo.connector.version3.1.1-SNAPSHOT/geronimo.connector.version There are also some internal compoents that are using different version then 4.0.0-SNAPSHOT. javaee-api.version6.0-SNAPSHOT/javaee-api.version some samples in trunk are using 1.1-SNAPSHOT, But I can find part of them are still 1.0-SNAPSHOT. I'm not sure what's the pratice to release javaee-api and samples when they don't share the same version with trunk. On Fri, Aug 26, 2011 at 1:58 PM, David Blevins david.blev...@gmail.com wrote: I suspect that even if we get started now, it will still be a few weeks before we see anything. It's been over a year on trunk with no release. It's going to be rough. Best case scenario, we get two releases out before October. Worst case scenario, we wait too long to start and don't get any. -David On Aug 25, 2011, at 10:49 PM, Shawn Jiang wrote: Don't know if geronimo can wait until javaone. We could release a openejb m1/beta1, and then release a m2/beta2 for javaone. On Fri, Aug 26, 2011 at 12:21 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: maybe we should wait just before javaone? - Romain 2011/8/26 Shawn Jiang genspr...@gmail.com Geronimo is going to make a beta release. Let's discuss a openejb trunk release again. On Tue, Jul 12, 2011 at 9:00 AM, David Blevins david.blev...@gmail.com wrote: Would be excellent if we could get a beta ready before this presentation on the 25th: http://www.oscon.com/oscon2011/public/schedule/detail/20105 Might be kind of tight, but ideally there would be at least something there for people to download and play with. -David -- Shawn -- Shawn -- Shawn
Re: Pruning OpenEJB project and co
I agree with the proposals in this thread. It would be great to see more work on the Jetty integration, but as there's a lot of work going on with TomEE so I have no problem with it going to the sandbox. I'm not sure where the spring module is at, but I think people are using it, so maybe that should stay where it is. Jon On Thu, Aug 25, 2011 at 6:27 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: +1 to split all is not directly involved in openejb/tomee in sandbox modules (spring, jetty, ...) - Romain 2011/8/25 Jean-Louis MONTEIRO jeano...@gmail.com David Blevins-2 wrote: We want to trim or retire these from trunk: - container/openejb-activemq4 - server/openejb-axis2 - server/openejb-webadmin Probably we can also get rid of: - server/openejb-corba - server/openejb-telnet +1 David Blevins-2 wrote: Geronimo does use 'server/openejb-axis' so it would need to exist somewhere. Here or Geronimo basically. Also +1 David Blevins-2 wrote: On the note of duplicate utils, the only copying I'm aware of is in the openejb-client jar and that is intentional to keep that jar independent and the client classpath small. Has there been other copying? Il was the case also for activemq-4 Another suggestion would be to better use ou sandbox area to store unterminated modules like: jetty, spring, junit or so Last would be to move deps sub module outside openejb3 to give them a different life cycle (ie. deliver deps without openejb). would be great to do that and to push a new snapshot. It would be also nice to push a milestone may be. Jean-Louis -- View this message in context: http://openejb.979440.n4.nabble.com/Pruning-OpenEJB-project-and-co-tp3686410p3768534.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Arquillian
Hi all, Just to let you know I committed some more Arquillian support into the sandbox area. There's now three modes of operation: 1. Remote (you have to have TomEE running) 2. Fully embedded (no need for a war file or anything like that) 3. Slightly less embeddded - this uses Arquillian/Shrinkwrap's Maven resolver to find a copy of openejb.war. I think a couple of the tests don't work in Maven, and you'll need an up to date build of trunk for it to work. Other than that, it hopefully works ok. Please shout if you see any problems. Jon
Re: Arquillian
David just pointed out to me on IRC that you'll need some artifacts from the JBoss repository. Here's the relevant profile section from my ~/.m2/settings.xml: profile idjboss-public-repository/id repositories repository idjboss-public-repository-group/id nameJBoss Public Maven Repository Group/name urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url layoutdefault/layout releases enabledtrue/enabled updatePolicynever/updatePolicy /releases snapshots enabledtrue/enabled updatePolicynever/updatePolicy /snapshots /repository /repositories pluginRepositories pluginRepository idjboss-public-repository-group/id nameJBoss Public Maven Repository Group/name urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url layoutdefault/layout releases enabledtrue/enabled updatePolicynever/updatePolicy /releases snapshots enabledtrue/enabled updatePolicynever/updatePolicy /snapshots /pluginRepository /pluginRepositories /profile We should probably include this in the pom.xml for the adaptor. Jon On Fri, Aug 19, 2011 at 7:54 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Hi all, Just to let you know I committed some more Arquillian support into the sandbox area. There's now three modes of operation: 1. Remote (you have to have TomEE running) 2. Fully embedded (no need for a war file or anything like that) 3. Slightly less embeddded - this uses Arquillian/Shrinkwrap's Maven resolver to find a copy of openejb.war. I think a couple of the tests don't work in Maven, and you'll need an up to date build of trunk for it to work. Other than that, it hopefully works ok. Please shout if you see any problems. Jon
Build failure
We've got a build failure on buildbot: http://ci.apache.org/builders/openejb-trunk-deploy/builds/46/steps/deploy/logs/stdio My guess is something is up with the changes to the javaee-api embedded stuff - the error is a missing artifact: org.apache.openejb:javaee-api:jar:embedded:6.0-SNAPSHOT. Anyone got any ideas? Jon
Re: Arquillian
That's great. Thanks Ranga! Jon On Fri, Aug 19, 2011 at 9:40 PM, Ranga S sra...@yahoo.com wrote: I updated the repositories in the MovieFun Example pom.xml to include the Jboss repo and it builds fine for me. repositories repository idapache-m2-snapshot/id nameApache Snapshot Repository/name urlhttp://repository.apache.org/snapshots/url /repository repository idjboss/id nameJboss Repository/name urlhttps://repository.jboss.org/nexus/content/groups/public /url /repository /repositories - Ranga From: Jonathan Gallimore jonathan.gallim...@gmail.com To: dev@openejb.apache.org Sent: Friday, August 19, 2011 1:12 PM Subject: Re: Arquillian David just pointed out to me on IRC that you'll need some artifacts from the JBoss repository. Here's the relevant profile section from my ~/.m2/settings.xml: profile idjboss-public-repository/id repositories repository idjboss-public-repository-group/id nameJBoss Public Maven Repository Group/name urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url layoutdefault/layout releases enabledtrue/enabled updatePolicynever/updatePolicy /releases snapshots enabledtrue/enabled updatePolicynever/updatePolicy /snapshots /repository /repositories pluginRepositories pluginRepository idjboss-public-repository-group/id nameJBoss Public Maven Repository Group/name urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url layoutdefault/layout releases enabledtrue/enabled updatePolicynever/updatePolicy /releases snapshots enabledtrue/enabled updatePolicynever/updatePolicy /snapshots /pluginRepository /pluginRepositories /profile We should probably include this in the pom.xml for the adaptor. Jon On Fri, Aug 19, 2011 at 7:54 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Hi all, Just to let you know I committed some more Arquillian support into the sandbox area. There's now three modes of operation: 1. Remote (you have to have TomEE running) 2. Fully embedded (no need for a war file or anything like that) 3. Slightly less embeddded - this uses Arquillian/Shrinkwrap's Maven resolver to find a copy of openejb.war. I think a couple of the tests don't work in Maven, and you'll need an up to date build of trunk for it to work. Other than that, it hopefully works ok. Please shout if you see any problems. Jon
Re: Build failure
Hi Romain, It works on my machine with a clean m2 repo. I guess there's some issue with buildbot. Anyone know if that's on maven 2 or 3? Jon On Aug 19, 2011 10:23 PM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Try with m3 Jon Le 19 août 2011 22:21, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : We've got a build failure on buildbot: http://ci.apache.org/builders/openejb-trunk-deploy/builds/46/steps/deploy/logs/stdio My guess is something is up with the changes to the javaee-api embedded stuff - the error is a missing artifact: org.apache.openejb:javaee-api:jar:embedded:6.0-SNAPSHOT. Anyone got any ideas? Jon
Re: CDI Failures (svn commit: r1152756)
On Wed, Aug 17, 2011 at 8:55 AM, David Blevins david.blev...@gmail.comwrote: Mentioned this on IRC, but here is where our CDI failures started. Tracked this down via cycling through OWB and OpenEJB commits one at a time. So if it was an OWB commit that cause the failure it would have shown up in that build. #!/bin/bash r=$1 a=$2 (mkdir $r cd $r svn co -r $r http://svn.apache.org/repos/asf/openwebbeans/trunkopenwebbeans svn co -r $r http://svn.apache.org/repos/asf/openejb/trunk/openejb3 for n in openwebbeans openejb3; do (cd $n mvn -o clean install -Dmaven.test.skip=true -DfailIfNoTests=false | tee build.log) done (cd openejb3/tck/cdi-tomee mvn -o clean install) } | tee build-$r-$a.log Here are the results: build-1150849-dblevins.log:Tests run: 774, Failures: 553, Errors: 0, Skipped: 0, Time elapsed: 1,127.015 sec FAILURE! build-1150892-dblevins.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 598.361 sec build-1150906-struberg.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 596.573 sec build-1150911-struberg.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 593.837 sec build-1150931-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 594.85 sec build-1150934-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 609.096 sec build-1150947-struberg.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 603.514 sec build-1150953-struberg.log:Tests run: 789, Failures: 7, Errors: 0, Skipped: 52, Time elapsed: 1,174.83 sec FAILURE! build-1151006-jlmonteiro.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 596.265 sec build-1151008-jlmonteiro.log:Tests run: 774, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 604.61 sec FAILURE! build-1151011-jlmonteiro.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 593.912 sec build-1151137-struberg.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 585.591 sec build-1151330-genspring.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 599.099 sec build-1151522-genspring.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 580.763 sec build-1151586-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 574.463 sec build-1151645-struberg.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 574.062 sec build-1151772-struberg.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 599.954 sec build-1151773-struberg.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 625.777 sec build-1152071-genspring.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 605.217 sec build-1152606-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 615.444 sec build-1152629-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 604.744 sec build-1152703-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 589.082 sec build-1152704-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 604.731 sec build-1152705-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 596.312 sec build-1152712-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 590.136 sec build-1152715-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 599.099 sec build-1152746-rmannibucau.log:Tests run: 774, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 622.18 sec build-1152756-rmannibucau.log:Tests run: 774, Failures: 48, Errors: 0, Skipped: 0, Time elapsed: 603.075 sec FAILURE! build-1152758-rmannibucau.log:Tests run: 774, Failures: 48, Errors: 0, Skipped: 0, Time elapsed: 565.456 sec FAILURE! Not sure when the failures went from 48 to 109. Currently using my machines to track down the source of the connector failures on the Java EE TCK side. I was looking at those connector failures that last night as well - using more or less the same technique you mention. I haven't yet pinned it down to a single commit, but will carry on later today. Jon
Re: hibernate?
I agree. Using hibernate seems to be a popular configuration so I think a Maven profile, or even something that could download hibernate and include it in TomEE (link in the OpenEJB web dashboard?) or some other means of making it easier to use these JPA providers would be great. Jon On Fri, Jul 29, 2011 at 8:13 PM, Jacek Laskowski ja...@japila.pl wrote: +1 On Fri, Jul 29, 2011 at 9:35 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote: Hi, As you may know a lot of people (i'm in these people ;)) use hibernate instead of openjpa for different reasons. As we deliver an Apache product we can't activate hibernate. However we can put a profile with hibernate into our pom if we dont' activate it on Apache platform isn't it? What i would like to do: - add a profile in openejb-core for openjpa - by default - add a profile in openejb-core for hibernate - activate on hibernate system property - ...if someone want eclipselink we can do the same etc... What is important if we do it is to use the system property because it will allow us to activate transitive profile from maven (yes!). Any thought? - Romain -- Jacek Laskowski Java EE, functional languages and IBM WebSphere - http://blog.japila.pl Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
Re: Investigation integration points with Cloud Foundry (.org) ?
I don't know much about CloudFoundry, but I'd love to see this working. If you're interested in working on it that would be great, I don't have a lot of experience with this sort of thing, but I'd be keen to help out if I can. Jon On Fri, Jul 29, 2011 at 9:55 AM, Bakalsky, Krum krum.bakal...@sap.comwrote: Hi Jacek, guys, Basically, CloudFoundry tries to be as generic as possible, when it comes to integrating runtimes and frameworks. Adopters are heavily contributing integration with different platforms and languages, so I thought about OpenEJB in this context. Currently, you can use only Tomcat as a Java framework (a contribution of Virgo integration is on the way). I suppose that maybe at some moment of time, running a classical JavaSE application on CF should be introduced as well, since the CF platform looks quite flexible and extensible. So, for the moment, a possible OpenEJB integration point, would be to provision the OpenEJB+Tomcat integration on CF. I think that this won't be difficult at all, but I haven't played with it yet. I suppose the from OpenEJB side nothing has to be particularly done about it. Currently Tomcat is provisioned on CF by unzipping its archive, and running shell scripts for starting/stopping the Catalina. There is a recognition step as well, which is pretty simple and aims to determine the app type by taking a look at the file system structure of the application. An 'OpenEJB' application could be defined by searching for \META-INF\ejb-jar.xml, for instance. At the staging step, a fresh new Tomcat instance could be provisioned, and the OpenEJB framework injected as well (according to the OpenEJB+Tomcat integration details, that I am not familiar with). When running simple JavaSE apps is supported by CF, no Tomcat should be needed. TomEE could be brought up in the cloud as well. I cannot myself evaluate whether this would be worth doing, and whether people will be happy to use it, but it would definitely be the first clouded EJB and clouded Java EE 6 web profile offering (speaking of open source, of course). And this sounds awesome to me :) Kindest Regards, Krum. -Original Message- From: Jacek Laskowski [mailto:ja...@japila.pl] Sent: Friday, July 29, 2011 10:02 AM To: dev@openejb.apache.org Subject: Re: Investigation integration points with Cloud Foundry (.org) ? On Thu, Jul 28, 2011 at 12:28 PM, Bakalsky, Krum krum.bakal...@sap.com wrote: I was wondering whether investigating CloudFoundry integration would sound worth taking a look ? I am just giving the idea and am curious about what you think. Basically, we could think of adding support for provisioning Tomcat+OpenEJB or even the whole TomEE server on CloudFoundry, as a framework on the Java runtime, speaking in terms of CF terminology. Hi Krum, I'm only sligtly aware of CF's existence and haven't tried it out yet. What would it take to provision openejb modules from it? Should we take any special steps to make it happen? Jacek -- Jacek Laskowski Java EE, functional languages and IBM WebSphere - http://blog.japila.pl Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
Re: [ANN][INVITATION] - Apache OpenEJB G+ Hangout
I wasn't going to admit to it, but so did I. I just happened to be messing around with my phone when Mohammed's 30 minutes to go e-mail arrived! Looking forward to seeing you guys on the next hangout! Jon On Fri, Jul 22, 2011 at 5:57 PM, Marius Kruger ama...@gmail.com wrote: On 22 July 2011 10:25, Jean-Louis MONTEIRO jeano...@gmail.com wrote: Arf, I'm so sory, I was available yesterday evening but was sure it will happen today. Sorry for not joining but I read Friday mid night whereas it was Friday 00:00. I suffered the same fate, oops. -- Marius
Re: [ANN][INVITATION] - Apache OpenEJB G+ Hangout
I'm on his profile, but there's no hangout button :S I'll keep trying. Jon On Thu, Jul 21, 2011 at 11:10 PM, Karan Malhi karan.ma...@gmail.com wrote: jump onto plus.google.com and click on the hangout button on Mohammad's profile On Thu, Jul 21, 2011 at 6:07 PM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: I can't see it - help! On Thu, Jul 21, 2011 at 11:06 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Yes - We are there already :) come and jump in On Fri, Jul 22, 2011 at 12:04 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Is it on yet? On Thu, Jul 21, 2011 at 10:37 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: less than 30 mins for the hangout ;) On Thu, Jul 21, 2011 at 1:50 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi all... Apache OpenEJB's 1st G+ Hangout will be held at [1]. For people voted on poll [2], *please* prepare your computers and test it with G+ Hangout before the time of the meeting. Looking forward seeing you all there ;). *NOTE*: For any other people who are interested to attend the Hangout and they didn't vote but the date and time are OK with them, please send me a reply on *this* thread to add you in invitation when the Hangout starts. [1] - http://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEJB+G%2B+Hangoutiso=20110722T00p1=53 [2] - http://markmail.org/message/ngv7sbtgxi7dalbq -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship Stay hungry, stay foolish. - Steve Jobs -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship Stay hungry, stay foolish. - Steve Jobs -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship Stay hungry, stay foolish. - Steve Jobs -- Karan Singh Malhi twitter.com/KaranSinghMalhi
Re: [POLL] - OpenEJB G+ Hangout
I'm likely to be away at the weekend, but if you decide to move the hangout I'll do my best to join. Jon On Tue, Jul 19, 2011 at 9:52 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote: For it should be OK on Friday (00:00 AM Paris TMZ). Otherwise, it's possible on Sunday same hour. But I will be out all the weekend until Sunday evening. Jean-Louis 2011/7/19 Mohammad Nour El-Din nour.moham...@gmail.com Hi Daniel (and all)... That would be the weekend, and I didn't want to spoil it for others :D, my wife is used to me having calls in the weekend, if thats OK for all/most of us I will change the timeanddate event and send an invitation for the G+ Hangout. Comments ? On Tue, Jul 19, 2011 at 8:25 AM, dsh daniel.hais...@googlemail.com wrote: So how about moving the meeting to Saturday or Sunday (similar time)? On Tue, Jul 19, 2011 at 8:09 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote: Hey Karan (and all), that's more or less the same for me. I have another meeting on Friday evening so I should not be available. But, if the hour remains the same (00:00 AM for me), may be I can join when arriving at home. Jean-Louis 2011/7/19 Karan Malhi karan.ma...@gmail.com Hate to be the spoiler here, but 3 hours before would not be possible for me. On Mon, Jul 18, 2011 at 9:51 PM, David Blevins david.blev...@gmail.com wrote: 3 hours before works for me too. On Jul 18, 2011, at 1:25 PM, Jonathan Gallimore wrote: I'm pretty flexible, time-wise. I won't be able to join during working hours 9-5.30 GMT but can do any evening and most weekends. The hangout looks like its at 11pm for me - 3 hours before that as Jacek suggested is also fine for me. Jon On Mon, Jul 18, 2011 at 6:45 PM, David Blevins david.blev...@gmail.com wrote: FYI, I can do that time, but will not be able to stay long (half hour tops). Hopefully will have a little more time after this month. -David On Jul 18, 2011, at 6:34 AM, Mohammad Nour El-Din wrote: Hi all... You should revive an e-mail from Doodle with a poll for the proposed date and time for the OpenEJB G+ Hangout. Would you please vote ASAP. Also if anyone is missing or didn't receive that e-mail, please notify me ASAP. NOTE: 1- The e-mails SHOULD be with this subject *Doodle: OpenEJB G+ Hangout DateTime Update* 2- If there are any comments on the proposed date and time please reply on this thread with new proposals. Thanks in advance :). -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship Stay hungry, stay foolish. - Steve Jobs -- Karan Singh Malhi twitter.com/KaranSinghMalhi -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship Stay hungry, stay foolish. - Steve Jobs
Re: [POLL] - OpenEJB G+ Hangout
I'm pretty flexible, time-wise. I won't be able to join during working hours 9-5.30 GMT but can do any evening and most weekends. The hangout looks like its at 11pm for me - 3 hours before that as Jacek suggested is also fine for me. Jon On Mon, Jul 18, 2011 at 6:45 PM, David Blevins david.blev...@gmail.comwrote: FYI, I can do that time, but will not be able to stay long (half hour tops). Hopefully will have a little more time after this month. -David On Jul 18, 2011, at 6:34 AM, Mohammad Nour El-Din wrote: Hi all... You should revive an e-mail from Doodle with a poll for the proposed date and time for the OpenEJB G+ Hangout. Would you please vote ASAP. Also if anyone is missing or didn't receive that e-mail, please notify me ASAP. NOTE: 1- The e-mails SHOULD be with this subject *Doodle: OpenEJB G+ Hangout DateTime Update* 2- If there are any comments on the proposed date and time please reply on this thread with new proposals. Thanks in advance :). -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship Stay hungry, stay foolish. - Steve Jobs
Re: TomEE cdi
I agree - it makes sense to strip these apps out. Would be great to separately distribute the ejb-examples app and perhaps the moviefun app as WAR files as well. Jon On Wed, Jul 13, 2011 at 7:48 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: lol, i thought it this morning, +1 to remove useless things - Romain 2011/7/13 David Blevins david.blev...@gmail.com On Jul 13, 2011, at 10:48 AM, Karan Malhi wrote: Currently TomEE ships with docs, examples, ejb-examples etc. For CDI TCK, I do not see the need to bundle all these webapps with TomEE. Should we create a separate TomEE bundle for CDI TCK with all these goodies removed? Would it be a separate new project? We delete them for the TCK as well. We could potentially remove them for TomEE in general. Provided we can make some other easier way to run the examples. -David
Re: [jira] [Commented] (OPENEJB-1618) Seem to be caching proxies in JNDI
No problem, go ahead and revert it and I'll take another look at it. Sorry if its caused any hassle. I'll see if I can run the relevant geronimo tests when I try and fix it. Jon On 2 Jul 2011 06:48, Shawn Jiang (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/OPENEJB-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058985#comment-13058985] Shawn Jiang commented on OPENEJB-1618: -- Hi Jonathan, This commit brought lots of ejb regressions on geronimo tck. One of the errors I can see is: Error in Main: java.lang.ClassFormatError: Illegal class name Lorg/apache/openejb/core/ivm/IntraVmProxy; in class file x/xxx/xxx/xxx/xxManagedBean$LocalBeanProxy. Because geronimo is in a tight schedule, I'm going to revert it for now if no objection. ASF #1141732 Thu Jun 30 21:42:27 UTC 2011 jgallimore OPENEJB-1618 don't cache anything that implements IntraVmProxy, make no-interface proxies implement IntraVmProxy as well Files Changed MODIFY /openejb/trunk/openejb3/container/openejb-core/src/test/java/org/apache/openejb/util/proxy/LocalBeanProxyGeneratorImplTest.java MODIFY /openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/core/ivm/naming/IvmContext.java MODIFY /openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyGeneratorImpl.java Seem to be caching proxies in JNDI -- Key: OPENEJB-1618 URL: https://issues.apache.org/jira/browse/OPENEJB-1618 Project: OpenEJB Issue Type: Bug Components: container system Reporter: Jonathan Gallimore Assignee: Jonathan Gallimore Priority: Minor There seems to be a case where a proxy can be cached in IvmContext instead of the reference. This can cause instances that have had an @Remove method called to be returned from a JNDI lookup without a create method being called. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (OPENEJB-1618) Seem to be caching proxies in JNDI
Thanks Shawn. I would be good to get the IvmContext change back in but leave the LocalBeanProxyGenerator change out. I'll try some Geronimo TCK tests here this morning and see how that does. Jon On Sat, Jul 2, 2011 at 9:20 AM, Shawn Jiang genspr...@gmail.com wrote: Thank you for your quick response. Just reverted it with #1142169 On Sat, Jul 2, 2011 at 3:35 PM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: No problem, go ahead and revert it and I'll take another look at it. Sorry if its caused any hassle. I'll see if I can run the relevant geronimo tests when I try and fix it. Jon On 2 Jul 2011 06:48, Shawn Jiang (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/OPENEJB-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058985#comment-13058985 ] Shawn Jiang commented on OPENEJB-1618: -- Hi Jonathan, This commit brought lots of ejb regressions on geronimo tck. One of the errors I can see is: Error in Main: java.lang.ClassFormatError: Illegal class name Lorg/apache/openejb/core/ivm/IntraVmProxy; in class file x/xxx/xxx/xxx/xxManagedBean$LocalBeanProxy. Because geronimo is in a tight schedule, I'm going to revert it for now if no objection. ASF #1141732 Thu Jun 30 21:42:27 UTC 2011 jgallimore OPENEJB-1618 don't cache anything that implements IntraVmProxy, make no-interface proxies implement IntraVmProxy as well Files Changed MODIFY /openejb/trunk/openejb3/container/openejb-core/src/test/java/org/apache/openejb/util/proxy/LocalBeanProxyGeneratorImplTest.java MODIFY /openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/core/ivm/naming/IvmContext.java MODIFY /openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyGeneratorImpl.java Seem to be caching proxies in JNDI -- Key: OPENEJB-1618 URL: https://issues.apache.org/jira/browse/OPENEJB-1618 Project: OpenEJB Issue Type: Bug Components: container system Reporter: Jonathan Gallimore Assignee: Jonathan Gallimore Priority: Minor There seems to be a case where a proxy can be cached in IvmContext instead of the reference. This can cause instances that have had an @Remove method called to be returned from a JNDI lookup without a create method being called. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira -- Shawn
Re: [jira] [Commented] (OPENEJB-1618) Seem to be caching proxies in JNDI
Hi Shawn, I committed this again (r1142239) - the Geronimo TCK test seemed to work for me. Please feel free to revert it if it does cause any problems. Regards Jon On Sat, Jul 2, 2011 at 10:08 AM, Shawn Jiang genspr...@gmail.com wrote: I send a mail on the regression to geronimo tck list, please check that when you have a chance to run geornimo tck against your changes. On Sat, Jul 2, 2011 at 4:55 PM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Thanks Shawn. I would be good to get the IvmContext change back in but leave the LocalBeanProxyGenerator change out. I'll try some Geronimo TCK tests here this morning and see how that does. Jon On Sat, Jul 2, 2011 at 9:20 AM, Shawn Jiang genspr...@gmail.com wrote: Thank you for your quick response. Just reverted it with #1142169 On Sat, Jul 2, 2011 at 3:35 PM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: No problem, go ahead and revert it and I'll take another look at it. Sorry if its caused any hassle. I'll see if I can run the relevant geronimo tests when I try and fix it. Jon On 2 Jul 2011 06:48, Shawn Jiang (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/OPENEJB-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058985#comment-13058985 ] Shawn Jiang commented on OPENEJB-1618: -- Hi Jonathan, This commit brought lots of ejb regressions on geronimo tck. One of the errors I can see is: Error in Main: java.lang.ClassFormatError: Illegal class name Lorg/apache/openejb/core/ivm/IntraVmProxy; in class file x/xxx/xxx/xxx/xxManagedBean$LocalBeanProxy. Because geronimo is in a tight schedule, I'm going to revert it for now if no objection. ASF #1141732 Thu Jun 30 21:42:27 UTC 2011 jgallimore OPENEJB-1618 don't cache anything that implements IntraVmProxy, make no-interface proxies implement IntraVmProxy as well Files Changed MODIFY /openejb/trunk/openejb3/container/openejb-core/src/test/java/org/apache/openejb/util/proxy/LocalBeanProxyGeneratorImplTest.java MODIFY /openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/core/ivm/naming/IvmContext.java MODIFY /openejb/trunk/openejb3/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyGeneratorImpl.java Seem to be caching proxies in JNDI -- Key: OPENEJB-1618 URL: https://issues.apache.org/jira/browse/OPENEJB-1618 Project: OpenEJB Issue Type: Bug Components: container system Reporter: Jonathan Gallimore Assignee: Jonathan Gallimore Priority: Minor There seems to be a case where a proxy can be cached in IvmContext instead of the reference. This can cause instances that have had an @Remove method called to be returned from a JNDI lookup without a create method being called. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira -- Shawn -- Shawn
Re: Arquillian adaptor for TomEE
Hi Vishwa
Thanks for checking out the adaptor, it would be great to take it further.
Hopefully I'll be able to do some more work on it myself next week. We can
definitely add the JBoss repo to the POM (I think I have it in my
settings.xml).
In terms of the dependencies, I've tried to keep them to a minimum, but the
examples I've seen, profiles are added to the POM to add the arquillian and
container dependencies. Then you can switch which container you're testing
with by using a different Maven profile.
I think it would be useful to setup an example in the sandbox along with the
adaptor (Moviefun perhaps) which uses the TomEE Arquillian adaptor and maybe
something like Selenium to run some tests.
Jon
On Sat, Jun 25, 2011 at 11:40 PM, stratwine tovishwan...@gmail.com wrote:
Hi Jon,
I was just thinking of starting with writing CDI examples and was wondering
how write tests. Got reminded of this adaptor. Been having fun, playing
around with this.. :)
These are a few things that I observed,
The example test is now failing with http://tinypaste.com/af837d
http://tinypaste.com/af837d in the snapshot version of Arquillian. On
changing it to 1.0.0.Alpha5 version it works fine.
Had to include the jboss-repo to the pom to get the Arquillian artifacts..
Looks like they haven't got it published in maven central yet.
repository
idjboss-public-repository-group/id
nameJBoss Public Maven Repository Group/name
urlhttps://repository.jboss.org/nexus/content/groups/public-jboss//url
layoutdefault/layout
releases
enabledtrue/enabled
updatePolicynever/updatePolicy
/releases
snapshots
enabledtrue/enabled
updatePolicynever/updatePolicy
/snapshots
/repository
And one doubt.. How would we run Arquillian tests using this adaptor.. ? By
adding this as a dependency in whichever project we write tests ?
I tried it this way.. and got a error on annotating the class with
@RunWith(Arquillian.class) with Arquillian.class not in classpath.
Commented out the test scope to have the tests running
dependency
groupIdorg.jboss.arquillian/groupId
artifactIdarquillian-junit/artifactId
version${version.arquillian}/version
/dependency
Will play around more with the adaptor..
-Vishwa
--
View this message in context:
http://openejb.979440.n4.nabble.com/Arquillian-adaptor-for-TomEE-tp3541150p3625145.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: java.lang.RuntimePermission setContextClassLoader if using java.security
No problem. I've been able to reproduce it - just using the security policy you provided with our simple-stateless example was enough. I don't have a fix yet, but I'll post back when I've debugged it a bit further. Cheers Jon On Thu, Jun 16, 2011 at 8:16 AM, mclu m...@markuslutum.de wrote: Thx Jonathan! Plz tell me at least if you can reproduce it or not. I can also try to create a small example zip if needed. I invested again a lot of hours and debug into jdk and openejb sources but I could not find the problem. Greets Markus Lutum -- View this message in context: http://openejb.979440.n4.nabble.com/java-lang-RuntimePermission-setContextClassLoader-if-using-java-security-tp3599454p3601707.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: java.lang.RuntimePermission setContextClassLoader if using java.security
Hi,
Thanks for posting. I'm not sure what's going on here. Sounds like a general
issue rather than anything specific to the Tomcat integration.
I'll give your sample a try this afternoon and let you know what I find.
Jon
On 15 Jun 2011 15:04, mclu m...@markuslutum.de wrote:
I have already postet to users list but now I thing its a general problem.
If you read my other post ignore the tomcat embedded stuff.
I have a main class that starts openejb via LocalInitialContextFactory and
looks up a local bean.
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
org.apache.openejb.client.LocalInitialContextFactory);
properties.setProperty(openejb.configuration,
openejbBaseDir+\\conf\\openejb.xml);
properties.setProperty(openejb.home, openejbBaseDir);
InitialContext localContext = new InitialContext(properties);
UserService test2 = (UserService)
localContext.lookup(UserServiceBeanLocal);
If I start this class with:
java OpenEJBStarter it works.
If I add a java.security file (policy.all) with:
grant {
permission java.security.AllPermission;
};
and starts with
java -Djava.security.manager
-Djava.security.policy=E:\pointTo\policy.all
-Djava.security.debug=access,failure OpenEJBStarter
I get a PermissionException. Check out the security.debug output:
access: access allowed (javax.security.jacc.EJBMethodPermission
UserServiceBean create,LocalHome,)
access: access denied (java.lang.RuntimePermission setContextClassLoader)
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1206)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:313)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.Thread.setContextClassLoader(Thread.java:1351)
at org.apache.openejb.core.ThreadContext.exit(ThreadContext.java:70)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
at
org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:284)
at
org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:169)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:282)
at $Proxy21.create(Unknown Source)
at
org.apache.openejb.core.ivm.naming.BusinessLocalReference.getObject(BusinessLocalReference.java:33)
at
org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:171)
at
org.apache.openejb.core.ivm.naming.ContextWrapper.lookup(ContextWrapper.java:115)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at com.nedap.openejb.OpenEJBStarter.startIt(OpenEJBStarter.java:73)
at com.nedap.openejb.OpenEJBStarter.main(OpenEJBStarter.java:32)
What is wrong here? Or is it a bug?
--
View this message in context:
http://openejb.979440.n4.nabble.com/java-lang-RuntimePermission-setContextClassLoader-if-using-java-security-tp3599454p3599454.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Connector 1.6 support
Hi All, I've been working on providing support for connector 1.6 modules. I've just committed a patch which moves us onto the latest geronimo connector, and also scrapes the new connector annotations and merges them into the JAXB tree. Most of the changes are in AnnotationDeployer, with a few tweaks where the Geronimo connector API has changed slightly. I'm pretty new to the connector stuff, so I've followed the examples in the connector tests to work out what I need to pass in. Hopefully its doing the right thing. There's still some validation stuff I want to add in to AnnotationDeployer, and I want to expand on the tests as well. It seems to work for the tests I've tried. If anyone has any feedback it would be gratefully received! Thanks Jon
Re: Road Map
Hi Hao, Alper and Ranga! Welcome! That all sounds good to me. Longer term I think it would be good to start work on a Jetty equivalent of TomEE as well. I'd definitely love to see some more work on the Arquillian side of things, I think it would be a great way to get involved with the project. I mentioned in a previous post that I've committed an adapter that boots an instance of TomEE embedded and deploys the app under test as well. Its not had much in the way of testing, so any usage and feedback would be most welcome. Moving the itests over to using Arquillian is a great idea. The adaptor is checked into the sandbox area: http://svn.apache.org/repos/asf/openejb/trunk/sandbox/arquillian-tomee/ I had a few thoughts on improving things with the adaptor: I think we need to improve the deployment mechanism - currently we drop the artifact to deploy in the webapps folder and poll a custom EJB to see when the app has been deployed. Nothing wrong with that, but I think it makes tests take longer to run than they need to. The sample test with source code currently takes about 17s on my machine with everything all downloaded and ready to go. When I saw the Arquillian demos at JAX London there was quite a focus on the speed tests run, and indeed OpenEJB seemed to compare very well with Glashfish embedded for pure EJB tests. The quicker we can get TomEE booted and the app deployed the better I think. I imagine switching to use the Deployer EJB might be better for this (does it block until deployment is complete?). It would be good if the interface for this was moved to a different module so we don't need to have openejb-core and its dependencies on the classpath to deploy an app. An alternative might be some kind of way to accept a ShrinkWrap archive directly in OpenEJB / TomEE - don't know how that might work, but might be an idea. A remote adapter would be useful as well - the other Arquillian adapters do that by having the remote adapter as a whole different adapter. We could add a switch to the current adapter to change between embedded and remote modes, or could have a separate module for the remote adaptor. The latter would probably be better so users can change what they are testing against by changing the Maven profile they are using. I did wonder whether we should get in touch with the JBoss guys regarding Arquillian I think it might be good to get it on their radar. Any thoughts? Jon On Sun, Jun 5, 2011 at 2:10 AM, David Blevins david.blev...@gmail.comwrote: Sent a note out to the LA JavaUsers Group about two weeks ago to see if anyone wanted to get together to do some hacking. Got three responses and we all got together today to give them an intro to the project and technology (hello Hao, Alper and Ranga!) So when asking myself what does the project need, here are some things that came to mind in no particular order. Servlet/EE Examples CDI Examples Bean Validation Examples Embedded TomEE Arquilian adapter Standalone TomEE Arquillian adapter Servlet EE Tests CDI/TCK/TomEE Harness BeanVal/TomEE harness BeanVal/Embedded harness Document Examples Overall I was thinking at this point we really need to flush out the CDI/BeanVal stuff from a TCK perspective. Add examples for those things. Get some more complete Arquillian support for TomEE and beef up the examples there as well, plus migrate some of our iTests over. And of course, get Web Profile Certified. That's hard to do unless you're a committer with an NDA, so the Arquillian set of tests seems critical for making it so more people can help in that regard. Thoughts? -David
Re: Arquillian adaptor for TomEE
Thanks! I quite like the way it runs embedded. I've tried to make it require as little as possible in the classpath, so currently the catalina jar is needed, but OpenEJB is picked up by deploying the openejb.war file. The first commit was a bit hacky, as it tried to pick up the openejb.war from the classpath, the idea being that you could just chuck the war on your classpath, and it would be picked up automatically. It doesn't seem to play nicely with Maven though, so although it worked on my machine at the time, it didn't when I tranferred everything over to my new work machine. Now, by default it looks for the war file on the file system, and Maven could be used to download it. I feel this could be better still though, with the adapter perhaps doing a download automatically if the war file isn't available rather than relying on the build system to provide it - the idea is to skip the build and test against as many containers as possible without the developer having to do too much extra work. I was thinking of perhaps making the Arquillian developers aware of this adapter - any thoughts or objections to that? Maybe they would have some thoughts or suggestions? Jon On Fri, May 27, 2011 at 7:32 PM, David Blevins david.blev...@gmail.comwrote: On May 21, 2011, at 1:36 PM, Jonathan Gallimore wrote: I hacked up a quick Arquillian adaptor for TomEE which I'm using for a project at work. Its a bit raw, but I've checked it into the sandbox area. If you fancy checking it out, any feedback would be welcome! Cool, looks like it boots TomEE embedded! Looks pretty good to me. What is raw about it? -David
Re: Idea: Maven Archetypes for OpenEJB
Hi Aldrin, I wrote a couple of Maven Archetypes a while back - one is for a simple ejb-jar and the other is a multi module ear project, with OpenEJB mixed in to do testing. They were based on some generic J2EE archetypes that were around at the time - not sure if they still are or not. I also committed an Arquillian adapter for our Tomcat integration (known as Apache TomEE) and it should also work for Tomcat 7 on its own as well. If you fancy taking a look at either of those, any feedback or improvements you have for either will be gratefully received! I'd love to see these taken further. This is all in our sandbox area here: Maven Archetypes: https://svn.apache.org/repos/asf/openejb/trunk/sandbox/openejb-maven-archetypes/ Arquillian Adapter: https://svn.apache.org/repos/asf/openejb/trunk/sandbox/arquillian-tomee/ In terms of answering your specific points: - Which kind of situations you've often found into, which could be mapped into archetypes? Generally the two mentioned above, the simple jar, and the full ear. I think an archetype for a web profile .war with ejbs mixed in that runs on TomEE would be great as well. - Which kind of persistence frameworks do you often use? OpenJPA which the default, but Hibernate is really popular as well. We also support EclipseLink, so it might be catering for that too. - Beside the choice of persistence, which other aspects would you like to be able to tune from an archetype? Not really given that one much thought to be honest. Running OpenEJB embedded in a unit test, most things are configurable using properties in the test itself. I'd be interested to see what suggestions others might have. - Which special spices would you like to get, beyond testing? I mean, to be able to turn into a full geronimo deployable artifact, or another container, using Archillian with OpenEJB wrapped inside, or simply being able to tweak properties easily? I'd definitely love to see things being more testable with TomEE, which is why did some work on the TomEE Arquillian adapter. Currently TomEE's config in that adapter is very hardcoded, being able to tweak any of that including the system properties would be a real bonus. Jon On Mon, May 23, 2011 at 8:32 AM, Aldrin Leal ald...@leal.eng.br wrote: Here is something I've been thinking about two days ago, and pinged about on twitter do dblevins. However, I'd like your feedback. I love using OpenEJB. Not only I write articles on it, I simply use it as an embedded container. Given its ease of use, I figure it would be a great idea to supply OpenEJB users with a set of M3 Archetypes for quickstart, ranging from a simple, fully embedded jar for primary development, as well as a full multimodule project envolving persistence, remoting, ejbs and ears. I am taking this opportunity to study and learn it, based from trunk. Meanwhile, here is what I need your advice: - Which kind of situations you've often found into, which could be mapped into archetypes? - Which kind of persistence frameworks do you often use? - Beside the choice of persistence, which other aspects would you like to be able to tune from an archetype? - Which special spices would you like to get, beyond testing? I mean, to be able to turn into a full geronimo deployable artifact, or another container, using Archillian with OpenEJB wrapped inside, or simply being able to tweak properties easily? Your comments are welcome. Thank you :) -- -- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/
Re: [VOTE] Shawn Jiang as committer
+1 Jon
Re: [VOTE] Romain Manni-Bucau as committer
+1 Jon
Re: Idea: Maven Archetypes for OpenEJB
They've been there for a pretty long time. It looks like they should work, and basically run the OpenEJB standalone server. I personally haven't used them, but it would be great to see them being used as well. Jon On Mon, May 23, 2011 at 9:17 AM, Aldrin Leal ald...@leal.eng.br wrote: Thank you. I just noticed there were already some archetypes. After that, I noticed the sandboxes also had some OpenEJB Mojos. Any opinions about it as well? Thank you -- -- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/ On Mon, May 23, 2011 at 5:15 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Hi Aldrin, I wrote a couple of Maven Archetypes a while back - one is for a simple ejb-jar and the other is a multi module ear project, with OpenEJB mixed in to do testing. They were based on some generic J2EE archetypes that were around at the time - not sure if they still are or not. I also committed an Arquillian adapter for our Tomcat integration (known as Apache TomEE) and it should also work for Tomcat 7 on its own as well. If you fancy taking a look at either of those, any feedback or improvements you have for either will be gratefully received! I'd love to see these taken further. This is all in our sandbox area here: Maven Archetypes: https://svn.apache.org/repos/asf/openejb/trunk/sandbox/openejb-maven-archetypes/ Arquillian Adapter: https://svn.apache.org/repos/asf/openejb/trunk/sandbox/arquillian-tomee/ In terms of answering your specific points: - Which kind of situations you've often found into, which could be mapped into archetypes? Generally the two mentioned above, the simple jar, and the full ear. I think an archetype for a web profile .war with ejbs mixed in that runs on TomEE would be great as well. - Which kind of persistence frameworks do you often use? OpenJPA which the default, but Hibernate is really popular as well. We also support EclipseLink, so it might be catering for that too. - Beside the choice of persistence, which other aspects would you like to be able to tune from an archetype? Not really given that one much thought to be honest. Running OpenEJB embedded in a unit test, most things are configurable using properties in the test itself. I'd be interested to see what suggestions others might have. - Which special spices would you like to get, beyond testing? I mean, to be able to turn into a full geronimo deployable artifact, or another container, using Archillian with OpenEJB wrapped inside, or simply being able to tweak properties easily? I'd definitely love to see things being more testable with TomEE, which is why did some work on the TomEE Arquillian adapter. Currently TomEE's config in that adapter is very hardcoded, being able to tweak any of that including the system properties would be a real bonus. Jon On Mon, May 23, 2011 at 8:32 AM, Aldrin Leal ald...@leal.eng.br wrote: Here is something I've been thinking about two days ago, and pinged about on twitter do dblevins. However, I'd like your feedback. I love using OpenEJB. Not only I write articles on it, I simply use it as an embedded container. Given its ease of use, I figure it would be a great idea to supply OpenEJB users with a set of M3 Archetypes for quickstart, ranging from a simple, fully embedded jar for primary development, as well as a full multimodule project envolving persistence, remoting, ejbs and ears. I am taking this opportunity to study and learn it, based from trunk. Meanwhile, here is what I need your advice: - Which kind of situations you've often found into, which could be mapped into archetypes? - Which kind of persistence frameworks do you often use? - Beside the choice of persistence, which other aspects would you like to be able to tune from an archetype? - Which special spices would you like to get, beyond testing? I mean, to be able to turn into a full geronimo deployable artifact, or another container, using Archillian with OpenEJB wrapped inside, or simply being able to tweak properties easily? Your comments are welcome. Thank you :) -- -- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/
Re: Idea: Maven Archetypes for OpenEJB
I use them a fair bit. Its a personal preference I guess, but if I'm trying something out, I like to try my own thing with a generated POM to get me started, rather than hack about someone else's example. Examples are extremely useful though, and I've always thought the OpenEJB examples are really great. They're also a great place to start contributing to the project :) Jon On Mon, May 23, 2011 at 12:48 PM, Romain Manni-Bucau rmannibu...@gmail.comwrote: Do you really use ma en archetypes? Personaly examples are more useful. - Romain Le 23 mai 2011 10:26, Jonathan Gallimore jonathan.gallim...@gmail.com a écrit : They've been there for a pretty long time. It looks like they should work, and basically run the OpenEJB standalone server. I personally haven't used them, but it would be great to see them being used as well. Jon On Mon, May 23, 2011 at 9:17 AM, Aldrin Leal ald...@leal.eng.br wrote: Thank you. I just noticed there were already some archetypes. After that, I noticed the sandboxes also had some OpenEJB Mojos. Any opinions about it as well? Thank you -- -- Aldrin Leal, ald...@leal.eng.br / http://www.leal.eng.br/mnemetica/ On Mon, May 23, 2011 at 5:15 AM, Jonathan Gallimore jonathan.gallim...@gmail.com wrote: Hi Aldrin, I wrote a couple of Maven Archetypes a while back - one is for a simple ejb-jar and the other is a multi module ear project, with OpenEJB mixed in to do testing. They were based on some generic J2EE archetypes that were around at the time - not sure if they still are or not. I also committed an Arquillian adapter for our Tomcat integration (known as Apache TomEE) and it should also work for Tomcat 7 on its own as well. If you fancy taking a look at either of those, any feedback or improvements you have for either will be gratefully received! I'd love to see these taken further. This is all in our sandbox area here: Maven Archetypes: https://svn.apache.org/repos/asf/openejb/trunk/sandbox/openejb-maven-archetypes/ Arquillian Adapter: https://svn.apache.org/repos/asf/openejb/trunk/sandbox/arquillian-tomee/ In terms of answering your specific points: - Which kind of situations you've often found into, which could be mapped into archetypes? Generally the two mentioned above, the simple jar, and the full ear. I think an archetype for a web profile .war with ejbs mixed in that runs on TomEE would be great as well. - Which kind of persistence frameworks do you often use? OpenJPA which the default, but Hibernate is really popular as well. We also support EclipseLink, so it might be catering for that too. - Beside the choice of persistence, which other aspects would you like to be able to tune from an archetype? Not really given that one much thought to be honest. Running OpenEJB embedded in a unit test, most things are configurable using properties in the test itself. I'd be interested to see what suggestions others might have. - Which special spices would you like to get, beyond testing? I mean, to be able to turn into a full geronimo deployable artifact, or another container, using Archillian with OpenEJB wrapped inside, or simply being able to tweak properties easily? I'd definitely love to see things being more testable with TomEE, which is why did some work on the TomEE Arquillian adapter. Currently TomEE's config in that adapter is very hardcoded, being able to tweak any of that including the system properties would be a real bonus. Jon On Mon, May 23, 2011 at 8:32 AM, Aldrin Leal ald...@leal.eng.br wrote: Here is something I've been thinking about two days ago, and pinged about on twitter do dblevins. However, I'd like your feedback. I love using OpenEJB. Not only I write articles on it, I simply use it as an embedded container. Given its ease of use, I figure it would be a great idea to supply OpenEJB users with a set of M3 Archetypes for quickstart, ranging from a simple, fully embedded jar for primary development, as well as a full multimodule project envolving persistence, remoting, ejbs and ears. I am taking this opportunity to study and learn it, based from trunk. Meanwhile, here is what I need your advice: - Which kind of situations you've often found into, which could be mapped into archetypes? - Which kind of persistence frameworks do you often use? - Beside the choice of persistence, which other aspects would you like to be able to tune from an archetype? - Which special spices would you like to get, beyond testing? I mean, to be able to turn into a full geronimo deployable artifact, or another container, using Archillian with OpenEJB wrapped inside, or simply being able to tweak
Setting module IDs
Hi, I just committed a small change to allow module IDs to be set from a system property, which has been useful to ensure a JNDI env entry was mapped to the right connector module. You can add a property like this: connector-filename.rar.moduleId=moduleId I don't think it'll cause any problems, but please shout if it does. Cheers Jon
Arquillian adaptor for TomEE
Hi all, I hacked up a quick Arquillian adaptor for TomEE which I'm using for a project at work. Its a bit raw, but I've checked it into the sandbox area. If you fancy checking it out, any feedback would be welcome! Cheers Jon
UserTransaction
Hi, Just wanted to give a heads-up - I spotted that java:comp/UserTransaction wasn't being setup correctly in our Tomcat integration for Tomcat 7, so looking it up from a servlet wasn't working. I've committed a simple fix. Please shout if it gives any problems! Jon
