Re: Annotation processing
On Dec 12, 2006, at 3:14 PM, David Jencks wrote: On Dec 12, 2006, at 1:07 PM, David Blevins wrote: 4. add objects to inject resources Here's where I get confused. Add objects to inject resources into what? The confusing part is that injection is done on instances of components (servlets, ejbs). Maybe the Tomcat/Jetty integrations are a lot tighter than I thought they were. Are we actually creating servlet and filter instances themselves? Definitely not for tomcat. For jetty these are created by a ServletHolder, which is wrapped into a gbean, so we could modify the object creation code. I imagine there's some similar way to customize tomcat, but I have no idea what it might be. In any case, my goal of using verbiage sufficiently general to be difficult to argue with failed :-). I have no idea what is needed nor how to do this. Do you have any advice? :) I have to imagine that both Jetty and Tomcat already have their own code for injecting the items from JNDI using the standard names [1], so if simply had some way to tell either of them which jndi names go with which fields we'd be good to go. [1] Granted the spec doesn't require you to inject straight from JNDI, but injection was intended to be done this way when the specs were written (even SessionContext is now in JNDI) and I'd be really surprised if there was anyone out there doing it differently. I'd be interested in what Jetty and Tomcat have in this regard. -David
Re: Annotation processing
On Dec 12, 2006, at 4:20 PM, David Blevins wrote: On Dec 12, 2006, at 3:14 PM, David Jencks wrote: On Dec 12, 2006, at 1:07 PM, David Blevins wrote: 4. add objects to inject resources Here's where I get confused. Add objects to inject resources into what? The confusing part is that injection is done on instances of components (servlets, ejbs). Maybe the Tomcat/Jetty integrations are a lot tighter than I thought they were. Are we actually creating servlet and filter instances themselves? Definitely not for tomcat. For jetty these are created by a ServletHolder, which is wrapped into a gbean, so we could modify the object creation code. I imagine there's some similar way to customize tomcat, but I have no idea what it might be. In any case, my goal of using verbiage sufficiently general to be difficult to argue with failed :-). I have no idea what is needed nor how to do this. Do you have any advice? :) I have to imagine that both Jetty and Tomcat already have their own code for injecting the items from JNDI using the standard names [1], so if simply had some way to tell either of them which jndi names go with which fields we'd be good to go. [1] Granted the spec doesn't require you to inject straight from JNDI, but injection was intended to be done this way when the specs were written (even SessionContext is now in JNDI) and I'd be really surprised if there was anyone out there doing it differently. I'd be interested in what Jetty and Tomcat have in this regard. I took a quick look at Jetty and Tomcat source. Tomcat has some complete looking code for injection via JNDI, except it seems it only supports using annotations as the source of injection data, nothing for xml as the source. http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/ catalina/util/DefaultAnnotationProcessor.java?view=markup Jetty doesn't seem to have anything in this area. I looked for any references to javax.annotation and didn't find any. Greg, any thoughts on what your plans are in this area? -David
Re: Split out transaction
On Dec 12, 2006, at 6:39 PM, Matt Hogstrom wrote: I'm ok for splitting it out. I'm not sure today is the best timing. My experience is the simple things like this as your releasing software is the thing that goes belly up and causes great pain. We'll have to peel it out, test it, vote on it, etc. I'd prefer to do this after we get 1.2-beta and 2.0-m1 out the door. Sure. We can start creating the separate modules now, but we can leave 1.2-beta and 2.0-m1 using their own copies. On Dec 12, 2006, at 9:14 PM, David Blevins wrote: I monitor a bunch of lists and it looks like the Geronimo transaction library is getting pretty popular. Looks like Ofbiz, ODE, and Tuscany are now using it. That's in addition to ServiceMix, ActiveMQ, and of course OpenEJB. Interesting thing is that their all using it standalone via the Jencks.org stuff. What is stopping us from splitting this out? I say we just leave the gbeans where they are, rename the module to geronimo-transaction-gbeans, then move the rest of the code out, make a new pom and mark any deps still required with 'scopeprovided'. Are you proposing: geronimo/server/[trunk | branches/1.2] /modules/geronimo- transaction-gbeans for the server and branches and geronimo/modules/geronimo-transaction/trunk/ /tags/ /branches/ for the externalized transaction and connector modules? Right. I could take or leave the 'modules' prefix, but it's kind of nice. So for after 2.0-m1 and 1.2-beta1 we would move it out and version it as 2.0-SNAPSHOT and release as -2.0. We can move out now and mark them 2.0-SNAPSHOT. After 2.0-m1 and 1.2- beta1 we can work on getting those codelines to use the independently versioned copies and when that works, we release them as 2.0. This kind of implies that the other modules like tomcat, jetty, activemq, etc should be renamed with -gbean suffixes to be consistent. The activemq one maybe as I think that one really does only have gbeans in it, but the rest have a lot more integration code. We can use any suffix we like really, we just need an artifactId different than geronimo-transaction. In fact we maybe just want to throw the leftover gbeans into another module, like geronimo-core. But we can decide that later. -David
Re: Annotation processing
On Dec 12, 2006, at 7:53 PM, Nicholas Gallardo wrote: David, Speaking from ignorance, is the intent to have all resources injected from JNDI, or is JAX-WS the only offender that has invocation specific resources that need to be individually injected? Certainly in the ejb side of the world there are no request specific injections. Not sure about the servlet side of things. -David - Original Message From: David Blevins [EMAIL PROTECTED] To: dev@geronimo.apache.org Cc: Greg Wilkins [EMAIL PROTECTED] Sent: Tuesday, December 12, 2006 6:43:56 PM Subject: Re: Annotation processing On Dec 12, 2006, at 4:20 PM, David Blevins wrote: On Dec 12, 2006, at 3:14 PM, David Jencks wrote: On Dec 12, 2006, at 1:07 PM, David Blevins wrote: 4. add objects to inject resources Here's where I get confused. Add objects to inject resources into what? The confusing part is that injection is done on instances of components (servlets, ejbs). Maybe the Tomcat/Jetty integrations are a lot tighter than I thought they were. Are we actually creating servlet and filter instances themselves? Definitely not for tomcat. For jetty these are created by a ServletHolder, which is wrapped into a gbean, so we could modify the object creation code. I imagine there's some similar way to customize tomcat, but I have no idea what it might be. In any case, my goal of using verbiage sufficiently general to be difficult to argue with failed :-). I have no idea what is needed nor how to do this. Do you have any advice? :) I have to imagine that both Jetty and Tomcat already have their own code for injecting the items from JNDI using the standard names [1], so if simply had some way to tell either of them which jndi names go with which fields we'd be good to go. [1] Granted the spec doesn't require you to inject straight from JNDI, but injection was intended to be done this way when the specs were written (even SessionContext is now in JNDI) and I'd be really surprised if there was anyone out there doing it differently. I'd be interested in what Jetty and Tomcat have in this regard. I took a quick look at Jetty and Tomcat source. Tomcat has some complete looking code for injection via JNDI, except it seems it only supports using annotations as the source of injection data, nothing for xml as the source. http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/ catalina/util/DefaultAnnotationProcessor.java?view=markup Jetty doesn't seem to have anything in this area. I looked for any references to javax.annotation and didn't find any. Greg, any thoughts on what your plans are in this area? -David __ __ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know.
Re: Split out transaction
On Dec 12, 2006, at 8:07 PM, Kevan Miller wrote: On Dec 12, 2006, at 9:14 PM, David Blevins wrote: I monitor a bunch of lists and it looks like the Geronimo transaction library is getting pretty popular. Looks like Ofbiz, ODE, and Tuscany are now using it. That's in addition to ServiceMix, ActiveMQ, and of course OpenEJB. Interesting thing is that their all using it standalone via the Jencks.org stuff. What is stopping us from splitting this out? I say we just leave the gbeans where they are, rename the module to geronimo-transaction-gbeans, then move the rest of the code out, make a new pom and mark any deps still required with 'scopeprovided'. Then we cut a release of it that both 1.2beta and 2.0m1 can use Beyond your note, what's motivating us to split it out? ;-) That not enough? ;-) Certainly makes sense to provide a module which is not dependent on GBeans (one day we'll get rid of them altogether...). That seems to be the important part of any splitting. This can occur with or without moving transactions to be separately releasable... I certainly wouldn't advocate doing anything like this so close to a release or two... See my response to Matt. -David
Re: TranQL Artifacts are now all released
I tried to build OpenEJB 2.2 with the released tranql-1.4 and nearly all of the org.apache.openejb.deployment.entity.cmp.cmr.* test fail. Going to see if I can't find a good revision... -David On Dec 13, 2006, at 8:47 AM, Matt Hogstrom wrote: All TranQL artifacts have now been released. The final tally is: TranQL 1.4 TranQL-Connector 1.3 TranQL-Connector-ra 1.3 TranQL-Connector-Derby-* 1.2 Matt Hogstrom [EMAIL PROTECTED]
Re: RELEASE-NOTES-2.0-M1.TXT
Cool. They look great! Could you do some release notes for 1.2 beta also? -David On Dec 13, 2006, at 12:16 PM, Hernan Cunico wrote: Hi All, Here is a template for the v2.0-M1 release notes. It is not complete and really need your input, specially for the know issues and limitations section. You'll find between *!-- --* the criteria I used to list these issues (both unresolved and fixed) Here is the link: http://cwiki.apache.org/GMOxDOC20/release-notes-20-m1txt.html I will also add this file to branches/2.0-M1 and trunk too Cheers! Hernan
Re: [vote] Release Geronimo 1.2-beta
On Dec 14, 2006, at 3:00 PM, toby cabot wrote: On Thu, Dec 14, 2006 at 02:08:25PM -0800, Dain Sundstrom wrote: On Dec 14, 2006, at 1:31 PM, Paul McMahan wrote: When I tried to build from src I got the error message below. Do I need to add the repo at http://people.apache.org/~dain/stage/ to a pom somewhere to make it build? Unfortunately, yes. This release has a deep dependency list of G projects. The next 1.2 release won't have this problem. Apologies for being the one to wave to maven-naive flag, but where do I need to add this? I added this repo to the project root's pom.xml like so: Index: pom.xml === --- pom.xml (revision 487372) +++ pom.xml (working copy) @@ -980,6 +980,16 @@ pluginRepositories pluginRepository +iddains-plugin-repository/id +urlhttp://people.apache.org/~dain/stage//url +snapshots +enabledtrue/enabled +/snapshots +releases +enabledfalse/enabled Change that line to 'enabledtrue' and it should work. -David +/releases +/pluginRepository +pluginRepository idCodehaus Snapshots/id urlhttp://snapshots.repository.codehaus.org//url snapshots @@ -1235,6 +1245,21 @@ -- repository +iddains-repo/id +nameApache Snapshots Repository/name +urlhttp://people.apache.org/~dain/stage/url +layoutdefault/layout +snapshots +enabledtrue/enabled +updatePolicydaily/updatePolicy +checksumPolicyignore/checksumPolicy +/snapshots +releases +enabledtrue/enabled +/releases +/repository + +repository idapache-snapshots/id nameApache Snapshots Repository/name urlhttp://people.apache.org/repo/m2-snapshot- repository/url But I still can't build: [INFO] Geronimo Assemblies :: J2EE + Tomcat [INFO] Geronimo Assemblies :: Minimal + Tomcat [INFO] Searching repository for plugin with prefix: 'install'. [INFO] org.apache.maven.plugins: checking for updates from codehaus [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from codehaus [INFO] org.codehaus.mojo: checking for updates from central Downloading: http://repository.codehaus.org/org/apache/geronimo/ genesis/plugins/tools-maven-plugin/1.1/tools-maven-plugin-1.1.jar [WARNING] Unable to get resource from repository codehaus (http:// repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/ genesis/plugins/tools-maven-plugin/1.1/tools-maven-plugin-1.1.jar [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) [INFO] Cannot find mojo descriptor for: 'install:install-file' - Treating as non-aggregator. Downloading: http://repository.codehaus.org/org/apache/geronimo/ genesis/plugins/tools-maven-plugin/1.1/tools-maven-plugin-1.1.jar [WARNING] Unable to get resource from repository codehaus (http:// repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/ genesis/plugins/tools-maven-plugin/1.1/tools-maven-plugin-1.1.jar [WARNING] Unable to get resource from repository central (http:// repo1.maven.org/maven2) [INFO] -- -- [ERROR] BUILD ERROR [INFO] -- -- [INFO] Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Do I need to add the ~dain repository somewhere else, too? Thanks, Toby
Re: [vote] Release Geronimo 1.2-beta
Here's my +1. Nicely formatted too! ;-) -David On Dec 14, 2006, at 9:37 AM, Dain Sundstrom wrote: The 1.2-beta release and all dependencies are cut and awaiting your vote! All the files are available in a staging area in my home dir on people. http://people.apache.org/~dain/stage/org/apache/geronimo/genesis genesis-1.1-incubating http://people.apache.org/~dain/stage/org/apache/geronimo/specs geronimo-activation_1.0.2_spec-1.2 geronimo-activation_1.1_spec-1.0-M1 geronimo-annotation_1.0_spec-1.0-M1 geronimo-ejb_2.1_spec-1.1 geronimo-ejb_3.0_spec-1.0-M1 geronimo-el_1.0_spec-1.0-M1 geronimo-interceptor_3.0_spec-1.0-M1 geronimo-j2ee-connector_1.5_spec-1.1 geronimo-j2ee-deployment_1.1_spec-1.1 geronimo-j2ee-jacc_1.0_spec-1.1 geronimo-j2ee-management_1.0_spec-1.1 geronimo-j2ee-management_1.1_spec-1.0-M1 geronimo-jacc_1.1_spec-1.0-M1 geronimo-javamail_1.3.1_spec-1.2 geronimo-javamail_1.4_spec-1.0-M1 geronimo-jaxr_1.0_spec-1.1 geronimo-jaxrpc_1.1_spec-1.1 geronimo-jms_1.1_spec-1.1 geronimo-jpa_3.0_spec-1.0-M1 geronimo-jsp_2.0_spec-1.1 geronimo-jsp_2.1_spec-1.0-M1 geronimo-jta_1.0.1B_spec-1.1 geronimo-jta_1.1_spec-1.0-M1 geronimo-qname_1.1_spec-1.1 geronimo-saaj_1.1_spec-1.1 geronimo-servlet_2.4_spec-1.1 geronimo-servlet_2.5_spec-1.1-M1 geronimo-ws-metadata_2.0_spec-1.1-M1 http://people.apache.org/~dain/stage/org/apache/geronimo/javamail geronimo-javamail_1.3.1_provider-1.0 geronimo-javamail_1.3.1_mail-1.0 geronimo-javamail_1.4_provider-1.0 geronimo-javamail_1.4_mail-1.0 http://people.apache.org/~dain/1.2-beta geronimo-1.2-beta-src geronimo-framework-1.2-beta geronimo-jetty-minimal-1.2-beta geronimo-tomcat-minimal-1.2-beta geronimo-jetty-j2ee-1.2-beta geronimo-tomcat-j2ee-1.2-beta All archives contain LICENSE and NOTICE. Each binary jar is also accompanied by source, javadoc, pom and all are signed, md5-ed, and secure-hashed. Keys file available here: http://people.apache.org/dist/geronimo/KEYS Svn tags are here: http://svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-1.1 http://svn.apache.org/repos/asf/geronimo/specs/tags http://svn.apache.org/repos/asf/geronimo/javamail/tags/javamail-1.0 http://svn.apache.org/repos/asf/geronimo/server/tags/1.2.0-beta Here's my +1! -dain
Re: Annotation processing
On Dec 13, 2006, at 1:53 AM, Greg Wilkins wrote:
David Blevins wrote:
I took a quick look at Jetty and Tomcat source. Tomcat has some
complete looking code for injection via JNDI, except it seems it only
supports using annotations as the source of injection data,
nothing for
xml as the source.
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/
catalina/util/DefaultAnnotationProcessor.java?view=markup
Jetty doesn't seem to have anything in this area. I looked for any
references to javax.annotation and didn't find any. Greg, any
thoughts
on what your plans are in this area?
Jan,
any thoughts on what your plans are in this area?
...
We do plan to support this, but it is rather painful and
intrusive to do. The injecting the resources is not the problem
it is finding them that is an issue. It appears that we must
get more involved in the classloading to find which classes should
be scanned for annotations. The code I have seen for this has
hacky special cases of jar not to scan etc etc.
I made xbean-finder's ClassFinder for exactly this purpose. It uses
ASM to introspect the classes for annotations as opposed to
reflection avoiding the security issues that would associated with
loading each and every class looking for annotations.
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/src/
test/java/org/apache/xbean/finder/ClassFinderTest.java
Here's a good thread to give a quick read: http://mail-
archives.apache.org/mod_mbox/geronimo-xbean-dev/200610.mbox/%
[EMAIL PROTECTED]
With it you can search:
1. A classloader, excluding any parent classloader if you wish
2. A set of URLs (var args... so one to many)
3. A set of Classes (also var args, so one or many)
So what we hope to provide is a mechanism to inject
(this should be done shortly) and a pluggable mechanism
for discovery of annotations. We will have our own simple
implementation, but ideally the integration with geronimo would share
the scanning that would be occurring for EJB3 etc. etc.
For the injection, we use xbean-reflect, which Dain created and I've
hacked on a bit to do field and private injection.
Here's an example of how we use it to do JNDI-based injection (sans
exception handling for brevity):
ObjectRecipe objectRecipe = new ObjectRecipe(beanClass);
objectRecipe.allow(Option.FIELD_INJECTION);
objectRecipe.allow(Option.PRIVATE_PROPERTIES);
objectRecipe.allow(Option.IGNORE_MISSING_PROPERTIES);
javax.naming.Context ctx = deploymentInfo.getJndiEnc();
for (Injection injection : deploymentInfo.getInjections
()) {
String jndiName = injection.getJndiName();
Object object = ctx.lookup(java:comp/env/ +
jndiName);
objectRecipe.setProperty(injection.getName(), new
StaticRecipe(object));
}
objectRecipe.setProperty(sessionContext, new
StaticRecipe(createSessionContext()));
bean = objectRecipe.create(beanClass.getClassLoader());
Note that the objectRecipe also has methods like setFieldProperty and
setMethodProperty that allow you be more specific on where the data
should go (field vs setter). The default when using the plain
setProperty when Option.FIELD_INJECTION is enabled is to first look
for a setter then to look for a field.
-David
Re: [VOTE] 2.0-M1 Release
+1 -David On Dec 18, 2006, at 12:57 AM, Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)
On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote: Process of branching and tagging (we already have a plethora of discussion...I think this needs to get on a Wiki) - includes tags and modifications Discussion, proposal, resolution and final vote. http://cwiki.apache.org/GMOxPMGT/release-branching-process.html Granted that was June, just about time to do it all over again :) In regards to the commit to the tag, I don't have a problem with it as it was completely ineffectual in any technical sense. We could of course thump the rule book and make Matt redo 8+ hours of work and have days worth of revoting followed up by a couple weeks worth of cumulative man hours on policy discussions... or we could just say close enough and focus on 2.0-M2. -David
Re: openejb-2.2 tag is not buildable
On Dec 18, 2006, at 1:51 PM, Jason Dillon wrote: I'm trying to build the OpenEJB 2.2 release so that I can continue working on Geronimo CTS/TCK automation... but the openejb-2.2 release tag is not buildable in a clean environment: [...] I am not sure that this is a priority for many folks, but I hope that someday it will become more important in your eyes. As you know you don't need to build openejb-2.2 to do your CTS/TCK testing. You can build 1.2-beta or 2.0-m1 as Dain or Matt did when they built those releases by adding this repo to your list temporarily: http://people.apache.org/~dblevins/stage/ But you're right, tags should be buildable. As openejb depends on geronimo and geronimo depends on openejb -- it's hard. As you and David J. have mentioned, it would be possible to: 1. release geronimo modules 2. release openejb 3. release geromimo applications, configs, and assemblies. But since we don't do that and I don't think anyone is willing to propose it, someone has to release with an imperfect tag and OpenEJB is always the one to fall on that sword. It has nothing to do with it not being important, that's just the compromise we make until either 1. OpenEJB stops depending on Geronimo snapshots, 2. Geronimo stops depending on OpenEJB snapshots, or 3. Geronimo releases modules and other in serial with a wait period in the middle for the OpenEJB release. You already know that too and I'm just reiterating what we've all gone over before. My perspective is we need a bit of 1, 2 and 3. In the meantime comments like I hope that someday it will become more important in your eyes don't sit well with me. So, the here and now: It's poor form to update tags, but it's also poor form to release stuff with snapshots, so I went with (hopefully) the lesser of the two evils and updated the tag. geronimo.*: 1.2-SNAPSHOT - 1.2-beta tools-maven-plugin: 1.1-SNAPSHOT - 1.1 Fair warning, the tag will still not build due to the missing geronimo dependencies. Geronimo 1.2-beta is waiting on OpenEJB 2.2 to be released. As you also know, you can add this repo to your list temporarily to build: http://people.apache.org/~dain/stage/ Hope this helps, -David
Re: [VOTE] Release XBean 2.8
A note, please do not add headers to the following: ==package-info.java (./xbean-finder/src/test/java/org/acme/foo/ package-info.java) ==java.io.InputStream (./xbean-finder/src/test/resources/META-INF/ java.io.InputStream) ==java.io.OutputStream (./xbean-finder/src/test/resources/META-INF/ java.io.OutputStream) ==java.io.Serializable (./xbean-finder/src/test/resources/META-INF/ java.io.Serializable) ==one (./xbean-finder/src/test/resources/META-INF/externalizables/one) ==three (./xbean-finder/src/test/resources/META-INF/externalizables/ three) ==two (./xbean-finder/src/test/resources/META-INF/externalizables/two) ==bar (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/bar) ==baz (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/baz) ==foo (./xbean-finder/src/test/resources/META-INF/ java.net.URLStreamHandler/foo) ==kernel (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/kernel) ==ldap (./xbean-finder/src/test/resources/META-INF/ javax.naming.spi.ObjectFactory/ldap) ==ishtar.properties (./xbean-finder/src/test/resources/META-INF/ movies/ishtar.properties) ==kingkong.properties (./xbean-finder/src/test/resources/META-INF/ movies/kingkong.properties) ==serentity.properties (./xbean-finder/src/test/resources/META-INF/ movies/serentity.properties) ==one (./xbean-finder/src/test/resources/META-INF/serializables/one) ==three (./xbean-finder/src/test/resources/META-INF/serializables/ three) ==two (./xbean-finder/src/test/resources/META-INF/serializables/two) ==familyguy.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/familyguy.properties) ==simpsons.properties (./xbean-finder/src/test/resources/META-INF/ tvshows/simpsons.properties) -David
Re: svn commit: r487651 - /geronimo/server/trunk/pom.xml
On Dec 19, 2006, at 6:23 AM, Vamsavardhana Reddy wrote: On 12/16/06, Matt Hogstrom [EMAIL PROTECTED] wrote: On Dec 15, 2006, at 3:57 PM, Jason Dillon wrote: Yikes... what happened on this change? The diff shows a lot more changed than just what was indicated in the comment... Ya, looks like a formatting change. A diff before would help :) I too am guilty of transgressions like this. Thanks for the reminder. I check the diff on each file before checkin and eliminate all unnecessary changes (like line with spaces replacing blank lines etc.). It costs some extra time :o(, but, keeps the commit clean. I hope that my energy will last for some more time :o) I usually do as Jason suggested and check my beauty diff in first. That is if I notice the formatting is not right before I start editing :) -David
[vote] Release geronimo-annotation_1.0_spec-1.0
I've done the work to fix some of our spec jars so they are compliant and would like us to start releasing them and removing snapshot references from our builds. The first one I fixed is javax.annotation 1.0: Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-annotation_1.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
[vote] Release geronimo-jta_1.1_spec-1.0
Verified and compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-jta_1.1_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
[vote] Release geronimo-interceptor_3.0_spec-1.0
Verified and compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-interceptor_3.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
Re: [vote] Release geronimo-jpa_3.0_spec-1.0
On Dec 21, 2006, at 8:42 AM, Dain Sundstrom wrote: On Dec 21, 2006, at 6:01 AM, Matt Hogstrom wrote: I'm not sure I understand this vote. BAsed on passed precedent we generally vote on a set of binaries and not a source tree. I think Dain offered to own releasing specs so will he be producing a set of binaries to vote on? I'm willing to do spec releases, but if David has the energy and motivation, then I am more then happy for him to run with the ball :) I'm fine releasing this set. Dain can have 'em back once they're released :) -David
Re: [vote] Release geronimo-jpa_3.0_spec-1.0
On Dec 21, 2006, at 6:46 AM, Matt Hogstrom wrote: On Dec 21, 2006, at 9:21 AM, Jeff Genender wrote: I think David is treating the branch as somewhat official and is bringing the community into it...nothing wrong with a healthy vote. I suggest we head off what looks like may be turning into a bike shed thread. ;-) Not my intent. I'd like to wait for David's response. I'm assuming that this series of votes is to notify folks that a branch is ready to begin a release cycle. I'm +1 for that. Just wanted to make sure I knew what I was voting for :) Let's wait for David to clarify. It was something Roy said recently on Incubator general that enlightened. On Dec 7, 2006, at 3:39 PM, Roy T. Fielding wrote: FYI, traditionally, all release votes are for the source code package and only that package. Once the source code version is set in stone, binaries and assorted other release artifacts can be generated by individual committers without a vote if the group trusts them to do so and they have a signed key. Some groups might require a vote on binaries as well, but the ASF only requires a vote on the source. I like voting on binaries for most our stuff as our build is massively complex. But in this case I figured I'd give the do you trust me to build/publish angle a try as these are tiny little jars that aren't complicated and it's way easier to just run the maven publish command on them after the vote than it is to create a staging build for each one and figuring out a non-trivial way to publish them later. -David
Re: [vote] Release geronimo-jpa_3.0_spec-1.0
On Dec 21, 2006, at 11:08 AM, Matt Hogstrom wrote: On Dec 21, 2006, at 2:01 PM, David Blevins wrote: I'm not sure I understand this vote. BAsed on passed precedent we generally vote on a set of binaries and not a source tree. I think Dain offered to own releasing specs so will he be producing a set of binaries to vote on? I'm willing to do spec releases, but if David has the energy and motivation, then I am more then happy for him to run with the ball :) I'm fine releasing this set. Dain can have 'em back once they're released :) -David Is this a vote to start the release process or is this a vote where you'll spin up the binaries after we vote? Since we vote on binaries I expect this is notice that the process is starting. Can you clarify please? I did, but for some reason this email got to the list first despite sending it 10 minutes after my clarifying response. Oh well :) -David
Re: [vote] Release geronimo-jpa_3.0_spec-1.0
On Dec 21, 2006, at 11:38 AM, Matt Hogstrom wrote: On Dec 21, 2006, at 1:50 PM, David Blevins wrote: On Dec 21, 2006, at 6:46 AM, Matt Hogstrom wrote: It was something Roy said recently on Incubator general that enlightened. On Dec 7, 2006, at 3:39 PM, Roy T. Fielding wrote: FYI, traditionally, all release votes are for the source code package and only that package. Once the source code version is set in stone, binaries and assorted other release artifacts can be generated by individual committers without a vote if the group trusts them to do so and they have a signed key. Some groups might require a vote on binaries as well, but the ASF only requires a vote on the source. I like voting on binaries for most our stuff as our build is massively complex. But in this case I figured I'd give the do you trust me to build/publish angle a try as these are tiny little jars that aren't complicated and it's way easier to just run the maven publish command on them after the vote than it is to create a staging build for each one and figuring out a non- trivial way to publish them later. -David Thanks...this was the missing context for me. I spect I'm not the only one who doesn't hang on the incubator thread so this helps. I'm confused about Roy's comments as there are specific requirements for including legal stuff in the binaries. Sounds like he is advocating everyone building their own copy and validating it. Since this is a change in process it would be good to outline how you propose it working for the benefit of the many on the list that don't have the benefit of your thinking apart from the reference above. It's pretty simple as Guillaume mentions. You just run 'mvn release:prepare release:perform'. I would very much like to see us change the process and the specs are probably a really good place to start. I'm +1 for changing the process. I would very much like to get the new process documented so that you don't end up becoming the release dog and have everyone making up a new way each time which is currently where we are at. Me too. To be clear it's not a new process, just new to us. Pretty much we just get the branch ready to go then use the maven release plugin once the vote is complete (mvn release:prepare release:perform). Anyway, as this is different than what we're used to I'll just go ahead and do the staging thing so the vote can continue. -David
Re: [vote] Release geronimo-interceptor_3.0_spec-1.0
Binaries here: http://people.apache.org/~dblevins/stage-specs/org/apache/geronimo/ specs/geronimo-jta_1.1_spec/1.0/ On Dec 20, 2006, at 11:47 PM, David Blevins wrote: Verified and compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-interceptor_3.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
Re: [vote] Release geronimo-annotation_1.0_spec-1.0
Binaries: http://people.apache.org/~dblevins/stage-specs/org/apache/geronimo/ specs/geronimo-annotation_1.0_spec/1.0/ On Dec 20, 2006, at 10:54 PM, David Blevins wrote: I've done the work to fix some of our spec jars so they are compliant and would like us to start releasing them and removing snapshot references from our builds. The first one I fixed is javax.annotation 1.0: Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-annotation_1.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
Re: [vote] Release geronimo-jpa_3.0_spec-1.0
Binaries here: http://people.apache.org/~dblevins/stage-specs/org/apache/geronimo/ specs/geronimo-jpa_3.0_spec/1.0/ On Dec 20, 2006, at 11:55 PM, David Blevins wrote: Fixed, verified to be compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-jpa_3.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
openejb-2.2 published
Binaries are up! http://people.apache.org/repo/m2-incubating-repository/org/apache/ openejb/ -David
Re: Mino down (again), all builds hosed
Yea, it's no fun. I've been slowly getting around this by editing my /etc/hosts file to point people.apache.org at repo1.maven.org which doesn't fix much other than keeping your builds from hanging. Then i've slowly been building all the source for the SNAPSHOT deps we have with maven. All the while using the maven options '-fae - Dmaven.test.skip=true' A little brute force, but seems to be slowly moving me forward. -David On Dec 26, 2006, at 3:15 PM, Jason Dillon wrote: Looks like Minotaur is down again... which hoses all of our m2 builds. I was going to spend the rest of this year to get a good enough solution up to run the TCK for branches/1.2... but seems like the universe has other plans. :-( I think we really, really, really need to isolate ourselves from remote repo failures like this. Anyone have any ideas how to go about doing that? --jason
[result] Release geronimo-jta_1.1_spec-1.0
Vote passes with 8 +1s (7 binding) and no other votes. -David On Dec 20, 2006, at 11:40 PM, David Blevins wrote: Verified and compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-jta_1.1_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
[result] Release geronimo-interceptor_3.0_spec-1.0
Vote passes with 8 +1s (7 binding) and no other votes. -David On Dec 20, 2006, at 11:47 PM, David Blevins wrote: Verified and compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-interceptor_3.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
[result] Release geronimo-jpa_3.0_spec-1.0
Vote passes with 7 +1s (6 binding) and no other votes. -David On Dec 20, 2006, at 11:55 PM, David Blevins wrote: Fixed, verified to be compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-jpa_3.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
[result] Release geronimo-annotation_1.0_spec-1.0
Vote passes with 9 +1s (8 binding) and no other votes. -David On Dec 20, 2006, at 10:54 PM, David Blevins wrote: I've done the work to fix some of our spec jars so they are compliant and would like us to start releasing them and removing snapshot references from our builds. The first one I fixed is javax.annotation 1.0: Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-annotation_1.0_spec-1.0 I hereby propose we release this branch as final. Here's my +1 -David
[vote] Release geronimo-ejb_3.0_spec
Fixed, verified to be compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-ejb_3.0_spec/ Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-ejb_3.0_spec/1.0/ I hereby propose we release this branch and it's binaries as final. Here's my +1 -David
Re: [vote] Release geronimo-ejb_3.0_spec
Hey All, back and catching up. As I mentioned in the first specs vote that I proposed I've done the work to fix some of our spec jars so they are compliant and would like us to start releasing them and removing snapshot references from our builds. I've since started abbreviating that to Fixed, verified to be compliant and ready for release as the changes the changes are pretty much N iterations of added/removed/updated a (or many) constructor/method/annotation. Anyway, I was half inclined to put links to the related commits in the vote threads as the diffs are the only real way to describe several API tweaks, but just didn't pull the trigger on that idea. Wish I had. Here's that info now: Changes to Annotations 1.0 http://svn.apache.org/viewvc?view=revrevision=489255 Changes to EJB 3.0 http://svn.apache.org/viewvc?view=revrev=489258 Changes to EJB 3.0 Persistence (JPA) http://svn.apache.org/viewvc?view=revrevision=489260 EJB 3.0 Interceptors and JTA 1.1 were fine hence the description of Verified and compliant and ready for release in their release threads. I haven't yet had the chance to verify any other specs for compliance. Happy New Year! -David
Re: [vote] Release geronimo-ejb_3.0_spec
On Jan 2, 2007, at 3:21 PM, David Jencks wrote: On Jan 2, 2007, at 5:19 PM, David Blevins wrote: Hey All, back and catching up. As I mentioned in the first specs vote that I proposed I've done the work to fix some of our spec jars so they are compliant and would like us to start releasing them and removing snapshot references from our builds. I've since started abbreviating that to Fixed, verified to be compliant and ready for release as the changes the changes are pretty much N iterations of added/removed/ updated a (or many) constructor/method/annotation. Anyway, I was half inclined to put links to the related commits in the vote threads as the diffs are the only real way to describe several API tweaks, but just didn't pull the trigger on that idea. Wish I had. Here's that info now: Changes to Annotations 1.0 http://svn.apache.org/viewvc?view=revrevision=489255 Changes to EJB 3.0 http://svn.apache.org/viewvc?view=revrev=489258 Changes to EJB 3.0 Persistence (JPA) http://svn.apache.org/viewvc?view=revrevision=489260 EJB 3.0 Interceptors and JTA 1.1 were fine hence the description of Verified and compliant and ready for release in their release threads. I haven't yet had the chance to verify any other specs for compliance. The jacc-1.1 spec has a significant amount of functionality in the permission classes so it needs more than just signature verification before we release it. Definitely. -David
Re: [vote] Release geronimo-ejb_3.0_spec
We have 6 +1 votes, but it'd be really nice to have more. Please vote! :) Going to close this out tomorrow. -David On Dec 28, 2006, at 1:29 PM, David Blevins wrote: Fixed, verified to be compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-ejb_3.0_spec/ Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-ejb_3.0_spec/1.0/ I hereby propose we release this branch and it's binaries as final. Here's my +1 -David
Re: [vote] Release geronimo-ejb_3.0_spec
On Jan 3, 2007, at 3:12 PM, Matt Hogstrom wrote: +1 ... sorry for the delay. Already counted you with your I'm ok with the vote proceeding as is...+1 comment. -David On Jan 3, 2007, at 2:28 PM, David Blevins wrote: We have 6 +1 votes, but it'd be really nice to have more. Please vote! :) Going to close this out tomorrow. -David On Dec 28, 2006, at 1:29 PM, David Blevins wrote: Fixed, verified to be compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-ejb_3.0_spec/ Built Binaries: http://people.apache.org/~dblevins/stage-specs/ org/apache/geronimo/specs/geronimo-ejb_3.0_spec/1.0/ I hereby propose we release this branch and it's binaries as final. Here's my +1 -David Matt Hogstrom [EMAIL PROTECTED]
Re: Annotation processing
On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote: Hi David, thanks for kicking off this discussion and I agree with most of your steps below. However, since it seems that annotations are now pervasive in many of the JSR specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably even more that I personally haven't uncovered) it seems like a concise set of responsibilities for all these annotation-specific JSRs might mitigate some confusion and hopefully prevent overlap and/or conflicts (i.e., who is going to do what). So for example, I'm responsible for the Geronimo JEE5 Deployment JSR (88) and I'm making these three assumptions below: 1 -- The current Geronimo JSR-88 implementation will be enhanced (by me) to provide a metadata-complete XML deployment descriptor, which is essentially what you've described below in steps 1-3. 2 -- The work associated with assumption #1 should encompass as many of the impacted JSRs as possible on the Geronimo side from a deployment perspective to minimize the number of folks making similar changes to the Geronimo builders/deployers. Thus, these JSRs should be encompassed by the JSR-88 implementation for Geronimo: -- JSR 77 (JEE5 management--this JSR in particular has already been mentioned as a candidate by Paul and Chris and I agree with them) -- JSR 88 (Deployment) -- JSR 175 (Java annotations) -- JSR 181 (Web Services metadata) -- JSR 250 (Common annotations) 3 -- Your step number 4 below (add objects to inject resources) feels like a duplicate of your step 3 (deploy from the modified xml descriptor...) but again will/should be implemented under the auspices of JSR-88. So, if that seems reasonable then I would still have a couple questions: 1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a separate and distinct deployment implementation for annotations in OpenEJB ?? I'm guessing yes based on the OPENEJB-216 JIRA and all its subtasks but just would again like some validation so as to better understand the implications if any from a Geronimo responsibility perspective. 2 -- Are there any other JSRs impacted by annotations for JEE5 compliance ?? Well, that's certainly an interesting idea. There are 149 annotations in all of Java EE 5 [1] and only 10 of them are generic JSR 250 annotations -- and most specs don't use those. Are you sure consolidating all of them into one task is a good idea? You'd be looking at months of work just to catch up to where most projects already are. If this is truly just about getting meta-data complete descriptors, there's really no work for ejbs anyway as there'll be a metadata- complete ejb-jar.xml in the GBeans we produce from deployment which is the way the current integration satisfies the JSR-88 requirement. Thoughts? -David [1] Made a list for you http://cwiki.apache.org/GMOxDEV/java-ee-5- annotations.html
[result] Release geronimo-ejb_3.0_spec
Vote passes with 6 +1s (5 binding) and no other votes. -David On Dec 28, 2006, at 1:29 PM, David Blevins wrote: Fixed, verified to be compliant and ready for release. Release Branch: https://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-ejb_3.0_spec/ Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-ejb_3.0_spec/1.0/ I hereby propose we release this branch and it's binaries as final. Here's my +1 -David
Re: Annotation processing
On Jan 4, 2007, at 12:22 PM, Tim McConnell wrote: Hi David, your definitive list of JEE5 annotations is wonderful-- I've been looking all over the place trying to locate the authoritative source. Where/how did you find them ?? Grepped all the spec jars and compared that against the TCK for accuracy and to fill in any missing. -David David Blevins wrote: On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote: Hi David, thanks for kicking off this discussion and I agree with most of your steps below. However, since it seems that annotations are now pervasive in many of the JSR specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably even more that I personally haven't uncovered) it seems like a concise set of responsibilities for all these annotation-specific JSRs might mitigate some confusion and hopefully prevent overlap and/or conflicts (i.e., who is going to do what). So for example, I'm responsible for the Geronimo JEE5 Deployment JSR (88) and I'm making these three assumptions below: 1 -- The current Geronimo JSR-88 implementation will be enhanced (by me) to provide a metadata-complete XML deployment descriptor, which is essentially what you've described below in steps 1-3. 2 -- The work associated with assumption #1 should encompass as many of the impacted JSRs as possible on the Geronimo side from a deployment perspective to minimize the number of folks making similar changes to the Geronimo builders/deployers. Thus, these JSRs should be encompassed by the JSR-88 implementation for Geronimo: -- JSR 77 (JEE5 management--this JSR in particular has already been mentioned as a candidate by Paul and Chris and I agree with them) -- JSR 88(Deployment) -- JSR 175 (Java annotations) -- JSR 181(Web Services metadata) -- JSR 250 (Common annotations) 3 -- Your step number 4 below (add objects to inject resources) feels like a duplicate of your step 3 (deploy from the modified xml descriptor...) but again will/should be implemented under the auspices of JSR-88. So, if that seems reasonable then I would still have a couple questions: 1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a separate and distinct deployment implementation for annotations in OpenEJB ?? I'm guessing yes based on the OPENEJB-216 JIRA and all its subtasks but just would again like some validation so as to better understand the implications if any from a Geronimo responsibility perspective. 2 -- Are there any other JSRs impacted by annotations for JEE5 compliance ?? Well, that's certainly an interesting idea. There are 149 annotations in all of Java EE 5 [1] and only 10 of them are generic JSR 250 annotations -- and most specs don't use those. Are you sure consolidating all of them into one task is a good idea? You'd be looking at months of work just to catch up to where most projects already are. If this is truly just about getting meta-data complete descriptors, there's really no work for ejbs anyway as there'll be a metadata-complete ejb-jar.xml in the GBeans we produce from deployment which is the way the current integration satisfies the JSR-88 requirement. Thoughts? -David [1] Made a list for you http://cwiki.apache.org/GMOxDEV/java-ee-5- annotations.html -- Thanks, Tim McConnell
Re: Help needed on http methods and regular expressions
On Jan 4, 2007, at 1:27 PM, David Jencks wrote:
Chris Cardona has been trying to test the jacc 1.1 extended http-
method support by deploying slide (GERONIMO-1747) and I don't know
enough about regular expressions to see where the problem is.
The http 1.1 spec says:
(5.1.1) extension-method = token
(2.2)
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
I think this means a hyphen is allowed in an extension-method.
It means hypen is not allowed. I.e. ascii 0-127 is allowed except
0-31,32,34,40,41,44,47,58,59,60,61,62,63,64,91,92,93,123,125
-David
The web-app 2.5 schema says:
xsd:simpleType name=http-methodType
xsd:annotation
xsd:documentation
A HTTP method type as defined in HTTP 1.1 section 2.2.
/xsd:documentation
/xsd:annotation
xsd:restriction base=xsd:token
xsd:pattern value=[\p{L}-[\p{Cc}\p{Z}]]+/
/xsd:restriction
/xsd:simpleType
I have roughly no clue what that means.
Xmlbeans is complaining:
cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not
match patter
n for http-methodType in namespace http://java.sun.com/xml/ns/
javaee, error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not match
pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
I see 3 possiblilites:
1. I'm wrong and http 1.1 spec does not allow hyphens in extension
methods
2. sun is wrong and the regexp in http-methodType means something
other than the definition in the http 1.1 spec
3. xmlbeans is wrong and is not interpreting the regexp in the
schema correctly.
Anyone have a clue?
Help!
thanks
david jencks
Re: Annotation processing
On Jan 4, 2007, at 3:13 PM, Tim McConnell wrote: Now that's very interesting, I've been using the Annotation Type Hierarchy from http://java.sun.com/javaee/5/docs/api/overview- tree.html but your list appears to be more accurate. Seems like they're missing these two: javax.xml.ws.addressing.Action javax.xml.ws.addressing.FaultAction Strange -David David Blevins wrote: On Jan 4, 2007, at 12:22 PM, Tim McConnell wrote: Hi David, your definitive list of JEE5 annotations is wonderful-- I've been looking all over the place trying to locate the authoritative source. Where/how did you find them ?? Grepped all the spec jars and compared that against the TCK for accuracy and to fill in any missing. -David David Blevins wrote: On Jan 2, 2007, at 7:57 PM, Tim McConnell wrote: Hi David, thanks for kicking off this discussion and I agree with most of your steps below. However, since it seems that annotations are now pervasive in many of the JSR specifications (i.e., JSRs 77, 88, 175, 181, 220, 250 and probably even more that I personally haven't uncovered) it seems like a concise set of responsibilities for all these annotation-specific JSRs might mitigate some confusion and hopefully prevent overlap and/or conflicts (i.e., who is going to do what). So for example, I'm responsible for the Geronimo JEE5 Deployment JSR (88) and I'm making these three assumptions below: 1 -- The current Geronimo JSR-88 implementation will be enhanced (by me) to provide a metadata-complete XML deployment descriptor, which is essentially what you've described below in steps 1-3. 2 -- The work associated with assumption #1 should encompass as many of the impacted JSRs as possible on the Geronimo side from a deployment perspective to minimize the number of folks making similar changes to the Geronimo builders/ deployers. Thus, these JSRs should be encompassed by the JSR-88 implementation for Geronimo: -- JSR 77 (JEE5 management--this JSR in particular has already been mentioned as a candidate by Paul and Chris and I agree with them) -- JSR 88(Deployment) -- JSR 175 (Java annotations) -- JSR 181(Web Services metadata) -- JSR 250 (Common annotations) 3 -- Your step number 4 below (add objects to inject resources) feels like a duplicate of your step 3 (deploy from the modified xml descriptor...) but again will/should be implemented under the auspices of JSR-88. So, if that seems reasonable then I would still have a couple questions: 1 -- Since JSR 220 (EJB) is impacted by annotations, will there be a separate and distinct deployment implementation for annotations in OpenEJB ?? I'm guessing yes based on the OPENEJB-216 JIRA and all its subtasks but just would again like some validation so as to better understand the implications if any from a Geronimo responsibility perspective. 2 -- Are there any other JSRs impacted by annotations for JEE5 compliance ?? Well, that's certainly an interesting idea. There are 149 annotations in all of Java EE 5 [1] and only 10 of them are generic JSR 250 annotations -- and most specs don't use those. Are you sure consolidating all of them into one task is a good idea? You'd be looking at months of work just to catch up to where most projects already are. If this is truly just about getting meta-data complete descriptors, there's really no work for ejbs anyway as there'll be a metadata-complete ejb-jar.xml in the GBeans we produce from deployment which is the way the current integration satisfies the JSR-88 requirement. Thoughts? -David [1] Made a list for you http://cwiki.apache.org/GMOxDEV/java- ee-5-annotations.html --Thanks, Tim McConnell -- Thanks, Tim McConnell
Re: Help needed on http methods and regular expressions
On Jan 4, 2007, at 7:35 PM, David Jencks wrote:
On Jan 4, 2007, at 6:12 PM, David Blevins wrote:
On Jan 4, 2007, at 1:27 PM, David Jencks wrote:
Chris Cardona has been trying to test the jacc 1.1 extended http-
method support by deploying slide (GERONIMO-1747) and I don't
know enough about regular expressions to see where the problem is.
The http 1.1 spec says:
(5.1.1) extension-method = token
(2.2)
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
I think this means a hyphen is allowed in an extension-method.
It means hypen is not allowed. I.e. ascii 0-127 is allowed except
0-31,32,34,40,41,44,47,58,59,60,61,62,63,64,91,92,93,123,125
I'm kinda confused here. According to http://www.asciitable.com/
hyphen is 45 which is not in your list of exclusions, not a control
character, and I might be blind but I don't see it in the http spec
list of separators. Why exactly is hyphen not allowed?
Whoop. My bad. Now I'm just as confused as you.
-David
thanks
david jencks
-David
The web-app 2.5 schema says:
xsd:simpleType name=http-methodType
xsd:annotation
xsd:documentation
A HTTP method type as defined in HTTP 1.1 section 2.2.
/xsd:documentation
/xsd:annotation
xsd:restriction base=xsd:token
xsd:pattern value=[\p{L}-[\p{Cc}\p{Z}]]+/
/xsd:restriction
/xsd:simpleType
I have roughly no clue what that means.
Xmlbeans is complaining:
cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not
match patter
n for http-methodType in namespace http://java.sun.com/xml/ns/
javaee, error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not
match pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
I see 3 possiblilites:
1. I'm wrong and http 1.1 spec does not allow hyphens in
extension methods
2. sun is wrong and the regexp in http-methodType means something
other than the definition in the http 1.1 spec
3. xmlbeans is wrong and is not interpreting the regexp in the
schema correctly.
Anyone have a clue?
Help!
thanks
david jencks
Re: possible 1.2 problem
On Jan 5, 2007, at 4:31 PM, David Jencks wrote: I fixed GERONIMO-2686 in 1.2 but have not been able to figure out what if any openejb2 version is supposed to go with it. If the openejb2 version exists and is not 2.3 (trunk) the changes may have broken the openejb2 build. See rev 493187 in openejb2 Hopefully this will refresh your memory. Dec 14 15:18:21 dblevins you can do anything you want to the interfaces as long as you keep them compatible in 1.2 and 2.0m2 Dec 14 15:18:34 dblevins 1.2 isn't frozen Dec 14 15:18:48 dblevins it's just been released as a beta Dec 14 15:20:29 djencks ok Dec 14 15:20:37 dblevins so to reiterate, you can make any change you want to 2.3 as long is you make it work in 1.2 and 2.0-m1 Dec 14 15:20:42 dblevins err m2 Dec 14 15:20:47 djencks ok Dec 14 15:20:52 dblevins and this is only temporary Dec 14 15:20:54 djencks I think I can live with that Dec 14 15:20:59 dblevins like 2-3 weeks tops Dec 14 15:21:05 djencks we hope :-) Dec 14 15:21:12 dblevins :) Dec 14 15:21:18 djencks OK, thanks Dec 14 15:21:27 dblevins thanks david! http://www.uwyn.com/drone/log/bevinbot/geronimo/20061214 -David
Re: openejb3 and web services
On Jan 9, 2007, at 7:28 AM, David Jencks wrote: On Jan 9, 2007, at 10:19 AM, Jarek Gawor wrote: Hi, I'm looking into integrating CXF with OpenEJB (OpenEJB3 specifically as that's the version that supposed to be integrated in M2). I see that OpenEJB2 has a bunch of code for web services support that's based on Axis1. However, I do not see such code for OpenEJB3. So I'm wondering what that means exactly as we still need support for JAX-RPC-based web services in 2.0. Perhaps the code hasn't been ported over yet or I'm just not finding the right code? Can someone please clarify? I think no one has looked at porting the code yet, but I could be wrong. I hope that whatever we come up with for openejb3 can work with axis1, cxf, and axis2, but I don't yet have an idea if this is practical. Right, it's not ported yet. -David
Re: openejb3 and web services
On Jan 9, 2007, at 8:44 PM, Jarek Gawor wrote: On 1/9/07, David Blevins [EMAIL PROTECTED] wrote: On Jan 9, 2007, at 7:28 AM, David Jencks wrote: On Jan 9, 2007, at 10:19 AM, Jarek Gawor wrote: Hi, I'm looking into integrating CXF with OpenEJB (OpenEJB3 specifically as that's the version that supposed to be integrated in M2). I see that OpenEJB2 has a bunch of code for web services support that's based on Axis1. However, I do not see such code for OpenEJB3. So I'm wondering what that means exactly as we still need support for JAX-RPC-based web services in 2.0. Perhaps the code hasn't been ported over yet or I'm just not finding the right code? Can someone please clarify? I think no one has looked at porting the code yet, but I could be wrong. I hope that whatever we come up with for openejb3 can work with axis1, cxf, and axis2, but I don't yet have an idea if this is practical. Right, it's not ported yet. Do you think this will be ported over before M2? We're most likely looking at M3 for that. -David
Re: jpa and annotation specs in 2.0
Yep. We now have final versions of these: geronimo-annotation_1.0_spec-1.0 geronimo-ejb_3.0_spec-1.0 geronimo-interceptor_3.0_spec-1.0 geronimo-jpa_3.0_spec-1.0 geronimo-jta_1.1_spec-1.0 -David On Jan 11, 2007, at 11:53 AM, Jason Dillon wrote: Same with geronimo-jta_1.1_spec Also, looks like some of these specs are listed twice in the dependencyManagement section... :-( --jason On Jan 11, 2007, at 2:49 PM, Jason Dillon wrote: Are these two specs sorted? Can we switch to using the released 1.0 for them? server/trunk is still using: dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jpa_3.0_spec/artifactId version1.0-SNAPSHOT/version /dependency dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-annotation_1.0_spec/artifactId version1.0-SNAPSHOT/version /dependency --jason
Re: Use JTA 1.1?
On Jan 11, 2007, at 4:55 PM, Jason Dillon wrote: Should we be using the jta 1.1 spec? Everywhere in server/trunk is configured to use 1.0.1B right now. It appears that when using 1.1 the server will compile and startup fine... though none of that really uses transactions. Anyone know if any problems will show up if we switch to the JTA 1.1 spec? Or maybe there is a little work (hopefully not a lot) that needs to be done in G to sync up the codebase for 1.1? Should be fine. There's just an additional interface in JTA 1.1. -David
Re: Use JTA 1.1?
On Jan 11, 2007, at 5:51 PM, Jason Dillon wrote: Do you (or anyone else) know why we have a geronimo-transaction and geronimo-transaction-jta11 module? Why do we need 2 modules for this? We don't anymore, but we did/do for 1.2.x as we can't certify on J2EE 1.4 with the jta 1.1 library in the path. -David --jason On Jan 11, 2007, at 8:34 PM, David Blevins wrote: On Jan 11, 2007, at 4:55 PM, Jason Dillon wrote: Should we be using the jta 1.1 spec? Everywhere in server/trunk is configured to use 1.0.1B right now. It appears that when using 1.1 the server will compile and startup fine... though none of that really uses transactions. Anyone know if any problems will show up if we switch to the JTA 1.1 spec? Or maybe there is a little work (hopefully not a lot) that needs to be done in G to sync up the codebase for 1.1? Should be fine. There's just an additional interface in JTA 1.1. -David
Fwd: [all] jarfiles in svn
So I don't forget, some commons projects need JDK 1.3 compiled versions of some of our J2EE 1.4 specs, so at some when I get a spare cycle I plan to build and put those up for a vote. -David Begin forwarded message: From: David Blevins [EMAIL PROTECTED] Date: January 10, 2007 11:27:41 AM PST To: Jakarta Commons Developers List commons-dev@jakarta.apache.org Subject: Re: [all] jarfiles in svn Reply-To: Jakarta Commons Developers List commons- [EMAIL PROTECTED] On Jan 10, 2007, at 2:39 AM, Joerg Heinicke wrote: David Blevins david.blevins at visi.com writes: Only passively reading the thread, but from some of the comments and your commit message it looks like you just need JDK 1.3 compiled versions of those specs. Yes, that's it. Cool. I'd be happy to apply your pom changes in the geronimo tree and put newly built versions up for a vote. That would be fine. But please review my pom changes. I'm not a Maven expert, but only googled for compiling for target JDK and found different approaches. Though this approach works for me there might be cases where it does not or simply better ones. It looks good, I'll give it a try. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: M2 Status - branch on Wednesday ?
On Jan 15, 2007, at 7:07 AM, Matt Hogstrom wrote: Based on the previous discussions about releases it looks like were about ready to branch for M2. Release notes are coming together and lots of other improvements to M2 have been added. I think the big thing we need to flush out is the EJB 3.0 integration at its current level. We can certainly flush out what we have at its current level. That level would be 'does not run any apps of any kind', is that cool? ;-p We agreed to an extremely aggressive date (2.0-M2) because it's just so much better to get the EJB 3 stuff in M2 to give it a really big attraction, but it's extremely extremely extremely tight. But we'll get there or die trying. Sometimes you have to take one for the team and do whatever it takes to make that happen. Being the eternal optimist I'm expecting that Dain's EJB 3.0 integration will be flawless :) and that we can branch for M2 this Wednesday. It'll be quite flawed, we're going for minimally function. High priorities are: 1. Basic invocations 2. JNDI references to the ejb 3. JNDI references from the ejb 4. Transaction support If were really lucky(er) priorities: - Security integration Not going to happen: - Web Services Integration - Corba integration In this list we're still fighting with priority #1 as to get there requires the most upfront work in deployment etc. Working from a timetable of hours counting down to zero, this nut should crack soon but hasn't cracked yet so can't say exactly which hour. We'll do a bit of fit and finish that we need to do so we'll spin a release up for review by Thursday with the next milestone out by the end of January. Any thoughts? What are your thoughts? -David
Re: M2 Status - branch on Wednesday ?
On Jan 15, 2007, at 5:17 PM, David Blevins wrote: On Jan 15, 2007, at 7:07 AM, Matt Hogstrom wrote: Based on the previous discussions about releases it looks like were about ready to branch for M2. Release notes are coming together and lots of other improvements to M2 have been added. I think the big thing we need to flush out is the EJB 3.0 integration at its current level. We can certainly flush out what we have at its current level. That level would be 'does not run any apps of any kind', is that cool? ;-p We agreed to an extremely aggressive date (2.0-M2) because it's just so much better to get the EJB 3 stuff in M2 to give it a really big attraction, but it's extremely extremely extremely tight. But we'll get there or die trying. Sometimes you have to take one for the team and do whatever it takes to make that happen. Just to add to my note If we can pull this off, I expect beers, cheering, and a chorus of For he's a jolly good fellow :) -David Being the eternal optimist I'm expecting that Dain's EJB 3.0 integration will be flawless :) and that we can branch for M2 this Wednesday. It'll be quite flawed, we're going for minimally function. High priorities are: 1. Basic invocations 2. JNDI references to the ejb 3. JNDI references from the ejb 4. Transaction support If were really lucky(er) priorities: - Security integration Not going to happen: - Web Services Integration - Corba integration In this list we're still fighting with priority #1 as to get there requires the most upfront work in deployment etc. Working from a timetable of hours counting down to zero, this nut should crack soon but hasn't cracked yet so can't say exactly which hour. We'll do a bit of fit and finish that we need to do so we'll spin a release up for review by Thursday with the next milestone out by the end of January. Any thoughts? What are your thoughts? -David
Re: geronimo-openejb is downloading 1.2-beta jars
On Jan 18, 2007, at 9:29 AM, anita kulshreshtha wrote: I looked at openejb3 pom at https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3 It is using 1.2-beta for all the geronimo jars! Right, that's actually ok, we just need some excludes in the geronimo- openejb* poms. We can add these later when we have a couple hours to get them right. -David Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: This is the output of building geronimo-openejb geronimo rev 497488: . ... Downloading: http://repo1.maven.org/maven2/org/springframework/spring/2.0/ spring-2.0.pom 12K downloaded Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ geronimo/s pecs/geronimo-ejb_3.0_spec/1.0-M1/geronimo-ejb_3.0_spec-1.0-M1.pom [WARNING] Unable to get resource from repository apache-incubator (http://people.apache.or g/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/apache/geronimo/specs/geronimo- ejb_3.0_spe c/1.0-M1/geronimo-ejb_3.0_spec-1.0-M1.pom [WARNING] Unable to get resource from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo- ejb_3.0_spec /1.0-M1/geronimo-ejb_3.0_spec-1.0-M1.pom 1K downloaded Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ geronimo/m odules/geronimo-security/1.2-beta/geronimo-security-1.2-beta.pom [WARNING] Unable to get resource from repository apache-incubator (http://people.apache.or g/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/apache/geronimo/modules/geronimo- security/ 1.2-beta/geronimo-security-1.2-beta.pom [WARNING] Unable to get resource from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/modules/geronimo- security/1 .2-beta/geronimo-security-1.2-beta.pom 2K downloaded Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ geronimo/m odules/modules/1.2-beta/modules-1.2-beta.pom [WARNING] Unable to get resource from repository apache-incubator (http://people.apache.or g/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/apache/geronimo/modules/modules/ 1.2-beta/m odules-1.2-beta.pom [WARNING] Unable to get resource from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/modules/modules/ 1.2-beta/mo dules-1.2-beta.pom 4K downloaded Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ geronimo/g eronimo/1.2-beta/geronimo-1.2-beta.pom [WARNING] Unable to get resource from repository apache-incubator (http://people.apache.or g/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/apache/geronimo/geronimo/1.2- beta/geronimo -1.2-beta.pom [WARNING] Unable to get resource from repository codehaus (http://repository.codehaus.org) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/geronimo/1.2-beta/ geronimo- 1.2-beta.pom 50K downloaded Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/ geronimo/m odules/geronimo-kernel/1.2-beta/geronimo-kernel-1.2-beta.pom [WARNING] Unable to get resource from repository apache-incubator (http://people.apache.or g/repo/m2-incubating-repository/) Downloading: http://repository.codehaus.org/org/apache/geronimo/modules/geronimo- kernel/1. 2-beta/geronimo-kernel-1.2-beta.pom [WARNING] Unable to get resource from repository codehaus (http://repository.codehaus.org) Thanks Anita __ __ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com __ __ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121
Re: svn commit: r497717 - in /geronimo/server/trunk: ./ configs/openejb/src/plan/ modules/geronimo-openejb/ modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/ modules/geronimo-openejb
On Jan 18, 2007, at 11:17 PM, Jacek Laskowski wrote:
On 1/19/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: dain
Date: Thu Jan 18 22:51:43 2007
New Revision: 497717
URL: http://svn.apache.org/viewvc?view=revrev=497717
Log:
Stubbed out ejb daemon gbean
...
+public class EjbDaemonGBean implements NetworkConnector,
GBeanLifecycle {
...
+public void doStart() throws Exception {
+Properties properties = new Properties();
+properties.setProperty(server,
org.apache.openejb.server.ejbd.EjbServer);
I wish we didn't include any unmodifiable values of GBean properties
like the above. Could it be overriden via the gbean's server
attribute?
That code didn't actually work anyway, so I yanked it. Check out the
new gbean.
-David
Re: EJB deployment error
Jarek, if you can send me the app I can take a look. -David On Jan 19, 2007, at 9:48 AM, Jarek Gawor wrote: Dain, This is just a simple EJB that tires to use JAXB or StAX API. It is not exposed (or deployed) as a web service. Jarek On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Please take a look at the M2 Status - branch on Wednesday thread. It contains a list of what works and what doesn't. The webservices integration doesn't work yet. -dain On Jan 19, 2007, at 9:34 AM, Jarek Gawor wrote: I get the following error after the openejb update: Deployer operation failed: org.apache.openejb.OpenEJBException: Cannot Load jar C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo-deployer34093.tmpdir \jaxb-ejb-2.0-SN APSHOT.jar. The number of beans deployed (0) does not match the number of beans actually in the jar (1). Please redeploy this jar. I see this error after updating the openejb-jar.xml (http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml (http://java.sun.com/xml/ns/javaee) descriptors with right namespaces. I'm running the testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb tests. The ejbs are very simple and do not use any annotations. Jarek
Conversion Tool
Keep your ejb related plan files intact or a copy of them at least. I'm going to try and write a conversion tool that will at least handle trivial apps. A non-trivial app would be one with CMPs. The new mapping.xml format for cmps is the jpa mapping.xml and converting that will be a little more work. Nothing done yet, just announcing intentions. -David
Re: Unable to deploy an EJB3.0 sample app
On Jan 21, 2007, at 1:03 PM, Prasad Kashyap wrote: I was able to deploy the app successfully but only after using an openejb-jar.xml. Dain Blevins, On the irc discussion on Sat, 01/20, we thought that an openejb-jar.xml is not mandatory. I debugged the builder and realized the contrary. In the EJBModuleBuilder.java, it doesn't check to see if the openejb-jar.xml is null or not. String openejbJarXml = XmlUtil.loadOpenejbJarXml(object, moduleFile); OpenejbJar openejbJar = XmlUtil.unmarshal(OpenejbJar.class, openejbJarXml); http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo- openejb-builder/src/main/java/org/apache/geronimo/openejb/ deployment/EjbModuleBuilder.java?view=log Should this be fixed ? Or is the openejb-jar.xml mandatory ? Nope, that should be fixed and very good work tracking this down. Do you want the honors of adding this fix? -David Cheers Prasad On 1/20/07, Prasad Kashyap [EMAIL PROTECTED] wrote: I have created a sample application out of the calculator-stateless-pojo example in OpenEJB 3.0 It is checked in here - http://svn.apache.org/viewvc/geronimo/samples/trunk/calculator- stateless-pojo/ The app tries to demonstrate dependency injection of the bean into a servlet and obviates the need for the deployment-descriptor. But I learnt from David Blevins that while the app may not need a DD, geronimo doesn't yet support ear archives with no ejb-jar.xml. It doesn't know to give them to openejb. Hence under his guidance I put a dummy ejb-jar.xml and a minimum geronimo-web.xml. When I try to deploy this app, it fails with the following error: Error: Unable to distribute calculator-stateless-ear-2.0- SNAPSHOT.ear: Module was not an EJB: calculator-stateless-ejb-2.0-SNAPSHOT.jar Am I missing anything else here ? Can someone please help ? Thanx in advance Prasad
Re: Conversion Tool
On Jan 19, 2007, at 5:07 PM, David Blevins wrote: Keep your ejb related plan files intact or a copy of them at least. I'm going to try and write a conversion tool that will at least handle trivial apps. A non-trivial app would be one with CMPs. The new mapping.xml format for cmps is the jpa mapping.xml and converting that will be a little more work. Nothing done yet, just announcing intentions. Ok, have a little progress on this. So far I am able to convert: - environment and children - security and children - gbean and children - message-destination and children - persistence-context-ref and children To see same converted document, look here: source: http://svn.apache.org/repos/asf/incubator/openejb/trunk/ openejb3/container/openejb-jee/src/test/resources/openejb-jar-2-full.xml result: http://svn.apache.org/repos/asf/incubator/openejb/trunk/ openejb3/container/openejb-jee/src/test/resources/geronimo-openejb- converted.xml It was a bit of work getting JAXB2 to work with our schemas because of duplicated elements combined with the fact that we allow invalid xml (i.e. no namespace at all). So I actually had to write a invalid 2 valid xml converter before I could get started on the openejb- jar.xml to geronimo-openejb.xml converter. Things should go faster from here. Will hack more in the morning. Not sure what the effort is going to be to convert the cmp information as that is a openejb-jar.xml 2 jpa mapping.xml conversion. Hoping Dain might have some input on that. -David
Re: EJB deployment error
On Jan 22, 2007, at 8:56 AM, Prasad Kashyap wrote: Jarek, I had the same error. Try something like the following in your openejb-jar.xml openejb-jar xmlns=http://www.openejb.org/openejb-jar/1.1; ejb-deployment ejb-name=Calculator deployment-id=samples/calculator/stateless/ CalculatorLocal container-id=Default Stateless Container/ /openejb-jar Aha, ok, well I think I may know what the problem is there. Let me see if I can't fix it. -David Cheers Prasad On 1/19/07, Prasad Kashyap [EMAIL PROTECTED] wrote: http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/ webservices-testsuite/jaxb-tests/jaxb-ejb/ Cheers Prasad On 1/19/07, Jarek Gawor [EMAIL PROTECTED] wrote: David, It's a test case in Geronimo source code. See testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb directory. Jarek On 1/19/07, David Blevins [EMAIL PROTECTED] wrote: Jarek, if you can send me the app I can take a look. -David On Jan 19, 2007, at 9:48 AM, Jarek Gawor wrote: Dain, This is just a simple EJB that tires to use JAXB or StAX API. It is not exposed (or deployed) as a web service. Jarek On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Please take a look at the M2 Status - branch on Wednesday thread. It contains a list of what works and what doesn't. The webservices integration doesn't work yet. -dain On Jan 19, 2007, at 9:34 AM, Jarek Gawor wrote: I get the following error after the openejb update: Deployer operation failed: org.apache.openejb.OpenEJBException: Cannot Load jar C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo- deployer34093.tmpdir \jaxb-ejb-2.0-SN APSHOT.jar. The number of beans deployed (0) does not match the number of beans actually in the jar (1). Please redeploy this jar. I see this error after updating the openejb-jar.xml (http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml (http://java.sun.com/xml/ns/javaee) descriptors with right namespaces. I'm running the testsuite/webservices-testsuite/jaxb- tests/jaxb-ejb tests. The ejbs are very simple and do not use any annotations. Jarek
Re: EJB deployment error
On Jan 22, 2007, at 3:21 PM, David Blevins wrote: On Jan 22, 2007, at 8:56 AM, Prasad Kashyap wrote: Jarek, I had the same error. Try something like the following in your openejb-jar.xml openejb-jar xmlns=http://www.openejb.org/openejb-jar/1.1; ejb-deployment ejb-name=Calculator deployment-id=samples/calculator/stateless/ CalculatorLocal container-id=Default Stateless Container/ /openejb-jar Aha, ok, well I think I may know what the problem is there. Let me see if I can't fix it. And thank you *very much* for digging into this and finding the missing part. It is a big help. -David -David Cheers Prasad On 1/19/07, Prasad Kashyap [EMAIL PROTECTED] wrote: http://svn.apache.org/viewvc/geronimo/server/trunk/testsuite/ webservices-testsuite/jaxb-tests/jaxb-ejb/ Cheers Prasad On 1/19/07, Jarek Gawor [EMAIL PROTECTED] wrote: David, It's a test case in Geronimo source code. See testsuite/webservices-testsuite/jaxb-tests/jaxb-ejb directory. Jarek On 1/19/07, David Blevins [EMAIL PROTECTED] wrote: Jarek, if you can send me the app I can take a look. -David On Jan 19, 2007, at 9:48 AM, Jarek Gawor wrote: Dain, This is just a simple EJB that tires to use JAXB or StAX API. It is not exposed (or deployed) as a web service. Jarek On 1/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Please take a look at the M2 Status - branch on Wednesday thread. It contains a list of what works and what doesn't. The webservices integration doesn't work yet. -dain On Jan 19, 2007, at 9:34 AM, Jarek Gawor wrote: I get the following error after the openejb update: Deployer operation failed: org.apache.openejb.OpenEJBException: Cannot Load jar C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\geronimo- deployer34093.tmpdir \jaxb-ejb-2.0-SN APSHOT.jar. The number of beans deployed (0) does not match the number of beans actually in the jar (1). Please redeploy this jar. I see this error after updating the openejb-jar.xml (http://www.openejb.org/openejb-jar/1.1) and ejb-jar.xml (http://java.sun.com/xml/ns/javaee) descriptors with right namespaces. I'm running the testsuite/webservices-testsuite/jaxb- tests/jaxb-ejb tests. The ejbs are very simple and do not use any annotations. Jarek
Re: Unable to deploy an EJB3.0 sample app -- Thank you Prasad
On Jan 21, 2007, at 1:03 PM, Prasad Kashyap wrote: I was able to deploy the app successfully but only after using an openejb-jar.xml. Dain Blevins, On the irc discussion on Sat, 01/20, we thought that an openejb-jar.xml is not mandatory. I debugged the builder and realized the contrary. In the EJBModuleBuilder.java, it doesn't check to see if the openejb-jar.xml is null or not. String openejbJarXml = XmlUtil.loadOpenejbJarXml(object, moduleFile); OpenejbJar openejbJar = XmlUtil.unmarshal(OpenejbJar.class, openejbJarXml); http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo- openejb-builder/src/main/java/org/apache/geronimo/openejb/ deployment/EjbModuleBuilder.java?view=log On Jan 22, 2007, at 8:56 AM, Prasad Kashyap wrote: Jarek, I had the same error. Try something like the following in your openejb-jar.xml openejb-jar xmlns=http://www.openejb.org/openejb-jar/1.1; ejb-deployment ejb-name=Calculator deployment-id=samples/calculator/stateless/ CalculatorLocal container-id=Default Stateless Container/ /openejb-jar First, a very big thank you to Prasad for really digging in this weekend helping to find things that needed to be fixed. All because if his input I was able to find what I think are the the last remaining gotchas in the EJB deployment system. I've tried to file jiras for everything, so here goes: The first issue he discovered is with deploying an ejb app with no ejb-jar.xml. Geronimo needs that file to determine it's an ejb app, so at least an empty one is required to make deployment work. Here's the jira for that: http://issues.apache.org/jira/browse/GERONIMO-2770 So to fix that I need to see if there are any annotated beans in the jar, which will be hard to do as there is no classloader available in the 'createModule' section of the Geronimo deployment system. I racked my brain for a bit and think with a little work to my xbean- finder ClassFinder I can do the required sniffing with no classloader as it's all ASM-based. I just need to add a couple methods to report that data. I've filed a jira for that as well: http://issues.apache.org/jira/browse/XBEAN-70 The second issue that Prasad found is that you have to had to have an openejb-jar element in your geronimo-openejb.xml or the EjbModuleBuilder will fail with a null pointer. This is the issue he posted above. Dain as already fixed that issue and now you can have an empty openejb-jar element in your geronimo-openejb.xml. But I was still surprised about one thing (issue number three). Even having an empty openejb-jar, which is something he tried, *should* work. So I dug a bit more in the code on the openejb side and found that the logic goes if you have an openejb-jar, use it. If you don't have one, create it automatically. I.e. so adding the empty openejb-jar element effectively shut off the auto deploy functionality. We do have the code that can augment an existing openejb-jar and add missing definitions automatically, so I've created an issue for that one as well. http://issues.apache.org/jira/browse/OPENEJB-452 Hope to get these fixed in a couple hours. Big thank you to Prasad for playing detective and finding *all* of these issues. Rather than stopping at the first one, he kept going all the way to the end and did what it took to get something working. Very appreciated and very big time saver for me at least as I spent the weekend working on the conversion tool and wouldn't have been able to do that without all his work on this. Nice Job, Prasad! -David
Re: Unable to deploy an EJB3.0 sample app -- Thank you Prasad
Ok. All of these issues should be fixed. -David On Jan 22, 2007, at 4:46 PM, David Blevins wrote: On Jan 21, 2007, at 1:03 PM, Prasad Kashyap wrote: I was able to deploy the app successfully but only after using an openejb-jar.xml. Dain Blevins, On the irc discussion on Sat, 01/20, we thought that an openejb-jar.xml is not mandatory. I debugged the builder and realized the contrary. In the EJBModuleBuilder.java, it doesn't check to see if the openejb-jar.xml is null or not. String openejbJarXml = XmlUtil.loadOpenejbJarXml(object, moduleFile); OpenejbJar openejbJar = XmlUtil.unmarshal(OpenejbJar.class, openejbJarXml); http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/ deployment/EjbModuleBuilder.java?view=log On Jan 22, 2007, at 8:56 AM, Prasad Kashyap wrote: Jarek, I had the same error. Try something like the following in your openejb-jar.xml openejb-jar xmlns=http://www.openejb.org/openejb-jar/1.1; ejb-deployment ejb-name=Calculator deployment-id=samples/calculator/stateless/ CalculatorLocal container-id=Default Stateless Container/ /openejb-jar First, a very big thank you to Prasad for really digging in this weekend helping to find things that needed to be fixed. All because if his input I was able to find what I think are the the last remaining gotchas in the EJB deployment system. I've tried to file jiras for everything, so here goes: The first issue he discovered is with deploying an ejb app with no ejb-jar.xml. Geronimo needs that file to determine it's an ejb app, so at least an empty one is required to make deployment work. Here's the jira for that: http://issues.apache.org/jira/browse/GERONIMO-2770 So to fix that I need to see if there are any annotated beans in the jar, which will be hard to do as there is no classloader available in the 'createModule' section of the Geronimo deployment system. I racked my brain for a bit and think with a little work to my xbean-finder ClassFinder I can do the required sniffing with no classloader as it's all ASM-based. I just need to add a couple methods to report that data. I've filed a jira for that as well: http://issues.apache.org/jira/browse/XBEAN-70 The second issue that Prasad found is that you have to had to have an openejb-jar element in your geronimo-openejb.xml or the EjbModuleBuilder will fail with a null pointer. This is the issue he posted above. Dain as already fixed that issue and now you can have an empty openejb-jar element in your geronimo-openejb.xml. But I was still surprised about one thing (issue number three). Even having an empty openejb-jar, which is something he tried, *should* work. So I dug a bit more in the code on the openejb side and found that the logic goes if you have an openejb-jar, use it. If you don't have one, create it automatically. I.e. so adding the empty openejb-jar element effectively shut off the auto deploy functionality. We do have the code that can augment an existing openejb-jar and add missing definitions automatically, so I've created an issue for that one as well. http://issues.apache.org/jira/browse/OPENEJB-452 Hope to get these fixed in a couple hours. Big thank you to Prasad for playing detective and finding *all* of these issues. Rather than stopping at the first one, he kept going all the way to the end and did what it took to get something working. Very appreciated and very big time saver for me at least as I spent the weekend working on the conversion tool and wouldn't have been able to do that without all his work on this. Nice Job, Prasad! -David
Re: M2 24-hour Branch Notice
On Jan 22, 2007, at 12:19 PM, Matt Hogstrom wrote: It looks like we have the makings of the M2 milestone that has been talked about. Dave and Dain made a huge chunk of code available so that one can deploy and use (in limited ways) EJB 3.0. Very impressed gents, kudos to the two of you. As we did for M1 I'd like to go ahead and branch tomorrow afternoon so we can tidy this release up without disrupting the continuous development on trunk. I'll pull in fixes to address the release as appropriate so that the server runs and we can show users a peek at a semi-stable environment. Remember this is a milestone and not a general release in terms of it is a view of the work in progress so fit and finish is coming :) Here are the major items I know about and limitations. Please comment where I'm in a ditch or on another planet. EJB 3.0 - Ability to deploy beans - Dependency injection still not functional but external plans can be used. Not sure what this item means exactly, but I've fixed the ejb builder so that it can recognize apps with annotations and no descriptor. I've also found and fixed an issue that would have prevented injection from working when there was no corresponding xml -- the itests that pass do test injection and it was working, just not if it was only via annotations where the xml would be created on the fly and not contain the proper mappedName that would hook it up to the right resource. If anyone finds an issue with the following features, please let me know immediately as they appear to be working as they should: Pojo Session EJBs Business interfaces Deployment with no ejb-jar.xml or openejb-jar (just need a geronimo- openejb.xml for all the geronimo-specific deployment stuff) injection via deployment descriptor @Resource injection for env-entries, resource-refs, message- destinations, service-refs, most resource-env-refs @EJB injection of ejb-refs and ejb-local-refs @PersistenceContext injection @PersistenceUnit injection -David
Re: Connector specs
On Jan 22, 2007, at 7:45 PM, anita kulshreshtha wrote: The connector 1.5 spec has dependency on jta-1.0.1B spec. Should this be changed to jta_1.1? This would mean republishing the connector spec.. That dep was marked as 'scopeprovided' so that the dep on jta_1.0.1B won't pollute our build via maven's transitivity. In fact, all of the deps in every spec module was marked as provided for the same reason. -David
Re: Connector specs
On Jan 22, 2007, at 8:34 PM, Jason Dillon wrote: Should probably still change the dep to help ensure compatibility. Ensure compatibility how? -David --jason On Jan 22, 2007, at 8:18 PM, David Blevins wrote: On Jan 22, 2007, at 7:45 PM, anita kulshreshtha wrote: The connector 1.5 spec has dependency on jta-1.0.1B spec. Should this be changed to jta_1.1? This would mean republishing the connector spec.. That dep was marked as 'scopeprovided' so that the dep on jta_1.0.1B won't pollute our build via maven's transitivity. In fact, all of the deps in every spec module was marked as provided for the same reason. -David
Re: Unable to deploy an EJB3.0 sample app
David J. found a couple issues with the latest changes, both have been fixed. Posting in case you ran into these. One was a null pointer caused during deployment: [WARNING] Caused by: java.lang.NullPointerException [WARNING] at org.apache.xbean.finder.ClassFinder.readClassDef (ClassFinder.java:681) [WARNING] at org.apache.xbean.finder.ClassFinder.init (ClassFinder.java:141) [WARNING] at org.apache.xbean.finder.ClassFinder.init (ClassFinder.java:113) [WARNING] at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java:153) [WARNING] at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.createModule (EjbModuleBuilder.java:129) The other was an issue with the containers created via the openejb plan not getting recognized in the system: org.apache.geronimo.common.DeploymentException: org.apache.openejb.OpenEJBException: A container of type STATELESS must be declared in the configuration file for bean: MyStatelessBean at org.apache.geronimo.openejb.deployment.EjbModuleBuilder.initContext (EjbModuleBuilder.java:325) at org.apache.geronimo.openejb.deployment.EjbModuleBuilder$ $FastClassByCGLIB$$cd80af20.invoke(generated) -David On Jan 22, 2007, at 6:55 PM, David Blevins wrote: Ok. All of these issues should be fixed. -David On Jan 22, 2007, at 4:46 PM, David Blevins wrote: On Jan 21, 2007, at 1:03 PM, Prasad Kashyap wrote: I was able to deploy the app successfully but only after using an openejb-jar.xml. Dain Blevins, On the irc discussion on Sat, 01/20, we thought that an openejb-jar.xml is not mandatory. I debugged the builder and realized the contrary. In the EJBModuleBuilder.java, it doesn't check to see if the openejb-jar.xml is null or not. String openejbJarXml = XmlUtil.loadOpenejbJarXml(object, moduleFile); OpenejbJar openejbJar = XmlUtil.unmarshal(OpenejbJar.class, openejbJarXml); http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-openejb-builder/src/main/java/org/apache/geronimo/ openejb/deployment/EjbModuleBuilder.java?view=log On Jan 22, 2007, at 8:56 AM, Prasad Kashyap wrote: Jarek, I had the same error. Try something like the following in your openejb-jar.xml openejb-jar xmlns=http://www.openejb.org/openejb-jar/1.1; ejb-deployment ejb-name=Calculator deployment-id=samples/calculator/stateless/ CalculatorLocal container-id=Default Stateless Container/ /openejb-jar First, a very big thank you to Prasad for really digging in this weekend helping to find things that needed to be fixed. All because if his input I was able to find what I think are the the last remaining gotchas in the EJB deployment system. I've tried to file jiras for everything, so here goes: The first issue he discovered is with deploying an ejb app with no ejb-jar.xml. Geronimo needs that file to determine it's an ejb app, so at least an empty one is required to make deployment work. Here's the jira for that: http://issues.apache.org/jira/browse/GERONIMO-2770 So to fix that I need to see if there are any annotated beans in the jar, which will be hard to do as there is no classloader available in the 'createModule' section of the Geronimo deployment system. I racked my brain for a bit and think with a little work to my xbean-finder ClassFinder I can do the required sniffing with no classloader as it's all ASM-based. I just need to add a couple methods to report that data. I've filed a jira for that as well: http://issues.apache.org/jira/browse/XBEAN-70 The second issue that Prasad found is that you have to had to have an openejb-jar element in your geronimo-openejb.xml or the EjbModuleBuilder will fail with a null pointer. This is the issue he posted above. Dain as already fixed that issue and now you can have an empty openejb-jar element in your geronimo-openejb.xml. But I was still surprised about one thing (issue number three). Even having an empty openejb-jar, which is something he tried, *should* work. So I dug a bit more in the code on the openejb side and found that the logic goes if you have an openejb-jar, use it. If you don't have one, create it automatically. I.e. so adding the empty openejb-jar element effectively shut off the auto deploy functionality. We do have the code that can augment an existing openejb-jar and add missing definitions automatically, so I've created an issue for that one as well. http://issues.apache.org/jira/browse/OPENEJB-452 Hope to get these fixed in a couple hours. Big thank you to Prasad for playing detective and finding *all* of these issues. Rather than stopping at the first one, he kept going all the way to the end and did what it took to get something working. Very appreciated and very big time saver for me at least as I spent the weekend working on the conversion tool and wouldn't have been able to do
Re: Cannot access a EJB 3.0 bean from a servlet
Alright, so I figured out how to fix the naming code so that it will work for business interfaces as well as references from servlets to ejb for business interfaces. Dain is hacking it in now. On Jan 23, 2007, at 11:49 AM, Prasad Kashyap wrote: The easiest way to reference a 3.0 EJB is by dependency injection (@EJB). But we don't have annotations working in servlets yet. So if we go back to doing the traditional way of a lookup, we would have to declare a ejb-ref in the web.xml Even if the annotations are processed, they write an ejb-ref element in the web.xml. However for a 3.0 EJB, the interface elements like home, local etc are not applicable inside a ejb-ref. So they are (should be) omitted. Here is the schema: http://java.sun.com/xml/ns/javaee/javaee_5.xsd This isn't exactly right. Those elements are still very applicable. For a proper ejb-ref to an EJB 3.0 bean (i.e. a business interface) it *must* have the remote or local and must *not* have the home or local-home. These can only be omitted in the case of dependency injection where the code using the @EJB to generate a metadata-complete ejb-ref should *always* fill in the remote element of the ejb-ref element. If the user does not specify the 'beanInterface' attribute of the @EJB annotation, then the code building the reference must use the class type of the field or method as the value of 'remote'. There is an edge case where you truly do not know if the @EJB is pointing to a local object or a remote object and therefore don't know whether to build a ejb-ref or an ejb-local-ref. For OpenEJB we build an ejb-ref and flag it as being ambiguous, then in the jndi building code we try to resolve it against the full list of available ejbs. We'll have to figure out some way to communicate this edge case to the ejb naming builder so we can deal with it. But our deployer has a hard requirement on those interfaces. It fails to deploy the module. Here is the stack trace excerpt: http://rifers.org/paste/show/3344 Dain should have this code fixed up soon. It'll work as long as the code building the ejb-ref for the servlet follows the rules I state above. Here is the jira for this problem: http://issues.apache.org/jira/browse/GERONIMO-2778 Thanks. I'm going to change the description of that jira issue to reflect that local or remote *should* be filled in before the ejb naming builder is invoked. I don't know where that code is, perhaps Tim knows. -David
Invalid xmlbeans tree for javaee 5
Dain and I are still hacking away and we just ran into this issue. It seems the xmlbeans tree from javaee 5 is invalid and needs to be recreated. Anytime someone either in a servlet or ejb declares a PersistenceContext ref of persistence-context-type 'Transaction', deployment will fail with an error like the following: Error: Unable to distribute openejb-itests-beans-3.0-incubating-SNAPSHOT.jar: Could not validate xmlObject of type [EMAIL PROTECTED]://java.sun.com/xml/ns/javaee Invalid deployment descriptor: [error: cvc-enumeration-valid: string value 'Transaction' is not a valid enumeration value for persistence-context-typeType in namespace http://java.sun.com/xml/ns/javaee] Descriptor: xml-fragment xmlns:jav=http://java.sun.com/xml/ns/javaee; jav:persistence-context-ref- nameorg.apache.openejb.test.stateful.AnnotatedFieldInjectionStatefulBea n/em/jav:persistence-context-ref-name jav:persistence-unit-nameopenjpa-test-unit/jav:persistence- unit-name jav:persistence-context-typeTransaction/jav:persistence- context-type /xml-fragment This obviously wrong as the javaee_5.xsd defines persistence-context- type as follows: xsd:complexType name=persistence-context-typeType xsd:annotation xsd:documentation The persistence-context-typeType specifies the transactional nature of a persistence context reference. The value of the persistence-context-type element must be one of the following: Transaction Extended /xsd:documentation /xsd:annotation xsd:simpleContent xsd:restriction base=javaee:string xsd:enumeration value=Transaction/ xsd:enumeration value=Extended/ /xsd:restriction /xsd:simpleContent /xsd:complexType Anyway we can get this done really fast? -David
EJB 3 integration status
Ok, so Dain and I have worked all through the night again to try and kill the last issues we've seen with the integration. We added a few more tests and such the itests and have hammered away till things worked. We had to do some ad-hoc surgery in the naming code and more that will have to be merged back to the M2 branch, but the result is a lot more is working. These have all been tested as working as of this morning: - ejb-jar.xml free deploy (this had issues actually and did not work as previously reported) - openejb-jar free deploy - Deployment of annotated beans (@Stateful and @Stateless) - Business interfaces both local and remote - Legacy component (i.e. home) interfaces on a Pojo session bean - xml-based *and* annotation-based injection for ejbs, except for message-destinations, or SessionContext when the field or setter is not named setSessionContext - references to business interfaces, local or remote, from a servlet or an ejb - references to home interfaces, local or remote, from a servlet or an ejb The following components are tested in the itests: - Stateful session beans - Stateless session beans - BMP Entity beans - CMP1 Entity beans (basic tests) - CMP2 Entity beans (basic tests) The following components are *not* tested in the itests: - Message-Driven Beans Dain may have a better idea of which CMP2 features are lacking. I'll let him go into detail about that. The issue with injection of SessionContext I hope to clear up in the morning. We also still really hope to at least put in a hole in the ejb module builder that would allow people to install an v2 openejb- jar.xml to geronimo-openejb.xml converter. (cross your fingers). -David
Re: EJB 3 integration status
FYI all openejb3 snapshots are current as of now, i.e. 20070124.144710, revision 499423. -David On Jan 24, 2007, at 6:00 AM, David Blevins wrote: Ok, so Dain and I have worked all through the night again to try and kill the last issues we've seen with the integration. We added a few more tests and such the itests and have hammered away till things worked. We had to do some ad-hoc surgery in the naming code and more that will have to be merged back to the M2 branch, but the result is a lot more is working. These have all been tested as working as of this morning: - ejb-jar.xml free deploy (this had issues actually and did not work as previously reported) - openejb-jar free deploy - Deployment of annotated beans (@Stateful and @Stateless) - Business interfaces both local and remote - Legacy component (i.e. home) interfaces on a Pojo session bean - xml-based *and* annotation-based injection for ejbs, except for message-destinations, or SessionContext when the field or setter is not named setSessionContext - references to business interfaces, local or remote, from a servlet or an ejb - references to home interfaces, local or remote, from a servlet or an ejb The following components are tested in the itests: - Stateful session beans - Stateless session beans - BMP Entity beans - CMP1 Entity beans (basic tests) - CMP2 Entity beans (basic tests) The following components are *not* tested in the itests: - Message-Driven Beans Dain may have a better idea of which CMP2 features are lacking. I'll let him go into detail about that. The issue with injection of SessionContext I hope to clear up in the morning. We also still really hope to at least put in a hole in the ejb module builder that would allow people to install an v2 openejb-jar.xml to geronimo-openejb.xml converter. (cross your fingers). -David
Re: EJB 3 integration status
On Jan 24, 2007, at 6:00 AM, David Blevins wrote: We had to do some ad-hoc surgery in the naming code and more that will have to be merged back to the M2 branch, but the result is a lot more is working. Just going to repost this then go to bed (promise :). Cc'ing Matt as he signed up to do merges, but I'm sure if someone beats him to it he won't mind. :) -David
Re: EJB 3 integration status
On Jan 24, 2007, at 2:09 PM, Dain Sundstrom wrote: On Jan 24, 2007, at 6:28 AM, Dain Sundstrom wrote: Tomorrow, I'm going to try to remove the requirement to have a geronimo-openejb.xml file. Funny, just tried it out and a geronimo-openejb.xml free deployment worked perfectly. The code has been in there for weeks :) in a very concerned voice Dain, how many weeks has it been since last wednesday? /me thinks dain needs more sleep :) -David
Re: [WELCOME] Chris Blythe as a new Committer to Apache Geronimo
Welcome, Chris! -David On Jan 24, 2007, at 10:53 AM, Matt Hogstrom wrote: In recognition of Chris' contributions to DayTrader (new UI, new runtime modes) and his sustained set of patches and nagging he has accepted our offer to join our merry little band of pirates. Please join me in welcoming Chris. Matt Hogstrom [EMAIL PROTECTED]
Re: Release Notes for 2.0-M2 - EJB content
On Jan 25, 2007, at 11:03 AM, Dave Colasurdo wrote: Limitations: - Undeploying an ejb module will not remove it's beans. The server has to be restarted to deploy the same module again. Ok, I've implemented undeploy and verified it works using the calculator sample app. I can guarantee there are leaks here (there always are the first few iterations), but the feature is functional. - Extended JNDI and DI types This works. If your env-entry-type is java.lang.String and we see you have a URL, for example, we will convert the value to a URL before injection. -David
Re: Release Notes for 2.0-M2 - EJB content
On Jan 26, 2007, at 5:46 AM, Dave Colasurdo wrote: Thanks... Have made the updates... Is there anything that should be added to the limitations section? One of the things I mentioned in another email is that MDBs are completely untested and should be assumed non-functional. Do we fully support EJB 3.0? :) -David -Dave- David Blevins wrote: On Jan 25, 2007, at 11:03 AM, Dave Colasurdo wrote: Limitations: - Undeploying an ejb module will not remove it's beans. The server has to be restarted to deploy the same module again. Ok, I've implemented undeploy and verified it works using the calculator sample app. I can guarantee there are leaks here (there always are the first few iterations), but the feature is functional. - Extended JNDI and DI types This works. If your env-entry-type is java.lang.String and we see you have a URL, for example, we will convert the value to a URL before injection. -David
Re: Release Notes for 2.0-M2 - EJB content
On Jan 26, 2007, at 12:21 PM, Bill Stoddard wrote: David Blevins wrote: On Jan 26, 2007, at 5:46 AM, Dave Colasurdo wrote: Thanks... Have made the updates... Is there anything that should be added to the limitations section? One of the things I mentioned in another email is that MDBs are completely untested and should be assumed non-functional. Do we fully support EJB 3.0? :) -David The answer probably depends on the definition of 'fully'. :) LOL! -David
Re: [VOTE] 2.0-M2 Milestone ready for review and JACC Specs
On Jan 27, 2007, at 7:39 PM, Kevan Miller wrote: On Jan 27, 2007, at 1:01 AM, Matt Hogstrom wrote: All, I have made the binaries from Geronimo 2.0-M2 available for review at: http://people.apache.org/~hogstrom/2.0-M2-rc1 In this directory you will find the various assemblies for your review as well as one massive tar ball that has the various artifacts that will ultimately be distributed. The files are being uploaded as this is being written so give them some time. Also included in this vote are the artifacts for the JACC spec 1.0- M2 which is required for 2.0-M2. Remember...this is a milestone and not a full release. Thanks for David Blevins for being quite the helper tonight in getting the Release Notes in line and helping out with Open EJB. As Prasad has noted in a separate thread, EJB@ injection for Jetty is not working. Matt can confirm, but I believe that he intentionally did not merge the latest changes from trunk into the M2 branch. A release manager needs to draw the line somewhere, and this allowed him to get the RC candidate built. I was (and still am) fine with delivering M2 with this limitation. We've got a lot of great function, here. I'm looking forward to getting on to making more great progress like this. I suggest we update the release notes to reflect this EJB@ limitation. Something like: - EJB 3.0 (via OpenEJB project) Supported: ... - @EJB injection of ejb-refs and ejb-local-refs (Tomcat) ... Limitations: - No support for MDBs. - @EJB injection of ejb-refs and ejb-local-refs (Jetty) I've tested both jee5 assemblies. The source and binary look good. With an update to the release notes, I'm +1. +1 to the release. And for the release notes we should make a new section for Servlets 2.5 and mention the @EJB Jetty limitation there. -David
Re: ClassFinder questions/problems -- annotation processing
On Jan 27, 2007, at 10:20 PM, Tim McConnell wrote:
Hi David, I'm having a couple problems with ClassFinder that I hope
you can help me with.
1 -- I've annotated a number of methods in a serlvlet with the
@Resource annotation, but I'm having some trouble discovering them
in the WAR file just prior to deployment. Doing some traces I can
see that the isAnnotationPresent() check in
ClassFinder.findAnnotatedMethods() is failing. This is a bit
perplexing to me since the @Resource has the RUNTIME retention
policy, and ClassFinder.FindAnnotatedMethods() finds both the
classinfo and the methodinfo. Also, it's not getting a
ClassNotFoundException. Have you seen this before and/or do you
know what might be causing this ??
I'm not sure how you're constructing the ClassFinder, but as I
mentioned to Dain when he hacked the @EJB stuff in for servlets you
definitely want to use the constructor where you pass in the webapp
classloader plus the exact list of URLs to search making sure you
don't search the URLs in any of the parents. The code that Dain came
up with which would also apply would be like this:
ClassLoader webappClassLoader = module.getEarContext
().getClassLoader();
UrlSet urlSet = new UrlSet(webappClassLoader);
if (classLoader instanceof MultiParentClassLoader) {
MultiParentClassLoader multiParentClassLoader =
(MultiParentClassLoader) webappClassLoader;
for (ClassLoader parent :
multiParentClassLoader.getParents()) {
if (parent != null) {
urlSet = urlSet.exclude(parent);
}
}
} else {
ClassLoader parent = webappClassLoader.getParent();
if (parent != null) {
urlSet = urlSet.exclude(parent);
}
}
ClassFinder finder = new ClassFinder
(webappClassLoader, urlSet.getUrls());
Then when you call ...
finder.findAnnotatedMethod(javax.annotation.Resource.class)
it should return the methods for all classes in the webapp that use
javax.annotation.Resource. If it doesn't, definitely make sure the
webapp doesn't have the annotation spec jar in the WEB-INF/lib/
directory. The easiest way to check for that is to simply...
ClassLoader webappClassLoader = module.getEarContext
().getClassLoader();
Class resourceAnnotation = webappClassLoader.loadClass
(javax.annotation.Resource);
assert javax.annotation.Resource.class.equals(resourceAnnotation);
If that assertion fails, than something is going very wrong with the
webapp classloader and definitely nothing annotation related will work.
2 -- I've also noticed that when I annotate a class that extends
another class, then the ClassFinder will fail with a
NoClassFoundException on the class that is extended. I assume this
is because the extended classes are not in the WAR file that is
getting deployed. I create my own classloader and create a
ClassFinder instance by passing it the URL of the WAR file itself
(plus the URL of any embedded JAR files in the WAR) and don't use a
parent classloader. My quandary is that I'm trying to discover
these annotation prior to deployment so I'm not sure I have a
parent or system classloader I can use to find these extended
classes. Do you have any recommendations ??
Yea, you really won't be able to do any annotation processing during
or before the createModule phase of deployment as there are no
classloaders. It's pretty much a hard wall with no way past. Kind
of frustrating. I noticed in your proposals for annotation
processing for JSR 88 you have most of the work being done before and
during the createModule phase. Unfortunately, none of that will be
possible without some major changes to the deployment system. You'll
probably have to do most the work in installModule and initContext
like we did for EJBs.
Thanks for any assistance.
Hope this helps.
-David
Re: Which ejb_3.0 spec?
On Jan 31, 2007, at 9:31 AM, anita kulshreshtha wrote: Geronimo uses version 1.0 for geronimo-ejb_3.0_spec where as openejb uses 1.0-M1. Which version should geronimo be using? Should we make sure that the other version in not brought in by openejb? I thought we did, just updated it. -David
Re: [VOTE] J2G Conversion tool acceptance
+1 -David On Jan 31, 2007, at 7:10 AM, Filip Hanik - Dev Lists wrote: This is the formal vote to accept the J2G codebase and bring it through incubation (see http://marc.theaimsgroup.com/?l=geronimo- devm=116906208022256w=2) The final destination is to be part of the geronimo devtool subproject. (see http://marc.theaimsgroup.com/?l=geronimo- devm=116958894929809w=2) The code donation is located at: https://issues.apache.org/jira/browse/GERONIMO-2743 [ ] +1 lets bring it in, this is great [ ] 0 do what ever you want, not my cup of tea [ ] -1 keep it out of our sight, I have a good reason Optional [ ] I'm willing to mentor this project while it is in incubation [ ] I'm willing to champion the effort while it is in incubation Committers' votes are binding, all other votes will be duly noted Best regards Filip
Re: [all] jarfiles in svn
Going to crank these out now, expect to see some votes for them. -David On Jan 11, 2007, at 9:53 PM, David Blevins wrote: So I don't forget, some commons projects need JDK 1.3 compiled versions of some of our J2EE 1.4 specs, so at some when I get a spare cycle I plan to build and put those up for a vote. -David Begin forwarded message: From: David Blevins [EMAIL PROTECTED] Date: January 10, 2007 11:27:41 AM PST To: Jakarta Commons Developers List commons- [EMAIL PROTECTED] Subject: Re: [all] jarfiles in svn Reply-To: Jakarta Commons Developers List commons- [EMAIL PROTECTED] On Jan 10, 2007, at 2:39 AM, Joerg Heinicke wrote: David Blevins david.blevins at visi.com writes: Only passively reading the thread, but from some of the comments and your commit message it looks like you just need JDK 1.3 compiled versions of those specs. Yes, that's it. Cool. I'd be happy to apply your pom changes in the geronimo tree and put newly built versions up for a vote. That would be fine. But please review my pom changes. I'm not a Maven expert, but only googled for compiling for target JDK and found different approaches. Though this approach works for me there might be cases where it does not or simply better ones. It looks good, I'll give it a try. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Release geronimo-j2ee-connector_1.5_spec-1.1.1
All, I've updated the pom of this spec to be compiled with jdk 1.3 as requested by a project in jakarta commons that needs them. I hereby propose we release this branch and it's binaries as final. Release Branch: http://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-j2ee-connector_1.5_spec-1.1.1 Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/ apache/geronimo/specs/geronimo-j2ee-connector_1.5_spec/1.1.1/ Here's my +1 -David
Re: Conversion Tool and OpenEJB 3.0 integration status -- please read and ask questions :)
Reposting this info with more details. So the 10,000 foot perspective is that we are creating a conversion tool to convert the prior openejb-jar.xml into the new set of descriptors (geronimo-openejb.xml, new openejb-jar.xml, jpa entity- mappings.xml). It is expected that all existing plans will work and no one will have to or even *should* migrate just yet. We are doing this for two reasons: 1. There is significant investment in current descriptor format. These come to mind: - TCK - DayTrader - iTests - Samples - All documentation to date - All user-land apps to date 2. The new plans will not be stable for a good long while. Primary reasons are: - Continued work in integration (security, webservices, corba, etc.) - Continued work implementing JavaEE 5 So the big motivation for the conversion tool is that with some hard work from Dain and I up front (and for a while really), we can save a few hundred developer and user hours over the next couple months. We're very close to having something running and hope to see something basically working by the end of the week. If we're really lucky after this week we can hide all the change under the conversion tool and no one (but the people working on and maintaining the conversion tool that is) will have to feel the pain or frustration while things move underneath. As we enable things like security people won't have to update their plans, we'll just add more conversion logic to port that information over and put it into action. I can say that the spirit of the new descriptor files is to fully embrace the anti-descriptor focus of Java EE 5 and to be as small and contain as little requirements as possible. Hopefully when the day comes to move over (not soon), it will more be a matter of deleting than adding. There will definitely be lots of experimentation in that area, so we'll see. As always, thoughts and questions very welcome and encouraged. -David On Jan 31, 2007, at 3:13 PM, Dain Sundstrom wrote: I just checked in the working converter for CMP beans. There is a fairly extensive test suite that converts the OpenEJB2 itests, daytrader and the OpenEJB2 CMR mappings tests. For example, here are the mappings for daytrader ejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/ daytrader/daytrader-ejb-jar.xml openejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/ daytrader/daytrader-openejb-jar.xml And the final JPA mappings -- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/ daytrader/daytrader-orm.xml I hope to have the converter fully integrated into Geronimo in by the end of the week. -dain On Jan 21, 2007, at 11:01 PM, David Blevins wrote: On Jan 19, 2007, at 5:07 PM, David Blevins wrote: Keep your ejb related plan files intact or a copy of them at least. I'm going to try and write a conversion tool that will at least handle trivial apps. A non-trivial app would be one with CMPs. The new mapping.xml format for cmps is the jpa mapping.xml and converting that will be a little more work. Nothing done yet, just announcing intentions. Ok, have a little progress on this. So far I am able to convert: - environment and children - security and children - gbean and children - message-destination and children - persistence-context-ref and children To see same converted document, look here: source: http://svn.apache.org/repos/asf/incubator/openejb/trunk/ openejb3/container/openejb-jee/src/test/resources/openejb-jar-2- full.xml result: http://svn.apache.org/repos/asf/incubator/openejb/trunk/ openejb3/container/openejb-jee/src/test/resources/geronimo-openejb- converted.xml It was a bit of work getting JAXB2 to work with our schemas because of duplicated elements combined with the fact that we allow invalid xml (i.e. no namespace at all). So I actually had to write a invalid 2 valid xml converter before I could get started on the openejb-jar.xml to geronimo-openejb.xml converter. Things should go faster from here. Will hack more in the morning. Not sure what the effort is going to be to convert the cmp information as that is a openejb-jar.xml 2 jpa mapping.xml conversion. Hoping Dain might have some input on that. -David
Re: [vote] Release geronimo-j2ee-connector_1.5_spec-1.1.1
On Feb 1, 2007, at 12:41 AM, David Jencks wrote: Can you explain the reasoning behind this version number? I would have thought 1.2 or 1.1-1 might be more appropriate. Just went with what we had done previously (thinking of 1.0.1). Whatever is fine with me. -David thanks david jencks On Jan 31, 2007, at 7:48 PM, David Blevins wrote: All, I've updated the pom of this spec to be compiled with jdk 1.3 as requested by a project in jakarta commons that needs them. I hereby propose we release this branch and it's binaries as final. Release Branch: http://svn.apache.org/repos/asf/geronimo/specs/ branches/geronimo-j2ee-connector_1.5_spec-1.1.1 Built Binaries: http://people.apache.org/~dblevins/stage-specs/ org/apache/geronimo/specs/geronimo-j2ee-connector_1.5_spec/1.1.1/ Here's my +1 -David
Re: [vote] Release geronimo-j2ee-connector_1.5_spec-1.1.1
On Feb 1, 2007, at 7:36 AM, Paul McMahan wrote:
Building from:
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-
j2ee-connector_1.5_spec-1.1.1
I get the following error:
% mvn install
[INFO] Scanning for projects...
[INFO]
--
--
[INFO] Building J2EE Connector 1.5
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 62 source files to
/Users/pmcmahan/src/geronimo/specs/branches/geronimo-j2ee-
connector_1.5_spec-1.1.1/target/classes
[INFO]
--
--
[ERROR] BUILD FAILURE
[INFO]
--
--
[INFO] Compilation failure
Failure executing javac, but could not parse the error:
javac: target release 1.3 conflicts with default source release 1.5
I see that pom.xml has
source1.3/source
target1.3/target
compilerVersion1.3/compilerVersion
So maybe I'm doing something wrong or my maven is not configured
properly? Please advise.
That's a maven bug as far as I can tell. Set your jdk to 1.4 and it
will work.
-David
Best wishes,
Paul
On 1/31/07, David Blevins [EMAIL PROTECTED] wrote:
All, I've updated the pom of this spec to be compiled with jdk 1.3 as
requested by a project in jakarta commons that needs them.
I hereby propose we release this branch and it's binaries as final.
Release Branch: http://svn.apache.org/repos/asf/geronimo/specs/
branches/geronimo-j2ee-connector_1.5_spec-1.1.1
Built Binaries: http://people.apache.org/~dblevins/stage-specs/org/
apache/geronimo/specs/geronimo-j2ee-connector_1.5_spec/1.1.1/
Here's my +1
-David
Re: Conversion Tool
Haven't been able to get a full deploy of anything (tried daytrader and the v2 itests), but things are starting to look good with the converter. The basic conversion is happening and conversion of things like environment and abstract name queries are definitely getting ported over. Still see some hiccups in CMPs, but apps without CMPs may deploy just fine. Will look into it more when I get up. Dain, can you take a look at the persistence unit part of the rewritten EjbModuleBuilder. Seems something in the way i've reworked the code results in those not coming through so well. -David On Jan 31, 2007, at 11:05 PM, David Blevins wrote: Reposting this info with more details. So the 10,000 foot perspective is that we are creating a conversion tool to convert the prior openejb-jar.xml into the new set of descriptors (geronimo-openejb.xml, new openejb-jar.xml, jpa entity- mappings.xml). It is expected that all existing plans will work and no one will have to or even *should* migrate just yet. We are doing this for two reasons: 1. There is significant investment in current descriptor format. These come to mind: - TCK - DayTrader - iTests - Samples - All documentation to date - All user-land apps to date 2. The new plans will not be stable for a good long while. Primary reasons are: - Continued work in integration (security, webservices, corba, etc.) - Continued work implementing JavaEE 5 So the big motivation for the conversion tool is that with some hard work from Dain and I up front (and for a while really), we can save a few hundred developer and user hours over the next couple months. We're very close to having something running and hope to see something basically working by the end of the week. If we're really lucky after this week we can hide all the change under the conversion tool and no one (but the people working on and maintaining the conversion tool that is) will have to feel the pain or frustration while things move underneath. As we enable things like security people won't have to update their plans, we'll just add more conversion logic to port that information over and put it into action. I can say that the spirit of the new descriptor files is to fully embrace the anti-descriptor focus of Java EE 5 and to be as small and contain as little requirements as possible. Hopefully when the day comes to move over (not soon), it will more be a matter of deleting than adding. There will definitely be lots of experimentation in that area, so we'll see. As always, thoughts and questions very welcome and encouraged. -David On Jan 31, 2007, at 3:13 PM, Dain Sundstrom wrote: I just checked in the working converter for CMP beans. There is a fairly extensive test suite that converts the OpenEJB2 itests, daytrader and the OpenEJB2 CMR mappings tests. For example, here are the mappings for daytrader ejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/ daytrader/daytrader-ejb-jar.xml openejb-jar.xml --- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/ daytrader/daytrader-openejb-jar.xml And the final JPA mappings -- https://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/ container/openejb-core/src/test/resources/convert/oej2/cmp/ daytrader/daytrader-orm.xml I hope to have the converter fully integrated into Geronimo in by the end of the week. -dain On Jan 21, 2007, at 11:01 PM, David Blevins wrote: On Jan 19, 2007, at 5:07 PM, David Blevins wrote: Keep your ejb related plan files intact or a copy of them at least. I'm going to try and write a conversion tool that will at least handle trivial apps. A non-trivial app would be one with CMPs. The new mapping.xml format for cmps is the jpa mapping.xml and converting that will be a little more work. Nothing done yet, just announcing intentions. Ok, have a little progress on this. So far I am able to convert: - environment and children - security and children - gbean and children - message-destination and children - persistence-context-ref and children To see same converted document, look here: source: http://svn.apache.org/repos/asf/incubator/openejb/trunk/ openejb3/container/openejb-jee/src/test/resources/openejb-jar-2- full.xml result: http://svn.apache.org/repos/asf/incubator/openejb/trunk/ openejb3/container/openejb-jee/src/test/resources/geronimo- openejb-converted.xml It was a bit of work getting JAXB2 to work with our schemas because of duplicated elements combined with the fact that we allow invalid xml (i.e. no namespace at all). So I actually had to write a invalid 2 valid xml converter before I could get started
Re: Trunk build failure in geronimo-openejb-builder w/ latest OpenEJB3 code
On Feb 6, 2007, at 5:06 AM, anita kulshreshtha wrote: --- Jacek Laskowski [EMAIL PROTECTED] wrote: On 2/6/07, anita kulshreshtha [EMAIL PROTECTED] wrote: This will introduce cyclic dependency between openejb and geronimo build. David B. had an alternate solution. Does it mean that M2 is not able to handle cyclic dependency in a satisfactory manner? I have not tried this to give a definite answer.. The only situation where one would see the effects of this are during an offline build of geronimo and openejb from a clean repo. One must build geronimo until the build fails for openejb, then build openejb and then continue with rest of the geronimo build. The really big issue is at release time, it's an absolute nightmare. The worst. This is a problem that has frustrated everyone and is one of the things we really focused on and fixed in OpenEJB 3 and the new integration (hallelujah!). Here's an email from the not to distant past. http://mail-archives.apache.org/mod_mbox/geronimo-dev/200612.mbox/% [EMAIL PROTECTED] -David I saw the comment of Dave B. where he had said that there should've been more exclude's in OpenEJB's poms. When I compiled OE3 yesterday, I noticed lots of libs of Geronimo from past releases and thought to get rid of them, but didn't have time. I'm investigating it now. Compiling openejb with 1.2-beta is working satisfactorily. the configs and hence assembled servers do not use any 1.2-beta jars. We can continue to do the same as long as it compiles with 1.2-beta. The exclusions do _confuse_ maven about which version of openejb specs to use. The results are different from top, 'modules' and 'geronimo-openejb-builder' directory! Now geronimo and openejb use same version of openejb spec hence this problem is not there. Thanks Anita Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl __ __ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
Re: ClassFinder questions/problems -- annotation processing
On Feb 4, 2007, at 7:19 PM, Tim McConnell wrote:
Hi again Dave, after your recommendation below to do all the
annotation discovery during the installModule phase of deployment
ClassFinder is working much better for me. I do still have another
scenario I'd appreciate some advice on. It seems that when an EJB
EAR file (with embedded JAR and WAR files) gets deployed in
Geronimo, there are two builders invoked: e.g., TomcatModuleBuilder/
AbstractWebModuleBuilder and EJBModuleBuilder such that the
embedded JAR file is not added to the ClassPath/ClassLoader when
the WAR is deployed (I assume this is the way it should work since
I haven't changed it--yet). So, if there are annotations in the WAR
class files pointing to classes in the JAR file, we'll still
encounter NoClassDefException(s). I can just add the JAR files in
the EAR to the classpath of the WAR, which is what I've done to get
around the problem, but I'm not sure this is the best alternative.
Do you have any thoughts?? Thanks much
Those should be added automatically via the deployment system. Very
puzzling. Dain, did you see anything like this when you did that
hack for @EJB annotation support in Servlets?
-David
David Blevins wrote:
On Jan 27, 2007, at 10:20 PM, Tim McConnell wrote:
Hi David, I'm having a couple problems with ClassFinder that I
hope you can help me with.
1 -- I've annotated a number of methods in a serlvlet with the
@Resource annotation, but I'm having some trouble discovering
them in the WAR file just prior to deployment. Doing some
traces I can see that the isAnnotationPresent() check in
ClassFinder.findAnnotatedMethods() is failing. This is a bit
perplexing to me since the @Resource has the RUNTIME retention
policy, and ClassFinder.FindAnnotatedMethods() finds both the
classinfo and the methodinfo. Also, it's not getting a
ClassNotFoundException. Have you seen this before and/or do you
know what might be causing this ??
I'm not sure how you're constructing the ClassFinder, but as I
mentioned to Dain when he hacked the @EJB stuff in for servlets
you definitely want to use the constructor where you pass in the
webapp classloader plus the exact list of URLs to search making
sure you don't search the URLs in any of the parents. The code
that Dain came up with which would also apply would be like this:
ClassLoader webappClassLoader =
module.getEarContext().getClassLoader();
UrlSet urlSet = new UrlSet(webappClassLoader);
if (classLoader instanceof MultiParentClassLoader) {
MultiParentClassLoader multiParentClassLoader
= (MultiParentClassLoader) webappClassLoader;
for (ClassLoader parent :
multiParentClassLoader.getParents()) {
if (parent != null) {
urlSet = urlSet.exclude(parent);
}
}
} else {
ClassLoader parent =
webappClassLoader.getParent();
if (parent != null) {
urlSet = urlSet.exclude(parent);
}
}
ClassFinder finder = new ClassFinder
(webappClassLoader, urlSet.getUrls());
Then when you call ...
finder.findAnnotatedMethod(javax.annotation.Resource.class)
it should return the methods for all classes in the webapp that
use javax.annotation.Resource. If it doesn't, definitely make
sure the webapp doesn't have the annotation spec jar in the WEB-
INF/lib/ directory. The easiest way to check for that is to
simply...
ClassLoader webappClassLoader = module.getEarContext
().getClassLoader();
Class resourceAnnotation = webappClassLoader.loadClass
(javax.annotation.Resource);
assert javax.annotation.Resource.class.equals(resourceAnnotation);
If that assertion fails, than something is going very wrong with
the webapp classloader and definitely nothing annotation related
will work.
2 -- I've also noticed that when I annotate a class that extends
another class, then the ClassFinder will fail with a
NoClassFoundException on the class that is extended. I assume
this is because the extended classes are not in the WAR file that
is getting deployed. I create my own classloader and create a
ClassFinder instance by passing it the URL of the WAR file itself
(plus the URL of any embedded JAR files in the WAR) and don't use
a parent classloader. My quandary is that I'm trying to discover
these annotation prior to deployment so I'm not sure I have a
parent or system classloader I can use to find these extended
classes. Do you have any recommendations ??
Yea, you really won't be able to do any annotation processing
during or before the createModule phase of deployment as there are
no classloaders. It's pretty much a hard wall with no way past.
Kind of frustrating. I noticed in your proposals
Re: branches/1.2 build failing; missing org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-M2-SNAPSHOT
On Feb 6, 2007, at 6:38 PM, David Jencks wrote:
Offhand I'd guess this is related to the problem we had with the
openejb container pom recently haven't kept up with whether the
maven guys have done anything about it.
Has everyone voted for
http://jira.codehaus.org/browse/MNG-2796
Voted. And as I vote for the readers, I know for a fact the maven
guys monitor/fix the issues with the highest votes -- i wrote the
script they use to do that reporting.
Rock the vote.
-David
?
thanks
david jencks
On Feb 6, 2007, at 6:22 PM, Jason Dillon wrote:
Weird... I think I must have checked yoko-rmi, not yoko-rmi-spec,
as I do see plenty of 1.0-incubating-M2-SNAPSHOT artifacts in here:
http://people.apache.org/repo/m2-snapshot-repository/org/
apache/yoko/yoko-rmi-spec/1.0-incubating-M2-SNAPSHOT/
Erg... wtf... how can we fix this? Anyone know of a workaround?
Or do we need to lean on the Maven team to fix this?
Until this is fixed I can't build any new CTS servers or run new
TCK testsuites on the latest codebase :-(
--jason
On Feb 6, 2007, at 6:05 PM, Dain Sundstrom wrote:
Notice the strange message:
1) org.apache.geronimo.configs:client-corba-yoko:car:1.2-SNAPSHOT
2) org.apache.yoko:yoko-rmi-impl:jar:1.0-incubating-M2-SNAPSHOT
3) org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-
M2-20070206.145504-10
The version changes from a SNAPSHOT to a timestamp dependency.
The timestamp dependency is in the repo but with the wrong build
number (not 11 instead of 10):
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
yoko/yoko-rmi-spec/1.0-incubating-M2-SNAPSHOT/yoko-rmi-spec-1.0-
incubating-M2-20070206.145504-11.jar
It looks like yet another wacky maven snapshot bug.
-dain
On Feb 6, 2007, at 5:44 PM, Jason Dillon wrote:
Appears that 'org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-
M2-SNAPSHOT' is missing.
Can someone from the Yoko team publish the latest 1.0-incubating-
M2-SNAPSHOT snapshots please?
snip
[INFO]
---
-
[INFO] Building Geronimo Configs :: Corba J2EE Client
[INFO]task-segment: [install]
[INFO]
---
-
[INFO] [tools:require-java-version {execution: validate-java-
version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/anthill/anthill3/agent/var/jobs/
projects/Geronimo_Server/build_1_2/project/configs/client-corba-
yoko/target/classes/META-INF
[INFO] Copying 2 files to /home/anthill/anthill3/agent/var/jobs/
projects/Geronimo_Server/build_1_2/project/configs/client-corba-
yoko/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/anthill/anthill3/agent/var/jobs/projects/
Geronimo_Server/build_1_2/project/configs/client-corba-yoko/
target/plan/plan.xml
[INFO] snapshot org.apache.yoko:yoko-rmi-impl:1.0-incubating-M2-
SNAPSHOT: checking for updates from apache-snapshots
[INFO] snapshot org.apache.yoko:yoko-rmi-impl:1.0-incubating-M2-
SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.yoko:yoko-rmi-impl:1.0-incubating-M2-
SNAPSHOT: checking for updates from apache.snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-rmi-impl/1.0-incubating-M2-
SNAPSHOT/yoko-rmi-impl-1.0-incubating-M2-20070206.145504-10.pom
1K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2-
SNAPSHOT/yoko-spec-corba-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository apache-
snapshots (http://people.apache.org/repo/m2-snapshot-repository)
Downloading: http://snapshots.repository.codehaus.org/org/apache/
yoko/yoko-spec-corba/1.0-incubating-M2-SNAPSHOT/yoko-spec-
corba-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository codehaus-
snapshots (http://snapshots.repository.codehaus.org)
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2-
SNAPSHOT/yoko-spec-corba-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository
apache.snapshots (http://people.apache.org/repo/m2-snapshot-
repository)
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-rmi-spec/1.0-incubating-M2-
SNAPSHOT/yoko-rmi-spec-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository apache-
snapshots (http://people.apache.org/repo/m2-snapshot-repository)
Downloading: http://snapshots.repository.codehaus.org/org/apache/
yoko/yoko-rmi-spec/1.0-incubating-M2-SNAPSHOT/yoko-rmi-spec-1.0-
incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository
Re: branches/1.2 build failing; missing org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-M2-SNAPSHOT
On Feb 6, 2007, at 6:44 PM, David Blevins wrote:
On Feb 6, 2007, at 6:38 PM, David Jencks wrote:
Offhand I'd guess this is related to the problem we had with the
openejb container pom recently haven't kept up with whether
the maven guys have done anything about it.
Has everyone voted for
http://jira.codehaus.org/browse/MNG-2796
Voted. And as I vote for the readers, I know for a fact the maven
guys monitor/fix the issues with the highest votes -- i wrote the
script they use to do that reporting.
That was supposed to be And as a note to for the readers... Not
enough sleep lately :)
-David
Rock the vote.
-David
?
thanks
david jencks
On Feb 6, 2007, at 6:22 PM, Jason Dillon wrote:
Weird... I think I must have checked yoko-rmi, not yoko-rmi-spec,
as I do see plenty of 1.0-incubating-M2-SNAPSHOT artifacts in here:
http://people.apache.org/repo/m2-snapshot-repository/org/
apache/yoko/yoko-rmi-spec/1.0-incubating-M2-SNAPSHOT/
Erg... wtf... how can we fix this? Anyone know of a workaround?
Or do we need to lean on the Maven team to fix this?
Until this is fixed I can't build any new CTS servers or run new
TCK testsuites on the latest codebase :-(
--jason
On Feb 6, 2007, at 6:05 PM, Dain Sundstrom wrote:
Notice the strange message:
1) org.apache.geronimo.configs:client-corba-yoko:car:1.2-
SNAPSHOT
2) org.apache.yoko:yoko-rmi-impl:jar:1.0-incubating-M2-SNAPSHOT
3) org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-
M2-20070206.145504-10
The version changes from a SNAPSHOT to a timestamp dependency.
The timestamp dependency is in the repo but with the wrong build
number (not 11 instead of 10):
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
yoko/yoko-rmi-spec/1.0-incubating-M2-SNAPSHOT/yoko-rmi-spec-1.0-
incubating-M2-20070206.145504-11.jar
It looks like yet another wacky maven snapshot bug.
-dain
On Feb 6, 2007, at 5:44 PM, Jason Dillon wrote:
Appears that 'org.apache.yoko:yoko-rmi-spec:jar:1.0-incubating-
M2-SNAPSHOT' is missing.
Can someone from the Yoko team publish the latest 1.0-
incubating-M2-SNAPSHOT snapshots please?
snip
[INFO]
--
--
[INFO] Building Geronimo Configs :: Corba J2EE Client
[INFO]task-segment: [install]
[INFO]
--
--
[INFO] [tools:require-java-version {execution: validate-java-
version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir: /home/anthill/anthill3/agent/var/jobs/
projects/Geronimo_Server/build_1_2/project/configs/client-corba-
yoko/target/classes/META-INF
[INFO] Copying 2 files to /home/anthill/anthill3/agent/var/jobs/
projects/Geronimo_Server/build_1_2/project/configs/client-corba-
yoko/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated: /home/anthill/anthill3/agent/var/jobs/
projects/Geronimo_Server/build_1_2/project/configs/client-corba-
yoko/target/plan/plan.xml
[INFO] snapshot org.apache.yoko:yoko-rmi-impl:1.0-incubating-M2-
SNAPSHOT: checking for updates from apache-snapshots
[INFO] snapshot org.apache.yoko:yoko-rmi-impl:1.0-incubating-M2-
SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.yoko:yoko-rmi-impl:1.0-incubating-M2-
SNAPSHOT: checking for updates from apache.snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-rmi-impl/1.0-incubating-M2-
SNAPSHOT/yoko-rmi-impl-1.0-incubating-M2-20070206.145504-10.pom
1K downloaded
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2-
SNAPSHOT/yoko-spec-corba-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository apache-
snapshots (http://people.apache.org/repo/m2-snapshot-repository)
Downloading: http://snapshots.repository.codehaus.org/org/
apache/yoko/yoko-spec-corba/1.0-incubating-M2-SNAPSHOT/yoko-
spec-corba-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository codehaus-
snapshots (http://snapshots.repository.codehaus.org)
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2-
SNAPSHOT/yoko-spec-corba-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository
apache.snapshots (http://people.apache.org/repo/m2-snapshot-
repository)
Downloading: http://people.apache.org/repo/m2-snapshot-
repository/org/apache/yoko/yoko-rmi-spec/1.0-incubating-M2-
SNAPSHOT/yoko-rmi-spec-1.0-incubating-M2-20070206.145504-10.pom
[WARNING] Unable to get resource from repository apache-
snapshots (http://people.apache.org/repo/m2-snapshot-repository)
Downloading: http://snapshots.repository.codehaus.org/org/
apache
Re: openejb3 and web services
On Jan 10, 2007, at 11:21 AM, David Blevins wrote: On Jan 9, 2007, at 8:44 PM, Jarek Gawor wrote: On 1/9/07, David Blevins [EMAIL PROTECTED] wrote: On Jan 9, 2007, at 7:28 AM, David Jencks wrote: On Jan 9, 2007, at 10:19 AM, Jarek Gawor wrote: Hi, I'm looking into integrating CXF with OpenEJB (OpenEJB3 specifically as that's the version that supposed to be integrated in M2). I see that OpenEJB2 has a bunch of code for web services support that's based on Axis1. However, I do not see such code for OpenEJB3. So I'm wondering what that means exactly as we still need support for JAX-RPC-based web services in 2.0. Perhaps the code hasn't been ported over yet or I'm just not finding the right code? Can someone please clarify? I think no one has looked at porting the code yet, but I could be wrong. I hope that whatever we come up with for openejb3 can work with axis1, cxf, and axis2, but I don't yet have an idea if this is practical. Right, it's not ported yet. Do you think this will be ported over before M2? We're most likely looking at M3 for that. Ok, I'm looking at this a bit now and have some initial thoughts. I think the easiest way to get started is to just forget about the handler chain for the moment and write something that can wrap and delegate to an org.apache.openejb.RpcContainer. Unmarshal the args from xml and pass them in as the arg list, then take the return value and create the SOAP response. Or if the invocation resulted in an exception thrown from the invoke method, take the exception and create a soap fault. The more I think about the j2ee 1.4 web service handler chain the more I know we want to do have that done via the new EJB 3 interceptors, which is what the new javaee 5 web services use. We can get started with what we have now and get basic invocations to work. Once the EJB 3 interceptor code is in place we can flip the unmarshalling/marshalling inside out and find a way to do it after the interceptor stack rather than before, very likely using an interceptor. -David -David
Re: Deployment Plan-openejb.jar
On Feb 6, 2007, at 8:57 PM, Kanchana Welagedara wrote: Hi Dan Thanks for your suggestion.We are hoping to complete the docs for G1.2 and then start working on G2.0.Basically the document migration will happen based on the content and the structure of v1.1 with needful enhancements.So by the time of end of completing the G1.2 hope deployment plans for G2.0 will be fixed. Obviously the affects of Geronimo implementation of openejb-3 we might have to come up with new sample applications and more contents.I'm in process trying out those.So that's the plan. I'm not sure I know how to read that response, so I'll just reiterate. What Dain means to say is please do not guide users to use the v3 plan at all for the near term. We do have and will maintain a converter for the v2 plans over the long term, but as the v3 plan changes (there are several things on that list) there will be no old v3 to new v3 converter. So users who stick with the v2 plan will be able to ride out the changes. And so far there are no extra things available in the v3 plan that would make for a good argument for choosing that over the v2 plan -- the opposite actually. There are several parts of the v2 plans which are not yet hooked up and will be over the near term. Hope that helps your planning! Thanks, -David Thanks and Regards Kanchana On Tue, 2007-02-06 at 20:05 -0800, Dain Sundstrom wrote: I strongly suggest you do not attempt to document the geronimo- openejb.xml plan in 2.0 yet as it has not been finalized and is likely to change drastically. -dain On Feb 6, 2007, at 7:33 PM, Karthiga Ratnam wrote: I'm in the process of re doing them for 1.2. Will update the docs as soon as possible. Regards Karthiga On 2/6/07, Hernan Cunico [EMAIL PROTECTED] wrote:VERY NICE GUYS ! Lot of info. It will be really great to have all these plans covered in 1.2 and 2.0 Cheers! Hernan Kanchana Welagedara wrote: Hi All Where to start ? Start from the Beginning-Allice in wonderland. So I started from the beginning from v1.1.This is the deployment plan-openejb.jar documentation for the geronimo v1.1.This document is being part and partial with sample application section and used them to describe the deployment plans for EJB application. http://cwiki.apache.org/GMOxDOC11/openejb-jarxml.html It's not only me, Karthiga( [EMAIL PROTECTED]) worked on the text formatting and diagrams in this article. I will continue to upgrade this document further for the more topics Geronimo v1.2 and GV2.0 as well. Thanks and Regards Kanchana
Re: 3rd consecutive day with build breaks!
On Feb 7, 2007, at 6:06 AM, Sachin Patel wrote: So we've had alot of recent build breaks, IIRC, this is the third day in a row. In most cases, these breaks are caused by something that got overlooked, either forgetting to check in files, publishing snapshots, etc.. Though these issues are small, they tend to cause disruption and block day to day progression. These break-ages can be easily avoided with people being more careful and taking necessary steps to prevent this. (1) If there are changes to external dependencies, make sure these dependencies are published prior to commiting. Many of us are committers in other projects and the tendency is to rely on locally built snapshots of those rather then published snapshots. FYI, I've been doing that pretty much continuously with OpenEJB (i've got a setup on people for publishing). Not sure what happened to last night's build/publish. -David (2) Make sure you're committing all necessary files if new files are introduced. To ensure this, if that means doing a new checkout and build of the tree to ensure that nothing got missed, then this would be good habit :) (3) Always try to do a full build. I know sometimes is easy to think, hey this is a one line change, it won't break anything, but I think its better to take these types of protective measures. I think taking an additional 15-20 minutes by each of us to first build is well worth the time to avoid the hours it can take to resolve the simplest of build breaks. (4) Periodically everyone should run builds with clean repositories so we can catch any overlooked dependency issues early. Is there anything else that we can do to minimize breakage's? Thanks. -sachin
Re: @EJB Deployment Plan
On Feb 7, 2007, at 10:47 PM, Tim McConnell wrote: jav:ejb-local-ref jav:ejb-ref- nameorg.apache.geronimo.samples.calculator.CalculatorServlet/calc/ jav:ejb-ref-name jav:local- homeorg.apache.geronimo.samples.slsb.calculator.CalculatorLocal/ jav:local-home jav:injection-target jav:injection-target- classorg.apache.geronimo.samples.calculator.CalculatorServlet/ jav:injection-target-class jav:injection-target-namecalc/jav:injection-target-name /jav:injection-target /jav:ejb-local-ref You've got the Calculator's ejb3 business interface marked as an ejb2 home interface. Just s/local-home/local/ and it should work. -David
Re: Where are the specs, esp. EJB 3.0 and JPA 1.0?
The bigger question is do our tcks match because the javaee5 tck definitely has that field as non-final. Made a comment on that issue, hopefully Marc can shed some light on it. -David On Feb 8, 2007, at 4:08 PM, Jacek Laskowski wrote: Hi, Just saw the issue reported by Marc (from OpenJPA) and as I thought I'd apply the patch, I realized I couldn't the specs. geronimo/specs/trunk contains only a few. Where are the others? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: svn commit: r505624 - in /geronimo/server/trunk: ./ assemblies/geronimo-jetty6-jee5/src/main/var/config/ assemblies/geronimo-tomcat6-jee5/src/main/var/config/ configs/axis-deployer/src/plan/ confi
On Feb 9, 2007, at 8:25 PM, Jarek Gawor wrote: David, Did you just disable support for Servlet-based WS? If so, why? No. Are they not working anymore? -David Jarek On 2/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: dblevins Date: Fri Feb 9 19:52:38 2007 New Revision: 505624 URL: http://svn.apache.org/viewvc?view=revrev=505624 Log: Ported Axis1 integration Added: geronimo/server/trunk/modules/geronimo-axis-builder/src/main/ java/org/apache/geronimo/axis/builder/AxisModuleBuilderExtension.java geronimo/server/trunk/modules/geronimo-axis/src/main/java/org/ apache/geronimo/axis/server/EjbWebServiceGBean.java geronimo/server/trunk/modules/geronimo-j2ee-builder/src/main/ java/org/apache/geronimo/j2ee/deployment/ModuleBuilderExtension.java Modified: geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ var/config/config.xml geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ main/var/config/config.xml geronimo/server/trunk/configs/axis-deployer/src/plan/plan.xml geronimo/server/trunk/configs/openejb-deployer/src/plan/plan.xml geronimo/server/trunk/configs/openejb/pom.xml geronimo/server/trunk/modules/geronimo-axis-builder/pom.xml geronimo/server/trunk/modules/geronimo-axis/pom.xml geronimo/server/trunk/modules/geronimo-axis/src/main/resources/ META-INF/geronimo-dependency.xml geronimo/server/trunk/modules/geronimo-openejb-builder/src/ main/java/org/apache/geronimo/openejb/deployment/ EjbModuleBuilder.java geronimo/server/trunk/modules/geronimo-openejb/src/main/java/ org/apache/geronimo/openejb/EjbDeployment.java geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/ src/main/var/config/config.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/ geronimo-jetty6-jee5/src/main/var/config/config.xml? view=diffrev=505624r1=505623r2=505624 = = --- geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ var/config/config.xml (original) +++ geronimo/server/trunk/assemblies/geronimo-jetty6-jee5/src/main/ var/config/config.xml Fri Feb 9 19:52:38 2007 @@ -142,17 +142,6 @@ namePersistenceUnitBuilder/name /pattern /reference -reference name=WebServiceBuilder -pattern -nameCXFBuilder/name -/pattern -pattern -nameAxis2Builder/name -/pattern -pattern -nameWebServiceBuilder/name -/pattern -/reference /gbean gbean name=EjbRefBuilder attribute name=eeNamespaceshttp://java.sun.com/ xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute Modified: geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/ src/main/var/config/config.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/ geronimo-tomcat6-jee5/src/main/var/config/config.xml? view=diffrev=505624r1=505623r2=505624 = = --- geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ main/var/config/config.xml (original) +++ geronimo/server/trunk/assemblies/geronimo-tomcat6-jee5/src/ main/var/config/config.xml Fri Feb 9 19:52:38 2007 @@ -149,17 +149,6 @@ namePersistenceUnitBuilder/name /pattern /reference -reference name=WebServiceBuilder -pattern -nameCXFBuilder/name -/pattern -pattern -nameAxis2Builder/name -/pattern -pattern -nameWebServiceBuilder/name -/pattern -/reference /gbean gbean name=EjbRefBuilder attribute name=eeNamespaceshttp://java.sun.com/ xml/ns/j2ee,http://java.sun.com/xml/ns/javaee/attribute Modified: geronimo/server/trunk/configs/axis-deployer/src/plan/ plan.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ axis-deployer/src/plan/plan.xml? view=diffrev=505624r1=505623r2=505624
Re: CORBA ported from OpenEJB 2
On Feb 9, 2007, at 10:26 PM, Dain Sundstrom wrote: On Feb 9, 2007, at 2:32 PM, Rick McGuire wrote: Dain Sundstrom wrote: I have ported the OpenEJB 2 CORBA code and updated it to the OpenEJB 3 APIs. The code is contained in three new modules geronimo-corba, geronimo-corba-builder and geronimo-yoko. The CORBA code is highly coupled to Geronimo so I put it in Geronimo. In the future, I would like to split this code into OpenEJB specific code and Geronimo specific code, but that will take a lot of effort that is currently better spent on Jee5. Hopefully, later this year I'll get time to split the code, but CORBA typically has a really low priority. Lastly, the code is ported, but not hooked up. So, it isn't going to work yet for the thousands of you that use CORBA :) For the one person here who does, what does not hooked up actually mean? In other words, how an I going to be spending my time in the near future :-) I figured you would be asking me that :) All of the GBeans, interceptors, delegates, adapters, etc have been ported over and I believe make the correct calls to the OpenEJB 3 deployments and containers. The piece that is not hooked up is deployment. You'll need to hook the EjbModuleBuilder and add the TSS link GBeans. You will also need to enable the CSS naming builder. To do that part just implement the ModuleBuilderExtension interface and you can hook into all phases of the EjbModuleBuilder. -David I'm sure there are other things I missed, but that should be the bulk of the work to hook it up. Of course then there is the TCK to contend with :) -dain`
Re: GERONIMO-2816 patch
On Feb 10, 2007, at 1:23 AM, Tim McConnell wrote: Hi, I've attached a patch and two new classes to the GERONIMO-2816 JIRA that provides support for the @EJB and @EJBs annotations if anyone would like to review. The intent is to demonstrate a final/permanent technique that can be extended and used throughout Geronimo to support annotations for JSR-88. This patch and new code works for Tomcat and circumvents the annotation processing that is currently in EjbRefBuilder (which did not update the deployment descriptor with the discovered annotations, but only updated the JNDI references). I'd appreciate some feedback before I start propagating this technique to the other module builders to support the remainder of the annotations. I already have another subclass ready to support the @Resource annotations but I didn't want to include it in this example since it doesn't demonstrate anything different than the EJBAnnotationHelper subclass, and I'd like to get some feedback first on the the technique. The general technique, which we've discussed before, is pretty straightforward and is summarized here for reference: 1 -- Discover the annotations: I had hoped that we could centralize the discovery of annotations in the Deployer class prior to the createModule phase of deployment, but as David Blevins pointed out this is almost impossible. So it has to be pushed down into the installModule phase of deployment after the necessary classloader (s) and module context(s) have been established (see the changes for AbstractWebModuleBuilder for an example). 2 -- Process the annotations: This just means to update the existing deployment descriptor (or create a new one) with the discovered annotations. 3 -- Set metadata-complete in the deployment descriptor to prevent repeated processing of annotations (see the EjbRefBuilder changes for an example) 4 -- Update the deployment descriptor in the module so that it can flow through the remainder of the deployment process much as before (for JNDI naming and resolution, and to remain with module in support of the JSR-77 requirements for management). Hey Tim, very clean and well documented code. I think we'll have to strip out all the documentation to comply with Geronimo's strict no javadoc policy ;) Couple notes. We should be able to get rid of the @EJB for Web processing in the EjbRefBuilder, no? That was there as temporary hack and wasn't meant to last. You definitely have all the right code in the EJBAnnotationHelper for Web/@EJB processsing. Other note is you definitely want to construct the ClassFinder exactly once for a module as each time it's constructed we'll have to reparse all the class definitions in the entire module which is especially nasty for web modules as there tend to be a lot of libraries in WEB-INF/lib and WEB-INF/classes. I mention that as a cautionary note as from the looks of where you're going each AnnotationHelper would create it's own finder in it's constructor. We may want to create the ClassFinder and pass it into the AnnotationHelpers and/or put it in the Module somewhere for all to use if they need it. -David -- Thanks, Tim McConnell
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
On Feb 10, 2007, at 3:02 PM, David Jencks wrote: The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Should be easy to fix. Is there an offline deployer somewhere I can update? -David
Re: New openejb deployer has very different assumptions than the rest of the deployment system-- not compatible with offline deployment
On Feb 11, 2007, at 4:04 PM, David Jencks wrote: On Feb 10, 2007, at 6:54 PM, David Blevins wrote: On Feb 10, 2007, at 3:02 PM, David Jencks wrote: The new trunk openejb-deployer module requires the openejb module to be running (started) due to a reference from the deployer gbean to the OpenEjbSystem gbean. This means that you need an entirely started geronimo server to deploy any ejbs. In particular this is inconsistent with the idea of the offline deployer, which we need to assume won't open any ports. Previously we went to a lot of trouble to make sure that every bit of deployment code ran without any runtime components started. I would like to know if this new dependency is intentional, and essential. I don't think we should introduce such a very large change in philosophy about the geronimo server architecture without discussion. Should be easy to fix. Is there an offline deployer somewhere I can update? The list of modules started for the offline deployer is in var/ config/offline-deployer.list, but gianny has a better way to run the offline deployer in the works. However, I don't see how that is relevant to my comment. Sorry, but I don't really get what to put what where. OpenEJB-wise, I can get you an online deployer and an offline deployer as fast as flicking a switch -- we support both. I'm just trying to understand what do to on the Geronimo side. We only have one config for an openejb-deployer. Do we want an online one (capable of adding containers etc based on the needs of the app) and an offline one or just an offline one or just an online one? I'm cool with whatever. -David
Re: GERONIMO-2816 patch
On Feb 11, 2007, at 6:12 PM, Tim McConnell wrote: HI Dain, thanks for reviewing. Yes, you're right--I am scanning all the classes in the web module for annotations, which might be excessive. I'll take a look at the OpenEJB AnnotationDeployer and DeploymentLoader classes tomorrow and see if I can discern the technique you mention (and then try to emulate it). If I have questions, which is likely, I'll ask. Thanks much It's pretty easy. Essentially I made it so ClassFinder can be constructed with a var-arg list of classes (may also support a plain List, can't remember). When that is done it only searches that set for annotations and doesn't do the whole asm routine to come up with a list of annotated classes. And now that I mention it, if you were to shift to that style of annotation searching you could disregard the comment I made earlier about constructing the ClassFinder exactly once per codebase -- if you could pretty much construct them and throw them away as you like. As far as the patch, there's nothing in there that can't be easily fixed and we're all on the same page, so I can check it in and you can work on your updates or I can wait for a revised patch. Whichever is easiest for you. Let me know. -David Dain Sundstrom wrote: Are you sure you must scan all classes in the web module for @EJB annotations? I don't think it is necessary or what you want to do. I believe that you should only be checking specific classes for the annotation such as all known servlets. This is how we process annotations for EJBs. First we find all EJBs, either listed in the ejb-jar.xml or found by scanning for @Stateless, @Stateful and @MessageDriven. Once we have the list of EJBs we check each class for the presence of the @EJB annotation. In your case, I believe you are scanning for all classes that have the @EJB annotation which will be a much larger number of classes then just the servlets. This over processing of classes can easily lead to naming conflicts. Also, I do not believe that servlet 2.5 has an @Servlet annotation, so I don't think you have to do any general purpose scanning like EJB module must do, which should make web deployment much more efficient. Other than that, the patches look good :) One minor thing to note is we don't use prefixes such as m_ for variables. Good job, -dain On Feb 10, 2007, at 1:23 AM, Tim McConnell wrote: Hi, I've attached a patch and two new classes to the GERONIMO-2816 JIRA that provides support for the @EJB and @EJBs annotations if anyone would like to review. The intent is to demonstrate a final/permanent technique that can be extended and used throughout Geronimo to support annotations for JSR-88. This patch and new code works for Tomcat and circumvents the annotation processing that is currently in EjbRefBuilder (which did not update the deployment descriptor with the discovered annotations, but only updated the JNDI references). I'd appreciate some feedback before I start propagating this technique to the other module builders to support the remainder of the annotations. I already have another subclass ready to support the @Resource annotations but I didn't want to include it in this example since it doesn't demonstrate anything different than the EJBAnnotationHelper subclass, and I'd like to get some feedback first on the the technique. The general technique, which we've discussed before, is pretty straightforward and is summarized here for reference: 1 -- Discover the annotations: I had hoped that we could centralize the discovery of annotations in the Deployer class prior to the createModule phase of deployment, but as David Blevins pointed out this is almost impossible. So it has to be pushed down into the installModule phase of deployment after the necessary classloader(s) and module context(s) have been established (see the changes for AbstractWebModuleBuilder for an example). 2 -- Process the annotations: This just means to update the existing deployment descriptor (or create a new one) with the discovered annotations. 3 -- Set metadata-complete in the deployment descriptor to prevent repeated processing of annotations (see the EjbRefBuilder changes for an example) 4 -- Update the deployment descriptor in the module so that it can flow through the remainder of the deployment process much as before (for JNDI naming and resolution, and to remain with module in support of the JSR-77 requirements for management). -- Thanks, Tim McConnell -- Thanks, Tim McConnell
