Where to find the Geronimo -ApacheDS plugin?
Hello, does anyone know, where to find or dowload the Geronimo -ApacheDS plugin. Originaly it was released on Sun, 16 Mar 2008 22:53:20 -0700 by David Jencks Or should I post the message on the ApacheDS mailing list? Thanks, Frank -- The Geronimo team is pleased to announce the release of the Apache Geronimo - Apache Directory Server plugin 1.0 This plugin allows installing and running the ApacheDS server version 1.5.1 in an Apache Geronimo 2.1 server. The ApacheDS server can be configured through a server.xml file just as with a standalone server. This is the initial release of this plugin. Many thanks -The Geronimo team -- -- View this message in context: http://old.nabble.com/Where-to-find-the-Geronimo--ApacheDS-plugin--tp27254246s134p27254246.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: rfc66 fun
On Jan 20, 2010, at 8:14 PM, Jarek Gawor wrote: David, This patch assumes that the entire gbean data can be loaded either via classSource bundle or configuration bundle. But that's not necessarily true. For example, web module builder setups a gbean for the web app context. That gbean has classSource set to tomcat or jetty configuration. One of the attributes of that gbean is a Map object that represents the jndi context for the application. During deployment different naming builders put objects into that map. These naming builders have totally separate classloaders (from web module builder) so the objects within the Map will be of different classloaders. And that means that during deserialization we can't read in the entire Map object using just the jetty or tomcat configuration. I see what you mean. In 2.2 we handle this by having the naming builders add to the environment so the eventual plugin can load the classes from these additions. My proposed patch is attached. My solution does serialize bundle symbolic names and use PackageAdmin to resolve them but it would be very easy to switch it to another method of resolving the symbolic names. Also, maybe this entire classSource problem goes away if we can use a ClassLoader that delegates to a bunch of Bundles. I think I remember an idea of having, as well as the bundle for the application, another bundle that import everything in the application, and everything needed for the gbeans for the application. On a similar line, maybe we could construct an additional bundle that imports all the packages that are used as we serialize the gbean data. This bundle would be the classSource bundle able to load everything to allow deserializing the gbean data, but it would allow normal osgi mechanisms to work to figure out where the classes are actually coming from. I'd guess that instead of writing the bundle symbolic name with each class, we could collect the packages and then use them for a manifest import-Package clause. Do you think this might be worth pursuing? I'm fine with just applying your proposal while we think about this more. thanks david jencks Jarek On Wed, Jan 20, 2010 at 5:44 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 20, 2010, at 11:38 AM, Jarek Gawor wrote: Hey, For last few days I've been looking into getting the rfc66 extender going in Geronimo but I ran into a problem. As previously mentioned on this list, the idea for the extender was to call the Tomcat/Jetty ModuleBuilders with a bundle as an input and once the deployment process was done start the generated configuration. All without creating any additional temporary or permanent bundles. Because we don't have a single classloader that can load all the gbeans within the configuration, David Jencks added a special classSource attribute to GBeanData which can be used to figure out the right Bundle to load the gbean class. Now, since we use Java serialization to save and load gbeans, we actually need to set the right classloader when we deserialize the gbean. That is, during deserialization as soon as we read the classSource we need to lookup and set the right classloader and then read the rest of the gbean data. This should (and seems to) work when all the attributes of the gbean are accessible from the same classloader. But what about if the gbean has some attribute with some values from different classloaders? For example, the Map object we build for jndi context can contain objects from different classloaders. I'm not exactly sure what to do about it. Although maybe having a custom ObjectOutputStream with annotateClass() method that saves classSource type of info for each unique class might work. Ideas? Also, I'm dealing with lots of classloader issues since there is no single classloader that load all the gbean classes and module classes. A lot of Geronimo and other code assumes a single classloader and resolving these problems is time consuming and not very fun (although probably good in long term). So I'm wondering if we can still somehow assemble a single classloader in the extender. For example, the http://www.osgi.org/blog/2008/08/classy-solutions-to-tricky-proxies.html post shows a classloader that delegates a number of different bundles. Maybe we could use that in Geronimo especially since we can figure out the bundles needed from the configuration environment information. Thoughts? Jarek I think that we are either going to load the gbean from the classSource bundle or from the configuration's bundle. Maybe sometimes we need to mix them... not sure. Anyway I think we can modify the ObjectInputStreamExt to look in the classSource's bundle or in the bundle as in the attached patch. I chatted with Jarek a bit on irc and I think he is thinking of writing the bundle symbolic name into the output stream and using package admin to look it up again. I'm a little worried
Re: Where to find the Geronimo -ApacheDS plugin?
You mean this one? http://repo1.maven.org/maven2/org/apache/geronimo/plugins/geronimo-directory/1.0/ It hasn't been updated to work with recent apacheds or geronimo versions. It should be moderately easy to update, if you'd like to take a look the geronimo project is here: https://svn.apache.org/repos/asf/geronimo/plugins/directory/trunk thanks david jencks On Jan 21, 2010, at 12:18 AM, frapien wrote: Hello, does anyone know, where to find or dowload the Geronimo -ApacheDS plugin. Originaly it was released on Sun, 16 Mar 2008 22:53:20 -0700 by David Jencks Or should I post the message on the ApacheDS mailing list? Thanks, Frank -- The Geronimo team is pleased to announce the release of the Apache Geronimo - Apache Directory Server plugin 1.0 This plugin allows installing and running the ApacheDS server version 1.5.1 in an Apache Geronimo 2.1 server. The ApacheDS server can be configured through a server.xml file just as with a standalone server. This is the initial release of this plugin. Many thanks -The Geronimo team -- -- View this message in context: http://old.nabble.com/Where-to-find-the-Geronimo--ApacheDS-plugin--tp27254246s134p27254246.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: console broken in trunk?
The new admin console depends on dojo. I've added the dojo dependencies to console-tomcat and console-jetty to enable the navigation tree. To pick up the changes quickly, please just: 1, svn up plugins 2, build plugins/dojo 3, build plugins/console On Thu, Jan 21, 2010 at 8:49 AM, David Jencks david_jen...@yahoo.comwrote: I fixed a split package problem and the defaultPageId. Now if I start the server from plugins/console/console-jetty-server I get an error about Module 15/15 org.apache.geronimo.plugins/plugin-console-jetty/3.0-SNAPSHOT/car Exception in thread Timer-32 java.lang.LinkageError: loader constraint violation: loader (instance of org/apache/felix/framework/ModuleImpl$ModuleClassLoader) previously initiated loading for a different type with name org/apache/xmlbeans/SchemaType which I'm not too worried about. Then, if I visit http://localhost:8080/console in firefox I get to the login page and can login. Then I see what looks like the skin with an empty navigation tree and no actual portlet page displayed. On the other hand if I go to http://localhost:8080/console/portal/0/Welcome I get what looks like the welcome page but with no skin or navigation tree. Could someone who knows how the javascript is supposed to work take a look? thanks david jencks On Jan 20, 2010, at 6:05 AM, Ivan wrote: Just tried to create a tomcat assembly with console, although there are some errors backgound, I could see the login page and I could login with Firefox. The page is not displayed correclty, but from the HTML source codes, most functions should work as expected. 2010/1/20 Ivan xhh...@gmail.com Fix the The failed Tomcat cluster case at rev.901175, it is caused by some code changes in Tomcat 7. 2010/1/20 Ivan xhh...@gmail.com I got the failed ClusteredManagerTest unit case, too. Will check what's wrong. For automated build, from the recent daily report message, it was always caused by failing to downloading some servicemix snapshots. Not sure all those snapshots could be found anywhere, for I always build those artifacts from source codes on my own machine. 2010/1/20 David Jencks david_jen...@yahoo.com I think we need to get our automated builds working and set up some kind of simple way to see if the test servers start without major errors. I'm having a test failure in plugins/tomcat/geronimo-tomcat7-clustering-wadi/src/test/java/org/apache/geronimo/tomcat/cluster/ClusteredManagerTest.java which I can't understand and after I disable the failing test the server builds and the console-jetty-server sort of starts but looking at the console gives HTTP ERROR 500 Problem accessing /console/portal/welcome. Reason: PageConfig for render path [/welcome] could not be found. Caused by: javax.servlet.ServletException: PageConfig for render path [/welcome] could not be found. at org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:179) at javax.servlet.http.HttpServlet.service(HttpServlet.java:575) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:532) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1232) at org.apache.geronimo.console.filter.RedirectByHashFilter.doFilter(RedirectByHashFilter.java:116) ... I suspect that this might be caused by the changes I made recently to load the gbean classes from a specified plugin rather than the app's bundle: the welcome app worked but I didn't test the console. In any case I wondered if anyone else has the console working or if they see a similar error. I'm happy to work on fixing it but I'd like to check that it isn't caused by something odd in my environment. thanks david jencks -- Ivan -- Ivan -- Ivan -- Shawn
[jira] Resolved: (GERONIMO-4948) To migrate existing geronimo gshell commands to karaf based shell.
[ https://issues.apache.org/jira/browse/GERONIMO-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Jiang resolved GERONIMO-4948. --- Resolution: Fixed Fix Version/s: 3.0 Migrated the commands from gshell to karaf shell. There are still some problems when executing the migrated commands under karaf due to broken JSR-88 Implementations after the OSGI enablement. But it is not a problem that this JIRA can cover. To migrate existing geronimo gshell commands to karaf based shell. -- Key: GERONIMO-4948 URL: https://issues.apache.org/jira/browse/GERONIMO-4948 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: commands, osgi Affects Versions: 3.0 Reporter: Shawn Jiang Assignee: Shawn Jiang Fix For: 3.0 Basically, we need to 1, Migrate all existing pre-3.0 gshell commands to the new karaf based shell in G3.0 2, Keep the same gsh/gsh.bat script external behavior at the same time. 3, Remove gshell from G3.0. See details discussion here: http://old.nabble.com/Is-there-any-plan-to-migrate-existing-geronimo-shell-commands-from--gshell-to-karaf-shell-in-geronimo-3.0---td26190578s134.html#a26226486 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: rfc66 fun
2010/1/21 David Jencks david_jen...@yahoo.com On Jan 20, 2010, at 8:14 PM, Jarek Gawor wrote: David, This patch assumes that the entire gbean data can be loaded either via classSource bundle or configuration bundle. But that's not necessarily true. For example, web module builder setups a gbean for the web app context. That gbean has classSource set to tomcat or jetty configuration. One of the attributes of that gbean is a Map object that represents the jndi context for the application. During deployment different naming builders put objects into that map. These naming builders have totally separate classloaders (from web module builder) so the objects within the Map will be of different classloaders. And that means that during deserialization we can't read in the entire Map object using just the jetty or tomcat configuration. I see what you mean. In 2.2 we handle this by having the naming builders add to the environment so the eventual plugin can load the classes from these additions. My proposed patch is attached. My solution does serialize bundle symbolic names and use PackageAdmin to resolve them but it would be very easy to switch it to another method of resolving the symbolic names. Also, maybe this entire classSource problem goes away if we can use a ClassLoader that delegates to a bunch of Bundles. I think I remember an idea of having, as well as the bundle for the application, another bundle that import everything in the application, and everything needed for the gbeans for the application. On a similar line, maybe we could construct an additional bundle that imports all the packages that are used as we serialize the gbean data. This bundle would be the classSource bundle able to load everything to allow deserializing the gbean data, but it would allow normal osgi mechanisms to work to figure out where the classes are actually coming from. I'd guess that instead of writing the bundle symbolic name with each class, we could collect the packages and then use them for a manifest import-Package clause. I agree with this approach, since we choose osgi framework to help the classloading in G3.0, we should not manually do it by ourselves again. And do you mean a fragment bundle or an individual car bundle for each app bundle? -Rex Do you think this might be worth pursuing? I'm fine with just applying your proposal while we think about this more. thanks david jencks Jarek On Wed, Jan 20, 2010 at 5:44 PM, David Jencks david_jen...@yahoo.com wrote: On Jan 20, 2010, at 11:38 AM, Jarek Gawor wrote: Hey, For last few days I've been looking into getting the rfc66 extender going in Geronimo but I ran into a problem. As previously mentioned on this list, the idea for the extender was to call the Tomcat/Jetty ModuleBuilders with a bundle as an input and once the deployment process was done start the generated configuration. All without creating any additional temporary or permanent bundles. Because we don't have a single classloader that can load all the gbeans within the configuration, David Jencks added a special classSource attribute to GBeanData which can be used to figure out the right Bundle to load the gbean class. Now, since we use Java serialization to save and load gbeans, we actually need to set the right classloader when we deserialize the gbean. That is, during deserialization as soon as we read the classSource we need to lookup and set the right classloader and then read the rest of the gbean data. This should (and seems to) work when all the attributes of the gbean are accessible from the same classloader. But what about if the gbean has some attribute with some values from different classloaders? For example, the Map object we build for jndi context can contain objects from different classloaders. I'm not exactly sure what to do about it. Although maybe having a custom ObjectOutputStream with annotateClass() method that saves classSource type of info for each unique class might work. Ideas? Also, I'm dealing with lots of classloader issues since there is no single classloader that load all the gbean classes and module classes. A lot of Geronimo and other code assumes a single classloader and resolving these problems is time consuming and not very fun (although probably good in long term). So I'm wondering if we can still somehow assemble a single classloader in the extender. For example, the http://www.osgi.org/blog/2008/08/classy-solutions-to-tricky-proxies.html post shows a classloader that delegates a number of different bundles. Maybe we could use that in Geronimo especially since we can figure out the bundles needed from the configuration environment information. Thoughts? Jarek I think that we are either going to load the gbean from the classSource bundle or from the configuration's bundle. Maybe sometimes we need to mix them... not sure. Anyway I think we can modify the
[jira] Updated: (GERONIMO-4945) Unable to deploy ejb with custom annotation
[
https://issues.apache.org/jira/browse/GERONIMO-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kaigorodov updated GERONIMO-4945:
Priority: Critical (was: Major)
Unable to deploy ejb with custom annotation
---
Key: GERONIMO-4945
URL: https://issues.apache.org/jira/browse/GERONIMO-4945
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: OpenEJB
Affects Versions: 2.2
Reporter: Alexey Kaigorodov
Priority: Critical
Attachments: test-custom-annotation-ejb-1.0.0-sources.jar,
test-custom-annotation-ejb-1.0.0.jar
Simple tast case:
@Stateless
@Local(Test.class)
@Custom(type = CustomType.A)
public class TestBean implements Test {
@Override
public void foo() {
}
}
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface Custom {
CustomType[] type() default {}; // works fine for non-array CustomType
type();
}
public enum CustomType {
A, B
}
geronimo.log:
2009-11-03 14:05:17,138 ERROR [Deployer] Deployment failed due to
java.lang.ArrayStoreException:
sun.reflect.annotation.AnnotationTypeMismatchExceptionProxy
at
sun.reflect.annotation.AnnotationParser.parseEnumArray(AnnotationParser.java:673)
at
sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:462)
at
sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286)
at
sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222)
at
sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69)
at
sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070)
at java.lang.Class.getAnnotation(Class.java:3029)
at java.lang.Class.isAnnotationPresent(Class.java:3042)
at
org.apache.xbean.finder.ClassFinder.findAnnotatedClasses(ClassFinder.java:241)
at
org.apache.openejb.config.AnnotationDeployer$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:459)
at
org.apache.openejb.config.AnnotationDeployer$DiscoverAnnotatedBeans.deploy(AnnotationDeployer.java:253)
at
org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:188)
at
org.apache.openejb.config.ConfigurationFactory$Chain.deploy(ConfigurationFactory.java:247)
at
org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:601)
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.configureApplication(EjbModuleBuilder.java:635)
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.getEjbJarInfo(EjbModuleBuilder.java:568)
at
org.apache.geronimo.openejb.deployment.EjbModuleBuilder.initContext(EjbModuleBuilder.java:493)
at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:592)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:136)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342)
at sun.reflect.GeneratedMethodAccessor159.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at
[BUILD] trunk: Failed for Revision: 901586
Geronimo Revision: 901586 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100121/build-0300.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20100121/unit-test-reports for artifact: org.apache.geronimo.modules:geronimo-jasper:bundle:3.0-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo2.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.jdt-core:jar:3.2.3_3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.jdt-core -Dversion=3.2.3_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.jdt-core -Dversion=3.2.3_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.modules:geronimo-jasper:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.jdt-core:jar:3.2.3_3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-jasper:bundle:3.0-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org), ibiblio.org (http://repo2.maven.org/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) org.apache.servicemix.bundles:org.apache.servicemix.bundles.jdt-core:jar:3.2.3_3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.jdt-core -Dversion=3.2.3_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.servicemix.bundles -DartifactId=org.apache.servicemix.bundles.jdt-core -Dversion=3.2.3_3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.modules:geronimo-jasper:bundle:3.0-SNAPSHOT 2) org.apache.servicemix.bundles:org.apache.servicemix.bundles.jdt-core:jar:3.2.3_3-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-jasper:bundle:3.0-SNAPSHOT from the specified remote repositories: ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/), apache.snapshots (http
Re: svn commit: r901700 - /geronimo/KEYS
Delos, you need to create a new PGP key that's 4096 bits, instead of the default 1024. Here is some info from a previous posting - Everyone who uploads artifacts (snapshot or release), don't forget that you need to: 1) update your existing PGP keys to avoid using SHA-1 http://www.apache.org/dev/openpgp.html#sha1 2) create a new 4096 bit key for future code signing http://www.apache.org/dev/key-transition.html 3) update/add your key into the KEYS file in svn - geronimo/KEYS 4) upload the updated KEYS file to our distro directory - /www/www.apache.org/dist/geronimo/ -Donald On 1/21/10 8:38 AM, de...@apache.org wrote: Author: delos Date: Thu Jan 21 13:38:06 2010 New Revision: 901700 URL: http://svn.apache.org/viewvc?rev=901700view=rev Log: append public key of delos Modified: geronimo/KEYS Modified: geronimo/KEYS URL: http://svn.apache.org/viewvc/geronimo/KEYS?rev=901700r1=901699r2=901700view=diff == --- geronimo/KEYS (original) +++ geronimo/KEYS Thu Jan 21 13:38:06 2010 @@ -1008,3 +1008,40 @@ WiPNXzqCfvuELA6IUAcu =N6IO -END PGP PUBLIC KEY BLOCK- + +pub 1024D/3D50A4B2 2010-01-21 +uid delos de...@apache.org +sig 33D50A4B2 2010-01-21 delos de...@apache.org +sub 2048g/10EAF5DA 2010-01-21 +sig 3D50A4B2 2010-01-21 delos de...@apache.org + +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.4.9 (GNU/Linux) + +mQGiBEtYHlQRBACsODzmCQRbMlLclxstXLcVfdW9ikMfR5fsAX0gNsEjmcXKX/kz +vljH76DuykeLK2DzeTYj3syL+R0yLEFrXuTF+aVbPH11eXTP1rWWL14NguxZmIfn +Tzzr+v/ndqzLLBkyNWnT/z8t83pHlBDUo/kvfVppKgDHyQ1EKIpdoglWkwCg8Hx8 +wk7PuBcW5QDnQCpIms0DR2UEAIafAVdS0uLj+G9DOqbUAV6Tnf3cvur873+cjb4M +aPUB4CXnF9rwbRWc/jNAZw7yu6KwLMR7lXuy0yB3bJYLzGfh0vFUVS2XlPDMbDYw +2WRxIQHLtQTD/w1YaL5vxu+FKwzaAp7/Ixt2K2HyjDJdtNxsEOWUqkdRXjGNOSxe +IiuUA/9M0Qz1p7/OQJ48AjPI3+KnQyFAewGhjQk2sOtEAB1TuvIAgY2N08f7sLh4 +SvSw/yZUWKMQA6HGHjmY1+mpOplY+AZVLmsp8gOZss9CJ/jwPsx9D7Kmt7hoGXaq +zsyk+pSi/bb31DZX2s2LoYKbh1bXjiFxPas5FQNZmrElkXzh3bQYZGVsb3MgPGRl +bG9zQGFwYWNoZS5vcmc+iGAEExECACAFAktYHlQCGwMGCwkIBwMCBBUCCAMEFgID +AQIeAQIXgAAKCRBaZfiFPVCksqklAJ9F7lcqF5mvpPndTYghVs+bYDs3gACeKoeQ +v2CVmxrivz8O5lsZkSfnO4y5Ag0ES1geWBAIAMLJxGyagLqsSpPARKl8gL6V6wDX +3O0VhwaUPd7hoihuAxQlGr4byUXeQObcq6P4K3rPWhQJgEjBFUjdds/zBvV8lr9q +etxqitXHXVs80tTSzhdVs809ofaR89CuEhubBUpqR1ExOglPuP7FGJRaIrQhxMPm +whHs7v33EbjOViHBBnVNI04k48SAwXSuVzevcAZWNo0U9smnUjFpS57JY0N8AAWN +G5yiABRhwgvovfuShIolI07KOLm59WiXvreAhRj85v3k8GL5z1SJyDromZuiiKao +hCeiWvzdX0fH1snlsQtFtfF7oK8X0oM0KvTNkgjsCGS4JEseMfElFTCO0OsAAwUH +/RhTsYbf5IvmRcfEDRfDATqADgYqheSS7KDhf2gmEBLZkaPtedxYUNaocOyjAQxM +5Ar//4VAeTE1IfPeNe70CYRY9kyHLnNcxyZm1Biuh56xNEJfbYL/Y1mumQHMpW2v +Cyq5GfwdUhMUJFNrQVZ0HsGtOPTObYghOxy1kKNGsyendra+AARWf8YzrP+yEgc1 +Wm878oalf4J2Gt0Jv+QEKDNBHUWh1dTbG+UyAnJxcoL+9QQ7+lKJt2oRpBgCRPC0 +zxeVc1A6+avz7/XnF8GQtfCzu4zXhi7kp+WnJOLu3BCOAXjALOLEt7v9WGRBvOtp +EBLfkZCg1JTzRPMKAJM5CiqISQQYEQIACQUCS1geWAIbDAAKCRBaZfiFPVCkslgG +AKDCE2bxV2FScEFsq+Bq+jCz1pzggACggovY/jhbCvj+NIlOXXMAANsqbdo= +=WjOT +-END PGP PUBLIC KEY BLOCK- +
[jira] Created: (GERONIMO-5040) PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows
PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows --- Key: GERONIMO-5040 URL: https://issues.apache.org/jira/browse/GERONIMO-5040 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.2, 2.1.4 Reporter: Johannes Weberhofer Geronimo should - in my optinion - be started in Java-Mode. In Java (and the currently used exe-Mode) it is necessary to add all important options directly into the startup-arguments fields before the -jar line, which should be noticed in the Wiki. The issue is related to DAEMON-119. At the shutdown page, it is necessary to explicitly select the Java-Mode and set a timeout (30 seconds or so); otherwise the geronimo server will simply be killed without any chance to terminate gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-5040) PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows
[ https://issues.apache.org/jira/browse/GERONIMO-5040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johannes Weberhofer updated GERONIMO-5040: -- Attachment: GERONIMO-5040-service_pr.bat.diff PermGenSpace Problems and shut-down issues when using the Apache Commons Daemon under Windows --- Key: GERONIMO-5040 URL: https://issues.apache.org/jira/browse/GERONIMO-5040 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.1.4, 2.2 Reporter: Johannes Weberhofer Attachments: GERONIMO-5040-service_pr.bat.diff Geronimo should - in my optinion - be started in Java-Mode. In Java (and the currently used exe-Mode) it is necessary to add all important options directly into the startup-arguments fields before the -jar line, which should be noticed in the Wiki. The issue is related to DAEMON-119. At the shutdown page, it is necessary to explicitly select the Java-Mode and set a timeout (30 seconds or so); otherwise the geronimo server will simply be killed without any chance to terminate gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-5036) [OpenEJB] Unable to clear Sun JarFileFactory cache: warning after upgrading to Sun JDK 1.6.0 u18
[ https://issues.apache.org/jira/browse/GERONIMO-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803336#action_12803336 ] fpientka commented on GERONIMO-5036: because of EJB 3.0 G 2.1.4 is also affected from this problem should be fixed in G 2.1.5 [OpenEJB] Unable to clear Sun JarFileFactory cache: warning after upgrading to Sun JDK 1.6.0 u18 Key: GERONIMO-5036 URL: https://issues.apache.org/jira/browse/GERONIMO-5036 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 2.2 Environment: Windows XP Reporter: Johannes Weberhofer Priority: Critical Fix For: 2.2.1 After Upgrading to Sun JDK 1.6.0 u18 the above mentioned warning occures. The bug is filed in OPENEJB-1131, a fix has been provided in the openejb3 svn for ClassLoaderUtil.java with revision number 98 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] GEP 2.2 release - RC3 (3rd try)
Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 2.2 *RC3*. Compared to RC2, RC3 contains source code packages, checksum and signature files for you to review. You can verify the integrity of the files with KEYS from http://www.apache.org/dist/geronimo/KEYS The source code packages are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.tar.gz http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.zip The deployable binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-deployable.zip The update site binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The current svn location is here (revision number 897748): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.2 The future svn location will be here (when approved): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.2 If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/PLUGIN_RELEASE-NOTES-2.2.0.txt There is a rudimentary set of install instructions available at the URL below that will hopefully describe the necessary prereq(s) and steps required to install and run the GEP: http://cwiki.apache.org/GMOxDOC22/how-to-install-geronimo-eclipse-plugin.html In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: http://cwiki.apache.org/GMOxDOC22/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Ganymede or Galileo) of Eclipse for downloading the GEP itself. This is also documented in the instructions, but you must use the staging site created for this vote at: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/updates/ Please let me know if there are any questions and/or problems. The vote is open for 72 hours. [ ] +1 Release Geronimo Eclipse Plugin 2.2 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.2 Thanks in advance! -- Best Regards, Delos
Re: Cancel - [VOTE] GEP 2.2 release - RC3 (3rd try)
Will update PGP keys according to Donald's suggestion. Please ignore the vote for RC3 2010/1/22 Delos dait...@gmail.com Hi everyone, Please review and vote on the release of the Geronimo Eclipse Plugin 2.2 *RC3*. Compared to RC2, RC3 contains source code packages, checksum and signature files for you to review. You can verify the integrity of the files with KEYS from http://www.apache.org/dist/geronimo/KEYS The source code packages are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.tar.gz http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2-source-release.zip The deployable binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-deployable.zip The update site binary zip file is here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/geronimo-eclipse-plugin-2.2.0-updatesite.zip The current svn location is here (revision number 897748): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/branches/2.2 The future svn location will be here (when approved): https://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/2.2 If you would like to review and/or comment on the release notes, they are here: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/PLUGIN_RELEASE-NOTES-2.2.0.txt There is a rudimentary set of install instructions available at the URL below that will hopefully describe the necessary prereq(s) and steps required to install and run the GEP: http://cwiki.apache.org/GMOxDOC22/how-to-install-geronimo-eclipse-plugin.html In an effort to get more people to review and vote I'd recommend going through this quick but useful tutorial demonstrating some of the capabilities of the GEP: http://cwiki.apache.org/GMOxDOC22/5-minute-tutorial-on-enterprise-application-development-with-eclipse-and-geronimo.html Finally, I've created a Staging Site that can be used to test the update manager functions (i.e., p2 in Ganymede or Galileo) of Eclipse for downloading the GEP itself. This is also documented in the instructions, but you must use the staging site created for this vote at: http://people.apache.org/dist/geronimo/eclipse/2.2.0/RC3/staging_site/updates/ Please let me know if there are any questions and/or problems. The vote is open for 72 hours. [ ] +1 Release Geronimo Eclipse Plugin 2.2 [ ] +0 No opinion [ ] -1 Don't release Geronimo Eclipse Plugin 2.2 Thanks in advance! -- Best Regards, Delos -- Best Regards, Delos
Re: svn commit: r901700 - /geronimo/KEYS
OK, thanks Donald. I will re-create the new key. 2010/1/21 Donald Woods dwo...@apache.org Delos, you need to create a new PGP key that's 4096 bits, instead of the default 1024. Here is some info from a previous posting - Everyone who uploads artifacts (snapshot or release), don't forget that you need to: 1) update your existing PGP keys to avoid using SHA-1 http://www.apache.org/dev/openpgp.html#sha1 2) create a new 4096 bit key for future code signing http://www.apache.org/dev/key-transition.html 3) update/add your key into the KEYS file in svn - geronimo/KEYS 4) upload the updated KEYS file to our distro directory - /www/www.apache.org/dist/geronimo/ -Donald On 1/21/10 8:38 AM, de...@apache.org wrote: Author: delos Date: Thu Jan 21 13:38:06 2010 New Revision: 901700 URL: http://svn.apache.org/viewvc?rev=901700view=rev Log: append public key of delos Modified: geronimo/KEYS Modified: geronimo/KEYS URL: http://svn.apache.org/viewvc/geronimo/KEYS?rev=901700r1=901699r2=901700view=diff == --- geronimo/KEYS (original) +++ geronimo/KEYS Thu Jan 21 13:38:06 2010 @@ -1008,3 +1008,40 @@ WiPNXzqCfvuELA6IUAcu =N6IO -END PGP PUBLIC KEY BLOCK- + +pub 1024D/3D50A4B2 2010-01-21 +uid delos de...@apache.org +sig 33D50A4B2 2010-01-21 delos de...@apache.org +sub 2048g/10EAF5DA 2010-01-21 +sig 3D50A4B2 2010-01-21 delos de...@apache.org + +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.4.9 (GNU/Linux) + +mQGiBEtYHlQRBACsODzmCQRbMlLclxstXLcVfdW9ikMfR5fsAX0gNsEjmcXKX/kz +vljH76DuykeLK2DzeTYj3syL+R0yLEFrXuTF+aVbPH11eXTP1rWWL14NguxZmIfn +Tzzr+v/ndqzLLBkyNWnT/z8t83pHlBDUo/kvfVppKgDHyQ1EKIpdoglWkwCg8Hx8 +wk7PuBcW5QDnQCpIms0DR2UEAIafAVdS0uLj+G9DOqbUAV6Tnf3cvur873+cjb4M +aPUB4CXnF9rwbRWc/jNAZw7yu6KwLMR7lXuy0yB3bJYLzGfh0vFUVS2XlPDMbDYw +2WRxIQHLtQTD/w1YaL5vxu+FKwzaAp7/Ixt2K2HyjDJdtNxsEOWUqkdRXjGNOSxe +IiuUA/9M0Qz1p7/OQJ48AjPI3+KnQyFAewGhjQk2sOtEAB1TuvIAgY2N08f7sLh4 +SvSw/yZUWKMQA6HGHjmY1+mpOplY+AZVLmsp8gOZss9CJ/jwPsx9D7Kmt7hoGXaq +zsyk+pSi/bb31DZX2s2LoYKbh1bXjiFxPas5FQNZmrElkXzh3bQYZGVsb3MgPGRl +bG9zQGFwYWNoZS5vcmc+iGAEExECACAFAktYHlQCGwMGCwkIBwMCBBUCCAMEFgID +AQIeAQIXgAAKCRBaZfiFPVCksqklAJ9F7lcqF5mvpPndTYghVs+bYDs3gACeKoeQ +v2CVmxrivz8O5lsZkSfnO4y5Ag0ES1geWBAIAMLJxGyagLqsSpPARKl8gL6V6wDX +3O0VhwaUPd7hoihuAxQlGr4byUXeQObcq6P4K3rPWhQJgEjBFUjdds/zBvV8lr9q +etxqitXHXVs80tTSzhdVs809ofaR89CuEhubBUpqR1ExOglPuP7FGJRaIrQhxMPm +whHs7v33EbjOViHBBnVNI04k48SAwXSuVzevcAZWNo0U9smnUjFpS57JY0N8AAWN +G5yiABRhwgvovfuShIolI07KOLm59WiXvreAhRj85v3k8GL5z1SJyDromZuiiKao +hCeiWvzdX0fH1snlsQtFtfF7oK8X0oM0KvTNkgjsCGS4JEseMfElFTCO0OsAAwUH +/RhTsYbf5IvmRcfEDRfDATqADgYqheSS7KDhf2gmEBLZkaPtedxYUNaocOyjAQxM +5Ar//4VAeTE1IfPeNe70CYRY9kyHLnNcxyZm1Biuh56xNEJfbYL/Y1mumQHMpW2v +Cyq5GfwdUhMUJFNrQVZ0HsGtOPTObYghOxy1kKNGsyendra+AARWf8YzrP+yEgc1 +Wm878oalf4J2Gt0Jv+QEKDNBHUWh1dTbG+UyAnJxcoL+9QQ7+lKJt2oRpBgCRPC0 +zxeVc1A6+avz7/XnF8GQtfCzu4zXhi7kp+WnJOLu3BCOAXjALOLEt7v9WGRBvOtp +EBLfkZCg1JTzRPMKAJM5CiqISQQYEQIACQUCS1geWAIbDAAKCRBaZfiFPVCkslgG +AKDCE2bxV2FScEFsq+Bq+jCz1pzggACggovY/jhbCvj+NIlOXXMAANsqbdo= +=WjOT +-END PGP PUBLIC KEY BLOCK- + -- Best Regards, Delos
Re: failover demo in sandbox
On Jan 20, 2010, at 12:15 AM, Kevan Miller wrote:
3) Geronimo currently requires multicast for the failover scenario.
This is great. However, we should also offer unicast-based support,
also. I frequently encounter users who are unable to use multicast
in their environments. Providing unicast support would be a valuable
addition, I think.
Agreed.
Currently with the way that everything is designed we theoretically
only need to replace this class:
org.apache.geronimo.farm.discovery.MulticastDiscoveryAgent
Which is an implementation of the DiscoveryAgent interface. The
primary job of the DiscoveryAgent is to receive notifications about
services coming and going and then simply notify the other parts of
the system that are interested in this information. These other
parts implement this interface:
public interface DiscoveryListener {
public void serviceAdded(URI service);
public void serviceRemoved(URI service);
}
So basically the new DiscoveryAgent needs to have a way to receive
service added and service removed messages and send that info to
the listener.
It seems that a REST implementation of DiscoveryAgent would be very
useful as a lot of shops use it quite extensively already for various
administration and it actually lines up pretty close. ServiceAdded
might be a PUT and serviceRemoved a DELETE.
Seems with something that simple it wouldn't be too hard to do
anything else that's required to get it to broadcast around.
-David
Re: failover demo in sandbox
On Jan 21, 2010, at 7:49 PM, David Blevins wrote:
On Jan 20, 2010, at 12:15 AM, Kevan Miller wrote:
3) Geronimo currently requires multicast for the failover scenario.
This is great. However, we should also offer unicast-based support,
also. I frequently encounter users who are unable to use multicast
in their environments. Providing unicast support would be a
valuable addition, I think.
Agreed.
Currently with the way that everything is designed we theoretically
only need to replace this class:
org.apache.geronimo.farm.discovery.MulticastDiscoveryAgent
Which is an implementation of the DiscoveryAgent interface. The
primary job of the DiscoveryAgent is to receive notifications about
services coming and going and then simply notify the other parts of
the system that are interested in this information. These other
parts implement this interface:
public interface DiscoveryListener {
public void serviceAdded(URI service);
public void serviceRemoved(URI service);
}
So basically the new DiscoveryAgent needs to have a way to receive
service added and service removed messages and send that info to
the listener.
It seems that a REST implementation of DiscoveryAgent would be very
useful as a lot of shops use it quite extensively already for
various administration and it actually lines up pretty close.
ServiceAdded might be a PUT and serviceRemoved a DELETE.
Seems with something that simple it wouldn't be too hard to do
anything else that's required to get it to broadcast around.
Another approach we could take is a DiscoveryAgent implementation that
is backed by a JMS Topic. It would be a closer match to Multicast,
though we'd have to do some additional work to figure out how to
ensure that the JMS Broker is not a single point of failure. Having
it be a single point of failure initially would be fine, but we would
eventually need to figure that out. ActiveMQ does have some features
in this regard, so it should hopefully be workable.
http://activemq.apache.org/how-do-distributed-queues-work.html
One option.
Bottom line is all we use multicast for is to move URLs around the
network, so some way to do that without multicast is all we need.
-David
Re: OpenJPA 2.0 usable with Geronimo 2.2
There are 2 plugins for 2.2, 2.2.1-SNAPSHOT and 2 for 2.1.3 through 2.1.5-SNAPSHOT (so openjpa2/geronimo-plugins.xml has 4 plugins total), as they have to be built against each branch to handle the different packaging/depends in each. -Donald On 1/21/10 2:30 AM, frapien wrote: Hi Donald, can you please check, because under is still http://geronimo.apache.org/plugins/openjpa2/geronimo-plugins.xml http://geronimo.apache.org/plugins/openjpa2/geronimo-plugins.xml geronimo-version2.1.3/geronimo-version geronimo-version2.1.4/geronimo-version geronimo-version2.1.5-SNAPSHOT/geronimo-version Thank, Frank I've updated the OpenJPA2 plugin for Geronimo 2.2 to support the released 2.2 server and the current 2.2.1-SNAPSHOT server. The plugin still uses OpenJPA 2.0.0-M3, but I'll update it again when either M4 or the final 2.0.0 release is available. -Donald
Re: -EA- in the jee6 spec versions.
On Jan 6, 2010, at 2:50 PM, Rick McGuire wrote: I believe the JEE6 specs have finally gone final. When would be the appropriate time to remove the -EA- indicator from the Geronimo spec jar versions? Noticed you removed the EA on all the specs. We need to do a release of the jcdi and interceptor libraries for an upcoming OWB release. What prefix do you propose as these aren't yet cleared by the final TCK? On a side note, the servlet-3.0 library is still horrendously out of date. Seems like no one has been taking care of it for quite a while. I can send you a report for it on the TCK list. Maybe you or someone will have the time to update it. -David
Re: -EA- in the jee6 spec versions.
On Jan 21, 2010, at 1:23 PM, David Blevins wrote: On Jan 6, 2010, at 2:50 PM, Rick McGuire wrote: I believe the JEE6 specs have finally gone final. When would be the appropriate time to remove the -EA- indicator from the Geronimo spec jar versions? Noticed you removed the EA on all the specs. We need to do a release of the jcdi and interceptor libraries for an upcoming OWB release. What prefix do you propose as these aren't yet cleared by the final TCK? On a side note, the servlet-3.0 library is still horrendously out of date. Seems like no one has been taking care of it for quite a while. I can send you a report for it on the TCK list. Maybe you or someone will have the time to update it. Please send me and/or the tck list details on the servlet spec. I was under the impression that it was completely up to date as several projects have been using it without complaints and IIUC at least one appears to have compared it with the glassfish jar. thanks david jencks -David
Re: about daytrader-web-jpa
OK, made the PersistenceContext - PersistenceUnit change but still no luck running it on a stand-alone Tomcat 6.0.20 I'm still seeing OpenJPA problems in getting the db connection. org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (Failed to start database 'tradedb', see the next exception for details.) -Donald On 1/20/10 2:10 AM, Forrest Xia wrote: Hi Donald, I tried the new assembly of daytrader -- daytrader-web-jpa, and did not get it work. The console log an error: 2010-01-20 14:08:24,774 ERROR [Log] Error: TradeJPADirect:createQuote -- exception creating Quote java.lang.NullPointerException java.lang.NullPointerException at org.apache.geronimo.samples.daytrader.core.direct.TradeJPADirect.createQuote(TradeJPADirect.java:418) at org.apache.geronimo.samples.daytrader.core.TradeAction.createQuote(TradeAction.java:373) at org.apache.geronimo.samples.daytrader.web.TradeBuildDB.init(TradeBuildDB.java:196) at org.apache.geronimo.samples.daytrader.web.TradeConfigServlet.service(TradeConfigServlet.java:411) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:420) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:361) at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Then I had a peek at the code, and think this NPE might be caused by PersistenceContext not injected in TradeJPADirect. Since TradeJPADirect is not a web container managed object(not servlet or context listener), so the annotation @PersistenceContext does not work. I guess daytrader-web-jpa assembly is to demo jpa usage in web module without session EJB involvement. If we want to demo container-managed entity manager via this assembly, we shall use @PersistenceContext on servlet or any web container managed object, then use JNDI lookup to get the entity manager from container. If we want to demo application-managed entity manager, we can use @PersistenceUnit to inject an EntityManagerFactory object in any web container managed object, then use EntityManagerFactory.createEntityManager() to get entity manager. Please kindly let me know your thoughts. Thanks! Forrest
[jira] Commented: (GERONIMO-5025) New module/app/global jndi contexts in javaee 6 spec
[ https://issues.apache.org/jira/browse/GERONIMO-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803554#action_12803554 ] David Jencks commented on GERONIMO-5025: rev 901935 basically does the work described above. There aren't really any tests yet. More stuff to do: 1. detect if an entry is specified twice and object if it is specified differently. 2. find out what is meant for web apps about java:comp and java:module being the same 3. figure out if/how to get the global context available to app clients. Also we could probably have a urlHandler for jca: and ger: contexts. What we used to do was bogus, treating the scheme part as a name component. New module/app/global jndi contexts in javaee 6 spec Key: GERONIMO-5025 URL: https://issues.apache.org/jira/browse/GERONIMO-5025 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: deployment, naming Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Javaee platform spec describes some new jndi java: contexts that are more shared between components. java:comp (existing) java:module java:app java:global My first idea for implementing this: 1. in RootContext, have the thread local represent java: rather than java:comp. So all the namespaces will be in the Context object. 2. Construct this Context by federating objects for each scope. We'll have to maintain a global context somewhere. The others can presumably be constructed during deployment and set up in the existing gbeans for the app components. 3. Modify the naming builders to put stuff into the right namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-5041) Use Aries InitialContextFactoryBuilder
Use Aries InitialContextFactoryBuilder -- Key: GERONIMO-5041 URL: https://issues.apache.org/jira/browse/GERONIMO-5041 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: naming, osgi Affects Versions: 3.0 Reporter: David Jencks Assignee: David Jencks Fix For: 3.0 Aries has a partial implementation of the osgi frc 142 jndi stuff. We should integrate it. One of the bits is an InitaliContextFactoryBuilder that uses the service registry to find appropriate url context factories rather than the unfortunate scheme envisaged by the jndi spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 901960
Geronimo Revision: 901960 built with tests included
See the full build-2100.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100121/build-2100.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20100121/unit-test-reports
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.062 sec
Running org.apache.geronimo.kernel.config.transformer.GroovyTransformerTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.796 sec
Results :
Tests run: 17, Failures: 0, Errors: 0, Skipped: 0
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] [geronimo-osgi:verify-manifest {execution: verify-manifest}]
[INFO] Resolving OSGi bundle:
org.apache.geronimo.framework.geronimo-config-groovy-transformer
[INFO] OSGi bundle is resolved:
org.apache.geronimo.framework.geronimo-config-groovy-transformer
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in:
geronimo-config-groovy-transformer-3.0-SNAPSHOT.jar
[INFO] [install:install {execution: default-install}]
[INFO] Installing
/home/geronimo/geronimo/trunk/framework/modules/geronimo-config-groovy-transformer/target/geronimo-config-groovy-transformer-3.0-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/framework/geronimo-config-groovy-transformer/3.0-SNAPSHOT/geronimo-config-groovy-transformer-3.0-SNAPSHOT.jar
[INFO] [bundle:install {execution: default-install}]
[INFO] Parsing file:/home/geronimo/.m2/repository/repository.xml
[INFO] Installing
org/apache/geronimo/framework/geronimo-config-groovy-transformer/3.0-SNAPSHOT/geronimo-config-groovy-transformer-3.0-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO]
[INFO] Building Geronimo Framework, Modules :: Naming
[INFO]task-segment: [install]
[INFO]
[INFO] [genesis:validate-configuration {execution: default}]
Downloading:
http://repo2.maven.org/maven2/org/apache/xbean/xbean-naming/3.6/xbean-naming-3.6.pom
[WARNING] Component returned which is not the same manager. Ignored.
component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@63f063f0
[WARNING] Component returned which is not the same manager. Ignored.
component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@63f063f0
[WARNING] Component returned which is not the same manager. Ignored.
component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@63f063f0
[WARNING] Component returned which is not the same manager. Ignored.
component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@63f063f0
[WARNING] Component returned which is not the same manager. Ignored.
component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@63f063f0
[WARNING] Component returned which is not the same manager. Ignored.
component=org.apache.maven.profiles.activation.operatingsystemprofileactiva...@63f063f0
Downloading:
http://repo2.maven.org/maven2/org/apache/xbean/xbean-naming/3.6/xbean-naming-3.6.jar
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/framework/modules/geronimo-naming/src/main/resources
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/framework/modules/geronimo-naming/src/main/filtered-resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 30 source files to
/home/geronimo/geronimo/trunk/framework/modules/geronimo-naming/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/home/geronimo/geronimo/trunk/framework/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/FederatedContextGBean.java:[25,38]
cannot find symbol
symbol : class ImmutableFederatedContext
location: package org.apache.xbean.naming.context
/home/geronimo/geronimo/trunk/framework/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/FederatedContextGBean.java:[35,43]
cannot find symbol
symbol: class ImmutableFederatedContext
public class FederatedContextGBean extends ImmutableFederatedContext implements
FederatedContext {
/home/geronimo/geronimo/trunk/framework/modules/geronimo-naming/src/main/java/org/apache/geronimo/naming/enc/EnterpriseNamingContext.java:[34,38]
cannot find symbol
symbol : class ImmutableFederatedContext
location: package org.apache.xbean.naming.context
/home/geronimo/geronimo/trunk/framework/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi
Re: [Discussion] Geronimo EL 2.2 Spec API
I added a global setting
org.apache.geronimo.spec.el.useCachedExpressionFactory in the ELContext,
by default, an cache expressionFactory will be added in the context to avoid
creating ExpressionFactory each time when doing the coerce. Plan to run it
against TCK when avaible.
2010/1/20 Ivan xhh...@gmail.com
Hi,
Recently, I am working on a new EL 2.2 Spec, and most of the codes are
done, however, some descriptions in the spec are ambiguous. I listed them
below, any comment would be welcomed.
Object BeanELResolver.invoke (ELContext context, Object base, Object
method, Class?[] paramTypes, Object[] params)
---
If the base object is not null, invoke the method,with the given
parameters on this bean.The return value
from the method is returned.
If the base is not null, the propertyResolved property of the ELContext
object must be set to
true by this resolver, before returning. If this property is not true
after this method is called, the caller
should ignore the return value.
The provided method object will first be coerced to a String. The
methods in the bean is then examined
and an attempt will be made to select one for invocation. If no
suitable can be found, a
MethodNotFoundException is thrown. If the given paramTypes is not null,
select the method with
the given name and parameter types. Else select the method with the
given name that has the same number
of parameters. If there are more than one such method, the method
selection process is undefined. Else
select the method with the given name that takes a variable number of
arguments. Note the resolution for
overloaded methods will likely be clarified in a future version of the
spec. The provide parameters are
coerced to the correcponding parameter types of the method, and the
method is then invoked.
---
a. The doc did not give enough description about how to coerce the
parameter values while the method is of variable arguments. So I use the
logic
// 1. If there is no parameter value left for the variable argment,
create a zero-length array
// 2. If there is only one parameter value left for the variable
argment, and it has the same array type with the varArgsClass, pass in
directly
// 3. Eles, create an array of varArgsClass type, and add all the left
coerced parameter values
b. There is no description about what's the correct behavior if base or
method is null, an exception is thrown or a null value is returned.
I keep the same way with the existing getValue method in the same
class, a null value is returned.
c. Not sure static method invocation is supported by this method, which
means the parameter base could be null.
Currently, I directly return null if base is null.
Object CompositeELResolver.(ELContext context, Object base, Object
method, Class?[] paramTypes, Object[] params)
---
Parameters:
context - The context of this evaluation.
base - The bean on which to invoke the method
method - The simple name of the method to invoke. Will be coerced to a
String. If method is “”or
“” a NoSuchMethodException is raised.
paramTypes
-AnarrayofClassobjectsidentifyingthemethod’sformalparametertypes,indeclared
order. Use an empty array if the method has no parameters. Can be
null, in which case the method’s
formal parameter types are assumed to be unknown.
params - The parameters to pass to the method, or null if no
parameters.
Returns: The result of the method invocation (null if the method has a
void return type).
---
a. About the parameter method, it says that it would be coerced to a
String, and if the method is , a NoSuchMethodException is raised.
But NoSuchMethodException is not a runtime exception, and invoke
method in ELResolver is not declared to throw it.
So I just use the codes below :
---
String targetMethod = (String)
expressionFactory.coerceToType(method, String.class);
if (targetMethod.length() == 0) {
throw new ELException(new NoSuchMethodException());
}
---
The last issue is that coerce action is required in the invoke method,
so a ExpressionFactory is required, but if we want to use its method :
public abstract Object coerceToType(Object obj, Class? expectedType)
throws ELException;
I must create a new instance, so I just feel that it might be less
efficient. I tried to improve it while using CompositeELReslover, but not
satisfied by myself.
I attached a patch file to GERONIMO-5031, it would be better if
somebody could help to review it before I do the changes.
Thanks !
--
Ivan
--
Ivan
G3.0 Plan and Status
Hi all, I had a discussion with Ivan, Shawn, Rex and Delos on all ongoing/TODO items and their status, and created a table here [1]. I hope this could be a starting point for us to put together the picture for G3.0. Note this is a very early version, and we must have missed or mis-interpreted something. Also, some areas are not detailed yet at all, e.g., documentation, sample, etc. So we urge everybody to take a look... The layout of the table is pretty straight forward. I tried to organize G3.0 release content into several categories, which consists of a number of components. Each component is further broken down into work items. The hope is that people can put their names to the work items that they are currently working on, describe the status (what's done, what's next, a brief estimation) and the dependencies. As a result, we can have a good overview of who's working on what and which parts need more love. All comments are welcome. -Jack [1] http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+3.0+Release+Status
Re: G3.0 Plan and Status
Hi Jack; I would like to work with OpenWebBeans integration. Last time we discussed integration, David Blevins created some modules for openwebbeans integration. I am going to fill the blanks and see what other pieces are required. Could I/you write my name to it? Thanks; Gurkan Erdogdu OWB Chair 2010/1/22 Jack Cai greensi...@gmail.com Hi all, I had a discussion with Ivan, Shawn, Rex and Delos on all ongoing/TODO items and their status, and created a table here [1]. I hope this could be a starting point for us to put together the picture for G3.0. Note this is a very early version, and we must have missed or mis-interpreted something. Also, some areas are not detailed yet at all, e.g., documentation, sample, etc. So we urge everybody to take a look... The layout of the table is pretty straight forward. I tried to organize G3.0 release content into several categories, which consists of a number of components. Each component is further broken down into work items. The hope is that people can put their names to the work items that they are currently working on, describe the status (what's done, what's next, a brief estimation) and the dependencies. As a result, we can have a good overview of who's working on what and which parts need more love. All comments are welcome. -Jack [1] http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+3.0+Release+Status -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
