Re: building error
If this occurred while building configs client-corba or j2ee-corba, I
have found the problem. You can fix it locally by including
geronimo
axis-deployer
${geronimo_version}
car
4
in your project.xml. I expect to commit this when svn revives.
If this doesn't fix the problem please let us know and indicate what
was being built at the time of the failure.
Incidentally I'd be curious to know what system you are running on: I
think the configs are getting built in a different order than on
everyone elses build machine.
Many thanks
david jencks
On May 11, 2006, at 10:00 PM, Rakesh Ranjan wrote:
Hi all,
When i building the Geronimo-1.1-SNAPSHOP, i get the following
exception :
27010 [main] ERROR
org.apache.geronimo.plugin.packaging.PackageBuilder -
org.apache.geronimo.kernel.config.LifecycleException: start of
geronimo/openejb-deployer/1.1-SNAPSHOT/car failed
org.apache.geronimo.kernel.config.LifecycleException: start of
geronimo/openejb-deployer/1.1-SNAPSHOT/car failed
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf
iguration(SimpleConfigurationManager.java :522)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf
iguration(SimpleConfigurationManager.java:486)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager$
$FastClassByCGLIB$$ce77a924.invoke ()
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
(FastMethodInvoker.java:38)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
(GBeanOperation.java:122)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
(GBeanInstance.java:817)
at org.apache.geronimo.gbean.runtime.RawInvoker.invoke
(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
(ProxyMethodInterceptor.java:96)
at org.apache.geronimo.kernel.config.ConfigurationManager$
$EnhancerByCGLIB$$39bce10d.startConfiguration ()
at
org.apache.geronimo.plugin.packaging.PackageBuilder.execute
(PackageBuilder.java:286)
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:324)
at
org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute
(PackageBuilderShell.java:251)
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:324)
at org.apache.commons.jelly.impl.DynamicBeanTag.doTag
(DynamicBeanTag.java:230)
at org.apache.commons.jelly.impl.StaticTagScript.run
(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run
(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag
$MavenGoalAction.performAction (MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain (Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal
(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag
(MavenAttainGoalTag.java:127)
at org.apache.commons.jelly.impl.TagScript.run
(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run
(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag
$MavenGoalAction.performAction (MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at org.apache.maven.plugin.PluginManager.attainGoals
(PluginManager.java:671)
at org.apache.maven.MavenSession.attainGoals
(MavenSession.java:263)
at org.apache.maven.jelly.tags.maven.ReactorTag.doTag
(ReactorTag.java:368)
at org.apache.commons.jelly.impl.TagScript.run
(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run
(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag
(MavenGoalTag.java:79)
Re: Google search on website?
I dunno... a box under Development on the leftnav would be fine. Maybe just another one called Search in the same style, with a text input on the top row, search button on the bottom? --jason On May 11, 2006, at 9:47 PM, Matt Hogstrom wrote: I meant where it would go. Jason Dillon wrote: Not sure I understand what you mean... --jason On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Do you have a template in mind? Jason Dillon wrote: > Any thoughts on adding a Google search form on the website? > > --jason > > >
Re: Geronimo documentation - upcoming look & feel
Looks like it addresses my gripes with the current confluence pages. Thanks! I also agree with the other comment that it would be ideal to have separate 1.0 and 1.1 "spaces" -- which is to say, separate documentation sets. Ultimately I think version N should have everything that version N-1 had only updated and with a "what changed" page and covering any new features. Thanks, Aaron On 5/11/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. Available at the following link is just a single page, static draft based on what is in the oven for Geronimo v1.1 documentation. The new confluence wiki will be running a plugin that automatically exports the new content into HTML format so it can be served as static content increasing the performance. Not only that, the HTML exports can be configured using templates so we can select the information we want to display, for example removing the classic "Added by / last edited by" if it turns to be an issue. Three key things to pay special attention from the template used are, obvious banner at the top of the page, user names removed and Apache license disclaimer at the very bottom of each page. http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Cheers! Hernan
building error
Hi all,When i building the Geronimo-1.1-SNAPSHOP, i get the following exception : 27010 [main] ERROR org.apache.geronimo.plugin.packaging.PackageBuilder - org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/openejb-deployer/1.1-SNAPSHOT/car failed org.apache.geronimo.kernel.config.LifecycleException: start of geronimo/openejb-deployer/1.1-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java :522) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:486) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke () at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$39bce10d.startConfiguration () at org.apache.geronimo.plugin.packaging.PackageBuilder.execute(PackageBuilder.java:286) 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:324) at org.apache.geronimo.plugin.packaging.PackageBuilderShell.execute (PackageBuilderShell.java:251) 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:324) at org.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run (StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.Goal.attainPrecursors(Goal.java:488) at com.werken.werkz.Goal.attain (Goal.java:573) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run (TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:368) at org.apache.commons.jelly.impl.TagScript.run (TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction (MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193) at org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run (ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java :110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plu
Re: Google search on website?
I meant where it would go. Jason Dillon wrote: Not sure I understand what you mean... --jason On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Do you have a template in mind? Jason Dillon wrote: > Any thoughts on adding a Google search form on the website? > > --jason > > >
Re: Where should M2 conversion be done? or Should/Will the trunk be abandoned completely?
On the "Thinking about 1.2 and moving forward" thread, (http://www.mail-archive.com/dev@geronimo.apache.org/msg22073.html), there was talk about making the current 1.1 as the new trunk and moving the changes from the existing trunk to this new trunk. So did you mean moving to this new trunk ? Are there any major pros and cons of moving to 1.1 as opposed to moving to the new trunk ? I don't see any. At present, I think we could wait till after we ship 1.1 and create this new trunk. But if somebody sees any some advantages, I'd appreciate their insight. Cheers Prasad On 5/11/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: Hi, It seems the closer 1.1 is to its destination, the more people are asking about the m2 conversion (or rather complaining it's not yet done, which is fair given how much time it has already taken). However, to go on with the conversion one needs to answer the question about the trunk. Should it be abandoned and kept only as a place for the changes that should eventually move to the 1.1 branch? Where should the migration take place? 1.1 branch or the trunk? Suggestions? Comments? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: OS License for IntelliJ
Check out their web site. They'll give you one good for a year. Jason Dillon wrote: Anyone know if we have an Intellij open source license for g commiters? --jason
OS License for IntelliJ
Anyone know if we have an Intellij open source license for g commiters? --jason
Re: Google search on website?
Not sure I understand what you mean... --jason On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Do you have a template in mind? Jason Dillon wrote: > Any thoughts on adding a Google search form on the website? > > --jason > > >
Re: Geronimo documentation - upcoming look & feel
On 5/11/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. ... http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Anyway we can figure how to reduce some of the logo/bread-crumbs/ toolbar height? --jason
Re: Geronimo documentation - upcoming look & feel
On 5/11/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. ... http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Whow, that looks pretty! If it becomes part of our distribution it will surely be a major differentiator against other application servers, esp. open source ones. I have always liked BEA WebLogic for their astonishing documentation online so when people realize we've got alike we're winners! Thanks Hernan! Hernan Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Artifact patch system [was Re: replacing tomcat classes]
Dain Sundstrom wrote: I think that technically this is a very easy problem to solve. The difficult problem will be our recommendation to users on how to use the feature. Technical - I think the best way to implement this is to add another method getPatches(Artifact artifact) the Repository interface (this is analogous to the getDependecies method which appends to the class path). Then we just modify the class loader building code in Configuration to put the patch jars before the artifact in the classpath. One thing to note, this proposed patch system will only address class loading of artifacts. If a user wants to patch a library inside of a web application, they will need to modify the web application directly. This is particularly tricky since the load order of jars in WEB-INF/lib is not specified and updating it requires a full redeploy (not a restart as most would expect). Additionally, this system would not address patching resources inside of a war. For that, the user would have to overwrite the files in the unpacked deployment. The only tricky part of implementing this system will be deciding how we want to associate patches with artifacts. A single flat directory is easiest for users, but it difficult to avoid name collisions. It would be very easy for us to have some sort of foo-1.1-23456.patch files in the normal repository structure, but that requires an administrator to know where to put files which is error prone. I'm personally leaning toward the single patch directory simply because it will make it easier for admins to see which patches the server has installed. Instead of having a single flat directory, would it be possible to have a file that maps an existing artifact to a patched artifact in the repository so that the patched artifact can be manipulated using standard maven tools. See link below to Maven proposal on artifact naming for patches etc. If a user wants to see what patched files are currently in use they can just look at this file. If a patch needs to be sent to a user manually, it could be sent to them in a tar/zip file that contains the appropriate directories under the repository directory that can be extracted to the repository directory. This would allow a number of different versions of the patch to be in the repository and the user can easily switch between patch versions or back-out the patch to a previous version that worked more reliably (in case a number of patch iterations were produced in an attempt to resolve a problem). Finally, this system will impact any tool that is using the repository. I'm specifically thinking of the plugin packaging and download code which will have to be modified to grab the patches. I also suspect it will effect the eclipse tooling also. Recomendations -- I agree with David that it is a bad idea to replace only a few classes in a jar. The process is inherently error prone, and only provides a very risky stop gap measure. I also agree with Matt that it is important be able to patch just a few classes in an emergency, and as soon as the emergency is over, work should start to roll the changes into a full jar update. I think we should recommend that our users don't use the patch feature unless there is an emergency. Further, I don't think this project should ever ship class level patches, since it is so easy for us to ship a whole jar. BTW, does anyone know if maven has a patch system in the pipeline? I'm not aware of a patch system as such, but have seen this proposal on artifact naming for patches/service packs etc. Not sure what the status of this proposal is: http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies Regards, John -dain On May 11, 2006, at 9:44 AM, David Jencks wrote: On May 11, 2006, at 9:16 AM, Joe Bohn wrote: Bumping up the version should work for the jar approach. However, I was still trying to figure out a way to honor the tomcat recommendation of replacing just the modified classes. Is there some way to make the version independent classloaders pick up individual classes rather than entire jars? No, and I think that's a good thing. I think the tomcat team is giving bad advice. thanks david jencks Joe David Jencks wrote: On May 11, 2006, at 8:29 AM, Joe Bohn wrote: Thanks for the quick response Jeff. I like the idea of a "system patch" location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I think this "system patch" idea will only work in environments with only one classloader, i.e. not geronimo. The problem is that the patched classes need to get into the correct classloader, "before" the normal versions. We'd need a patch directory for each module. I also think any solution that relies on the order of stuff in a classpath is inherently unstable and unreliable. Basically I think this is a terrib
[jira] Updated: (GERONIMO-2013) make upgrader into a command line tool
[ http://issues.apache.org/jira/browse/GERONIMO-2013?page=all ] David Jencks updated GERONIMO-2013: --- Attachment: 2013_upgrade_commandline.diff > make upgrader into a command line tool > -- > > Key: GERONIMO-2013 > URL: http://issues.apache.org/jira/browse/GERONIMO-2013 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1 > Attachments: 2013_upgrade_commandline.diff > > Upgrade functionality needs to be exposed somehow. One way is as a command > line tool. Current version is a 5M standalone jar: I'm not sure what other > choices there are. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-708) changes to connector host and port not persisted in geronimo
[ https://issues.apache.org/activemq/browse/AMQ-708?page=all ] Hiram Chirino resolved AMQ-708: --- Resolution: Fixed Patch applied! Thanks. > changes to connector host and port not persisted in geronimo > > > Key: AMQ-708 > URL: https://issues.apache.org/activemq/browse/AMQ-708 > Project: ActiveMQ > Type: Bug > Components: Geronimo Integration > Versions: 3.2.4 > Environment: activemq 3.4 running in geronimo 1.1 > Reporter: Paul McMahan > Fix For: 3.2.4 > Attachments: ACTIVEMQ-gbean.patch > > > Hostname and port changes I made to the activemq connectors via the geronimo > admin console don't get persisted in geronimo's var/config/config.xml, > causing them to revert to their original values when the server restarts. > To fix this problem ActiveMQConnectorGBean needs to declare the host and port > attributes as manageable when it creates its gbeaninfo. See the attached > patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMODEVTOOLS-80) Error with create DeploymentUtils.createJarFile() during publish of Geronimo server
Error with create DeploymentUtils.createJarFile() during publish of Geronimo server --- Key: GERONIMODEVTOOLS-80 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-80 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Versions: 1.0.0 Environment: Windows XP Reporter: Kathy Chan Driver: WTP 1.5 200605091754 + Geronimo 1.0 plugin + Geronimo server When publishing the Geronimo server programmatically using the Web services wizard, I got the error: org.eclipse.wst.common.frameworks.datamodel.IDataModel: method getDefaultOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; not found java.lang.NoSuchMethodError: org.eclipse.wst.common.frameworks.datamodel.IDataModel: method getDefaultOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; not found at org.apache.geronimo.core.DeploymentUtils.createJarFile(DeploymentUtils.java:73) at org.apache.geronimo.core.commands.DistributeCommand.execute(DistributeCommand.java:43) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.java:77) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeploymentOp.java:69) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.distribute(GeronimoServerBehaviour.java:337) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:258) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:230) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:214) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:672) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:752) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:610) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:803) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:791) at org.eclipse.jst.ws.internal.consumption.ui.command.StartServerCommand$1.run(StartServerCommand.java:129) at org.eclipse.jst.ws.internal.consumption.ui.command.StartServerCommand.publish(StartServerCommand.java:141) at org.eclipse.jst.ws.internal.consumption.ui.command.StartServerCommand.execute(StartServerCommand.java:79) at org.eclipse.jst.ws.internal.consumption.ui.server.StartServerWidget$StartServerJob.run(StartServerWidget.java:305) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) I have no problem with starting the server manually using server tooling "start server" command. I also did not have problem with publishing to Geronimo using Web services wizard using Geronimo 1.0 plugin with the WTP 1.0 driver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2013) make upgrader into a command line tool
make upgrader into a command line tool -- Key: GERONIMO-2013 URL: http://issues.apache.org/jira/browse/GERONIMO-2013 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 Attachments: 2013_upgrade_commandline.diff Upgrade functionality needs to be exposed somehow. One way is as a command line tool. Current version is a 5M standalone jar: I'm not sure what other choices there are. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-80) Error with create DeploymentUtils.createJarFile() during publish of Geronimo server
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-80?page=comments#action_12379157 ] Kathy Chan commented on GERONIMODEVTOOLS-80: Correction: Problem occurs also manuall using server tooling. This problem occurs just by doing the following: - Create and start Geronimo 1.0 server - Create hello.html - Run on server on hello.html Results in the error: !MESSAGE An internal error occurred during: "Publishing to Apache Geronimo 1.0...". !STACK 0 java.lang.NoSuchMethodError: org.eclipse.wst.common.frameworks.datamodel.IDataModel: method getDefau ltOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; not found at org.apache.geronimo.core.DeploymentUtils.createJarFile(DeploymentUtils.java:73) at org.apache.geronimo.core.commands.DistributeCommand.execute(DistributeCommand.java:43) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.j ava:77) at org.apache.geronimo.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeployment Op.java:69) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.distribute(GeronimoServerBehavi our.java:337) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviou r.java:258) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBeh aviour.java:230) at org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBeh aviour.java:214) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDe legate.java:672) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourD elegate.java:752) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate .java:610) at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:803) at org.eclipse.wst.server.core.internal.Server.publish(Server.java:791) at org.eclipse.wst.server.core.internal.PublishServerJob.run(PublishServerJob.java:145) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) > Error with create DeploymentUtils.createJarFile() during publish of Geronimo > server > --- > > Key: GERONIMODEVTOOLS-80 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-80 > Project: Geronimo-Devtools > Type: Bug > Components: eclipse-plugin > Versions: 1.0.0 > Environment: Windows XP > Reporter: Kathy Chan > > Driver: WTP 1.5 200605091754 + Geronimo 1.0 plugin + Geronimo server > When publishing the Geronimo server programmatically using the Web services > wizard, I got the error: > org.eclipse.wst.common.frameworks.datamodel.IDataModel: method > getDefaultOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; > not found > java.lang.NoSuchMethodError: > org.eclipse.wst.common.frameworks.datamodel.IDataModel: method > getDefaultOperation()Lorg/eclipse/wst/common/frameworks/datamodel/IDataModelOperation; > not found > at > org.apache.geronimo.core.DeploymentUtils.createJarFile(DeploymentUtils.java:73) > at > org.apache.geronimo.core.commands.DistributeCommand.execute(DistributeCommand.java:43) > at > org.apache.geronimo.core.commands.SynchronizedDeploymentOp.run(SynchronizedDeploymentOp.java:77) > at > org.apache.geronimo.core.commands.SynchronizedDeploymentOp.execute(SynchronizedDeploymentOp.java:69) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.distribute(GeronimoServerBehaviour.java:337) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.doDeploy(GeronimoServerBehaviour.java:258) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.invokeCommand(GeronimoServerBehaviour.java:230) > at > org.apache.geronimo.core.internal.GeronimoServerBehaviour.publishModule(GeronimoServerBehaviour.java:214) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModule(ServerBehaviourDelegate.java:672) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publishModules(ServerBehaviourDelegate.java:752) > at > org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:610) > at org.eclipse.wst.server.core.internal.Server.doPublish(Server.java:803) > at org.eclipse.wst.server.core.internal.Server.publish(Server.java:791) > at > org.eclipse.jst.ws.internal.consumption.ui.command.StartServerCommand$1.run(StartServerCommand.java:129) > at > org.eclipse.jst.ws.internal.consumption.ui.command.StartServerCommand.publish(StartServerCommand.java:141) > at > org.eclipse.jst.ws.internal.consumption.ui.command.StartServerCommand.execute(StartServerCommand
[jira] Assigned: (GERONIMO-1507) prototype offline deploy tool
[ http://issues.apache.org/jira/browse/GERONIMO-1507?page=all ] David Jencks reassigned GERONIMO-1507: -- Assign To: David Jencks > prototype offline deploy tool > - > > Key: GERONIMO-1507 > URL: http://issues.apache.org/jira/browse/GERONIMO-1507 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Geronimo 1.0 branch, > Reporter: toby cabot > Assignee: David Jencks > Priority: Minor > Attachments: offline-patch.txt > > Here's a prototype offline deploy tool. It has only one command, for offline > distribution of applications. It's basically a clone of the online tool so > it works in a similar way, but for the distribute-offline command it uses a > hacked version of the packaging plugin's PackageBuilder class to start a > kernel, load some configurations, and then call the deployer. > It has one serious bug at the moment: it doesn't switch between tomcat and > jetty. Not sure why, but I can look into it more. > It has some missing features: > - it should get dependencies from somewhere (maybe download them from an > online Maven repo) > - it should be able to manipulate config.xml > - it needs more commands (at least undistribute) > - it needs to allow the user to specify the config-store to write to > There's probably a lot of unused code there, too, since I haven't figured out > what everything does yet. But it's a start. > You can use it like the online tool. The jar is > $GERONIMO_HOME/bin/offline.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1507) prototype offline deploy tool
[ http://issues.apache.org/jira/browse/GERONIMO-1507?page=all ] David Jencks updated GERONIMO-1507: --- Attachment: 1507_offline-deployer.diff Inspired by this I implemented an offline deployer as part of deployer.jar. You use the --offline flag. It starts up a kernel in-vm and starts the configurations listed in var/config/offline-deployer-list and registers a shutdown hook. Then the normal deploy commands proceed using this in-vm kernel. I'll apply this when svn comes back to life. > prototype offline deploy tool > - > > Key: GERONIMO-1507 > URL: http://issues.apache.org/jira/browse/GERONIMO-1507 > Project: Geronimo > Type: New Feature > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Geronimo 1.0 branch, > Reporter: toby cabot > Assignee: David Jencks > Priority: Minor > Attachments: 1507_offline-deployer.diff, offline-patch.txt > > Here's a prototype offline deploy tool. It has only one command, for offline > distribution of applications. It's basically a clone of the online tool so > it works in a similar way, but for the distribute-offline command it uses a > hacked version of the packaging plugin's PackageBuilder class to start a > kernel, load some configurations, and then call the deployer. > It has one serious bug at the moment: it doesn't switch between tomcat and > jetty. Not sure why, but I can look into it more. > It has some missing features: > - it should get dependencies from somewhere (maybe download them from an > online Maven repo) > - it should be able to manipulate config.xml > - it needs more commands (at least undistribute) > - it needs to allow the user to specify the config-store to write to > There's probably a lot of unused code there, too, since I haven't figured out > what everything does yet. But it's a start. > You can use it like the online tool. The jar is > $GERONIMO_HOME/bin/offline.jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Where should M2 conversion be done? or Should/Will the trunk be abandoned completely?
Hi, It seems the closer 1.1 is to its destination, the more people are asking about the m2 conversion (or rather complaining it's not yet done, which is fair given how much time it has already taken). However, to go on with the conversion one needs to answer the question about the trunk. Should it be abandoned and kept only as a place for the changes that should eventually move to the 1.1 branch? Where should the migration take place? 1.1 branch or the trunk? Suggestions? Comments? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: 1.1 Package Upgrade List
On 5/10/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: All work related to M2 was halted until the trunk was merged. M2 packaging plugin would require transferring all M2 work to 1.1. I do not think there are any plans to do it before the merge or at least the 1.1. release. I think using Maven1 will be best at this time. Let's hear from Jacek.. Well, the issue with the 1.1 branch has completely distracted me from the M2 migration and I've decided to wait patiently until Geronimo 1.1 is out. I don't know if it'd be worthwhile to go on with the migration on the trunk or start it off on the 1.1 branch. I don't want to make noise about it and am learning M2 tips and tricks so I'm better prepared for the task. I'll start another thread about our M2 migration and its place Anita Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Assigned: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2011?page=all ] Joe Bohn reassigned GERONIMO-2011: -- Assign To: Matt Hogstrom (was: Joe Bohn) Matt, Can you please review and integrate this fix? > Set default logging to INFO rather than DEBUG in minimal assemblies > --- > > Key: GERONIMO-2011 > URL: http://issues.apache.org/jira/browse/GERONIMO-2011 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Assignee: Matt Hogstrom > Fix For: 1.1 > Attachments: 2011_LogLevel.patch > > The assemblies for j2ee-jetty-server and j2ee-tomcat-server have the default > logging level set to INFO rather than Debug.The little-G assemblies > (minimal-jetty-server & minimal-tomcat-server) should have the same settings > as we deliver the geronimo 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1 Package Upgrade List
Someone hit me in the head about priorities (I think it was Prasad). If someone isn't working on 1.1 and has time this is excellent. Please don't let me distract you from 1.1 though :) Prasad Kashyap wrote: Hi Matt, Moving the M2 conversion work from the trunk to 1.1 should not be disruptive. It would have the following changes 1) add pom.xmls in all modules 2) add a few ant files in some modules 3) change *Test.java files in quite a few modules. I have no strong objections to it except that I'm afraid it might pull folks off of 1.1 while trying to do this. Cheers Prasad. On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'd defer to Jacek to do the merging since he's familiar with it. If he's not available then I'd be happy to take a patch from you :) Also, if anyone has any objections re: getting this done then hollar now. anita kulshreshtha wrote: > > --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> Since the M2 conversion is independent of 1.1 what does the community >> think about starting that >> merge into 1.1 now? I think it would allow us to become more >> productive on 1.2 since the work would >> already be in place. For those working on the M2 conversion what do >> you think about starting that >> work and do you think we can do it without impacting 1.1? >We can safely transfer all the work from 1.2 to 1.1 without > impacting anything. What is the best way to do this? > > Thanks > Anita > >> anita kulshreshtha wrote: >>> All work related to M2 was halted until the trunk was merged. >> M2 >>> packaging plugin would require transferring all M2 work to 1.1. I >> do >>> not think there are any plans to do it before the merge or at least >> the >>> 1.1. release. I think using Maven1 will be best at this time. Let's >>> hear from Jacek.. >>> >>> Thanks >>> Anita >>> >>> --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>> I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins >> have to be in a m2 layout, but the only tools to create a car is a m1 >> plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: > I'd rather handle the ApacheDS integration separately from the >> 1.1 > release. Fortunately, the plugins work with the Maven 2 repository, > so that issue should be easier. > > The main question is how to do the build and packaging. If the >> API is > unchanged, we can build our integration module using our Maven 1 > packaging plugin against ADS 0.9.2 and just have it apply the >> 1.0.x > JARs at installation time. If the API is different, it may make the > most sense to try to split out our directory integration and do >> the > build and packaging under Maven 2 (I'm assuming that Geronimo >> HEAD has > a Maven 2 packaging plugin, but if not, I guess we can work on one). > Thanks, >Aaron > > On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > >> ApacheDS0.9.2 to 1.0-RC2 ? >> I have a patch to port the Geronimo part to 1.0-RC2. However, >> currently ADS 1.0 jars propagated to maven2 repo only. >> >> 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: >>> Consolidated list so far is: >>> >>> Axis from 1.4-356167 to 1.4 >>> commons-fileupload 1.1-dev to 1.1 >>> jasper from 5.5.9 to 5.5.15 >>> Jetty from 5.1.9 to 5.1.10 >>> stax from 1.1.1-dev to 1.1.2 >>> Tomcat 5.5.9 to 5.5.15 >>> tranql from1.2.1 to 1.3-SNAPSHOT >>> tranql-connector from 1.1 to 1.2-SNAPSHOT >>> >>> Keep 'em coming. >>> >>> Matt >>> >>> Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from >> 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Here are the packages I'm recommending for 1.1. If I missed one > please chime in. > > Axis from 1.4-356167 to 1.4 > jasper from 5.5.9 to 5.5.15 > Jetty from 5.1.9 to 5.1.10 > stax from 1.1.1-dev to 1.1.2 > tranql from1.2.1 to 1.3-SNAPSHOT > tranql-connector from 1.1 to 1.2-SNAPSHOT > > This is the list so far...I've updated > > http://opensource.atlassian.com/confluence/oss/display/GERO
Re: Geronimo documentation - upcoming look & feel
Thanks Hernan for plugging on this. Hernan Cunico wrote: Yup, once we move to cwiki I will reorg the documentation, and along comes another call for volunteers to contribute with this effort :) The plan is, each release doc goes into it's own space, other docs will be grouped by relevance into their own separated spaces. The main pointers to those spaces will be from the Geronimo web site. Having individual spaces will give us more flexibility for managing them, better structure, reduced footprint for the exports, improved performance, etc, overall content will be more organized. It is funny, on my local confluence installation, I have been working on that reorganization for some time now and I called the spaces (the short names) in the same way :D We are working with the infrastructure team to see what's needed to go live with cwiki.apache.org Cheers! Hernan Jason Dillon wrote: Just a thought... we may eventually want to have a space per-version for our documentation. GDOCS10 GDOCS11 etc... I think we should not limit ourselves to one space, but use them to organize documents on a very high-level. --jason On 5/11/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: I just wanted to show how the doc will potentially look like, just the look & feel. The content is being baked and what is shown there is not the main page, just a tentative TOC under development for the Geronimo v1.1 documentation Once cwiki is implemented, the main page should be on the Geronimo web site pointing to the specific Geronimo's version and available project's documentation. In plain English it would be something like: Documentation page - Apache Geronimo v1.0 - User's guide - Apache Geronimo v1.1 - User's guide - Apache Geronimo - Developer's guide ... On the draft I sent, I just wanted to highlight the top banner, the removal of user names and the ASL license disclaimer at the bottom of each page, not the actual content. However, this is a good opportunity to refresh the call for volunteers to contribute with the Project's documentation. Just in case you forgotten ;) , the TOC for Geronimo's v1.1 documentation is available at the following URL: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation If anybody is able to contribute with the project's documentation, in any possible way, please feel free to ping me if you have any questions, concerns, suggestions, Thanks in advance !!! Cheers! Hernan Matt Hogstrom wrote: > Looks good Hernan. For context, is this the main documentation page ? > Perhaps it would make it clearer to call this the "Project User's Guide" > so as to avoid confusion between this and other forms of documentation > at developerworks, articles, etc. > > Hernan Cunico wrote: > >> Hi All, >> I just wanted to give you guys a heads up on how the Geronimo's >> confluence wiki may look like once >> cwiki.apache.org jumps in production. >> >> Available at the following link is just a single page, static draft >> based on what is in the oven for Geronimo v1.1 documentation. The new >> confluence wiki will be running a plugin that automatically exports >> the new content into HTML format so it can be served as static content >> increasing the performance. >> >> Not only that, the HTML exports can be configured using templates so >> we can select the information we want to display, for example removing >> the classic "Added by / last edited by" if it turns to be an issue. >> >> Three key things to pay special attention from the template used are, >> obvious banner at the top of the page, user names removed and Apache >> license disclaimer at the very bottom of each page. >> >> http://people.apache.org/~hcunico/cwiki/documentation.html >> >> Comments, questions, suggestions are welcomed :) >> >> Cheers! >> Hernan >> >> >> >> >
Geronimo v1.1 documentation update
Hi All, here are two updates for the Geronimo v1.1 documentation Tools and Commands: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+v1.1+-+Tools+and+Commands Deployer tool: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+v1.1+-+Deployer+tool Cheers! Hernan
Geronimo 1.1 web tier clustering (with Tomcat 5.5.15) - documentation
The Geronimo 1.1 web tier clustering documentation (using Tomcat 5.5.15) and updated deployment plans are available at: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Clustering+Example -Dave-
Re: Google search on website?
Do you have a template in mind? Jason Dillon wrote: Any thoughts on adding a Google search form on the website? --jason
Re: Geronimo documentation - upcoming look & feel
Yup, once we move to cwiki I will reorg the documentation, and along comes another call for volunteers to contribute with this effort :) The plan is, each release doc goes into it's own space, other docs will be grouped by relevance into their own separated spaces. The main pointers to those spaces will be from the Geronimo web site. Having individual spaces will give us more flexibility for managing them, better structure, reduced footprint for the exports, improved performance, etc, overall content will be more organized. It is funny, on my local confluence installation, I have been working on that reorganization for some time now and I called the spaces (the short names) in the same way :D We are working with the infrastructure team to see what's needed to go live with cwiki.apache.org Cheers! Hernan Jason Dillon wrote: Just a thought... we may eventually want to have a space per-version for our documentation. GDOCS10 GDOCS11 etc... I think we should not limit ourselves to one space, but use them to organize documents on a very high-level. --jason On 5/11/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: I just wanted to show how the doc will potentially look like, just the look & feel. The content is being baked and what is shown there is not the main page, just a tentative TOC under development for the Geronimo v1.1 documentation Once cwiki is implemented, the main page should be on the Geronimo web site pointing to the specific Geronimo's version and available project's documentation. In plain English it would be something like: Documentation page - Apache Geronimo v1.0 - User's guide - Apache Geronimo v1.1 - User's guide - Apache Geronimo - Developer's guide ... On the draft I sent, I just wanted to highlight the top banner, the removal of user names and the ASL license disclaimer at the bottom of each page, not the actual content. However, this is a good opportunity to refresh the call for volunteers to contribute with the Project's documentation. Just in case you forgotten ;) , the TOC for Geronimo's v1.1 documentation is available at the following URL: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation If anybody is able to contribute with the project's documentation, in any possible way, please feel free to ping me if you have any questions, concerns, suggestions, Thanks in advance !!! Cheers! Hernan Matt Hogstrom wrote: > Looks good Hernan. For context, is this the main documentation page ? > Perhaps it would make it clearer to call this the "Project User's Guide" > so as to avoid confusion between this and other forms of documentation > at developerworks, articles, etc. > > Hernan Cunico wrote: > >> Hi All, >> I just wanted to give you guys a heads up on how the Geronimo's >> confluence wiki may look like once >> cwiki.apache.org jumps in production. >> >> Available at the following link is just a single page, static draft >> based on what is in the oven for Geronimo v1.1 documentation. The new >> confluence wiki will be running a plugin that automatically exports >> the new content into HTML format so it can be served as static content >> increasing the performance. >> >> Not only that, the HTML exports can be configured using templates so >> we can select the information we want to display, for example removing >> the classic "Added by / last edited by" if it turns to be an issue. >> >> Three key things to pay special attention from the template used are, >> obvious banner at the top of the page, user names removed and Apache >> license disclaimer at the very bottom of each page. >> >> http://people.apache.org/~hcunico/cwiki/documentation.html >> >> Comments, questions, suggestions are welcomed :) >> >> Cheers! >> Hernan >> >> >> >> >
Re: Geronimo documentation - upcoming look & feel
Just a thought... we may eventually want to have a space per-version for our documentation. GDOCS10 GDOCS11 etc... I think we should not limit ourselves to one space, but use them to organize documents on a very high-level. --jason On 5/11/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: I just wanted to show how the doc will potentially look like, just the look & feel. The content is being baked and what is shown there is not the main page, just a tentative TOC under development for the Geronimo v1.1 documentation Once cwiki is implemented, the main page should be on the Geronimo web site pointing to the specific Geronimo's version and available project's documentation. In plain English it would be something like: Documentation page - Apache Geronimo v1.0 - User's guide - Apache Geronimo v1.1 - User's guide - Apache Geronimo - Developer's guide ... On the draft I sent, I just wanted to highlight the top banner, the removal of user names and the ASL license disclaimer at the bottom of each page, not the actual content. However, this is a good opportunity to refresh the call for volunteers to contribute with the Project's documentation. Just in case you forgotten ;) , the TOC for Geronimo's v1.1 documentation is available at the following URL: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation If anybody is able to contribute with the project's documentation, in any possible way, please feel free to ping me if you have any questions, concerns, suggestions, Thanks in advance !!! Cheers! Hernan Matt Hogstrom wrote: > Looks good Hernan. For context, is this the main documentation page ? > Perhaps it would make it clearer to call this the "Project User's Guide" > so as to avoid confusion between this and other forms of documentation > at developerworks, articles, etc. > > Hernan Cunico wrote: > >> Hi All, >> I just wanted to give you guys a heads up on how the Geronimo's >> confluence wiki may look like once >> cwiki.apache.org jumps in production. >> >> Available at the following link is just a single page, static draft >> based on what is in the oven for Geronimo v1.1 documentation. The new >> confluence wiki will be running a plugin that automatically exports >> the new content into HTML format so it can be served as static content >> increasing the performance. >> >> Not only that, the HTML exports can be configured using templates so >> we can select the information we want to display, for example removing >> the classic "Added by / last edited by" if it turns to be an issue. >> >> Three key things to pay special attention from the template used are, >> obvious banner at the top of the page, user names removed and Apache >> license disclaimer at the very bottom of each page. >> >> http://people.apache.org/~hcunico/cwiki/documentation.html >> >> Comments, questions, suggestions are welcomed :) >> >> Cheers! >> Hernan >> >> >> >> >
Re: Google search on website?
Also, how about translation links for other languages using Babelfish or Google as described here?: http://labnol.blogspot.com/2005/11/add-language-translation-to-website.html +1, awesome... though I have been told that these sometimes butcher things... but hopefully the gist gets through. --jason
Re: 1.1 Package Upgrade List
Ant files are used to do some custom things that jelly did in Maven 1. Eg: modules\installer-support\setup.xml The Test class names didn't change. Minor modifications to the code in the *Test.java were done. Sorry for the confusion. Cheers Prasad On 5/11/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: What are the ant files used for ? And why changing the test class names ? Surefire can be configured specifically if needed ... So this change could be delayed. Cheers, Guillaume Nodet Prasad Kashyap wrote: > Hi Matt, > > Moving the M2 conversion work from the trunk to 1.1 should not be > disruptive. It would have the following changes > 1) add pom.xmls in all modules > 2) add a few ant files in some modules > 3) change *Test.java files in quite a few modules. > > I have no strong objections to it except that I'm afraid it might pull > folks off of 1.1 while trying to do this. > > Cheers > Prasad. > > On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> I'd defer to Jacek to do the merging since he's familiar with it. If >> he's not available then I'd be >> happy to take a patch from you :) >> >> Also, if anyone has any objections re: getting this done then hollar >> now. >> >> anita kulshreshtha wrote: >> > >> > --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: >> > >> >> Since the M2 conversion is independent of 1.1 what does the community >> >> think about starting that >> >> merge into 1.1 now? I think it would allow us to become more >> >> productive on 1.2 since the work would >> >> already be in place. For those working on the M2 conversion what do >> >> you think about starting that >> >> work and do you think we can do it without impacting 1.1? >> >We can safely transfer all the work from 1.2 to 1.1 without >> > impacting anything. What is the best way to do this? >> > >> > Thanks >> > Anita >> > >> >> anita kulshreshtha wrote: >> >>> All work related to M2 was halted until the trunk was merged. >> >> M2 >> >>> packaging plugin would require transferring all M2 work to 1.1. I >> >> do >> >>> not think there are any plans to do it before the merge or at least >> >> the >> >>> 1.1. release. I think using Maven1 will be best at this time. Let's >> >>> hear from Jacek.. >> >>> >> >>> Thanks >> >>> Anita >> >>> >> >>> --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >>> >> I haven't seen any geronimo plugin for m2 in head. >> That whould be very usefull, especially because Geronimo plugins >> >> have >> to >> be in a m2 layout, but the only tools to create a car is a m1 >> >> plugin. >> Any idea ? >> >> Cheers, >> Guillaume Nodet >> >> Aaron Mulder wrote: >> >> > I'd rather handle the ApacheDS integration separately from the >> >> 1.1 >> > release. Fortunately, the plugins work with the Maven 2 >> repository, >> > so that issue should be easier. >> > >> > The main question is how to do the build and packaging. If the >> >> API >> is >> > unchanged, we can build our integration module using our Maven 1 >> > packaging plugin against ADS 0.9.2 and just have it apply the >> >> 1.0.x >> > JARs at installation time. If the API is different, it may make >> the >> > most sense to try to split out our directory integration and do >> >> the >> > build and packaging under Maven 2 (I'm assuming that Geronimo >> >> HEAD >> has >> > a Maven 2 packaging plugin, but if not, I guess we can work on >> one). >> > Thanks, >> >Aaron >> > >> > On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: >> > >> >> ApacheDS0.9.2 to 1.0-RC2 ? >> >> I have a patch to port the Geronimo part to 1.0-RC2. However, >> >> currently ADS 1.0 jars propagated to maven2 repo only. >> >> >> >> 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: >> >>> Consolidated list so far is: >> >>> >> >>> Axis from 1.4-356167 to 1.4 >> >>> commons-fileupload 1.1-dev to 1.1 >> >>> jasper from 5.5.9 to 5.5.15 >> >>> Jetty from 5.1.9 to 5.1.10 >> >>> stax from 1.1.1-dev to 1.1.2 >> >>> Tomcat 5.5.9 to 5.5.15 >> >>> tranql from1.2.1 to 1.3-SNAPSHOT >> >>> tranql-connector from 1.1 to 1.2-SNAPSHOT >> >>> >> >>> Keep 'em coming. >> >>> >> >>> Matt >> >>> >> >>> Aaron Mulder wrote: >> That issue has a great list. >> >> We definitely need to try updating commons-fileupload (from >> >> 1.1-dev to >> 1.1). I think there may even be a separate Jira for that. >> But the >> old one occasionally hangs, so it's definitely worth trying >> the new >> one. >> >> Thanks, >> Aaron >> >> On 5/9/06, Matt Hogstrom <[EMAI
Re: Tomcat version in G1.1 for clustering
Filip Hanik - Dev Lists wrote: Dave Colasurdo wrote: *Problem1* When testing Sticky session, my browser locks unto a particular cluster member (e.g. node1) due to the nodeid in the cookie. If I kill node1, the session fails over into node2 and all my session data is still present. This is good. The nodeid in the cookie continues to say node1 (this is also true w/ TC 5.5.9 w/ and mod-jk).. ok, this is probably not desired behavior for a cluster with more than 2 nodes. For this to work correctly, you need to have the JvmRouteBinderValve configured in tomcat. This valve, will rewrite the sessionId to include the new jvmRoute, node2 in your scenario. Filip Updated the deployment plan with the new Valve (included in the Valve Chain) and all now works as expected. After failover, the cookie is updated with the nodeid of the new server that processes the request. name="className">org.apache.catalina.cluster.session.JvmRouteBinderValve enabled=true Will update the G1.1 plan on the wiki. -Dave-
Re: Google search on website?
In the template I posted for the upcoming Geronimo's confluence wiki there is a Google search already included. It would be cool to have one on the web site too :) http://people.apache.org/~hcunico/cwiki/documentation.html Cheers! Hernan Jason Dillon wrote: Any thoughts on adding a Google search form on the website? --jason
Re: replacing tomcat classes
That technique will only work for a limited set of use cases, and is very error prone. The fundamental problem is you are moving a class from a node deep in the the class loader graph to the system class loader. That means the class will only be able to see classes on the system class path. Specifically, a servlet would not be able to see the javax.servlet.Servlet class :( -dain On May 11, 2006, at 11:26 AM, Paul McMahan wrote: It seems that you can override some of the jars in geronimo/lib by dropping a jar into geronimo/lib/ext. As a test I recompiled a change into o.a.g.system.main.Daemon that became visible when I put the updated jar into that directory. But using the same technique for a deployed webapp didn't have the same results, presumably due to the deeper classloader structure in effect for stuff loaded from the repository (as David described earlier). I agree it would be nice to have a directory whose contents trump all classloaders used for quick testing and "hotfixes" and such. But I can sympathize with concerns that it may be abused and lead to instability. I have wasted a good deal of time in the past chasing red herrings caused by jars I didn't realize were in jre/lib/ext :-) Paul On 5/11/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Matt Hogstrom wrote: > > > David Jencks wrote: >> >> On May 11, 2006, at 8:29 AM, Joe Bohn wrote: >> >>> >>> Thanks for the quick response Jeff. >>> >>> I like the idea of a "system patch" location in the classpath where >>> we can pick up patches for anything we might include in a geronimo >>> assembly. >> >> I think this "system patch" idea will only work in environments with >> only one classloader, i.e. not geronimo. The problem is that the >> patched classes need to get into the correct classloader, "before" the >> normal versions. We'd need a patch directory for each module. I >> also think any solution that relies on the order of stuff in a >> classpath is inherently unstable and unreliable. > > I agree that it would be very unwieldy. For some folks providing > support for Geronimo it might be nice for the classloaders to look in an > aside dir (./patches) for a jar with the artifact name with a > -pmmddss suffix so patches can be applied. The ss allows for the > sequencing to be addressed. This would make it easier to provide one > hit patches that can get rolled up into the released jar you describe > below and the user would not have to wait for a release to come out > which could be a few months. Matt, you hit the nail on the head. I really think a simple patching system...call it..."quick hit" ;-) could have some big beneficial uses. I have many times run into this situation where I needed to be able to do this. Only through altering the CLASSPATH or changing the jar was I able to get around the problem. I always wanted a way to drop in a jar w/o having to alter core services that allowed me to patch what I needed. There are many use cases for this, with the biggest being a possible way for us to release "service paks" w/o the need to download and fully reconfigure a new server. I only see this feature as an added extension to make thing easier for development/support/and heavily configured prod servers. Jeff
Re: Geronimo documentation - upcoming look & feel
I just wanted to show how the doc will potentially look like, just the look & feel. The content is being baked and what is shown there is not the main page, just a tentative TOC under development for the Geronimo v1.1 documentation Once cwiki is implemented, the main page should be on the Geronimo web site pointing to the specific Geronimo's version and available project's documentation. In plain English it would be something like: Documentation page - Apache Geronimo v1.0 - User's guide - Apache Geronimo v1.1 - User's guide - Apache Geronimo - Developer's guide ... On the draft I sent, I just wanted to highlight the top banner, the removal of user names and the ASL license disclaimer at the bottom of each page, not the actual content. However, this is a good opportunity to refresh the call for volunteers to contribute with the Project's documentation. Just in case you forgotten ;) , the TOC for Geronimo's v1.1 documentation is available at the following URL: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Apache+Geronimo+V1.1+-+Documentation If anybody is able to contribute with the project's documentation, in any possible way, please feel free to ping me if you have any questions, concerns, suggestions, Thanks in advance !!! Cheers! Hernan Matt Hogstrom wrote: Looks good Hernan. For context, is this the main documentation page ? Perhaps it would make it clearer to call this the "Project User's Guide" so as to avoid confusion between this and other forms of documentation at developerworks, articles, etc. Hernan Cunico wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. Available at the following link is just a single page, static draft based on what is in the oven for Geronimo v1.1 documentation. The new confluence wiki will be running a plugin that automatically exports the new content into HTML format so it can be served as static content increasing the performance. Not only that, the HTML exports can be configured using templates so we can select the information we want to display, for example removing the classic "Added by / last edited by" if it turns to be an issue. Three key things to pay special attention from the template used are, obvious banner at the top of the page, user names removed and Apache license disclaimer at the very bottom of each page. http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Cheers! Hernan
[jira] Assigned: (GERONIMO-1861) Assembly plugin should make a backup "original" copy of the config.xml file
[ http://issues.apache.org/jira/browse/GERONIMO-1861?page=all ] David Jencks reassigned GERONIMO-1861: -- Assign To: David Jencks (was: Dain Sundstrom) I'm making another change to the assembly plugin for offline deploy and will include this modification. Offline deploy is tracked in GERONIMO-1507 > Assembly plugin should make a backup "original" copy of the config.xml file > --- > > Key: GERONIMO-1861 > URL: http://issues.apache.org/jira/browse/GERONIMO-1861 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: buildsystem > Reporter: Dain Sundstrom > Assignee: David Jencks > Fix For: 1.1 > Attachments: assembly-plugin.patch, assembly-version-change-openejb.patch, > change-assembly-version.patch > > The assembly plugin should create a config.xml.original > (config.xml.factory-defaults) file next to the config.xml file. This way if > you really mess up your system, you can restore factory-defaults, or diff the > two files. > The current config.bak file is fairly useless since the server overwrites it > after every change, which only gives you one level of undo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Artifact patch system [was Re: replacing tomcat classes]
I think that technically this is a very easy problem to solve. The difficult problem will be our recommendation to users on how to use the feature. Technical - I think the best way to implement this is to add another method getPatches(Artifact artifact) the Repository interface (this is analogous to the getDependecies method which appends to the class path). Then we just modify the class loader building code in Configuration to put the patch jars before the artifact in the classpath. One thing to note, this proposed patch system will only address class loading of artifacts. If a user wants to patch a library inside of a web application, they will need to modify the web application directly. This is particularly tricky since the load order of jars in WEB-INF/lib is not specified and updating it requires a full redeploy (not a restart as most would expect). Additionally, this system would not address patching resources inside of a war. For that, the user would have to overwrite the files in the unpacked deployment. The only tricky part of implementing this system will be deciding how we want to associate patches with artifacts. A single flat directory is easiest for users, but it difficult to avoid name collisions. It would be very easy for us to have some sort of foo-1.1-23456.patch files in the normal repository structure, but that requires an administrator to know where to put files which is error prone. I'm personally leaning toward the single patch directory simply because it will make it easier for admins to see which patches the server has installed. Finally, this system will impact any tool that is using the repository. I'm specifically thinking of the plugin packaging and download code which will have to be modified to grab the patches. I also suspect it will effect the eclipse tooling also. Recomendations -- I agree with David that it is a bad idea to replace only a few classes in a jar. The process is inherently error prone, and only provides a very risky stop gap measure. I also agree with Matt that it is important be able to patch just a few classes in an emergency, and as soon as the emergency is over, work should start to roll the changes into a full jar update. I think we should recommend that our users don't use the patch feature unless there is an emergency. Further, I don't think this project should ever ship class level patches, since it is so easy for us to ship a whole jar. BTW, does anyone know if maven has a patch system in the pipeline? -dain On May 11, 2006, at 9:44 AM, David Jencks wrote: On May 11, 2006, at 9:16 AM, Joe Bohn wrote: Bumping up the version should work for the jar approach. However, I was still trying to figure out a way to honor the tomcat recommendation of replacing just the modified classes. Is there some way to make the version independent classloaders pick up individual classes rather than entire jars? No, and I think that's a good thing. I think the tomcat team is giving bad advice. thanks david jencks Joe David Jencks wrote: On May 11, 2006, at 8:29 AM, Joe Bohn wrote: Thanks for the quick response Jeff. I like the idea of a "system patch" location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I think this "system patch" idea will only work in environments with only one classloader, i.e. not geronimo. The problem is that the patched classes need to get into the correct classloader, "before" the normal versions. We'd need a patch directory for each module. I also think any solution that relies on the order of stuff in a classpath is inherently unstable and unreliable. Basically I think this is a terrible idea and we should avoid it at all costs. I think instead we should use our new version independence and replace jars with patched jars with slightly higher version numbers. IIUC this is what you propose doing below. This should not require removing the standard tomcat jars: the hight version number should be enough to get the correct version picked up. thanks david jencks I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Ger
Re: Directory Update (Jeff?)
Alexei, Sorry but we have not looked back after the M2 conversion. Our poms have changed much since then because of transitive deps so it would take a significant effort to produce the M1 poms again. Really wish we had a tool for this. Regards, Alex Alexei Zakharov wrote: BTW, Alex, are there plans to propagate ADS jars to maven1 repo? Geronimo 1.1 currently supports maven1 only. Thanks, 2006/5/6, Alexei Zakharov <[EMAIL PROTECTED]>: Alex, Oh, I've been searching in old "directory" and "directory-network" groups rather than "org/apache/directory/server/apacheds-core". Thank you for pointing the right group id. 2006/5/5, Alex Karasulu <[EMAIL PROTECTED]>: > Alexei Zakharov wrote: > > Hi, > > > > I have created a patch to move the G directory module to ApacheDS 1.0 > > RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at > > /maven nor at /maven2. The most recent version is 0.9.3. The same > > situation for MINA. So I can't post the patch right now since it will > > not work without these jars. > > Alex, I just want to let you know about this situation. > > > Hmmm I'm seeing the RC2 jars just fine. Take a look here at the core > jar for example: > > http://www.ibiblio.org/maven2/org/apache/directory/server/apacheds-core/1.0-RC2/ > > Also MINA stuff is here: > > http://www.ibiblio.org/maven2/org/apache/directory/mina/mina-core/0.9.4/ > > HTH, > Alex > > > > 2006/4/24, Alex Karasulu <[EMAIL PROTECTED]>: > >> Aaron Mulder wrote: > >> > I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. > >> > > >> Ya all including RC1 should be in the M2 repo if not let me know. > >> > >> Alex > >> > Thanks, > >> > Aaron > >> > > >> > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > >> > > >> >> Alex, > >> >> > >> >> Can you get the jars in ibiblio and I can get the integration > >> going? I > >> >> am only seeing 0.9.2 in ibiblio at the moment. > >> >> > >> >> Thanks, > >> >> > >> >> Jeff > >> >> > >> >> Alex Karasulu wrote: > >> >> > >> >>> Jeff Genender wrote: > >> >>> > >> If the changes are not huge, I can probably do it. Alex, are the > >> updates significant? > >> > >> >>> Since 0.9.2 I'd say RC1 is a significant update. There are > >> package name > >> >>> changes to comply with Directory's TLP domain name which are > >> perhaps the > >> >>> most significant changes. There are changes to a couple > >> dependencies. > >> >>> For the most part the code has been cleaned up and several > >> *severe* bugs > >> >>> have been corrected and tested. RC1 is also an order of > >> magnitude faster. > >> >>> > >> >>> We plan to get another 1.0 release candidate (RC2) out soon > >> perhaps by > >> >>> the end of this week coming week or week there after. But > >> looking at > >> >>> emails out there from Dain and Aaron it sounds to me like the > >> update to > >> >>> G can take place any time after the 1.1 release. Let us know if you > >> >>> have any problems or need a hand while performing an upgrade > >> either to > >> >>> RC1 or RC2 when it comes out. > >> >>> > >> >>> Regards, > >> >>> Alex
Re: replacing tomcat classes
It seems that you can override some of the jars in geronimo/lib by dropping a jar into geronimo/lib/ext. As a test I recompiled a change into o.a.g.system.main.Daemon that became visible when I put the updated jar into that directory. But using the same technique for a deployed webapp didn't have the same results, presumably due to the deeper classloader structure in effect for stuff loaded from the repository (as David described earlier). I agree it would be nice to have a directory whose contents trump all classloaders used for quick testing and "hotfixes" and such. But I can sympathize with concerns that it may be abused and lead to instability. I have wasted a good deal of time in the past chasing red herrings caused by jars I didn't realize were in jre/lib/ext :-) Paul On 5/11/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Matt Hogstrom wrote: > > > David Jencks wrote: >> >> On May 11, 2006, at 8:29 AM, Joe Bohn wrote: >> >>> >>> Thanks for the quick response Jeff. >>> >>> I like the idea of a "system patch" location in the classpath where >>> we can pick up patches for anything we might include in a geronimo >>> assembly. >> >> I think this "system patch" idea will only work in environments with >> only one classloader, i.e. not geronimo. The problem is that the >> patched classes need to get into the correct classloader, "before" the >> normal versions. We'd need a patch directory for each module. I >> also think any solution that relies on the order of stuff in a >> classpath is inherently unstable and unreliable. > > I agree that it would be very unwieldy. For some folks providing > support for Geronimo it might be nice for the classloaders to look in an > aside dir (./patches) for a jar with the artifact name with a > -pmmddss suffix so patches can be applied. The ss allows for the > sequencing to be addressed. This would make it easier to provide one > hit patches that can get rolled up into the released jar you describe > below and the user would not have to wait for a release to come out > which could be a few months. Matt, you hit the nail on the head. I really think a simple patching system...call it..."quick hit" ;-) could have some big beneficial uses. I have many times run into this situation where I needed to be able to do this. Only through altering the CLASSPATH or changing the jar was I able to get around the problem. I always wanted a way to drop in a jar w/o having to alter core services that allowed me to patch what I needed. There are many use cases for this, with the biggest being a possible way for us to release "service paks" w/o the need to download and fully reconfigure a new server. I only see this feature as an added extension to make thing easier for development/support/and heavily configured prod servers. Jeff
Re: rename the "configuration" element in config.xml file ?
I created a JIRA for this issue so that we had a place to put Dain's patch until SVN is back up. http://issues.apache.org/jira/browse/GERONIMO-2012 Joe Dain Sundstrom wrote: On May 10, 2006, at 11:25 PM, John Sisson wrote: I noticed we still have a "configuration" element in the config.xml file. I am thinking of doing the following for 1.1: * most importantly, change the "configuration" element name to "module" to have consistent terminology considering the recent configId changes. I have a commit (since svn went down) for this one. My code supports the both 1.0 (configuration) and 1.1 (module) formats. * update cmd line help for --override option in Daemon to use "module" terminology. * update the wording in the var\config\README.txt to use the "module" terminology. * change the --long startup output to use the word "Module" instead of "Configuration" - also give us a bit more room on each line. +1 -dain -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
[jira] Commented: (GERONIMO-1974) Can't "redeploy" a copy of an application using a different version in the module ID
[ http://issues.apache.org/jira/browse/GERONIMO-1974?page=comments#action_12379119 ] Prasad Kashyap commented on GERONIMO-1974: -- In my C:\Apache\geronimo\configs\welcome-jetty\target\plan\plan.xml file, I changed the version number from 1.1 to 1.2. Then I executed the following command - deploy --user system --password manager redeploy C:\Apache\geronimo\applications\welcome\target\geronimo-welcome-1.1-SNAPSHOT.war C:\Apache\geronimo\configs\welcome-jetty\target\plan\plan.xml geronimo/welcome-jetty/1.1-SNAPSHOT/car > Can't "redeploy" a copy of an application using a different version in the > module ID > > > Key: GERONIMO-1974 > URL: http://issues.apache.org/jira/browse/GERONIMO-1974 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Dain Sundstrom > Priority: Blocker > Fix For: 1.1 > Attachments: 1974-redeploy-improvements.patch, redeploy-stacktrace.txt > > If you deploy an application with version foo/bar/1.0/baz and then change the > plan to be foo/bar/1.1/baz and try to redeploy it doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2012) Reflect configuration -> module change in config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2012?page=all ] Dain Sundstrom updated GERONIMO-2012: - Attachment: 2012.patch > Reflect configuration -> module change in config.xml > > > Key: GERONIMO-2012 > URL: http://issues.apache.org/jira/browse/GERONIMO-2012 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: all > Reporter: Joe Bohn > Assignee: Dain Sundstrom > Fix For: 1.1 > Attachments: 2012.patch > > This JIRA is to capture an issue raised by John Sissino so that we have > something to attach a patch created by Dain to while SVN is down. > The problem was reported in John's note to the dev list: > http://www.mail-archive.com/dev%40geronimo.apache.org/msg22260.html > text from email: > I noticed we still have a "configuration" element in the config.xml file. > I am thinking of doing the following for 1.1: > * most importantly, change the "configuration" element name to "module" to > have consistent terminology considering the recent configId changes. > * update cmd line help for --override option in Daemon to use "module" > terminology. > * update the wording in the var\config\README.txt to use the "module" > terminology. > * change the --long startup output to use the word "Module" instead of > "Configuration" - also give us a bit more room on each line. > Any objections? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2012) Reflect configuration -> module change in config.xml
Reflect configuration -> module change in config.xml Key: GERONIMO-2012 URL: http://issues.apache.org/jira/browse/GERONIMO-2012 Project: Geronimo Type: Bug Security: public (Regular issues) Components: general Versions: 1.1 Environment: all Reporter: Joe Bohn Assigned to: Dain Sundstrom Fix For: 1.1 This JIRA is to capture an issue raised by John Sissino so that we have something to attach a patch created by Dain to while SVN is down. The problem was reported in John's note to the dev list: http://www.mail-archive.com/dev%40geronimo.apache.org/msg22260.html text from email: I noticed we still have a "configuration" element in the config.xml file. I am thinking of doing the following for 1.1: * most importantly, change the "configuration" element name to "module" to have consistent terminology considering the recent configId changes. * update cmd line help for --override option in Daemon to use "module" terminology. * update the wording in the var\config\README.txt to use the "module" terminology. * change the --long startup output to use the word "Module" instead of "Configuration" - also give us a bit more room on each line. Any objections? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1974) Can't "redeploy" a copy of an application using a different version in the module ID
[ http://issues.apache.org/jira/browse/GERONIMO-1974?page=comments#action_12379113 ] Prasad Kashyap commented on GERONIMO-1974: -- When a newer version of the module is redeployed, the configuration of the newer module is marked as load=false, even though the configuration it is replacing is not marked such. 1) unpacked server. 2) redeployed welcome-jetty version 1.2 (by changing version number in plan to 1.2) 3) config.xml contains welcome-jetty 1.2 configuration now. (good) 4) welcome-jetty/1.2/car has load="false" (???) > Can't "redeploy" a copy of an application using a different version in the > module ID > > > Key: GERONIMO-1974 > URL: http://issues.apache.org/jira/browse/GERONIMO-1974 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Prasad Kashyap > Assignee: Dain Sundstrom > Priority: Blocker > Fix For: 1.1 > Attachments: 1974-redeploy-improvements.patch, redeploy-stacktrace.txt > > If you deploy an application with version foo/bar/1.0/baz and then change the > plan to be foo/bar/1.1/baz and try to redeploy it doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Google search on website?
On 5/11/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Any thoughts on adding a Google search form on the website?
+1
Also, how about translation links for other languages using Babelfish
or Google as described here?:
http://labnol.blogspot.com/2005/11/add-language-translation-to-website.html
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: 1.1 Package Upgrade List
What are the ant files used for ? And why changing the test class names ? Surefire can be configured specifically if needed ... So this change could be delayed. Cheers, Guillaume Nodet Prasad Kashyap wrote: Hi Matt, Moving the M2 conversion work from the trunk to 1.1 should not be disruptive. It would have the following changes 1) add pom.xmls in all modules 2) add a few ant files in some modules 3) change *Test.java files in quite a few modules. I have no strong objections to it except that I'm afraid it might pull folks off of 1.1 while trying to do this. Cheers Prasad. On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'd defer to Jacek to do the merging since he's familiar with it. If he's not available then I'd be happy to take a patch from you :) Also, if anyone has any objections re: getting this done then hollar now. anita kulshreshtha wrote: > > --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> Since the M2 conversion is independent of 1.1 what does the community >> think about starting that >> merge into 1.1 now? I think it would allow us to become more >> productive on 1.2 since the work would >> already be in place. For those working on the M2 conversion what do >> you think about starting that >> work and do you think we can do it without impacting 1.1? >We can safely transfer all the work from 1.2 to 1.1 without > impacting anything. What is the best way to do this? > > Thanks > Anita > >> anita kulshreshtha wrote: >>> All work related to M2 was halted until the trunk was merged. >> M2 >>> packaging plugin would require transferring all M2 work to 1.1. I >> do >>> not think there are any plans to do it before the merge or at least >> the >>> 1.1. release. I think using Maven1 will be best at this time. Let's >>> hear from Jacek.. >>> >>> Thanks >>> Anita >>> >>> --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>> I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins >> have to be in a m2 layout, but the only tools to create a car is a m1 >> plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: > I'd rather handle the ApacheDS integration separately from the >> 1.1 > release. Fortunately, the plugins work with the Maven 2 repository, > so that issue should be easier. > > The main question is how to do the build and packaging. If the >> API is > unchanged, we can build our integration module using our Maven 1 > packaging plugin against ADS 0.9.2 and just have it apply the >> 1.0.x > JARs at installation time. If the API is different, it may make the > most sense to try to split out our directory integration and do >> the > build and packaging under Maven 2 (I'm assuming that Geronimo >> HEAD has > a Maven 2 packaging plugin, but if not, I guess we can work on one). > Thanks, >Aaron > > On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > >> ApacheDS0.9.2 to 1.0-RC2 ? >> I have a patch to port the Geronimo part to 1.0-RC2. However, >> currently ADS 1.0 jars propagated to maven2 repo only. >> >> 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: >>> Consolidated list so far is: >>> >>> Axis from 1.4-356167 to 1.4 >>> commons-fileupload 1.1-dev to 1.1 >>> jasper from 5.5.9 to 5.5.15 >>> Jetty from 5.1.9 to 5.1.10 >>> stax from 1.1.1-dev to 1.1.2 >>> Tomcat 5.5.9 to 5.5.15 >>> tranql from1.2.1 to 1.3-SNAPSHOT >>> tranql-connector from 1.1 to 1.2-SNAPSHOT >>> >>> Keep 'em coming. >>> >>> Matt >>> >>> Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from >> 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Here are the packages I'm recommending for 1.1. If I missed one > please chime in. > > Axis from 1.4-356167 to 1.4 > jasper from 5.5.9 to 5.5.15 > Jetty from 5.1.9 to 5.1.10 > stax from 1.1.1-dev to 1.1.2 > tranql from1.2.1 to 1.3-SNAPSHOT > tranql-connector from 1.1 to 1.2-SNAPSHOT > > This is the list so far...I've updated > > http://opensource.atlassian.com/confluence/oss/display/
Google search on website?
Any thoughts on adding a Google search form on the website? --jason
Re: 1.1 Package Upgrade List
Hi Matt, Moving the M2 conversion work from the trunk to 1.1 should not be disruptive. It would have the following changes 1) add pom.xmls in all modules 2) add a few ant files in some modules 3) change *Test.java files in quite a few modules. I have no strong objections to it except that I'm afraid it might pull folks off of 1.1 while trying to do this. Cheers Prasad. On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I'd defer to Jacek to do the merging since he's familiar with it. If he's not available then I'd be happy to take a patch from you :) Also, if anyone has any objections re: getting this done then hollar now. anita kulshreshtha wrote: > > --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> Since the M2 conversion is independent of 1.1 what does the community >> think about starting that >> merge into 1.1 now? I think it would allow us to become more >> productive on 1.2 since the work would >> already be in place. For those working on the M2 conversion what do >> you think about starting that >> work and do you think we can do it without impacting 1.1? >We can safely transfer all the work from 1.2 to 1.1 without > impacting anything. What is the best way to do this? > > Thanks > Anita > >> anita kulshreshtha wrote: >>> All work related to M2 was halted until the trunk was merged. >> M2 >>> packaging plugin would require transferring all M2 work to 1.1. I >> do >>> not think there are any plans to do it before the merge or at least >> the >>> 1.1. release. I think using Maven1 will be best at this time. Let's >>> hear from Jacek.. >>> >>> Thanks >>> Anita >>> >>> --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>> I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins >> have to be in a m2 layout, but the only tools to create a car is a m1 >> plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: > I'd rather handle the ApacheDS integration separately from the >> 1.1 > release. Fortunately, the plugins work with the Maven 2 repository, > so that issue should be easier. > > The main question is how to do the build and packaging. If the >> API is > unchanged, we can build our integration module using our Maven 1 > packaging plugin against ADS 0.9.2 and just have it apply the >> 1.0.x > JARs at installation time. If the API is different, it may make the > most sense to try to split out our directory integration and do >> the > build and packaging under Maven 2 (I'm assuming that Geronimo >> HEAD has > a Maven 2 packaging plugin, but if not, I guess we can work on one). > Thanks, >Aaron > > On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > >> ApacheDS0.9.2 to 1.0-RC2 ? >> I have a patch to port the Geronimo part to 1.0-RC2. However, >> currently ADS 1.0 jars propagated to maven2 repo only. >> >> 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: >>> Consolidated list so far is: >>> >>> Axis from 1.4-356167 to 1.4 >>> commons-fileupload 1.1-dev to 1.1 >>> jasper from 5.5.9 to 5.5.15 >>> Jetty from 5.1.9 to 5.1.10 >>> stax from 1.1.1-dev to 1.1.2 >>> Tomcat 5.5.9 to 5.5.15 >>> tranql from1.2.1 to 1.3-SNAPSHOT >>> tranql-connector from 1.1 to 1.2-SNAPSHOT >>> >>> Keep 'em coming. >>> >>> Matt >>> >>> Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from >> 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Here are the packages I'm recommending for 1.1. If I missed one > please chime in. > > Axis from 1.4-356167 to 1.4 > jasper from 5.5.9 to 5.5.15 > Jetty from 5.1.9 to 5.1.10 > stax from 1.1.1-dev to 1.1.2 > tranql from1.2.1 to 1.3-SNAPSHOT > tranql-connector from 1.1 to 1.2-SNAPSHOT > > This is the list so far...I've updated > > http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > with this information. > > Was mentioned on the list: > Howl- Researching this >> -- >> Alexei Zakharov, >> Intel Middleware Produc
Re: patch for geronimo integration
I was looking at the wrong jira website (jira.activemq.org) which is pointed at from www.activemq.org. Once I realized the correct jira website was at issues.apache.org (duh!) I created AMQ-708 and attached the patch. What are the chances of getting this patch into the activemq release that will ship with Geronimo 1.1? Paul On 5/10/06, Paul McMahan <[EMAIL PROTECTED]> wrote: While working on a patch for GERONIMO-1896 I noticed that hostname and port changes I made to the activemq connectors via the geronimo admin console don't get persisted in geronimo's config.xml, causing them to revert to their original values when the server restarts. To fix this problem ActiveMQConnectorGBean needs to declare the host and port attributes as manageable when it creates its gbeaninfo. After creating a patch I went to open an activemq JIRA but I can't select ACTIVEMQ for the project. I can only select ActiveSOAP, ActiveSpace, etc. Maybe I'm looking in the wrong place. Anyway, the patch is attached to this email. Let me know if you need this in a JIRA instead. Best wishes, Paul
Re: rename the "configuration" element in config.xml file ?
On May 10, 2006, at 11:25 PM, John Sisson wrote: I noticed we still have a "configuration" element in the config.xml file. I am thinking of doing the following for 1.1: * most importantly, change the "configuration" element name to "module" to have consistent terminology considering the recent configId changes. I have a commit (since svn went down) for this one. My code supports the both 1.0 (configuration) and 1.1 (module) formats. * update cmd line help for --override option in Daemon to use "module" terminology. * update the wording in the var\config\README.txt to use the "module" terminology. * change the --long startup output to use the word "Module" instead of "Configuration" - also give us a bit more room on each line. +1 -dain
[jira] Created: (AMQ-708) changes to connector host and port not persisted in geronimo
changes to connector host and port not persisted in geronimo Key: AMQ-708 URL: https://issues.apache.org/activemq/browse/AMQ-708 Project: ActiveMQ Type: Bug Components: Geronimo Integration Versions: 3.2.4 Environment: activemq 3.4 running in geronimo 1.1 Reporter: Paul McMahan Fix For: 3.2.4 Attachments: ACTIVEMQ-gbean.patch Hostname and port changes I made to the activemq connectors via the geronimo admin console don't get persisted in geronimo's var/config/config.xml, causing them to revert to their original values when the server restarts. To fix this problem ActiveMQConnectorGBean needs to declare the host and port attributes as manageable when it creates its gbeaninfo. See the attached patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: replacing tomcat classes
Matt Hogstrom wrote: > > > David Jencks wrote: >> >> On May 11, 2006, at 8:29 AM, Joe Bohn wrote: >> >>> >>> Thanks for the quick response Jeff. >>> >>> I like the idea of a "system patch" location in the classpath where >>> we can pick up patches for anything we might include in a geronimo >>> assembly. >> >> I think this "system patch" idea will only work in environments with >> only one classloader, i.e. not geronimo. The problem is that the >> patched classes need to get into the correct classloader, "before" the >> normal versions. We'd need a patch directory for each module. I >> also think any solution that relies on the order of stuff in a >> classpath is inherently unstable and unreliable. > > I agree that it would be very unwieldy. For some folks providing > support for Geronimo it might be nice for the classloaders to look in an > aside dir (./patches) for a jar with the artifact name with a > -pmmddss suffix so patches can be applied. The ss allows for the > sequencing to be addressed. This would make it easier to provide one > hit patches that can get rolled up into the released jar you describe > below and the user would not have to wait for a release to come out > which could be a few months. Matt, you hit the nail on the head. I really think a simple patching system...call it..."quick hit" ;-) could have some big beneficial uses. I have many times run into this situation where I needed to be able to do this. Only through altering the CLASSPATH or changing the jar was I able to get around the problem. I always wanted a way to drop in a jar w/o having to alter core services that allowed me to patch what I needed. There are many use cases for this, with the biggest being a possible way for us to release "service paks" w/o the need to download and fully reconfigure a new server. I only see this feature as an added extension to make thing easier for development/support/and heavily configured prod servers. Jeff
Re: replacing tomcat classes
On May 11, 2006, at 9:16 AM, Joe Bohn wrote: Bumping up the version should work for the jar approach. However, I was still trying to figure out a way to honor the tomcat recommendation of replacing just the modified classes. Is there some way to make the version independent classloaders pick up individual classes rather than entire jars? No, and I think that's a good thing. I think the tomcat team is giving bad advice. thanks david jencks Joe David Jencks wrote: On May 11, 2006, at 8:29 AM, Joe Bohn wrote: Thanks for the quick response Jeff. I like the idea of a "system patch" location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I think this "system patch" idea will only work in environments with only one classloader, i.e. not geronimo. The problem is that the patched classes need to get into the correct classloader, "before" the normal versions. We'd need a patch directory for each module. I also think any solution that relies on the order of stuff in a classpath is inherently unstable and unreliable. Basically I think this is a terrible idea and we should avoid it at all costs. I think instead we should use our new version independence and replace jars with patched jars with slightly higher version numbers. IIUC this is what you propose doing below. This should not require removing the standard tomcat jars: the hight version number should be enough to get the correct version picked up. thanks david jencks I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Geronimo I'm thinking of using a compromise solution. The changes I need in tomcat result in 4 of the 13 tomcat jars getting rebuilt. Rather than replacing all of the tomcat jars with my local build I have verified that replacing just the 4 changed jars appears to work fine. I'm hoping this hybrid solution keeps most of the official tomcat image and our local changes. I haven't noticed any problems. Assuming the source is mostly identical (apart from our changes) does anybody know of a reason that I should definitely not take this approach? Joe Jeff Genender wrote: Ultimately, we probably would need to somehow build a "patch" directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release "service paks" or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these "patch classes" in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would
Re: replacing tomcat classes
David Jencks wrote: On May 11, 2006, at 8:29 AM, Joe Bohn wrote: Thanks for the quick response Jeff. I like the idea of a "system patch" location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I think this "system patch" idea will only work in environments with only one classloader, i.e. not geronimo. The problem is that the patched classes need to get into the correct classloader, "before" the normal versions. We'd need a patch directory for each module. I also think any solution that relies on the order of stuff in a classpath is inherently unstable and unreliable. I agree that it would be very unwieldy. For some folks providing support for Geronimo it might be nice for the classloaders to look in an aside dir (./patches) for a jar with the artifact name with a -pmmddss suffix so patches can be applied. The ss allows for the sequencing to be addressed. This would make it easier to provide one hit patches that can get rolled up into the released jar you describe below and the user would not have to wait for a release to come out which could be a few months. Basically I think this is a terrible idea and we should avoid it at all costs. I think instead we should use our new version independence and replace jars with patched jars with slightly higher version numbers. IIUC this is what you propose doing below. This should not require removing the standard tomcat jars: the hight version number should be enough to get the correct version picked up. thanks david jencks I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Geronimo I'm thinking of using a compromise solution. The changes I need in tomcat result in 4 of the 13 tomcat jars getting rebuilt. Rather than replacing all of the tomcat jars with my local build I have verified that replacing just the 4 changed jars appears to work fine. I'm hoping this hybrid solution keeps most of the official tomcat image and our local changes. I haven't noticed any problems. Assuming the source is mostly identical (apart from our changes) does anybody know of a reason that I should definitely not take this approach? Joe Jeff Genender wrote: Ultimately, we probably would need to somehow build a "patch" directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release "service paks" or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these "patch classes" in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in shar
Re: Geronimo documentation - upcoming look & feel
Looks good Hernan. For context, is this the main documentation page ? Perhaps it would make it clearer to call this the "Project User's Guide" so as to avoid confusion between this and other forms of documentation at developerworks, articles, etc. Hernan Cunico wrote: Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. Available at the following link is just a single page, static draft based on what is in the oven for Geronimo v1.1 documentation. The new confluence wiki will be running a plugin that automatically exports the new content into HTML format so it can be served as static content increasing the performance. Not only that, the HTML exports can be configured using templates so we can select the information we want to display, for example removing the classic "Added by / last edited by" if it turns to be an issue. Three key things to pay special attention from the template used are, obvious banner at the top of the page, user names removed and Apache license disclaimer at the very bottom of each page. http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Cheers! Hernan
[jira] Created: (AMQ-707) makefile plus some changes for the CMS C++ client
makefile plus some changes for the CMS C++ client -- Key: AMQ-707 URL: https://issues.apache.org/activemq/browse/AMQ-707 Project: ActiveMQ Type: Improvement Components: JMS client Versions: 4.0 RC2 Reporter: Manuel Teira Priority: Minor Fix For: 4.0 RC2 Attachments: patch.bz2 I've written a trivial makefile to be able to compile the CMS over Stomp C++ client on Solaris , using Sun Workshop 6. I've also made some changes: -Added a strerror_r macro for solaris. -Define MSG_NOSIGNAL as zero for solaris -Added 'using namespace activemq' to some files to make Sun Workshop find some objects. -Corrected a pair of memory leaks found under purify sessions. -Corrected a bug in StompTransportFactory::createTransport, not using the argument brokerUrl -Deleted a trailing comma in a enum in Session.h, making Sun CC to warn. -Added a dummy test to just send a message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: replacing tomcat classes
Bumping up the version should work for the jar approach. However, I was still trying to figure out a way to honor the tomcat recommendation of replacing just the modified classes. Is there some way to make the version independent classloaders pick up individual classes rather than entire jars? Joe David Jencks wrote: On May 11, 2006, at 8:29 AM, Joe Bohn wrote: Thanks for the quick response Jeff. I like the idea of a "system patch" location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I think this "system patch" idea will only work in environments with only one classloader, i.e. not geronimo. The problem is that the patched classes need to get into the correct classloader, "before" the normal versions. We'd need a patch directory for each module. I also think any solution that relies on the order of stuff in a classpath is inherently unstable and unreliable. Basically I think this is a terrible idea and we should avoid it at all costs. I think instead we should use our new version independence and replace jars with patched jars with slightly higher version numbers. IIUC this is what you propose doing below. This should not require removing the standard tomcat jars: the hight version number should be enough to get the correct version picked up. thanks david jencks I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Geronimo I'm thinking of using a compromise solution. The changes I need in tomcat result in 4 of the 13 tomcat jars getting rebuilt. Rather than replacing all of the tomcat jars with my local build I have verified that replacing just the 4 changed jars appears to work fine. I'm hoping this hybrid solution keeps most of the official tomcat image and our local changes. I haven't noticed any problems. Assuming the source is mostly identical (apart from our changes) does anybody know of a reason that I should definitely not take this approach? Joe Jeff Genender wrote: Ultimately, we probably would need to somehow build a "patch" directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release "service paks" or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these "patch classes" in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in sharedlib even if the user only intended these classes for some subset of the apps. Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who
Re: 1.1 JIRA's Reminaing, Release Contents and the Gipper Speech
I agree... Aaron Mulder wrote: Please let's not make a release until Apache SVN comes back. There are a lot of patches that should go in. Maybe Saturday, infrastructure permitting? Thanks, Aaron On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: There are currently 136 JIRAs open against 1.1 as the target fix release. I would like to start managing these down to zero as we march towards release. Here is a best guess to get 1.1 out. Target release date: May 26th (1 month past the original date) To make this date we have two weeks left to complete the remaining JIRAs. Here is how they break down: 14 Blockers 52 Criticals 42 Majors 24 Minors 4 Trivial I think we should focus on the Blockers first and then the Critical ones. Aaron, most of the JIRAs in these categories are assigned to you. I've had a few people ask me what they can do to help so I'd like to start pointing them at JIRA's. Could you go through the ones assigned to you and unassign the ones you don't think you'll have time for so we can get them to some other folks? I'm not sure which ones you already have in progress. Between the Blockers and the criticals we have more JIRA's than we'll likely be able to address so we'll have to draw the line next week. As far as contents of the Release I see it shaking out like this: 4 releases as we had last time (Tomcat and Jetty on Windows and Unix). I'd also like to include Little-G as well. However, that will also include 4 releases which seems like a lot. It makes sense for this release but one of the "Roadmap" items would be to figure out how we will "create" the custom servers so we have a single download that can generate the desired server so we don't bloat the number of images for download. There will not be an installer for several reasons so this will have to be a 1.2 item. Anyone interested in picking up where Erik left off? I'd like to get a new unstable release out today or tomorrow before Java One (probably tomorrow). We'll have one more unstable release late next week or early the week after and then get G out by the 26th. Thanks to Kevan, Jencks, Dain and Blevins for and everyone else that struggled testing. Its been hard but I think we're in good shape. Let's get G 1.1 out the door so we can focus on new feature / function for a while. Thanks all...we're almost there.
Re: replacing tomcat classes
On May 11, 2006, at 8:29 AM, Joe Bohn wrote: Thanks for the quick response Jeff. I like the idea of a "system patch" location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I think this "system patch" idea will only work in environments with only one classloader, i.e. not geronimo. The problem is that the patched classes need to get into the correct classloader, "before" the normal versions. We'd need a patch directory for each module. I also think any solution that relies on the order of stuff in a classpath is inherently unstable and unreliable. Basically I think this is a terrible idea and we should avoid it at all costs. I think instead we should use our new version independence and replace jars with patched jars with slightly higher version numbers. IIUC this is what you propose doing below. This should not require removing the standard tomcat jars: the hight version number should be enough to get the correct version picked up. thanks david jencks I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Geronimo I'm thinking of using a compromise solution. The changes I need in tomcat result in 4 of the 13 tomcat jars getting rebuilt. Rather than replacing all of the tomcat jars with my local build I have verified that replacing just the 4 changed jars appears to work fine. I'm hoping this hybrid solution keeps most of the official tomcat image and our local changes. I haven't noticed any problems. Assuming the source is mostly identical (apart from our changes) does anybody know of a reason that I should definitely not take this approach? Joe Jeff Genender wrote: Ultimately, we probably would need to somehow build a "patch" directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release "service paks" or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these "patch classes" in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in sharedlib even if the user only intended these classes for some subset of the apps. Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
[jira] Updated: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2011?page=all ] Joe Bohn updated GERONIMO-2011: --- Attachment: 2011_LogLevel.patch patch created on windows xp in geronimo root directory > Set default logging to INFO rather than DEBUG in minimal assemblies > --- > > Key: GERONIMO-2011 > URL: http://issues.apache.org/jira/browse/GERONIMO-2011 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Assignee: Joe Bohn > Fix For: 1.1 > Attachments: 2011_LogLevel.patch > > The assemblies for j2ee-jetty-server and j2ee-tomcat-server have the default > logging level set to INFO rather than Debug.The little-G assemblies > (minimal-jetty-server & minimal-tomcat-server) should have the same settings > as we deliver the geronimo 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: replacing tomcat classes
Thanks for the quick response Jeff. I like the idea of a "system patch" location in the classpath where we can pick up patches for anything we might include in a geronimo assembly. I too was confused by the tomcat recommendation but it does seem that they have a strategy for addressing necessary changes with minimal interference in tomcat. I have also noticed some things that make me wonder if my local tomcat build of 5.5.15 really does match the official 5.5.15 build. For example, the only source for 5.5.15 that I could find was a zip file rather than a svn branch or tag. I am not able to build from the unpacked zip without making a change to move the contents of jasper/jasper2 into the jasper directory itself. And the version that is displayed when I hit tomcat with my rebuilt image is 5.5 rather than 5.5.15 as with the official image. Until we figure out the correct approach for Geronimo I'm thinking of using a compromise solution. The changes I need in tomcat result in 4 of the 13 tomcat jars getting rebuilt. Rather than replacing all of the tomcat jars with my local build I have verified that replacing just the 4 changed jars appears to work fine. I'm hoping this hybrid solution keeps most of the official tomcat image and our local changes. I haven't noticed any problems. Assuming the source is mostly identical (apart from our changes) does anybody know of a reason that I should definitely not take this approach? Joe Jeff Genender wrote: Ultimately, we probably would need to somehow build a "patch" directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release "service paks" or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these "patch classes" in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in sharedlib even if the user only intended these classes for some subset of the apps. Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: JSF impl included into Apache Geronimo
On 5/11/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: Are there any plans to include a JSF impl inside of Geronimo 1.0 ? Since the Java2EE 1.4 Spec doesn't require it, I think it might be usful to have this "optional" feature. Geronimo 1.x does not include a JSF impl per se, but it can support web applications that use JSF. I tried the myfaces sample in Geronimo a while ago and it worked ok but required a few minor tweaks to the web.xml before it would deploy, namely removing the elements from the and elements. Since JSF enablement is usually internal to a web app do you think Geronimo (being an application server) can do something to be more JSF-friendly from an end user's perspective? A couple of ideas that come to mind are to 1.) make a shared version of the myfaces jars available in its repository so JSF apps don't have to include their own and 2.) provide a JSF sample at a geronimo plugins site (see http://geronimoplugins.com/ for an example plugins site). How has this *integration* to be solved technical? (new to geronimo) Must the JSF jars be included inside the web-container (jetty/tomcat) or wired into Gernonimo by the GBean facility? Neither of the suggestions above really require anything that complicated, just packaging and naming archives the right way and putting them in the right place for later consumption by myfaces apps. Others may reply with suggestions that require a more technical approach, but I doubt that the Gbean facility will be required. One of the items that Geronimo is currently investigating is how to integrate AJAX libraries like dojo. From what I understand myfaces is currently investigating dojo integration as well. Can you comment on what this integration will look like from a technical point of view? And do you think it would make sense for Geronimo to integrate dojo in a way that is consumable by a JSF impl that is itself integrated in Geronimo? The challenge seems to be in coming up with a good way to version and share a collection of static .js files across multiple applications. Looking forward to hearing your thoughts. Best wishes, Paul Thanks, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten http://jroller.com/page/mwessendorf mwessendorf-at-gmail-dot-com
Re: JSF impl included into Apache Geronimo
But I cannot see any need for GBean code for this. ok, thanks! -Matthias Jeff Matthias Wessendorf wrote: >> However, I believe it is a required inclusion of the Java EE5 spec, so I >> am pretty sure they will be included in G2.X. > > Yes it requires it. My question was more about how the integration > might look like. > Will the JSF impl *depend* on the used web-container (jetty/tomcat), > or will G2.x ship the jars itself > > Thanks, > Matthias > >> >> Jeff >> >> Matthias Wessendorf wrote: >> > Are there any plans to include a JSF impl inside of Geronimo 1.0 ? >> > Since the Java2EE 1.4 Spec doesn't require it, I think it might be >> > usful to have this "optional" feature. >> > >> > How has this *integration* to be solved technical? (new to geronimo) >> > Must the JSF jars be included inside the web-container (jetty/tomcat) >> > or wired into Gernonimo by the GBean facility? >> > >> > Thanks, >> > Matthias >> > >> > > -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten http://jroller.com/page/mwessendorf mwessendorf-at-gmail-dot-com
Geronimo documentation - upcoming look & feel
Hi All, I just wanted to give you guys a heads up on how the Geronimo's confluence wiki may look like once cwiki.apache.org jumps in production. Available at the following link is just a single page, static draft based on what is in the oven for Geronimo v1.1 documentation. The new confluence wiki will be running a plugin that automatically exports the new content into HTML format so it can be served as static content increasing the performance. Not only that, the HTML exports can be configured using templates so we can select the information we want to display, for example removing the classic "Added by / last edited by" if it turns to be an issue. Three key things to pay special attention from the template used are, obvious banner at the top of the page, user names removed and Apache license disclaimer at the very bottom of each page. http://people.apache.org/~hcunico/cwiki/documentation.html Comments, questions, suggestions are welcomed :) Cheers! Hernan
Re: packaging plugin
On May 11, 2006, at 7:39 AM, anita kulshreshtha wrote: David J, If I run maven car:package on a non executable configuration, I get the following message - .. 3578 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanInstanceState for: ge ronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car? ServiceModule=geronimo/geronimo-gbean-deployer/1.1-S NAPSHOT/car,j2eeType=Deployer,name=Deployer State changed from stopped to starting Generated package D:\anita\geronimo\geronimo-1.1\configs\j2ee-server\target\j2ee- server-1.1-SNAPSHOT .car BUILD SUCCESSFUL Total time: 12 seconds Finished at: Thu May 11 08:28:35 EDT 2006 But the generated car (zip file) is not at this location. The ..car directory is at target/repository/ . Where is the zip file being generated? It is put in .maven during car:install by copyConfig. If a zip file is always generated, Why could we not use artifact:install? -- it looks to me as if the message is wrong. I don't know how hard it will be to fix it: I suspect changing it to not specify a location at all is the best approach. -- packaging a configuration can result in multiple car files (e.g. for app clients). Also the configurations are generated into a m2 repository that has a somewhat tenuous relationship to the m1 repo maven uses. I couldn't see a good way to get all the artifacts copied with artifact:install, whereas setting up a m2 repository and scanning it and copying everything in it seemed fairly straightforward. thanks david jencks Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: JSF impl included into Apache Geronimo
I assume the G2.X will ship with the jars. I cannot see any dependency on the web-container at all - just the other spec jars. I really think its just a matter of including JSF at the server level so its available "server-wide". There *may* be some classloading code to be sure there is no crossing of data/objects...I haven't dug into that part of the spec, so I don't know that answer at this point. But I cannot see any need for GBean code for this. Jeff Matthias Wessendorf wrote: >> However, I believe it is a required inclusion of the Java EE5 spec, so I >> am pretty sure they will be included in G2.X. > > Yes it requires it. My question was more about how the integration > might look like. > Will the JSF impl *depend* on the used web-container (jetty/tomcat), > or will G2.x ship the jars itself > > Thanks, > Matthias > >> >> Jeff >> >> Matthias Wessendorf wrote: >> > Are there any plans to include a JSF impl inside of Geronimo 1.0 ? >> > Since the Java2EE 1.4 Spec doesn't require it, I think it might be >> > usful to have this "optional" feature. >> > >> > How has this *integration* to be solved technical? (new to geronimo) >> > Must the JSF jars be included inside the web-container (jetty/tomcat) >> > or wired into Gernonimo by the GBean facility? >> > >> > Thanks, >> > Matthias >> > >> > >
Re: replacing tomcat classes
Ultimately, we probably would need to somehow build a "patch" directory or lib directory where we can ensure the URLClassLoader picks that up before all other classes. I think this is probably a good idea to have as well, so that we could release "service paks" or patches. I would be interested in others' thoughts on this, but I think this would be a nice feature to have. Right now I think your only choices are to either hard set a classpath to be sure the patches get picked up first or build a hacked Tomcat version, or rebuild Tomcat. Dain or David Jencks may be able to verify if the classpath solution would work or not as I have not dug into the new G classloaders to know if this would even be possible. The best solution right now may be to just build TC. I am a little confused as to why the TC guys say not to build the Tomcat from source (after its hacked). It seems like just an ant build script, so I don't understand why this is being discouraged. This way you can replace the Tomcat jars in the repo and you are good to go. Jeff Joe Bohn wrote: > > Jeff, > > I am working with a user that is moving some applications from tomcat to > geronimo. Due to some problems they have had to modify tomcat source. > I was chatting with jasonb on the tomcat irc channel and he recommended > that we only build the classes rather than rebuilding all of tomcat. He > discouraged rebuilding all of tomcat because there are many permutations > that can result in different build images and we should run with as much > of the official tomcat build as possible to avoid problems. He also > indicated that Tomcat's directory structure provides a place to put > these "patch classes" in CATALINA_HOME/server/classes . > > Is there a similar place that we can put classes when tomcat is running > under geronimo to have them picked up? Adding the tomcat classes to our > new sharedlib doesn't seem to be the right place because it would > require a dependency from the tomcat config on sharelib. The net result > would be that all tomcat apps would potentially pick up user classes > added in sharedlib even if the user only intended these classes for some > subset of the apps. > > Joe >
Re: 1.1 Package Upgrade List
I'd defer to Jacek to do the merging since he's familiar with it. If he's not available then I'd be happy to take a patch from you :) Also, if anyone has any objections re: getting this done then hollar now. anita kulshreshtha wrote: --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: Since the M2 conversion is independent of 1.1 what does the community think about starting that merge into 1.1 now? I think it would allow us to become more productive on 1.2 since the work would already be in place. For those working on the M2 conversion what do you think about starting that work and do you think we can do it without impacting 1.1? We can safely transfer all the work from 1.2 to 1.1 without impacting anything. What is the best way to do this? Thanks Anita anita kulshreshtha wrote: All work related to M2 was halted until the trunk was merged. M2 packaging plugin would require transferring all M2 work to 1.1. I do not think there are any plans to do it before the merge or at least the 1.1. release. I think using Maven1 will be best at this time. Let's hear from Jacek.. Thanks Anita --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins have to be in a m2 layout, but the only tools to create a car is a m1 plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload 1.1-dev to 1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9 to 5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-2011) Set default logging to INFO rather than DEBUG in minimal assemblies
Set default logging to INFO rather than DEBUG in minimal assemblies --- Key: GERONIMO-2011 URL: http://issues.apache.org/jira/browse/GERONIMO-2011 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: general Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assigned to: Joe Bohn Fix For: 1.1 The assemblies for j2ee-jetty-server and j2ee-tomcat-server have the default logging level set to INFO rather than Debug.The little-G assemblies (minimal-jetty-server & minimal-tomcat-server) should have the same settings as we deliver the geronimo 1.1 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1 JIRA's Reminaing, Release Contents and the Gipper Speech
Please let's not make a release until Apache SVN comes back. There are a lot of patches that should go in. Maybe Saturday, infrastructure permitting? Thanks, Aaron On 5/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: There are currently 136 JIRAs open against 1.1 as the target fix release. I would like to start managing these down to zero as we march towards release. Here is a best guess to get 1.1 out. Target release date: May 26th (1 month past the original date) To make this date we have two weeks left to complete the remaining JIRAs. Here is how they break down: 14 Blockers 52 Criticals 42 Majors 24 Minors 4 Trivial I think we should focus on the Blockers first and then the Critical ones. Aaron, most of the JIRAs in these categories are assigned to you. I've had a few people ask me what they can do to help so I'd like to start pointing them at JIRA's. Could you go through the ones assigned to you and unassign the ones you don't think you'll have time for so we can get them to some other folks? I'm not sure which ones you already have in progress. Between the Blockers and the criticals we have more JIRA's than we'll likely be able to address so we'll have to draw the line next week. As far as contents of the Release I see it shaking out like this: 4 releases as we had last time (Tomcat and Jetty on Windows and Unix). I'd also like to include Little-G as well. However, that will also include 4 releases which seems like a lot. It makes sense for this release but one of the "Roadmap" items would be to figure out how we will "create" the custom servers so we have a single download that can generate the desired server so we don't bloat the number of images for download. There will not be an installer for several reasons so this will have to be a 1.2 item. Anyone interested in picking up where Erik left off? I'd like to get a new unstable release out today or tomorrow before Java One (probably tomorrow). We'll have one more unstable release late next week or early the week after and then get G out by the 26th. Thanks to Kevan, Jencks, Dain and Blevins for and everyone else that struggled testing. Its been hard but I think we're in good shape. Let's get G 1.1 out the door so we can focus on new feature / function for a while. Thanks all...we're almost there.
Re: 1.1 Package Upgrade List
--- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > Since the M2 conversion is independent of 1.1 what does the community > think about starting that > merge into 1.1 now? I think it would allow us to become more > productive on 1.2 since the work would > already be in place. For those working on the M2 conversion what do > you think about starting that > work and do you think we can do it without impacting 1.1? We can safely transfer all the work from 1.2 to 1.1 without impacting anything. What is the best way to do this? Thanks Anita > > anita kulshreshtha wrote: > > All work related to M2 was halted until the trunk was merged. > M2 > > packaging plugin would require transferring all M2 work to 1.1. I > do > > not think there are any plans to do it before the merge or at least > the > > 1.1. release. I think using Maven1 will be best at this time. Let's > > hear from Jacek.. > > > > Thanks > > Anita > > > > --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > >> I haven't seen any geronimo plugin for m2 in head. > >> That whould be very usefull, especially because Geronimo plugins > have > >> to > >> be in a m2 layout, but the only tools to create a car is a m1 > plugin. > >> Any idea ? > >> > >> Cheers, > >> Guillaume Nodet > >> > >> Aaron Mulder wrote: > >> > >>> I'd rather handle the ApacheDS integration separately from the > 1.1 > >>> release. Fortunately, the plugins work with the Maven 2 > >> repository, > >>> so that issue should be easier. > >>> > >>> The main question is how to do the build and packaging. If the > API > >> is > >>> unchanged, we can build our integration module using our Maven 1 > >>> packaging plugin against ADS 0.9.2 and just have it apply the > 1.0.x > >>> JARs at installation time. If the API is different, it may make > >> the > >>> most sense to try to split out our directory integration and do > the > >>> build and packaging under Maven 2 (I'm assuming that Geronimo > HEAD > >> has > >>> a Maven 2 packaging plugin, but if not, I guess we can work on > >> one). > >>> Thanks, > >>>Aaron > >>> > >>> On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > >>> > ApacheDS0.9.2 to 1.0-RC2 ? > I have a patch to port the Geronimo part to 1.0-RC2. However, > currently ADS 1.0 jars propagated to maven2 repo only. > > 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > > Consolidated list so far is: > > > > Axis from 1.4-356167 to 1.4 > > commons-fileupload 1.1-dev to 1.1 > > jasper from 5.5.9 to 5.5.15 > > Jetty from 5.1.9 to 5.1.10 > > stax from 1.1.1-dev to 1.1.2 > > Tomcat 5.5.9 to 5.5.15 > > tranql from1.2.1 to 1.3-SNAPSHOT > > tranql-connector from 1.1 to 1.2-SNAPSHOT > > > > Keep 'em coming. > > > > Matt > > > > Aaron Mulder wrote: > >> That issue has a great list. > >> > >> We definitely need to try updating commons-fileupload (from > 1.1-dev to > >> 1.1). I think there may even be a separate Jira for that. > >> But the > >> old one occasionally hangs, so it's definitely worth trying > >> the new > >> one. > >> > >> Thanks, > >>Aaron > >> > >> On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >>> Here are the packages I'm recommending for 1.1. If I missed > >> one > >>> please chime in. > >>> > >>> Axis from 1.4-356167 to 1.4 > >>> jasper from 5.5.9 to 5.5.15 > >>> Jetty from 5.1.9 to 5.1.10 > >>> stax from 1.1.1-dev to 1.1.2 > >>> tranql from1.2.1 to 1.3-SNAPSHOT > >>> tranql-connector from 1.1 to 1.2-SNAPSHOT > >>> > >>> This is the list so far...I've updated > >>> > > > http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > >>> with this information. > >>> > >>> Was mentioned on the list: > >>> Howl- Researching this > > -- > Alexei Zakharov, > Intel Middleware Product Division > > >>> > > > > > > __ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
1.1 JIRA's Reminaing, Release Contents and the Gipper Speech
There are currently 136 JIRAs open against 1.1 as the target fix release. I would like to start managing these down to zero as we march towards release. Here is a best guess to get 1.1 out. Target release date: May 26th (1 month past the original date) To make this date we have two weeks left to complete the remaining JIRAs. Here is how they break down: 14 Blockers 52 Criticals 42 Majors 24 Minors 4 Trivial I think we should focus on the Blockers first and then the Critical ones. Aaron, most of the JIRAs in these categories are assigned to you. I've had a few people ask me what they can do to help so I'd like to start pointing them at JIRA's. Could you go through the ones assigned to you and unassign the ones you don't think you'll have time for so we can get them to some other folks? I'm not sure which ones you already have in progress. Between the Blockers and the criticals we have more JIRA's than we'll likely be able to address so we'll have to draw the line next week. As far as contents of the Release I see it shaking out like this: 4 releases as we had last time (Tomcat and Jetty on Windows and Unix). I'd also like to include Little-G as well. However, that will also include 4 releases which seems like a lot. It makes sense for this release but one of the "Roadmap" items would be to figure out how we will "create" the custom servers so we have a single download that can generate the desired server so we don't bloat the number of images for download. There will not be an installer for several reasons so this will have to be a 1.2 item. Anyone interested in picking up where Erik left off? I'd like to get a new unstable release out today or tomorrow before Java One (probably tomorrow). We'll have one more unstable release late next week or early the week after and then get G out by the 26th. Thanks to Kevan, Jencks, Dain and Blevins for and everyone else that struggled testing. Its been hard but I think we're in good shape. Let's get G 1.1 out the door so we can focus on new feature / function for a while. Thanks all...we're almost there.
Re: JSF impl included into Apache Geronimo
However, I believe it is a required inclusion of the Java EE5 spec, so I am pretty sure they will be included in G2.X. Yes it requires it. My question was more about how the integration might look like. Will the JSF impl *depend* on the used web-container (jetty/tomcat), or will G2.x ship the jars itself Thanks, Matthias Jeff Matthias Wessendorf wrote: > Are there any plans to include a JSF impl inside of Geronimo 1.0 ? > Since the Java2EE 1.4 Spec doesn't require it, I think it might be > usful to have this "optional" feature. > > How has this *integration* to be solved technical? (new to geronimo) > Must the JSF jars be included inside the web-container (jetty/tomcat) > or wired into Gernonimo by the GBean facility? > > Thanks, > Matthias > -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten http://jroller.com/page/mwessendorf mwessendorf-at-gmail-dot-com
packaging plugin
David J, If I run maven car:package on a non executable configuration, I get the following message - .. 3578 [main] DEBUG org.apache.geronimo.gbean.runtime.GBeanInstanceState - GBeanInstanceState for: ge ronimo/geronimo-gbean-deployer/1.1-SNAPSHOT/car?ServiceModule=geronimo/geronimo-gbean-deployer/1.1-S NAPSHOT/car,j2eeType=Deployer,name=Deployer State changed from stopped to starting Generated package D:\anita\geronimo\geronimo-1.1\configs\j2ee-server\target\j2ee-server-1.1-SNAPSHOT .car BUILD SUCCESSFUL Total time: 12 seconds Finished at: Thu May 11 08:28:35 EDT 2006 But the generated car (zip file) is not at this location. The ..car directory is at target/repository/ . Where is the zip file being generated? It is put in .maven during car:install by copyConfig. If a zip file is always generated, Why could we not use artifact:install? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: XA_RDONLY optimization - question
On May 10, 2006, at 10:47 PM, ludovic orban wrote: David, 1. there's only one resource in the transaction. Well, you can just call 1pc commit on it. As a special case, if there are lots of resources, but all but the last one says it's read-only, you can just call 1pc commit on the last one (skipping prepare). I think it's sort of obvious this works, and doesn't introduce any risks of data loss. I agree on this but running the prepare calls in parallel voids the special case of the last resource returning read-only. 2. if your last resource only supports 1pc (it's not xa) some people think you can just call commit on it, and then write the prepare record for the other participants: you use the result of this 1pc commit to decide whether to proceed or roll back the other participants. A little thought shows that the time between the completion of the 1pc commit and writing the prepare record to the log is vulnerable and can result in inconsistency. (many people don't seem to realize this). This is what Mike calls 'Last Resource Gambit'. It's main usage is to allow non-XA resources to participate in 2PC, it has very little to do with transaction speed optimization. I personally refuse to use that trick since it's not ACID. However, there's a trick that can make it work :-) If you store the transaction log in the 1pc resource, and only do the commit as a part of writing the prepare record to the log (ignoring the 1pc commit call directly to the resource) then the semantics work out properly. AFAIK Jeremy Boynes thought this up, and I've implemented it in geronimo, but so far there is no testing of it. BEA implemented this in Weblogic 9 and called it 'Logging Last Resource' (http://edocs.bea.com/wls/docs90/jta/llr.html). The good points of this technique are that you can use a non-XA resource in 2PC while staying 100% ACID and you get a slight performance boost if you only use 2 resources in the transaction. The bad points are that if you use more than 2 resources this method is slower than using a file based tx log and also it messes up a bit your DB schema since you have to create some tx log table(s) in the same DB schema. It also can only work if the resource is a database. So if I properly deciphered your email, the XA_RDONLY vote is pretty much useless since it only allows a 1PC optimization on the last resource to be prepared and only if your don't run prepare calls in parallel. Am I right ? As far as I can tell, yes :-) thanks david jencks Thank you, Ludovic
How do we build the latest Eclipse plug-in?
How are we supposed to build the latest source from - geronimo/devtools/eclipse-plugin/trunk There are no instruction on the Geronimo Subprojects - Devtools section, so I tried running a Maven build (using 2.0.4) from the trunk directory since there only exists a pom.xml now, by just running - mvn but it fails with the following - [INFO] Scanning for projects... Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/devtools/eclipse- plugins-parent/1.0/eclipse-plugins-parent-1.0.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org /maven2) [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: org.apache.geronimo.devtools ArtifactId: eclipse-plugins-parent Version: 1.0 Reason: Unable to download the artifact from any repository org.apache.geronimo.devtools:eclipse-plugins-parent:pom:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Cannot find parent: org.apache .geronimo.devtools:eclipse-plugins-parent for project: org.apache.geronimo.devto ols:config-store-service:jar:1.0 at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) 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.project.ProjectBuildingException: Cannot find parent : org.apache.geronimo.devtools:eclipse-plugins-parent for project: org.apache.ge ronimo.devtools:config-store-service:jar:1.0 at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1161) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFi leInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMave nProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) ... 11 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.ge ronimo.devtools:eclipse-plugins-parent' not found in repository: Unable to downl oad the artifact from any repository org.apache.geronimo.devtools:eclipse-plugins-parent:pom:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:513) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1157) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.geronimo.devtools:eclipse-plugins-parent:pom:1.0 from the specified remote repositories: central (http://repo1.maven.org/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:136) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:467) ... 19 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to downl oad the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(Def aultWagonManager.java:260) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:124) ... 21 more [INFO] -
Re: 1.1 Package Upgrade List
Since the M2 conversion is independent of 1.1 what does the community think about starting that merge into 1.1 now? I think it would allow us to become more productive on 1.2 since the work would already be in place. For those working on the M2 conversion what do you think about starting that work and do you think we can do it without impacting 1.1? anita kulshreshtha wrote: All work related to M2 was halted until the trunk was merged. M2 packaging plugin would require transferring all M2 work to 1.1. I do not think there are any plans to do it before the merge or at least the 1.1. release. I think using Maven1 will be best at this time. Let's hear from Jacek.. Thanks Anita --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins have to be in a m2 layout, but the only tools to create a car is a m1 plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload 1.1-dev to 1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9 to 5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: 1.1 Package Upgrade List
Let's address Directory in 1.2. Since its not core to CTS I think it would be pushing 1.1 out. It would be awesome to get this updated in 1.2 when we finally ship 1.1. Looking at the packages out there we are ut of date on several so one of the first things I'd like to do is get current on packages when we cut the new branch; Directory being one of them. Matt Alexei Zakharov wrote: FYI: ADS API has changed significantly since 0.9.2. 2006/5/10, Aaron Mulder <[EMAIL PROTECTED]>: I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > ApacheDS0.9.2 to 1.0-RC2 ? > I have a patch to port the Geronimo part to 1.0-RC2. However, > currently ADS 1.0 jars propagated to maven2 repo only. > > 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > > Consolidated list so far is: > > > > Axis from 1.4-356167 to 1.4 > > commons-fileupload 1.1-dev to 1.1 > > jasper from 5.5.9 to 5.5.15 > > Jetty from 5.1.9 to 5.1.10 > > stax from 1.1.1-dev to 1.1.2 > > Tomcat 5.5.9 to 5.5.15 > > tranql from1.2.1 to 1.3-SNAPSHOT > > tranql-connector from 1.1 to 1.2-SNAPSHOT > > > > Keep 'em coming. > > > > Matt > > > > Aaron Mulder wrote: > > > That issue has a great list. > > > > > > We definitely need to try updating commons-fileupload (from 1.1-dev to > > > 1.1). I think there may even be a separate Jira for that. But the > > > old one occasionally hangs, so it's definitely worth trying the new > > > one. > > > > > > Thanks, > > >Aaron > > > > > > On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > >> Here are the packages I'm recommending for 1.1. If I missed one > > >> please chime in. > > >> > > >> Axis from 1.4-356167 to 1.4 > > >> jasper from 5.5.9 to 5.5.15 > > >> Jetty from 5.1.9 to 5.1.10 > > >> stax from 1.1.1-dev to 1.1.2 > > >> tranql from1.2.1 to 1.3-SNAPSHOT > > >> tranql-connector from 1.1 to 1.2-SNAPSHOT > > >> > > >> This is the list so far...I've updated > > >> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > > >> > > >> with this information. > > >> > > >> Was mentioned on the list: > > >> Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division
Re: 1.1 Package Upgrade List
Gianny, TranQL 1.3 has several performance and feature fixes (thanks to you) that we've been planning on for 1.1. I didn't realize the changes to OpenEJB however. I'd like to get this release wrapped up the week after Java One if possible (end of the month). Can you guesstimate the potential impact? If its destabilizing then perhaps we should defer to G 1.2. What are your thoughts? Gianny Damour wrote: Kevan Miller wrote: On May 9, 2006, at 12:42 PM, Matt Hogstrom wrote: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload1.1-devto1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9to5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT We're already on Tomcat 5.5.15, but fine to keep it on the list. I assume the final tranql and tranql-connector versions will be 1.3 and 1.2. We'll use the SNAPSHOT versions until a new tranql release is published (which will happen before we ship 1.1...). As a matter of fact, an upgrade to TranQL 1.3 requires some code changes to OpenEJB (repackaging). Also, it would be nice to port dynamic queries from trunk to 1.1. If there is no objection, I propose to do that this week-end and ensure that this does not break the tck. Thanks, Gianny I'll start testing these versions once we clean up a few problems. --kevan
replacing tomcat classes
Jeff, I am working with a user that is moving some applications from tomcat to geronimo. Due to some problems they have had to modify tomcat source. I was chatting with jasonb on the tomcat irc channel and he recommended that we only build the classes rather than rebuilding all of tomcat. He discouraged rebuilding all of tomcat because there are many permutations that can result in different build images and we should run with as much of the official tomcat build as possible to avoid problems. He also indicated that Tomcat's directory structure provides a place to put these "patch classes" in CATALINA_HOME/server/classes . Is there a similar place that we can put classes when tomcat is running under geronimo to have them picked up? Adding the tomcat classes to our new sharedlib doesn't seem to be the right place because it would require a dependency from the tomcat config on sharelib. The net result would be that all tomcat apps would potentially pick up user classes added in sharedlib even if the user only intended these classes for some subset of the apps. Joe -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: G1.1 Tomcat Clustering - Good news
Yay! Thanks for being diligent on this Dave. Dave Colasurdo wrote: > Now that we have officially upgraded to TC 5.5.15, I've gone back and > retried the clustering tests and it looks like G1.1 clustering is now > working with TC5.5.15!! > > The "Unable to send message through cluster sender" exception that was > being thrown was caused by a problem in the application deployment plan. > Specifically, the tcpListen address had extra whitespace on the end > that creates this problem. Seems this should be trimmed automatically. > > class="org.apache.geronimo.tomcat.cluster.ReceiverGBean"> > name="className">org.apache.catalina.cluster.tcp.ReplicationListener > > > tcpListenAddress=192.168.0.1 > tcpListenPort=4001 > tcpSelectorTimeout=100 > tcpThreadCount=6 > > > > Anyway, it seems that we can change this value to auto (e.g. > tcpListenAddress=auto) for TC 5.5.15 and all works well. > > -Dave-
Re: JavaOne BOF
Matt, I could help out here...especially since I am unofficially your copilot on this on this ;-) Lets chat so I can get everything covered. Jeff Matt Hogstrom wrote: > I'll provide some info on the release schedule (can you say end of month > :)? > > Unfortunately, I'm leaving Thursday morning I think so I won't be there > at the BOF. Any volunteers to present the material ? > > Aaron Mulder wrote: >> Someone (cough, Matt, cough) needs to discuss the release schedule. >> >> We should cover the new moduleId syntax (Dain or David J?). >> >> I'd like to spend 10 minutes or so talking about plugins. >> >> We should be prepared with our initial thoughts on Java EE 5 integration. >> >> As for what users want to see, we should probably ask on the user@ >> list. It would be great to spend some time soliciting feature >> ideas/requests. >> >> Thanks, >>Aaron >> >> On 5/10/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >>> Geir, >>> >>> It looks like we now have a BOF, care of you ;-) Is this correct?: >>> >>> Thursday, 5/18 from 10:30pm to 11:20pm - BOF 9921 >>> >>> If so, should we talk a bit about what we should present, etc? >>> >>> Anything out there the users would like to have covered? >>> >>> Thanks, >>> >>> Jeff >>> >> >> >>
Re: configuration dependencies
Joe,
Thanks! More inline..
--- Joe Bohn <[EMAIL PROTECTED]> wrote:
> Anita,
>
> Sorry for the long delay ... had queued this up to look at later and
> later finally arrived. :-)
>
> On the first change we should probably remove unnecessary
> dependencies
> such as jetty in rmi-naming and system-database. I'm sure there are
> plenty more.
>
> I'll defer to Aaron on the way versions for dependencies are
> specified
> in the console geronimo-plugin.xml. It seems like the best approach
> is
> to omit the version if possible as with many of the other
> dependencies
> listed. My guess is that there must have been multiple versions
> available in the system for activemq and some other modules where
> they
> are "hard coded". This may be resolved by now and we might be able
> to
> omit the activemq version entirely.
>
> Can you describe the second patch some more? What is the goal? I
> recall that you were trying to build the assemblies without building
> the
> configurations (by just downloading the plugins). This would provide
> a
> faster "build" (really assembly creation) if you had no need to build
>
> any of the contents of any of the configurations. However, I'm not
> certain that is a common case.
The main idea was that if a configuration needs a jar or a war, it
should specify it as a dependency (regular), It should not depend on
the fact that it was already put in the local maven repository by
earlier operations. This would not be an issue if we were allowed to
use only 'maven new' and not 'maven new4'. However considering how many
people would care for that, it is not important. Dain also suggested
the same.
Thanks
Anita
>
> Joe
>
>
> anita kulshreshtha wrote:
> > David J and Joe,
> >I am attaching two patches:
> > The first one configs.patch removes jetty from rmi-naming and
> > system-database configurations. The
> > console-tomcat/..geronimo-plugin.xml is using
> >
>
activemq/activemq-gbean-management/3.2.4-SNAPSHOT/jar
> > activemq/activemq-gbean/3.2.4-SNAPSHOT/jar
> >and the versions are hardcoded instead of using ${...}. Is this
> > desired? If not there is a patch to fix this. This file does not
> have
> > its eol style set, hence there are so many lines in the patch.
> > The second patch shortens the build time and makes the server
> > assembly independent of the earlier build stages. Is this useful?
> > How is geronimo-console...ear being generated?
> >
> > Thanks
> > Anita
> > --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Joe,
> >>Thanks! Sending it to the list..
> >>
> >>--- Joe Bohn <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>Anita,
> >>>
> >>>Ahh ... now I see what you were trying to accomplish. I think
> this
> >>>is a
> >>>good question for the dev list.
> >>>
> >>>I personally don't think that it is important to ensure that your
> >>>build
> >>>includes/excludes match what is in geronimo with M1 exactly. In
> >>>fact, I
> >>>think what we have in M1 is really just a jumble of things that
> >>>people
> >>>at one time thought were needed, copied from other configurations,
> >>
> >>or
> >>
> >>>whatever to get things to build. Sure, there are very specific,
> >>
> >>well
> >>
> >>>placed dependencies that were added as well. But I don't think
> >>
> >>that
> >>
> >>>the
> >>>omissions were necessarily deliberate just as not all of the
> >>>additions
> >>>were deliberate (such as is likely the case with the jetty
> deployer
> >>>in
> >>>remote-deploy-tomcat).
> >>>
> >>>Also, based upon my recent experience with the
> >>
> >>geronimo.dependencies,
> >>
> >>>even those are often the result of copied code. I didn't resolve
> >>>all
> >>>of these geronimo.dependencies by a long shot. I was specifically
>
> >>>focused on making changes and validating dependencies to remove
> >>>unnecessary items from inclusion in the little-G assembly. So
> I'm
> >>
> >>>fairly sure there are still plenty of bogus geronimo.dependencies
> >>>there too.
> >>>
> >>>Yes, with the M2 transitive dependencies we may very well be able
> >>
> >>to
> >>
> >>>build and bad things could happen because of a missing
> >>>geronimo.dependency when you attempt to run the server. However,
> I
> >>
> >>>consider this no different than today where you must manually add
> >>>both.
> >>> It's still very possible to add one and not the other with the
> >>>result
> >>>being a server that cannot start (in fact I just did it this
> >>
> >>morning
> >>
> >>>on
> >>>my test machine). However, I think this typically speaks more to
> >>
> >>a
> >>
> >>>problem in the building of the configuration rather than the
> >>
> >>building
> >>
> >>>of
> >>>the assembly. External dependencies by configuration must be
> added
> >>>to
> >>>the verified/added to the assemblies when the configurations are
> >>>added
> >>>to the assemblies.
> >>>
> >>>
> >>>Joe
> >>>
> >>>
> >>>anita kulshreshtha wrote:
> >>>
> Joe,
> Thanks.
[jira] Updated: (GERONIMO-2010) Simplify the assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2010?page=all ] Joe Bohn updated GERONIMO-2010: --- Summary: Simplify the assemblies (was: Simpify the assemblies) > Simplify the assemblies > --- > > Key: GERONIMO-2010 > URL: http://issues.apache.org/jira/browse/GERONIMO-2010 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Assignee: David Jencks > Priority: Minor > Fix For: 1.1 > Attachments: 2010_RemoveDeps.patch > > Per a recommendation of David Jencks, I removed the explicit inclusion of the > specs in the repository for the various geronimo assemblies. This way, a > spec will only be included in the assembly if it is in fact needed. My test > with this patch indicated that it did not change the end result of the > geronimo images. Apparently all of the specs included in each assembly were > also included in the necessary configurations.Therefore, I think we > should remove the dependencies from the assemblies to avoid confusion and > future complications.I also included in this patch a change recommended > by Anita remove build dependencies on jetty from rmi-naming and > system-database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2010) Simpify the assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2010?page=all ] Joe Bohn reassigned GERONIMO-2010: -- Assign To: David Jencks (was: Joe Bohn) > Simpify the assemblies > -- > > Key: GERONIMO-2010 > URL: http://issues.apache.org/jira/browse/GERONIMO-2010 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Assignee: David Jencks > Priority: Minor > Fix For: 1.1 > Attachments: 2010_RemoveDeps.patch > > Per a recommendation of David Jencks, I removed the explicit inclusion of the > specs in the repository for the various geronimo assemblies. This way, a > spec will only be included in the assembly if it is in fact needed. My test > with this patch indicated that it did not change the end result of the > geronimo images. Apparently all of the specs included in each assembly were > also included in the necessary configurations.Therefore, I think we > should remove the dependencies from the assemblies to avoid confusion and > future complications.I also included in this patch a change recommended > by Anita remove build dependencies on jetty from rmi-naming and > system-database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2010) Simpify the assemblies
[ http://issues.apache.org/jira/browse/GERONIMO-2010?page=all ] Joe Bohn updated GERONIMO-2010: --- Attachment: 2010_RemoveDeps.patch patch created from geronimo root on windows xp. > Simpify the assemblies > -- > > Key: GERONIMO-2010 > URL: http://issues.apache.org/jira/browse/GERONIMO-2010 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: general > Versions: 1.1 > Environment: windows xp > Reporter: Joe Bohn > Assignee: Joe Bohn > Priority: Minor > Fix For: 1.1 > Attachments: 2010_RemoveDeps.patch > > Per a recommendation of David Jencks, I removed the explicit inclusion of the > specs in the repository for the various geronimo assemblies. This way, a > spec will only be included in the assembly if it is in fact needed. My test > with this patch indicated that it did not change the end result of the > geronimo images. Apparently all of the specs included in each assembly were > also included in the necessary configurations.Therefore, I think we > should remove the dependencies from the assemblies to avoid confusion and > future complications.I also included in this patch a change recommended > by Anita remove build dependencies on jetty from rmi-naming and > system-database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2010) Simpify the assemblies
Simpify the assemblies -- Key: GERONIMO-2010 URL: http://issues.apache.org/jira/browse/GERONIMO-2010 Project: Geronimo Type: Bug Security: public (Regular issues) Components: general Versions: 1.1 Environment: windows xp Reporter: Joe Bohn Assigned to: Joe Bohn Priority: Minor Fix For: 1.1 Per a recommendation of David Jencks, I removed the explicit inclusion of the specs in the repository for the various geronimo assemblies. This way, a spec will only be included in the assembly if it is in fact needed. My test with this patch indicated that it did not change the end result of the geronimo images. Apparently all of the specs included in each assembly were also included in the necessary configurations.Therefore, I think we should remove the dependencies from the assemblies to avoid confusion and future complications.I also included in this patch a change recommended by Anita remove build dependencies on jetty from rmi-naming and system-database. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JSF impl included into Apache Geronimo
The JSF jars would not require a GBean. There are no plans to include them in 1.X AFAIK. However, I believe it is a required inclusion of the Java EE5 spec, so I am pretty sure they will be included in G2.X. Jeff Matthias Wessendorf wrote: > Are there any plans to include a JSF impl inside of Geronimo 1.0 ? > Since the Java2EE 1.4 Spec doesn't require it, I think it might be > usful to have this "optional" feature. > > How has this *integration* to be solved technical? (new to geronimo) > Must the JSF jars be included inside the web-container (jetty/tomcat) > or wired into Gernonimo by the GBean facility? > > Thanks, > Matthias >
Re: 1.1 Package Upgrade List
Kevan Miller wrote: On May 9, 2006, at 12:42 PM, Matt Hogstrom wrote: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload1.1-devto1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9to5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT We're already on Tomcat 5.5.15, but fine to keep it on the list. I assume the final tranql and tranql-connector versions will be 1.3 and 1.2. We'll use the SNAPSHOT versions until a new tranql release is published (which will happen before we ship 1.1...). As a matter of fact, an upgrade to TranQL 1.3 requires some code changes to OpenEJB (repackaging). Also, it would be nice to port dynamic queries from trunk to 1.1. If there is no objection, I propose to do that this week-end and ensure that this does not break the tck. Thanks, Gianny I'll start testing these versions once we clean up a few problems. --kevan
Re: Directory Update (Jeff?)
BTW, Alex, are there plans to propagate ADS jars to maven1 repo? Geronimo 1.1 currently supports maven1 only. Thanks, 2006/5/6, Alexei Zakharov <[EMAIL PROTECTED]>: Alex, Oh, I've been searching in old "directory" and "directory-network" groups rather than "org/apache/directory/server/apacheds-core". Thank you for pointing the right group id. 2006/5/5, Alex Karasulu <[EMAIL PROTECTED]>: > Alexei Zakharov wrote: > > Hi, > > > > I have created a patch to move the G directory module to ApacheDS 1.0 > > RC2. But I didn't find necessary 1.0 RCx jars at ibiblio neither at > > /maven nor at /maven2. The most recent version is 0.9.3. The same > > situation for MINA. So I can't post the patch right now since it will > > not work without these jars. > > Alex, I just want to let you know about this situation. > > > Hmmm I'm seeing the RC2 jars just fine. Take a look here at the core > jar for example: > > http://www.ibiblio.org/maven2/org/apache/directory/server/apacheds-core/1.0-RC2/ > > Also MINA stuff is here: > > http://www.ibiblio.org/maven2/org/apache/directory/mina/mina-core/0.9.4/ > > HTH, > Alex > > > > 2006/4/24, Alex Karasulu <[EMAIL PROTECTED]>: > >> Aaron Mulder wrote: > >> > I know 0.9.3 is there (in the /maven2 repo). Not sure about the RC's. > >> > > >> Ya all including RC1 should be in the M2 repo if not let me know. > >> > >> Alex > >> > Thanks, > >> > Aaron > >> > > >> > On 4/24/06, Jeff Genender <[EMAIL PROTECTED]> wrote: > >> > > >> >> Alex, > >> >> > >> >> Can you get the jars in ibiblio and I can get the integration > >> going? I > >> >> am only seeing 0.9.2 in ibiblio at the moment. > >> >> > >> >> Thanks, > >> >> > >> >> Jeff > >> >> > >> >> Alex Karasulu wrote: > >> >> > >> >>> Jeff Genender wrote: > >> >>> > >> If the changes are not huge, I can probably do it. Alex, are the > >> updates significant? > >> > >> >>> Since 0.9.2 I'd say RC1 is a significant update. There are > >> package name > >> >>> changes to comply with Directory's TLP domain name which are > >> perhaps the > >> >>> most significant changes. There are changes to a couple > >> dependencies. > >> >>> For the most part the code has been cleaned up and several > >> *severe* bugs > >> >>> have been corrected and tested. RC1 is also an order of > >> magnitude faster. > >> >>> > >> >>> We plan to get another 1.0 release candidate (RC2) out soon > >> perhaps by > >> >>> the end of this week coming week or week there after. But > >> looking at > >> >>> emails out there from Dain and Aaron it sounds to me like the > >> update to > >> >>> G can take place any time after the 1.1 release. Let us know if you > >> >>> have any problems or need a hand while performing an upgrade > >> either to > >> >>> RC1 or RC2 when it comes out. > >> >>> > >> >>> Regards, > >> >>> Alex -- Alexei Zakharov, Intel Middleware Product Division
Re: New Feature Wednesday
I agree with everyone else that it is really great to have these unstable builds being produced and posted on a regular basis! It will help encourage users to pick up the latest more quickly and provide us with quicker feedback. How is it expected that users will find these unstable builds? Is there some way to get to the unstable builds from the geronimo web site? I think more people would find it and use it if there was a link from the downloads page to http://cvs.apache.org/dist/geronimo/unstable/ . One more question: How long will these builds "hang around"? I see that there are still builds from 1.0 out there. Just a nit - but it would be nice if we could put the most recent build at the top of the list. Joe David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David -- Joe Bohn joe.bohn at earthlink.net "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
JSF impl included into Apache Geronimo
Are there any plans to include a JSF impl inside of Geronimo 1.0 ? Since the Java2EE 1.4 Spec doesn't require it, I think it might be usful to have this "optional" feature. How has this *integration* to be solved technical? (new to geronimo) Must the JSF jars be included inside the web-container (jetty/tomcat) or wired into Gernonimo by the GBean facility? Thanks, Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten http://jroller.com/page/mwessendorf mwessendorf-at-gmail-dot-com
Re: configuration dependencies
Anita,
Sorry for the long delay ... had queued this up to look at later and
later finally arrived. :-)
On the first change we should probably remove unnecessary dependencies
such as jetty in rmi-naming and system-database. I'm sure there are
plenty more.
I'll defer to Aaron on the way versions for dependencies are specified
in the console geronimo-plugin.xml. It seems like the best approach is
to omit the version if possible as with many of the other dependencies
listed. My guess is that there must have been multiple versions
available in the system for activemq and some other modules where they
are "hard coded". This may be resolved by now and we might be able to
omit the activemq version entirely.
Can you describe the second patch some more? What is the goal? I
recall that you were trying to build the assemblies without building the
configurations (by just downloading the plugins). This would provide a
faster "build" (really assembly creation) if you had no need to build
any of the contents of any of the configurations. However, I'm not
certain that is a common case.
Joe
anita kulshreshtha wrote:
David J and Joe,
I am attaching two patches:
The first one configs.patch removes jetty from rmi-naming and
system-database configurations. The
console-tomcat/..geronimo-plugin.xml is using
activemq/activemq-gbean-management/3.2.4-SNAPSHOT/jar
activemq/activemq-gbean/3.2.4-SNAPSHOT/jar
and the versions are hardcoded instead of using ${...}. Is this
desired? If not there is a patch to fix this. This file does not have
its eol style set, hence there are so many lines in the patch.
The second patch shortens the build time and makes the server
assembly independent of the earlier build stages. Is this useful?
How is geronimo-console...ear being generated?
Thanks
Anita
--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
Joe,
Thanks! Sending it to the list..
--- Joe Bohn <[EMAIL PROTECTED]> wrote:
Anita,
Ahh ... now I see what you were trying to accomplish. I think this
is a
good question for the dev list.
I personally don't think that it is important to ensure that your
build
includes/excludes match what is in geronimo with M1 exactly. In
fact, I
think what we have in M1 is really just a jumble of things that
people
at one time thought were needed, copied from other configurations,
or
whatever to get things to build. Sure, there are very specific,
well
placed dependencies that were added as well. But I don't think
that
the
omissions were necessarily deliberate just as not all of the
additions
were deliberate (such as is likely the case with the jetty deployer
in
remote-deploy-tomcat).
Also, based upon my recent experience with the
geronimo.dependencies,
even those are often the result of copied code. I didn't resolve
all
of these geronimo.dependencies by a long shot. I was specifically
focused on making changes and validating dependencies to remove
unnecessary items from inclusion in the little-G assembly. So I'm
fairly sure there are still plenty of bogus geronimo.dependencies
there too.
Yes, with the M2 transitive dependencies we may very well be able
to
build and bad things could happen because of a missing
geronimo.dependency when you attempt to run the server. However, I
consider this no different than today where you must manually add
both.
It's still very possible to add one and not the other with the
result
being a server that cannot start (in fact I just did it this
morning
on
my test machine). However, I think this typically speaks more to
a
problem in the building of the configuration rather than the
building
of
the assembly. External dependencies by configuration must be added
to
the verified/added to the assemblies when the configurations are
added
to the assemblies.
Joe
anita kulshreshtha wrote:
Joe,
Thanks. I was trying to understand the process of assembly. so
I
did
the following :
1. checkout ONLY top level dir, /etc and /assemblies.
2. cd j2ee-tomcat-server
3. maven
I think I should be able to do this without building
(modules,
configs, apps) anything else. It worked fine until I got to
g/javamail/../car. A jar was missing.
Now why would someone in the right mind do that... It is for
M2. As
you said downloading everything is automatic in m2, Trying to
prevent
one dependency is a nightmare. It will be quite a challenge to
find
equivalent of g.reference, g.import and g.dependency using only
'provided' and 'exclude' and arrive at the same list as m1.
You have answered my question that the
javamail-transport..jar
is
needed for j2ee-tomcat-server. So if it gets added by M2 it will
not be
a bad thing!
I built the server using above 3 step today, the error
message
is gone. But this jar is not in GERONIMO_HOME/repository/.. When
I
start this server bad things will happen!
A similar situation is wi
Re: New Feature Wednesday
Cool stuff!!! long time needed :D Thanks David Cheers! Hernan David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Re: rename the "configuration" element in config.xml file ?
John, I think making those changes as well makes sense. f we don't get to a level of consistency then I think we missed the objective :) John Sisson wrote: I noticed we still have a "configuration" element in the config.xml file. I am thinking of doing the following for 1.1: * most importantly, change the "configuration" element name to "module" to have consistent terminology considering the recent configId changes. * update cmd line help for --override option in Daemon to use "module" terminology. * update the wording in the var\config\README.txt to use the "module" terminology. * change the --long startup output to use the word "Module" instead of "Configuration" - also give us a bit more room on each line. Any objections? John
RE : Problem with DataBase Connection
Title: RE : Problem with DataBase Connection Hello, I have already tried to specify the schema in the query, but it didn't work. But I found a solution, I'm not sure it's the best one : After the connection, I put this query : "Set Current Schema='Nom_Schema'" So it works correctly... It was so easy... In any case, thank you for your help ! Cordialement, Thibault HAMELIN Tél. : 01 70 38 32 19 -Message d'origine- De : Hernan Cunico [mailto:[EMAIL PROTECTED]] Envoyé : 10 May 2006 18:58 À : dev@geronimo.apache.org Objet : Re: Problem with DataBase Connection Hi Thibault, you should still be able to access the data if you specify the schema in your query (schema.table) The id for connection does not necessarily need to be the same that created data/schema in the db. HTH Cheers! Hernan Hamelin, Thibault wrote: > Hello, > > I'm currently developping an application with EJB, and I have a big > problem with the connection to the DB2 DataBase. > In the Resource Adapter, I defined correctly the user/pwd for my > connection but when I try to get data with my EJB, the database schema > used is set with my username. > > I want to use of course a data base schema different from my user name. > > I tried to create a schema with a name equals to my username, and of > course I succeed to get my data. > > How can I set a different schema name to use ? Unfortunately, I have > constraints with the usernames which can be created. > > > Cordialement, > > Thibault HAMELIN > >
[jira] Updated: (GERONIMO-2009) JarFileResourceFinder ResourceEnumeration can't count.
[ http://issues.apache.org/jira/browse/GERONIMO-2009?page=all ] David Jencks updated GERONIMO-2009: --- Attachment: 2009_JarFileResourceFinder.diff diff made in modules/kernel > JarFileResourceFinder ResourceEnumeration can't count. > -- > > Key: GERONIMO-2009 > URL: http://issues.apache.org/jira/browse/GERONIMO-2009 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: kernel > Versions: 1.1 > Reporter: David Jencks > Assignee: David Jencks > Fix For: 1.1 > Attachments: 2009_JarFileResourceFinder.diff > > JarFileResourceFinder.ResourceEnumeration always advances its iterator when > you call hasMoreElements() and nextElement(), so in a typical loop you only > get half the elements. > I'll apply the patch when svn revives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2009) JarFileResourceFinder ResourceEnumeration can't count.
JarFileResourceFinder ResourceEnumeration can't count. -- Key: GERONIMO-2009 URL: http://issues.apache.org/jira/browse/GERONIMO-2009 Project: Geronimo Type: Bug Security: public (Regular issues) Components: kernel Versions: 1.1 Reporter: David Jencks Assigned to: David Jencks Fix For: 1.1 JarFileResourceFinder.ResourceEnumeration always advances its iterator when you call hasMoreElements() and nextElement(), so in a typical loop you only get half the elements. I'll apply the patch when svn revives. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
