[jira] Updated: (GERONIMO-4231) Build exception: java.net.MalformedURLException: no !/ in spec
[ https://issues.apache.org/jira/browse/GERONIMO-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cai Jun Jie updated GERONIMO-4231: -- Description: When building server in Linux, the following exceptions occurs several times in the build log: [INFO] Started deployer: org.apache.geronimo.configs/jasper-deployer/2.1.1/car java.net.MalformedURLException: no !/ in spec at java.net.URL.(URL.java:636) at java.net.URL.(URL.java:499) at java.net.URL.(URL.java:448) at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:181) at java.net.JarURLConnection.(JarURLConnection.java:164) at sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:93) at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:42) at java.net.URL.openConnection(URL.java:978) at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:856) at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:813) at sun.misc.URLClassPath$3.rtJarLoader(URLClassPath.java:588) at sun.misc.URLClassPath$3.run(URLClassPath.java:519) at java.security.AccessController.doPrivileged(AccessController.java:246) at sun.misc.URLClassPath.getLoader(URLClassPath.java:508) at sun.misc.URLClassPath.getLoader(URLClassPath.java:473) at sun.misc.URLClassPath.getResource(URLClassPath.java:322) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1032) at java.security.AccessController.doPrivileged(AccessController.java:279) at java.net.URLClassLoader.findClass(URLClassLoader.java:491) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:470) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:407) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:595) at java.beans.Introspector.instantiate(Introspector.java:1482) at java.beans.PropertyEditorManager.findEditor(PropertyEditorManager.java:106) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:63) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:120) at org.apache.geronimo.deployment.service.SingleGBeanBuilder.setAttribute(SingleGBeanBuilder.java:78) at org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:113) at org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:98) at org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:48) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:367) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:330) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer(PackageMojo.java:507) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage(PackageMojo.java:326) at org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute(PackageMojo.java:228) at org.codehaus.mojo.pluginsupport.MojoSupport.execute(MojoSupport.java:122) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at
Re: Documentation of new 2.2 features in current wiki?
Thanks Joe for all the work here! After going through the new structure proposed by Rebekah, I would say it is a derived version from 2.1, instead of a whole new structure. So I don't think somebody familar with the current 2.1 structure would need much time to get familiar with the new structure. And for new users, the new structure seems earier to start with. It is more natural and is better organized from user's point of view, instead of technology-oriented. Users turn to the documentation when they met some problems and cannot figure it out by exploring the software alone(so ideal software should be self-evident with their UI and do not need any doc :-)), so many product documentation nowadays are usally scenario or task oriented. I guess Rebekah can do a better job in explaining this to us since she has been working on product documentation for several years. We do have some resource available to do the migration from 2.1 to 2.2 doc manually. So if we could agree that we can have a better doc structure, we can put the new structure on the new wiki space and have more discussion on the structure itself. We definitely need your opinions to make it better... Currently Rebekah has made 2 proposals, 1 follows 2.1 which divides the doc into user's guide and developer's guide, the other integrates them together. Personally I prefer the latter because it simplifies user's view. I would say most, if not all, geronimo users are also developers. So it will be easier for user to locate information based on their tasks instead of asking them to decide whether he/she is a user or a developer beforehands (which typically ends up browsing both guides). Open for your comments.
[jira] Updated: (GERONIMO-4219) Edited GBean properties not reflected on restart
[ https://issues.apache.org/jira/browse/GERONIMO-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manu T George updated GERONIMO-4219: Attachment: G4219_r682459.patch My understanding when I made this patch was that there is only one instance of the LocalAttributeManager per server. Please review and commit if appropriate. Edited GBean properties not reflected on restart Key: GERONIMO-4219 URL: https://issues.apache.org/jira/browse/GERONIMO-4219 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.0.2, 2.1, 2.1.1 Environment: All Reporter: Manu T George Assignee: Manu T George Attachments: G4219_r682459.patch If I edit one of the gbean attributes of an already started gbean in a configuration and I then restart that configuration from the console then the edited properties are not reflected in the restarted gbean. On editing the properties are definitely persisted to config.xml but then on restart they are not read. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4219) Edited GBean properties not reflected on restart
[ https://issues.apache.org/jira/browse/GERONIMO-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manu T George reassigned GERONIMO-4219: --- Assignee: (was: Manu T George) Edited GBean properties not reflected on restart Key: GERONIMO-4219 URL: https://issues.apache.org/jira/browse/GERONIMO-4219 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 2.0.2, 2.1, 2.1.1 Environment: All Reporter: Manu T George Attachments: G4219_r682459.patch If I edit one of the gbean attributes of an already started gbean in a configuration and I then restart that configuration from the console then the edited properties are not reflected in the restarted gbean. On editing the properties are definitely persisted to config.xml but then on restart they are not read. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4225) Allow Run SQL portlet run sql against any configured data source
[ https://issues.apache.org/jira/browse/GERONIMO-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620909#action_12620909 ] Michal Borowiecki commented on GERONIMO-4225: - The trunk patch (sysdb-portlets-trunk.patch) can also be used to patch the recent 2.1.2 release. Allow Run SQL portlet run sql against any configured data source Key: GERONIMO-4225 URL: https://issues.apache.org/jira/browse/GERONIMO-4225 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: databases Affects Versions: 2.1.1 Reporter: Michal Borowiecki Priority: Minor Attachments: sysdb-portlets-2.1.1.patch, sysdb-portlets-trunk.patch Currently Run SQL portlet allows only running queries against internal Derby databases. It would be very useful if it allowed to run SQL against any of the datasources configured. Create DB and Delete DB features are Derby specific, Use DB on the other hand can be easily generalized to use any data source. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4231) Build exception: java.net.MalformedURLException: no !/ in spec
[ https://issues.apache.org/jira/browse/GERONIMO-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-4231: -- Assignee: Donald Woods Build exception: java.net.MalformedURLException: no !/ in spec -- Key: GERONIMO-4231 URL: https://issues.apache.org/jira/browse/GERONIMO-4231 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1 Environment: Linux Reporter: Cai Jun Jie Assignee: Donald Woods Priority: Minor Fix For: 2.1.3 When building server in Linux, the following exceptions occurs several times in the build log: [INFO] Started deployer: org.apache.geronimo.configs/jasper-deployer/2.1.1/car java.net.MalformedURLException: no !/ in spec at java.net.URL.(URL.java:636) at java.net.URL.(URL.java:499) at java.net.URL.(URL.java:448) at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:181) at java.net.JarURLConnection.(JarURLConnection.java:164) at sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:93) at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:42) at java.net.URL.openConnection(URL.java:978) at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:856) at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:813) at sun.misc.URLClassPath$3.rtJarLoader(URLClassPath.java:588) at sun.misc.URLClassPath$3.run(URLClassPath.java:519) at java.security.AccessController.doPrivileged(AccessController.java:246) at sun.misc.URLClassPath.getLoader(URLClassPath.java:508) at sun.misc.URLClassPath.getLoader(URLClassPath.java:473) at sun.misc.URLClassPath.getResource(URLClassPath.java:322) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1032) at java.security.AccessController.doPrivileged(AccessController.java:279) at java.net.URLClassLoader.findClass(URLClassLoader.java:491) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:470) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:407) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:595) at java.beans.Introspector.instantiate(Introspector.java:1482) at java.beans.PropertyEditorManager.findEditor(PropertyEditorManager.java:106) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:63) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:120) at org.apache.geronimo.deployment.service.SingleGBeanBuilder.setAttribute(SingleGBeanBuilder.java:78) at org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:113) at org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:98) at org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:48) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:367) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:330) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at
[jira] Updated: (GERONIMO-4231) Build exception: java.net.MalformedURLException: no !/ in spec
[ https://issues.apache.org/jira/browse/GERONIMO-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4231: --- Affects Version/s: 2.2 2.1.2 2.1.1 Fix Version/s: 2.2 Yep, I've seen this on Linux and MacOSX builds for awhile, but been ignoring it as it didn't cause any problems. I've got a minor fix that properly catches the exception and does a log.debug() in case it ever starts creating a problem that needs to be addressed. Build exception: java.net.MalformedURLException: no !/ in spec -- Key: GERONIMO-4231 URL: https://issues.apache.org/jira/browse/GERONIMO-4231 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1, 2.1.1, 2.1.2, 2.2 Environment: Linux Reporter: Cai Jun Jie Assignee: Donald Woods Priority: Minor Fix For: 2.1.3, 2.2 When building server in Linux, the following exceptions occurs several times in the build log: [INFO] Started deployer: org.apache.geronimo.configs/jasper-deployer/2.1.1/car java.net.MalformedURLException: no !/ in spec at java.net.URL.(URL.java:636) at java.net.URL.(URL.java:499) at java.net.URL.(URL.java:448) at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:181) at java.net.JarURLConnection.(JarURLConnection.java:164) at sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:93) at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:42) at java.net.URL.openConnection(URL.java:978) at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:856) at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:813) at sun.misc.URLClassPath$3.rtJarLoader(URLClassPath.java:588) at sun.misc.URLClassPath$3.run(URLClassPath.java:519) at java.security.AccessController.doPrivileged(AccessController.java:246) at sun.misc.URLClassPath.getLoader(URLClassPath.java:508) at sun.misc.URLClassPath.getLoader(URLClassPath.java:473) at sun.misc.URLClassPath.getResource(URLClassPath.java:322) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1032) at java.security.AccessController.doPrivileged(AccessController.java:279) at java.net.URLClassLoader.findClass(URLClassLoader.java:491) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:470) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:407) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:595) at java.beans.Introspector.instantiate(Introspector.java:1482) at java.beans.PropertyEditorManager.findEditor(PropertyEditorManager.java:106) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:63) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:120) at org.apache.geronimo.deployment.service.SingleGBeanBuilder.setAttribute(SingleGBeanBuilder.java:78) at org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:113) at org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:98) at org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:48) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:367) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:330) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) at
[jira] Closed: (GERONIMO-4231) Build exception: java.net.MalformedURLException: no !/ in spec
[ https://issues.apache.org/jira/browse/GERONIMO-4231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-4231. -- Resolution: Fixed r683958 in branches/2.1 (2.1.3-SNAPSHOT) r683959 in trunk (2.2-SNAPSHOT) Build exception: java.net.MalformedURLException: no !/ in spec -- Key: GERONIMO-4231 URL: https://issues.apache.org/jira/browse/GERONIMO-4231 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general Affects Versions: 2.1, 2.1.1, 2.1.2, 2.2 Environment: Linux Reporter: Cai Jun Jie Assignee: Donald Woods Priority: Minor Fix For: 2.1.3, 2.2 When building server in Linux, the following exceptions occurs several times in the build log: [INFO] Started deployer: org.apache.geronimo.configs/jasper-deployer/2.1.1/car java.net.MalformedURLException: no !/ in spec at java.net.URL.(URL.java:636) at java.net.URL.(URL.java:499) at java.net.URL.(URL.java:448) at java.net.JarURLConnection.parseSpecs(JarURLConnection.java:181) at java.net.JarURLConnection.(JarURLConnection.java:164) at sun.net.www.protocol.jar.JarURLConnection.(JarURLConnection.java:93) at sun.net.www.protocol.jar.Handler.openConnection(Handler.java:42) at java.net.URL.openConnection(URL.java:978) at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:856) at sun.misc.URLClassPath$JarLoader.(URLClassPath.java:813) at sun.misc.URLClassPath$3.rtJarLoader(URLClassPath.java:588) at sun.misc.URLClassPath$3.run(URLClassPath.java:519) at java.security.AccessController.doPrivileged(AccessController.java:246) at sun.misc.URLClassPath.getLoader(URLClassPath.java:508) at sun.misc.URLClassPath.getLoader(URLClassPath.java:473) at sun.misc.URLClassPath.getResource(URLClassPath.java:322) at java.net.URLClassLoader$ClassFinder.run(URLClassLoader.java:1032) at java.security.AccessController.doPrivileged(AccessController.java:279) at java.net.URLClassLoader.findClass(URLClassLoader.java:491) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:470) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClassInternal(MultiParentClassLoader.java:456) at org.apache.geronimo.kernel.config.MultiParentClassLoader.checkParents(MultiParentClassLoader.java:498) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:407) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:278) at java.lang.ClassLoader.loadClass(ClassLoader.java:595) at java.beans.Introspector.instantiate(Introspector.java:1482) at java.beans.PropertyEditorManager.findEditor(PropertyEditorManager.java:106) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:63) at org.apache.geronimo.common.propertyeditor.PropertyEditors.findEditor(PropertyEditors.java:120) at org.apache.geronimo.deployment.service.SingleGBeanBuilder.setAttribute(SingleGBeanBuilder.java:78) at org.apache.geronimo.deployment.service.GBeanBuilder.addGBeanData(GBeanBuilder.java:113) at org.apache.geronimo.deployment.service.GBeanBuilder.build(GBeanBuilder.java:98) at org.apache.geronimo.deployment.NamespaceDrivenBuilderCollection.build(NamespaceDrivenBuilderCollection.java:48) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.basicInitContext(AbstractWebModuleBuilder.java:367) at org.apache.geronimo.tomcat.deployment.TomcatModuleBuilder.initContext(TomcatModuleBuilder.java:330) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.initContext(SwitchingModuleBuilder.java:159) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:595) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at
Re: Where has Jason been?
Well, I'm outta the hospital now, back at home finally. Should be around more, though still quite week atm :-( * * * Don't feel too obligated to leave problems for me to fix though :-P --jason On Aug 7, 2008, at 9:01 AM, Kevan Miller wrote: On Aug 5, 2008, at 9:39 AM, Jason Dillon wrote: Just a little note to you guys. I've been in and out of hospitals for the past few weeks with some mystery skin rash and medley of other problems. Spent the last few nights in a hospital room, finally home again today, may have to go back tomorrow. Trying to get through emails, if I have to go back and I can get a decent network connection I should be around. Hopefully they can at least tell me what is wrong, else I think I may have to fly back to the states and let them fix me... :-( Sorry I've been away for so long... hopefully will get whatever this is sorted soon and I'll be back here more. Absolutely no need for any apologies. Focus on getting well. We'll still be here... And we'll even leave a problem or two for you to work on... ;-) --kevan
Re: timestamped snapshots
I've included the uniqueVersion=false in Genesis 1.5-SNAPSHOT and 2.0-SNAPSHOT and deployed builds for each out to the snapshot repo. Working on updating the samples 2.1 branch locally from genesis-1.4 to 1.5-SNAPSHOT to verify we aren't missing anything in the newer genesis code before trying to upgrade any other builds. -Donald Donald Woods wrote: Yes, you need to set - uniqueVersionfalse/uniqueVersion for the snapshot repository, even though this should really be set in the top-level apache.pom that everyone inherits. For now, the following should be added to the Genesis pom.xml that the server inherits and into any subproject that doesn't use Genesis as its parent pom - distributionManagement repository idapache.releases/id nameApache Release Distribution Repository/name urlscp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-r sync-repository/url /repository snapshotRepository idapache.snapshots/id nameApache Development Snapshot Repository/name urlscp://people.apache.org/www/people.apache.org/repo/m2-snapshot- repository/url uniqueVersionfalse/uniqueVersion /snapshotRepository /distributionManagement -Donald Joe Bohn wrote: There have recently been issues with the snapshot repository because it was running low on space and so any snapshot older than 30 days was deleted across the board. One reason given for the rapid growth in the repository size was due to projects using timestamped snapshots. It was stated that using timestamped repos in general was wrong for the apache snapshot repo. Geronimo uses timestamped snapshots. Myfaces was listed as an example of doing things the right way (http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3-SNAPSHOT/). Does anybody know how we can remove the timestamps (assuming they are not needed for any particular reason)? Joe smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMODEVTOOLS-467) Can't uninstall runtime after installing it via eclipse update manager in Ganymede
Can't uninstall runtime after installing it via eclipse update manager in Ganymede -- Key: GERONIMODEVTOOLS-467 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-467 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.1.2 The WTP server adatper features install with p2, but p2 can't handle the runtime, and brings up the old update manager to install it. I cannot then uninstall the runtime. Can we remove the runtime altogether? I think the predominant scenario is the user install Geronimo separately, then uses GEP to develop apps on it. I don't think eclipse is used to download Geronimo. If a user does this, the Download and Install button on a defined server is the easiest way to do it, especially given the extra work of pre-req checking, and reverting to the old eclipse update manager. Probably the runtime feature needs to be there for Download and Install to work. We just my need to update our doc... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-467) Can't uninstall runtime after installing it via eclipse update manager in Ganymede
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Kirby updated GERONIMODEVTOOLS-467: --- Issue Type: Sub-task (was: Bug) Parent: GERONIMODEVTOOLS-433 Can't uninstall runtime after installing it via eclipse update manager in Ganymede -- Key: GERONIMODEVTOOLS-467 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-467 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Ted Kirby Assignee: Tim McConnell Fix For: 2.1.2 The WTP server adatper features install with p2, but p2 can't handle the runtime, and brings up the old update manager to install it. I cannot then uninstall the runtime. Can we remove the runtime altogether? I think the predominant scenario is the user install Geronimo separately, then uses GEP to develop apps on it. I don't think eclipse is used to download Geronimo. If a user does this, the Download and Install button on a defined server is the easiest way to do it, especially given the extra work of pre-req checking, and reverting to the old eclipse update manager. Probably the runtime feature needs to be there for Download and Install to work. We just my need to update our doc... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Another samples issue ... how much does a user have to build?
I just upgraded the 2.1 samples branch (r683972) to use the updated genesis-1.5-SNAPSHOT build (which turns off the unique timestamps on snapshot artifacts.) I'll work on updating the build to use the server's private repo artifacts later today and then will work on merging all these changes into the samples trunk. -Donald Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Thanks, Joe smime.p7s Description: S/MIME Cryptographic Signature
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
For 2.1.x based subprojects, I'm thinking of going the route of creating a repository/pom.xml in each subproject that points to the server/tags/2.1.2 directory for the private artifacts (since it may be awhile until we release a 2.1.3 server and we want to get the 2.1.2 Samples and GEP out ASAP.) For 2.2 based subprojects, I like the idea of publishing the patched artifacts under a org.apache.geronimo.patches groupid and will work on that solution as soon as I finish updating the 2.1 subproject builds. -Donald Kevan Miller wrote: On Aug 7, 2008, at 8:26 PM, Donald Woods wrote: True, but wouldn't that introduce the overhead of our release process and voting? I wouldn't call it overhead. I'd call it oversight. Our community is releasing the patches and publishing the binaries. Server release votes have covered this, to date. Any process changes must maintain this same level of oversight. Would we create a geronimo/patches subproject arranged like our specs, where each artifact would be its own subdir and still check the patched artifacts in for the build to use and then move them to tags after they are released? We could release them separately. Or, we could include them (as they are currently) in the server. The difference is that there would be org.apache.geronimo.patches artifacts in our release and snapshot repositories. Would we version the artifacts based on the originating project or with a double version like we specs (which would be hard to follow)? Either way would work. For simplicity, my tendency is to include them in our server tree. However, there may be differing opinions. I'm fine either way... --kevan smime.p7s Description: S/MIME Cryptographic Signature
Re: Where has Jason been?
On Aug 8, 2008, at 9:44 AM, Jason Dillon wrote: Well, I'm outta the hospital now, back at home finally. Should be around more, though still quite week atm :-( * * * Don't feel too obligated to leave problems for me to fix though :-P That's good news, Jason. Rest up. --kevan
[jira] Created: (GERONIMO-4232) JMSException: Failed to build body from bytes
JMSException: Failed to build body from bytes - Key: GERONIMO-4232 URL: https://issues.apache.org/jira/browse/GERONIMO-4232 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.2, 2.1.3, 2.2 Reporter: Kevan Miller Fix For: 2.2 There's a problem receiving JMS ObjectMessages if the JMS Connector is deployed separately from the EAR containing the MDB. It looks like we're attempting to load the ObjectMessage using the Connector ClassLoader, rather than the MDB ClassLoader. You can work-around the problem by deploying the Connector within the EAR or by moving the necessary objects to your Connector deployment (e.g. add a dependency to your connector deployment plan). Pretty sure that this is an OpenEJB problem (will open a Jira), but will use this to track the problem for Geronimo users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-468) JAXBException when marshalling geronimo-web.xml
JAXBException when marshalling geronimo-web.xml --- Key: GERONIMODEVTOOLS-468 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-468 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.2 Environment: Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. C:\java -version java version 1.6.0_07 Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing) Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.2 org.apache.geronimo.st.core: JAXBException: JAXBUtils.marshalDeploymentPlan()( parm1=[/test1/WebContent/WEB-INF/geronimo-web.xml] ) javax.xml.bind.PropertyException: name: com.sun.xml.bind.namespacePrefixMapper value: [EMAIL PROTECTED] at javax.xml.bind.helpers.AbstractMarshallerImpl.setProperty(Unknown Source) at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.setProperty(Unknown Source) at org.apache.geronimo.st.core.jaxb.JAXBUtils.marshalDeploymentPlan(JAXBUtils.java:75) at org.apache.geronimo.st.v21.core.operations.V21DeploymentPlanCreationOperation.createGeronimoWebDeploymentPlan(V21DeploymentPlanCreationOperation.java:107) at org.apache.geronimo.st.core.operations.DeploymentPlanCreationOperation.execute(DeploymentPlanCreationOperation.java:67) at org.apache.geronimo.st.core.operations.DeploymentPlanCreationOperation.execute(DeploymentPlanCreationOperation.java:57) at org.apache.geronimo.st.core.GeronimoFacetInstallDelegate.execute(GeronimoFacetInstallDelegate.java:48) at org.eclipse.wst.common.project.facet.core.internal.FacetedProject.callDelegate(FacetedProject.java:1394) at org.eclipse.wst.common.project.facet.core.internal.FacetedProject.modifyInternal(FacetedProject.java:401) at org.eclipse.wst.common.project.facet.core.internal.FacetedProject.mergeChangesInternal(FacetedProject.java:1134) at org.eclipse.wst.common.project.facet.core.internal.FacetedProject.access$2(FacetedProject.java:1070) at org.eclipse.wst.common.project.facet.core.internal.FacetedProject$5.run(FacetedProject.java:1052) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.wst.common.project.facet.core.internal.FacetedProject.mergeChanges(FacetedProject.java:1062) at org.eclipse.wst.common.project.facet.core.internal.FacetedProjectWorkingCopy.commitChanges(FacetedProjectWorkingCopy.java:1834) at org.eclipse.wst.common.project.facet.ui.ModifyFacetedProjectWizard.performFinish(ModifyFacetedProjectWizard.java:388) at org.eclipse.wst.web.ui.internal.wizards.NewProjectDataModelFacetWizard.performFinish(NewProjectDataModelFacetWizard.java:276) at org.eclipse.wst.common.project.facet.ui.ModifyFacetedProjectWizard$3.run(ModifyFacetedProjectWizard.java:330) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800) at org.eclipse.wst.common.project.facet.ui.ModifyFacetedProjectWizard$4.run(ModifyFacetedProjectWizard.java:344) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Handling of Security Exposures in Geronimo
On Jul 23, 2008, at 3:15 PM, Joe Bohn wrote: Kevan Miller wrote: All, There was a recent report by Fortify on Open Source Security -- http://www.fortify.com/l/oss/assets/OpenSource_Security_WP_v5.pdf The report says there were some number of potential vulnerabilities identified in Geronimo. No details of the vulnerabilities have been reported to us (although the tests seem to have been run some time ago...). Once we understand what the potential vulnerabilities are, we can start to assess... The report does identify concerns that we could be doing a better job of reporting security vulnerabilities and letting users know how they can report security vulnerabilities to our project. I agree with this. As noted here -- http://www.apache.org/foundation/contact.html -- any ASF security concerns can be safely relayed with an email to [EMAIL PROTECTED] . It probably makes sense for us to create a [EMAIL PROTECTED] mailing list. Project-specific security mailing lists are automatically relayed to the [EMAIL PROTECTED] mailing list. A project-specific list will reduce spam and allow us to focus on Geronimo issues, rather than Apache-wide issues. +1 I also think that we should create a security page on our web site (e.g. geronimo.apache.org/security). This page could be used to describe how any potential vulnerabilities should be reported. It should also be used to report vulnerabilities as they are fixed. This allows users to easily identify what security exposures a particular version of Geronimo might have. +1 Thoughts on the mailing list and web site? Assuming we're in general agreement, I'd like to see us working on these in the near future. I think they are both good ideas. I'm going to be working on making the above items happen: creating a security mailing list and a security page on our web site. Finally, I've learned that there are a few potential sources for running static code analysis scans against our codebase: https://opensource.fortify.com/teamserver/welcome.fhtml http://scan.coverity.com/ I think we should take a look at these and decide if it's something we want to take advantage of. Thoughts? It's probably worth taking a look. Looking at the fortify site and the rungs on the coverity site got me thinking about the packages we include. Some of them are listed but many are not. I wonder how valuable running scans on Geronimo would be if the dependent packages are not also participating. We might end up being the middleman for reporting security issues in a number of other projects. I guess that's still good as long as they are caught ... but it might be a good bit of effort. I'll investigate these as a lower priority task. Still haven't heard any specifics on any vulnerabilities. --kevan
Maven woes
Hi I'm trying to build geronimo on my laptop using my college wifi, which gets disconnected occasionally and maven basically stops at that point without giving any error or warning. I'm forced to ctrl+C the build and repeat it but it doesn't seem to work. Is there a way to resume the build from where it ended? Or is there a windows based interface for maven that might help? I really need to get it built, mostly to show it off here :-D and finish up on PlanCreator. Thanks, -- Shrey Banga Bachelor of Technology, IV year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Maven woes
On Aug 8, 2008, at 12:43 PM, Shrey Banga wrote: Hi I'm trying to build geronimo on my laptop using my college wifi, which gets disconnected occasionally and maven basically stops at that point without giving any error or warning. I'm forced to ctrl+C the build and repeat it but it doesn't seem to work. Is there a way to resume the build from where it ended? Or is there a windows based interface for maven that might help? I really need to get it built, mostly to show it off here :-D and finish up on PlanCreator. Once you have all the dependencies downloaded you can use mvn clean install -o for an offline build. I've been using nexus as a repo manager and I think it insulates me somewhat from bad connection issues at any rate I'm currently experiencing very flaky wifi and no build problems. http://nexus.sonatype.org/ I also usually only rebuild the parts of geronimo that have changed or depend on what I've changed. hope this helps david jencks Thanks, -- Shrey Banga Bachelor of Technology, IV year Department of Electrical Engineering Indian Institute of Technology Roorkee
Re: Maven woes
You can also skip the tests and testsuite to save on retry times - mvn install -Dtest=false -Pno-it One thing I have noticed, is that you need to clean the assemblies between rebuilds, due to some car-maven-plugin problem where it sometimes generates bogus server assemblies. cd assemblies mvn clean -Donald David Jencks wrote: On Aug 8, 2008, at 12:43 PM, Shrey Banga wrote: Hi I'm trying to build geronimo on my laptop using my college wifi, which gets disconnected occasionally and maven basically stops at that point without giving any error or warning. I'm forced to ctrl+C the build and repeat it but it doesn't seem to work. Is there a way to resume the build from where it ended? Or is there a windows based interface for maven that might help? I really need to get it built, mostly to show it off here :-D and finish up on PlanCreator. Once you have all the dependencies downloaded you can use mvn clean install -o for an offline build. I've been using nexus as a repo manager and I think it insulates me somewhat from bad connection issues at any rate I'm currently experiencing very flaky wifi and no build problems. http://nexus.sonatype.org/ I also usually only rebuild the parts of geronimo that have changed or depend on what I've changed. hope this helps david jencks Thanks, -- Shrey Banga Bachelor of Technology, IV year Department of Electrical Engineering Indian Institute of Technology Roorkee smime.p7s Description: S/MIME Cryptographic Signature
Re: timestamped snapshots
Excellent. Thanks Donald! Joe Donald Woods wrote: I've included the uniqueVersion=false in Genesis 1.5-SNAPSHOT and 2.0-SNAPSHOT and deployed builds for each out to the snapshot repo. Working on updating the samples 2.1 branch locally from genesis-1.4 to 1.5-SNAPSHOT to verify we aren't missing anything in the newer genesis code before trying to upgrade any other builds. -Donald Donald Woods wrote: Yes, you need to set - uniqueVersionfalse/uniqueVersion for the snapshot repository, even though this should really be set in the top-level apache.pom that everyone inherits. For now, the following should be added to the Genesis pom.xml that the server inherits and into any subproject that doesn't use Genesis as its parent pom - distributionManagement repository idapache.releases/id nameApache Release Distribution Repository/name urlscp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-r sync-repository/url /repository snapshotRepository idapache.snapshots/id nameApache Development Snapshot Repository/name urlscp://people.apache.org/www/people.apache.org/repo/m2-snapshot- repository/url uniqueVersionfalse/uniqueVersion /snapshotRepository /distributionManagement -Donald Joe Bohn wrote: There have recently been issues with the snapshot repository because it was running low on space and so any snapshot older than 30 days was deleted across the board. One reason given for the rapid growth in the repository size was due to projects using timestamped snapshots. It was stated that using timestamped repos in general was wrong for the apache snapshot repo. Geronimo uses timestamped snapshots. Myfaces was listed as an example of doing things the right way (http://people.apache.org/repo/m2-snapshot-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.3-SNAPSHOT/). Does anybody know how we can remove the timestamps (assuming they are not needed for any particular reason)? Joe
Re: [DISCUSS] Handling of Security Exposures in Geronimo
+1 Jacek On Wed, Jul 23, 2008 at 7:13 PM, Kevan Miller [EMAIL PROTECTED] wrote: All, There was a recent report by Fortify on Open Source Security -- http://www.fortify.com/l/oss/assets/OpenSource_Security_WP_v5.pdf The report says there were some number of potential vulnerabilities identified in Geronimo. No details of the vulnerabilities have been reported to us (although the tests seem to have been run some time ago...). Once we understand what the potential vulnerabilities are, we can start to assess... The report does identify concerns that we could be doing a better job of reporting security vulnerabilities and letting users know how they can report security vulnerabilities to our project. I agree with this. As noted here -- http://www.apache.org/foundation/contact.html -- any ASF security concerns can be safely relayed with an email to [EMAIL PROTECTED] It probably makes sense for us to create a [EMAIL PROTECTED] mailing list. Project-specific security mailing lists are automatically relayed to the [EMAIL PROTECTED] mailing list. A project-specific list will reduce spam and allow us to focus on Geronimo issues, rather than Apache-wide issues. I also think that we should create a security page on our web site (e.g. geronimo.apache.org/security). This page could be used to describe how any potential vulnerabilities should be reported. It should also be used to report vulnerabilities as they are fixed. This allows users to easily identify what security exposures a particular version of Geronimo might have. Thoughts on the mailing list and web site? Assuming we're in general agreement, I'd like to see us working on these in the near future. Finally, I've learned that there are a few potential sources for running static code analysis scans against our codebase: https://opensource.fortify.com/teamserver/welcome.fhtml http://scan.coverity.com/ I think we should take a look at these and decide if it's something we want to take advantage of. Thoughts? --kevan -- Jacek Laskowski Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMODEVTOOLS-461) Documentation updates
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12621067#action_12621067 ] Ted Kirby commented on GERONIMODEVTOOLS-461: To set the M2_REPO classpath variable: preferences-java-build path-classpath variables: New... Name M2_REPO click folder, navigate to your M2_REPO. Let's update the news at the bottom of http://geronimo.apache.org/development-tools.html. The most recent entry is over a year old! Documentation updates - Key: GERONIMODEVTOOLS-461 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-461 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.2 Reporter: Tim McConnell Assignee: Ashish Jain Fix For: 2.1.2 These tutorials below need to be updated once GEP 2.1.2 is released: (X) http://cwiki.apache.org/GMOxDOC21/web-application-for-ejb-access.html (X) http://cwiki.apache.org/GMOxDOC21/quick-start-fast-and-easy-development.html (X) http://cwiki.apache.org/GMOxDOC21/development-environment.html#Developmentenvironment-InstallingEclipse (X) http://geronimo.apache.org/developing-the-geronimo-eclipse-plugin-in-eclipse.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Documentation of new 2.2 features in current wiki?
Thank you for the additional information Rebekah. I didn't intend to imply that change was bad ... I just wanted to better understand the what was driving the change. Change just for the sake of change can be useless and produce less than desirable results. I now understand the problems that you are trying to solve and agree that some changes are necessary. I agree with Jacek that I prefer the merged (infocenter) style approach. Overall, I like the organization that you have proposed. I have just 2 initial alternative ideas to propose on the structure: 1) I would move the the content of section 3.2 (getting and building Geronimo) somewhere under section 6 on development (perhaps Developing Apache Geronimo). I think that most users will begin with our pre-built assemblies and may never see a need to build Geronimo themselves. Under section 3.2 I would include information on choosing a Geronimo assembly, obtaining it, and leveraging the pre-built server. We should also mention the possibility of custom built assemblies and appropriate pointers if they choose to either create their own server using the customer server features or go hog wild and build a unique server image directly using maven (in which case they would need to understand how to build a G server from our source). 2) Consider moving the extensible administration console sections (4.8) under development as well. Also, like Jacek, I would like to harness your enthusiasm to seed the 2.2 content (with a new structure) from the 2.1 documentation. I think that would be a great help to get the 2.2 documentation effort off the ground. Thanks, Joe wei zhang wrote: Hi folks, Changes are not always bad. We are making changes every day, aren't we? The world is always dynamic. : ) We did a scenario based task analysis, and tried to organize the topics in a way that reflects the work flow that users adopt to complete certain tasks with Geronimo. We tried to organize the topics from the users' perspective and make the information more easy to use and easy to find. Quality technical information claims good organization. We also prefer the information center based approach because Geronimo users are mostly developers and it's hard to differentiation one from the other. Take the original user's guide for example, tools and commands are discussed separately in GShell, Tooling, and Administration. However, these tools and commands are also used elsewhere. The Tools and commands topic is placed under Administration, while some commands will not be used until the users do deployment. So, separating this topic from Administration as reference information makes more sense. What's more, some topics in the user's guide seem not to be at the appropriate level, for example, the Clustering topic might go well under Configuring Geronimo instead of standing out. As for the original Developer's Guide, the Tutorial section is not supposed to be placed inside a Developer's Guide as the two are different types of information. And, the information in the Tutorial section is ordinary tasks that developers can perform. The primary function of tutorial information is to move the user's skill set from their current expertise to a more experienced level. Often, this information functions as an introduction to a solution or product that centers on the user's acquisition of general product knowledge and practice. Unlike Wizards or UA task topics, however, a tutorial's main purpose is to create understanding about the concepts supporting a technology or a product, and so to teach fundamental distinctions, skills and heuristic approaches to using the software more effectively. We changed the original Tutorial part to a section that contains specific tasks developers can perform: 6.2 Developing applications for Geronimo 6.2.1 Getting familiar with the development environment 6.2.1.1 http://6.2.1.1 Configuring Application Specific Logging with Log4j 6.2.1.2 http://6.2.1.2 Preparing to run SQL statements at Deployment Time 6.2.1.3 http://6.2.1.3 Locating your application specific configuration files 6.2.1.4 http://6.2.1.4 Quick Debugging JSPs of your application 6.2.1.5 http://6.2.1.5 Deploying applications using the Geronimo Eclipse Plugin (GEP) 6.2.2 Developing Web applications with GEP 6.2.2.1 http://6.2.2.1 Creating a Dynamic Web project using Eclipse 6.2.2.2 http://6.2.2.2 Developing Web applications for accessing EJB 6.2.2.3 http://6.2.2.3 Developing Web applications for accessing JDBC 6.2.2.4 http://6.2.2.4 Developing Web applications for accessing JMS 6.2.2.5 http://6.2.2.5 Developing JavaServer faces applications 6.2.2.5.1 Basics of JavaServer Faces 6.2.2.5.2 Developing AJAX with JSF applications in GEP 6.2.2.5.3 Using JSP immediate expressions to access JSF
Re: [DISCUSS] Time to create a geronimo/repo branch in svn for private depends
I'd say yes, except that using svn.apache.org as a repo URL is notoriously problematic due to the configuration of httpd there. Best bet is to create a repo in svn, then auto-export that tree on to our zone, and then configure a vanilla httpd there to serve it up, so that users don't get build failures trying to resolve stuff from http://svn.apache.org/ ... I had planned on creating a little experiment to show this, but then I got sick. --jason On Aug 7, 2008, at 8:13 PM, Donald Woods wrote: We have danced around the problem of not being able to build Samples, Plugins or GEP from a clean m2 repo without building the Server's repository subdir for long enough. I believe it is time to create the following location in SVN - geronimo/repo Which would hold our private patched artifacts of other projects (like Tomcat, Pluto, ...), just like the OpenEJB team has done for some of their private depends. I don't see this as a major hit to the svn infrastructure, given the jars (10 for 2.2.) will only be downloaded when starting with a clean m2 repo or when we publish any updated depends. Unless someone comes up with a better solution by Friday morning, I'll create the new repo branch and populate it with the latest 2.1.2 and 2.2 patched artifacts tomorrow. -Donald
