[jira] Commented: (GERONIMO-4337) Upgrade to activeMQ 5.x
[ https://issues.apache.org/jira/browse/GERONIMO-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640083#action_12640083 ] John Charles commented on GERONIMO-4337: David, The icla was sent snail mail and will take up to a week. I am no Maven expert so I was just exploring under the hood. However I am studying how it hangs together because I would like to use it on other projects. I have checked out the latest changes as per Donald Woods updates with updated pom files under activemq5 and will rebuild and test. I nuked the local cache activemq5* repository mods; they get built anyway. I will rebuild and see how the ActiveMQ 5.1.0 references go. John C. Upgrade to activeMQ 5.x --- Key: GERONIMO-4337 URL: https://issues.apache.org/jira/browse/GERONIMO-4337 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.2 Reporter: David Jencks Fix For: 2.2 Upgrade activemq support to 5.x. A few steps along the way: - create an activemq5 work area under plugins - move the specification of amq version from the root pom dependency management to the activemq and activemq5 plugins. - keep only the broker gbean - use an activemq configuration file in var/activemq, referenced by the broker gbean - update dependencies to latest activemq - figure out how much of the current jms portlet functionality can be reasonably kept. From discussions with Hiram I think that trying to reconfigure the broker while its running is a very bad idea and we should just drop the parts of the console that try to do this. - investigate how to run the amq console in geronimo, preferably as portlets inside the g. admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4337) Upgrade to activeMQ 5.x
[ https://issues.apache.org/jira/browse/GERONIMO-4337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640084#action_12640084 ] John Charles commented on GERONIMO-4337: David, Thanks for the update. I have checked out the latest release and will rebuild with our changes to see how it goes. Cheers, John C. Upgrade to activeMQ 5.x --- Key: GERONIMO-4337 URL: https://issues.apache.org/jira/browse/GERONIMO-4337 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 2.2 Reporter: David Jencks Fix For: 2.2 Upgrade activemq support to 5.x. A few steps along the way: - create an activemq5 work area under plugins - move the specification of amq version from the root pom dependency management to the activemq and activemq5 plugins. - keep only the broker gbean - use an activemq configuration file in var/activemq, referenced by the broker gbean - update dependencies to latest activemq - figure out how much of the current jms portlet functionality can be reasonably kept. From discussions with Hiram I think that trying to reconfigure the broker while its running is a very bad idea and we should just drop the parts of the console that try to do this. - investigate how to run the amq console in geronimo, preferably as portlets inside the g. admin console. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[GSHELL] Timeframe ?
In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: svn commit: r704975 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/
I didn't really want to expose setLocation in Command, hence the
reason why it was coded like that.
--jason
On Oct 16, 2008, at 1:04 AM, [EMAIL PROTECTED] wrote:
Author: gnodet
Date: Wed Oct 15 11:04:24 2008
New Revision: 704975
URL: http://svn.apache.org/viewvc?rev=704975view=rev
Log:
Remove an ugly cast by adding the setLocation method to the Command
interface
Modified:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Command.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/registry/
CommandRegistryImpl.java
Modified: geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Command.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java?rev=704975r1=704974r2=704975view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Command.java (original)
+++ geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Command.java Wed Oct 15 11:04:24 2008
@@ -31,6 +31,8 @@
{
CommandLocation getLocation();
+void setLocation(CommandLocation location);
+
/**
* Returns the action of the command.
*
Modified: geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/
main/java/org/apache/geronimo/gshell/wisdom/registry/
CommandRegistryImpl.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java?rev=704975r1=704974r2=704975view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/registry/
CommandRegistryImpl.java (original)
+++ geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/registry/
CommandRegistryImpl.java Wed Oct 15 11:04:24 2008
@@ -60,9 +60,7 @@
throw new DuplicateCommandException(name);
}
-if (command instanceof CommandSupport) {
-((CommandSupport)command).setLocation(new
CommandLocationImpl(name));
-}
+command.setLocation(new CommandLocationImpl(name));
commands.put(name, command);
Re: svn commit: r704975 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/
Yeah, I was supposing so.
However, it seems more natural, as the only place where the location
is set is when registering the command in the registry.
Maybe another way would be to say that the location has to be set on
the command in some way before registering it: the registry would
retrieve the location from the command instead of receiving it as an
argument to the registerCommand method and then setting the location.
As the same command object can not be registered at two different
locations (else one location would be somehow lost on the command), it
may make sense. The location could be set directly when the
PluginParser creates the bean definition. Wdyt ?
On Thu, Oct 16, 2008 at 9:24 AM, Jason Dillon [EMAIL PROTECTED] wrote:
I didn't really want to expose setLocation in Command, hence the reason why
it was coded like that.
--jason
On Oct 16, 2008, at 1:04 AM, [EMAIL PROTECTED] wrote:
Author: gnodet
Date: Wed Oct 15 11:04:24 2008
New Revision: 704975
URL: http://svn.apache.org/viewvc?rev=704975view=rev
Log:
Remove an ugly cast by adding the setLocation method to the Command
interface
Modified:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
Modified:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java?rev=704975r1=704974r2=704975view=diff
==
---
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
(original)
+++
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
Wed Oct 15 11:04:24 2008
@@ -31,6 +31,8 @@
{
CommandLocation getLocation();
+void setLocation(CommandLocation location);
+
/**
* Returns the action of the command.
*
Modified:
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java?rev=704975r1=704974r2=704975view=diff
==
---
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
(original)
+++
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
Wed Oct 15 11:04:24 2008
@@ -60,9 +60,7 @@
throw new DuplicateCommandException(name);
}
-if (command instanceof CommandSupport) {
-((CommandSupport)command).setLocation(new
CommandLocationImpl(name));
-}
+command.setLocation(new CommandLocationImpl(name));
commands.put(name, command);
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: svn commit: r704975 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/
Actually, using a cast makes things very difficult to use in OSGi, as
when using spring-dm in OSGi, it creates proxies for the commands, so
the cast does not work and we end up with exceptions everywhere, as
the location is a mandatory part of the command.
On Thu, Oct 16, 2008 at 9:33 AM, Guillaume Nodet [EMAIL PROTECTED] wrote:
Yeah, I was supposing so.
However, it seems more natural, as the only place where the location
is set is when registering the command in the registry.
Maybe another way would be to say that the location has to be set on
the command in some way before registering it: the registry would
retrieve the location from the command instead of receiving it as an
argument to the registerCommand method and then setting the location.
As the same command object can not be registered at two different
locations (else one location would be somehow lost on the command), it
may make sense. The location could be set directly when the
PluginParser creates the bean definition. Wdyt ?
On Thu, Oct 16, 2008 at 9:24 AM, Jason Dillon [EMAIL PROTECTED] wrote:
I didn't really want to expose setLocation in Command, hence the reason why
it was coded like that.
--jason
On Oct 16, 2008, at 1:04 AM, [EMAIL PROTECTED] wrote:
Author: gnodet
Date: Wed Oct 15 11:04:24 2008
New Revision: 704975
URL: http://svn.apache.org/viewvc?rev=704975view=rev
Log:
Remove an ugly cast by adding the setLocation method to the Command
interface
Modified:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
Modified:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java?rev=704975r1=704974r2=704975view=diff
==
---
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
(original)
+++
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Command.java
Wed Oct 15 11:04:24 2008
@@ -31,6 +31,8 @@
{
CommandLocation getLocation();
+void setLocation(CommandLocation location);
+
/**
* Returns the action of the command.
*
Modified:
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java?rev=704975r1=704974r2=704975view=diff
==
---
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
(original)
+++
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/registry/CommandRegistryImpl.java
Wed Oct 15 11:04:24 2008
@@ -60,9 +60,7 @@
throw new DuplicateCommandException(name);
}
-if (command instanceof CommandSupport) {
-((CommandSupport)command).setLocation(new
CommandLocationImpl(name));
-}
+command.setLocation(new CommandLocationImpl(name));
commands.put(name, command);
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
Re: An idea for defining custom valves in config.xml
Hi David, You are correct: the underpinning philosophy of these approaches is to make it easier to modify pre-canned plugins through extension points. This may be a good approach to improve further the packaging model of dependencies and services. Let's say that an end-user wants to add a connector to the tomcat6 plugin. Instead of using the admin console or updating his config.xml, he can simply deploy a cumulative plan. This notion of cumulative plan is the key differentiator as users can share their cumulative plans as-is - i.e. w/o knowing what the plugin to be modified looks like. To some extent, providing a plan ready to be deployed instead of deployment instructions is better for novices. I will work on the Groovy builder approach and post back more details as I go. Thanks, Gianny On 16/10/2008, at 10:59 AM, David Jencks wrote: Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g- p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks
[BUILD] trunk: Failed for Revision: 705147
Geronimo Revision: 705147 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081016/build-0300.log Download the binaries from http://people.apache.org/builds/geronimo/server/binaries/trunk/20081016 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 41 minutes 40 seconds [INFO] Finished at: Thu Oct 16 03:43:49 EDT 2008 [INFO] Final Memory: 404M/972M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://people.apache.org/builds/geronimo/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20081016/logs-0300-tomcat/test.log Booting Geronimo Kernel (in Java 1.5.0_12)... Module 1/73 org.apache.geronimo.framework/j2ee-system/2.2-SNAPSHOT/car started in .000s Module 2/73 org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car started in .001s Module 3/73 org.apache.geronimo.framework/rmi-naming/2.2-SNAPSHOT/car started in .190s Module 4/73 org.apache.geronimo.plugins.classloaders/geronimo-javaee-deployment_1.1MR3_spec/2.2-SNAPSHOT/car started in .000s Module 5/73 org.apache.geronimo.framework/plugin/2.2-SNAPSHOT/car started in 1.235s Module 6/73 org.apache.geronimo.framework/j2ee-security/2.2-SNAPSHOT/car started in .334s Module 7/73 org.apache.geronimo.configs/j2ee-server/2.2-SNAPSHOT/car started in .101s Module 8/73 org.apache.geronimo.configs/transaction/2.2-SNAPSHOT/car started in .337s Module 9/73 org.apache.geronimo.framework/server-security-config/2.2-SNAPSHOT/car started in .080s Module 10/73 org.apache.geronimo.configs/jasper/2.2-SNAPSHOT/car started in .003s Module 11/73 org.apache.geronimo.framework/xmlbeans/2.2-SNAPSHOT/car started in .001s Module 12/73 org.apache.geronimo.plugins.classloaders/geronimo-schema-jee_5/2.2-SNAPSHOT/car started in .000s Module 13/73 org.apache.geronimo.configs/webservices-common/2.2-SNAPSHOT/car started in .000s Module 14/73 org.apache.geronimo.configs/tomcat6/2.2-SNAPSHOT/car started in 2.636s Module 15/73 org.apache.geronimo.configs/welcome-tomcat/2.2-SNAPSHOT/car started in .263s Module 16/73 org.apache.geronimo.framework/gshell-framework/2.2-SNAPSHOT/car started in .001s Module 17/73 org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car started in .000s Module 18/73 org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car started in .001s Module 19/73 org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car started in .006s Module 20/73 org.apache.geronimo.framework/transformer-agent/2.2-SNAPSHOT/car started in .000s Module 21/73 org.apache.geronimo.framework/geronimo-gbean-deployer/2.2-SNAPSHOT/car started in .333s Module 22/73 org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car started in .174s Module 23/73 org.apache.geronimo.plugins.classloaders/xbean-finder/2.2-SNAPSHOT/car started in .000s Module 24/73 org.apache.geronimo.configs/j2ee-deployer/2.2-SNAPSHOT/car started in .276s Module 25/73 org.apache.geronimo.configs/connector-deployer/2.2-SNAPSHOT/car started in .120s Module 26/73 org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car started in .090s Module 27/73 org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car started in .012s Module 28/73 org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car started in 1.511s Module 29/73 org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car 03:49:49,722 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/client-deployer/2.2-SNAPSHOT/car
[jira] Created: (GERONIMO-4366) Non-ASCII chars in deployment plan xml files cause deployment failed with NPE on deployment time
Non-ASCII chars in deployment plan xml files cause deployment failed with NPE on deployment time Key: GERONIMO-4366 URL: https://issues.apache.org/jira/browse/GERONIMO-4366 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.1.3 Environment: Any platforms Reporter: Forrest Xia Steps to recur: 1. checkout AG samples 2.1.2 2. build them 3. install jms-mdb-xxx.ear with plan samples\jms-mdb\jms-mdb-tomcat\target\resources\META-INF\plan.xml in admin console You will get an NPE like this: java.lang.NullPointerException org.apache.geronimo.common.DeploymentException: java.lang.NullPointerException at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:275) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:810) Caused by: java.lang.NullPointerException at org.apache.geronimo.deployment.CopyResourceContext.addFile(CopyResourceContext.java:144) at org.apache.geronimo.deployment.DeploymentContext.addFile(DeploymentContext.java:461) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.installModule(AbstractWebModuleBuilder.java:289) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.installModule(SwitchingModuleBuilder.java:153) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:586) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) ... 12 more To remove it, update all deployment plan files to remove any non-ascii chars, then rebuild and redeploy through admin console, it works! So I doubt AG does not support any non-ASCII chars in deployment plan. But for non-english environment, user might leave some comments including non-english chars in deployment plan, so it's necessary to take time to make our deployment plan could contain non-ASCII chars. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Where will ee6 development take place?
I think it all depends on the amount of tck destabilization and how long we think it might take to get things resolved. IMO we should be thinking about releasing 2.2 soon. I'm all for getting as much ee6 content included as possible ... but if too much breaks in the tck it could take a long time to recover. So I think this is a case by case decision. If we know something will cause significant instability regarding tck then I think we should consider branching 2.2 and let trunk continue with ee6. Joe David Jencks wrote: I realize I've been assuming that we'll just develop ee6 features in trunk and release 2.2 with a bunch or all of ee6 implemented. I have some connector 1.6 stuff I'm about to commit This attitude might cause tck problems especially with signature tests. On the other hand maybe we can get signature updates. What do other people think we should do? thanks david jencks
Re: Grails, JRuby on Rails, etc... scripting languages/environments and Geronimo integration
Gianny Damour wrote: Hi, I also do not see a lot of room for improvement in Grails integration. FWIW, in addition to the sample Grails application of the IBM article, the WADI administration console, a Grails Web-app, can be deployed out-of-the-box to Geronimo to introspect WADI clusters. I believe there is room for scripting languages in Geronimo. For instance, gshell users can source command files to automate some of their actions. A more powerful approach would be to provide scripting capabilities to gshell users. I believe, Groovy is an appropriate scripting language choice as it is very easy to learn for Java people. Another user case would be to use scripting to replace the serialized configuration, I mean the config.ser. An xmlbean serialization of configurations is way better than a native Java serialization as end-users can easily see and update values of serialized stuff. A YAML or even better a Groovy builder serialization would be way better than a xmlbean serialization. i would even go a step further and say that the geronimo DD could be replaced by scripts. A programmatic way to configure GBeans would be simpler. This could be a little bit like the programmatic servlet component configuration mechanism defined by the upcoming Servlet spec. Sorry for the delayed response. I still haven't quite gotten my head around this idea yet? Can you provide some more information on how this would look and behave? I guess I need to take a look at the new Servlet spec. A third example is to provide a simpler extension of configurations. The addition of a custom Tomcat valve to the tomcat6 config is a use case. When a configuration is started a script is executed to provide GBean overrides (add, update or remove) and dependencies overrides to the pre-canned configuration. In the scripting context, users have access to the pre-canned configuration and are able to return an altered one if they want. This too is an interesting idea. Are you thinking that the extensions would only live in the script and be executed each time the configuration is started or would they be somehow persistent in the configuration? It seems that this and the previous idea are two different approaches to the same end ... an easy way for a user to enhance/alter a configuration via a scripting language ... is that correct? Joe Thanks, Gianny On 11/10/2008, at 5:42 AM, Jason Dillon wrote: IMO, language is irrelevant. What you want to consider is what you want the scripting language to do for you... that is what is important. Basically (almost) any scripting language can be integrated (bsf or direct) but what is missing is the users use-cases for what the really want scripted. But.. users't don't always tell you want they want up front, they look at what you have and then complain when its broken wrt their own needs. So it might be worthwhile doing some POC work to add more scripting support. Though I don't think that web-app scripting crapski is the best way to provide that. If you think about it, there are a few uses for scripting in the application server's context. First is that the app developers prefer the language, but they still provide JavaEE muck to install/run. So we could reduce some footprint by providing plugins, but that not really that important, as the feature will still work w/o it. The second is where the application exposes some configuration logic which is intended to be easily augmented when installing/running the application. In this model part of the application's behavior is configured via some scripting language, which is intended to be changed (slightly or dramatically) to fit the application installations requirements. The third is where the application wants to provide an extensible action interface, so allow such an application to do whatever it wants. For example, if an application supports some concept of filtering, one might desire that the filter be implemented by a script which the administrator of the application could writte/configure. I'm sure I'm missing more examples, but it should be sufficient to point these out. Scripting is a very powerful way to extend you application, and I'm certainly a proponent. But what I'm having trouble realizing is... for a JavaEE application server, what/how/why would a developer want to script? --jason On Oct 11, 2008, at 1:13 AM, Joe Bohn wrote: ant elder wrote: On Thu, Oct 9, 2008 at 10:38 PM, bill stoddard [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Joe Bohn wrote: Any ideas on PHP and if this would be another potential area for integration? Python Joe Bill Also JavaScript with Rhino, and that gives you the big four - Groovy, JRuby, Rhino, and Jython. PHP would good but i've never found a PHP impl with Java integration and a compatible license. You can also use the JSR-223 APIs (Apache BSF) and get easy access to
Re: An idea for defining custom valves in config.xml
On Wed, Oct 15, 2008 at 7:59 PM, David Jencks [EMAIL PROTECTED]wrote: Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. I think, from a user perspective, the best of all possible worlds is to have both options available. Thinking in the context of the original custom valve scenario, since we seem to have expanded the scope a little, it shouldn't be necessary for a straight user to delve into the world of plugins to deploy a valve. Regardless of how simple we make deploying a plugin, that's still an added level of complexity that we shouldn't require of a user who is working solely in the realm of a webapp. I realize I made this argument earlier, but after tinkering with your proposed approach and thinking about it some more, I've come back around to my original line of thinking, though hopefully better informed this time. I understand the objections to the original proposal of using an attribute, but if sufficiently simple to define, Gianny's approach might be the right way to accomplish the same goal. At the same time, I'm still all for improving and simplifying the method in which we deploy plugins. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g-p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks -- ~Jason Warner
Re: An idea for defining custom valves in config.xml
While David is more interested in the philosophy, I'd prefer to know a little bit more about your thoughts on implementation. Specifically what do you imagine would be involved in defining this configuration? Would it be as simple as a definition in config.xml? On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour [EMAIL PROTECTED] wrote: Hi David, You are correct: the underpinning philosophy of these approaches is to make it easier to modify pre-canned plugins through extension points. This may be a good approach to improve further the packaging model of dependencies and services. Let's say that an end-user wants to add a connector to the tomcat6 plugin. Instead of using the admin console or updating his config.xml, he can simply deploy a cumulative plan. This notion of cumulative plan is the key differentiator as users can share their cumulative plans as-is - i.e. w/o knowing what the plugin to be modified looks like. To some extent, providing a plan ready to be deployed instead of deployment instructions is better for novices. I will work on the Groovy builder approach and post back more details as I go. Thanks, Gianny On 16/10/2008, at 10:59 AM, David Jencks wrote: Hi Gianny, First, I'd like to make sure I understand the philosophy behind your proposals. IIUC they both involve the idea of making it easy to modify an existing plugin rather than making it easy to replace an existing plugin with a similar one. Why is this a good idea? My idea has been that we should make it easier to replace a plugin with a similar one than modify an existing one, and then we will have the best of all worlds. All this being said, I think your ideas are both quite interesting. I'm especially interested in the groovy builder approach. I'll be fairly unavailable until next week but might keep thinking about this anyway. thanks! david jencks On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: On 15/10/2008, at 4:16 AM, David Jencks wrote: That's one of the main missing bits of functionality. Right now the only way to get the g-p.xml is to use c-m-p or to export the plugin from a server it's been deployed into, or to do something by hand with jar packing and unpacking. The biggest problem here, in my mind, is that jsr88 only wants you to have one plan: to deploy something you get to specify the artifact and one plan. Our deployment system is built around jsr88 so we either have to condense the g-p.xml and plan into one plan or abandon jsr88. At the moment I'm thinking that one satisfactory solution might be to more or less embed the plan into g-p.xml. Perhaps we could avoid duplicating most of the dependency info by adding the import element to the dependencies in g-p.xml. I guess we'd expect a more or less empty environment element in the plan and fill in the dependencies from the g-p.xml when deploying. I guess another possibility might be to include the info from g-p.xml in the environment element of the plan. I've been thinking about this on and off for a long time and don't have any solution I'm entirely happy with so discussion and more ideas are more than welcome :-) Hi, Another possible solution would be to allow the extension of a given configuration by other configurations. This could work like the web.xml fragment mechanism of the upcoming servlet specs which allows framework libraries to transparently install Web components to the baseline components defined by the web.xml DD. When a configuration starts it looks for complementing configurations whose responsibility is to alter the baseline configuration. The identification of complementing configurations could be based on a simple naming convention scheme, e.g. if the base configuration is org/tomcat6//car then all the configurations matching the pattern org/tomcat6-transform-DiscriminatorName//car are identified as complementing configurations. If there are complementing configurations, then the baseline ConfigurationData could be passed to them for arbitrary transformation, e.g. add, update or remove dependencies. An updated ConfigurationData is passed back and actually loaded by the kernel. The main drawback of this approach is the added configuration complexity. The main benefits is that it provides application server configuration traceability and a mean to perform very simple changes to a baseline configuration w/o having to redefine in its entirety the configuration to be slightly changed. In another thread about scripting language integration, I suggested an even simpler approach whereby a script is executed to perform ConfigurationData transformations. If any of these two options are plausible solutions, then I am happy to move forward with an implementation. Thanks, Gianny thanks david jencks -- ~Jason Warner
maven site generation genesis
I've been making some changes to Genesis 1.5-SNAPSHOT to get maven site generation working a little bit better and fix a few other things. All of this is because there were still some maven site generation issues after releasing samples. I think I have things working better now ... but I have some questions: - Regarding the site.xml ... it looked to me like the original intent was to leverage completely the site.xml from genesis. However, I could never get this working correctly to include the header for the generated site. As a result ... I ended up including some of the same site.xml content in samples such as the skin and banner definition. Is that a problem? - Genesis: When we were getting samples out the door I ended up including some temporary junk in the sample pom/site. I've now removed this and made some minor changes to genesis/branches/genesis-1.x. Should I look at releasing Genesis 1.5 until 2.0 is complete or should we put all emphasis on 2.0? What is the current status of 2.0? BTW .. I also noticed that generating a site for genesis 2.0-SNAPSHOT itself has some issues something else to look into. - Specs: I've also made some similar changes locally for specs. I think these will produce more correct maven sites. However, the would require changes to depend on a newer Genesis and would require releasing a new specs-parent (1.6). I don't want to include these snapshot dependencies which would hinder the ability to release specs for now ... so I'm waiting on the Genesis decision. If we want to push out a Genesis 1.5 rc and get that up for vote. General: Is this really worth the effort? It seems that we haven't put much of an emphasis on maven sites. Is this because there were problems generating them or because we don't see much value? Most of what we have out there now is 2 years old (see http://cwiki.apache.org/GMOxDEV/maven-generated-documentation.html). It think there are some concerns of how useful these are, particularly for multi-project release (like server). The site information generated is per project and doesn't provide a good overview. IIUC, this can be aggregated for some if not all things (like javadoc). In the past we have provided independent javadoc in addition to the site (which I suspect is why, I suspect that the latest javadoc available for the server from our site if for 2.0.1). Should we focus energy on getting independent javadoc release, improve maven site generation and leverage that for javadoc/xrefs, or both? Joe
Re: Where will ee6 development take place?
see inline On Wed, Oct 15, 2008 at 7:50 PM, David Jencks [EMAIL PROTECTED]wrote: I realize I've been assuming that we'll just develop ee6 features in trunk and release 2.2 with a bunch or all of ee6 implemented. I have some connector 1.6 stuff I'm about to commit That was my assumption as well. This attitude might cause tck problems especially with signature tests. On the other hand maybe we can get signature updates. I think a trunk build is the perfect place to introduce tck problems, so long as they can be resolved before a release. I think this could be discussed further and in more detail, but would prefer to do that on the tck list. What do other people think we should do? thanks david jencks -- ~Jason Warner
[VOTE RESULT] Release SAAJ 1.3 spec jar version 1.0.1
Hi, This vote passes with 10 +1 votes. I'll push out the binaries today but will not publish the site as we discovered problems with it. Thanks, Jarek On Mon, Oct 13, 2008 at 10:56 AM, Jarek Gawor [EMAIL PROTECTED] wrote: Hi, This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one change from version 1.0.0: https://issues.apache.org/jira/browse/GERONIMO-4289 Staging repo: http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/ Staging site: http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/ The vote is open until Thursday (October 16th). [ ] +1 [ ] +0 [ ] -1 Jarek
Re: Continuous TCK Testing
While we wait to hear back in regards to the license, I'm going to update the maven used in build-support. The server now requires 2.0.9 and the version currently used by build support is 2.0.5. I suppose we'll need to update ant, as well. What version of ant should we be using? 1.7.1? On Fri, Oct 10, 2008 at 11:25 AM, Kevan Miller [EMAIL PROTECTED]wrote: On Oct 8, 2008, at 11:56 PM, Kevan Miller wrote: On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? IIRC, the overwhelming reason we stopped using it before was because of hosting issues -- spotty networking, hardware failures, poor colo support, etc. We shouldn't have any of these problems, now. If we do run into problems, they should now be fixable. I have no reason to favor Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for it. There's only one potential issue, that I'm aware of. We previously had an Open Source License issued for our use of Anthill. Here's some of the old discussion -- http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902http://www.nabble.com/Geronimo-build-automation-status-%28longish%29-tt7649902.html#a7649902 Although the board was aware of our usage of AntHill, since we weren't running AntHill on ASF hardware, I'm not sure the license was fully vetted by Infra. I don't see any issues, but I'll want to run this by Infra. Jason D, will the existing license cover the version of AntHill that we'll want to use? I'll run the license by Infra and will also describe the issue for review by the Board, in our quarterly report. IMO, I'd proceed with the assumption that we'll be using AHP. Just don't install it on Apache hardware, yet. I've requested a new license from Anthill. Will let you know when I get it. --kevan -- ~Jason Warner
Re: Continuous TCK Testing
Whoops... just realized that this was actually removed and I was looking at a stickied revision of viewVC. Nevermind. On Thu, Oct 16, 2008 at 11:15 AM, Jason Warner [EMAIL PROTECTED] wrote: While we wait to hear back in regards to the license, I'm going to update the maven used in build-support. The server now requires 2.0.9 and the version currently used by build support is 2.0.5. I suppose we'll need to update ant, as well. What version of ant should we be using? 1.7.1? On Fri, Oct 10, 2008 at 11:25 AM, Kevan Miller [EMAIL PROTECTED]wrote: On Oct 8, 2008, at 11:56 PM, Kevan Miller wrote: On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? IIRC, the overwhelming reason we stopped using it before was because of hosting issues -- spotty networking, hardware failures, poor colo support, etc. We shouldn't have any of these problems, now. If we do run into problems, they should now be fixable. I have no reason to favor Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for it. There's only one potential issue, that I'm aware of. We previously had an Open Source License issued for our use of Anthill. Here's some of the old discussion -- http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902http://www.nabble.com/Geronimo-build-automation-status-%28longish%29-tt7649902.html#a7649902 Although the board was aware of our usage of AntHill, since we weren't running AntHill on ASF hardware, I'm not sure the license was fully vetted by Infra. I don't see any issues, but I'll want to run this by Infra. Jason D, will the existing license cover the version of AntHill that we'll want to use? I'll run the license by Infra and will also describe the issue for review by the Board, in our quarterly report. IMO, I'd proceed with the assumption that we'll be using AHP. Just don't install it on Apache hardware, yet. I've requested a new license from Anthill. Will let you know when I get it. --kevan -- ~Jason Warner -- ~Jason Warner
[jira] Resolved: (GERONIMODEVTOOLS-377) need way to manage the adminobject list
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed resolved GERONIMODEVTOOLS-377. Resolution: Fixed Fix Version/s: (was: 2.2.0) 2.1.4 Fixed with revision 705267 in 2.1.4 and 705268 in trunk. Added a Tree Section to the Connector Deployment Plan Editor so that Admin Objects can be managed. need way to manage the adminobject list --- Key: GERONIMODEVTOOLS-377 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-377 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.3 Reporter: B.J. Reed Assignee: B.J. Reed Priority: Minor Fix For: 2.1.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Where will ee6 development take place?
On Oct 15, 2008, at 7:50 PM, David Jencks wrote: I realize I've been assuming that we'll just develop ee6 features in trunk and release 2.2 with a bunch or all of ee6 implemented. I have some connector 1.6 stuff I'm about to commit This attitude might cause tck problems especially with signature tests. On the other hand maybe we can get signature updates. What do other people think we should do? I'm all for making progress w/ Java EE 6 items. However, It's highly doubtful that we'll see tck updates for specs which are not even in public draft form. So, I' wouldn't be too hopeful that we'll see timely Java EE 5 TCK updates from Sun. I think we should plan accordingly and have Java EE 5 configurations that we're able to target our compliance efforts on. --kevan
Re: [VOTE RESULT] Release SAAJ 1.3 spec jar version 1.0.1
Jarek, I think it is OK to make the site public. It isn't perfect from an appearance perspective but all of the appropriate content is included. IMO it's better to have something than nothing. Joe Jarek Gawor wrote: Hi, This vote passes with 10 +1 votes. I'll push out the binaries today but will not publish the site as we discovered problems with it. Thanks, Jarek On Mon, Oct 13, 2008 at 10:56 AM, Jarek Gawor [EMAIL PROTECTED] wrote: Hi, This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one change from version 1.0.0: https://issues.apache.org/jira/browse/GERONIMO-4289 Staging repo: http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/ Staging site: http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/ The vote is open until Thursday (October 16th). [ ] +1 [ ] +0 [ ] -1 Jarek
[jira] Resolved: (GERONIMO-4364) Split the assemblylist page to 2 pages
[ https://issues.apache.org/jira/browse/GERONIMO-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun resolved GERONIMO-4364. --- Resolution: Fixed rev 705134 enables the hover plugin to show plugin description, per Jarek's suggestion. rev 705317 splits the page into 2. Split the assemblylist page to 2 pages -- Key: GERONIMO-4364 URL: https://issues.apache.org/jira/browse/GERONIMO-4364 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.2 Currently, this page is a bit cluttered. I propose we split it into 2 pages: 1st page - Name the server to be assembled 2nd page - Select from plugins in current server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4364) Split the assemblylist page to 2 pages
[ https://issues.apache.org/jira/browse/GERONIMO-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun closed GERONIMO-4364. - tested change on tomcat assembly Split the assemblylist page to 2 pages -- Key: GERONIMO-4364 URL: https://issues.apache.org/jira/browse/GERONIMO-4364 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.2 Reporter: Lin Sun Assignee: Lin Sun Priority: Minor Fix For: 2.2 Currently, this page is a bit cluttered. I propose we split it into 2 pages: 1st page - Name the server to be assembled 2nd page - Select from plugins in current server -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Multiple Instances With One Repository
djencks wrote: In the WASCE_HOME directory, there is the main repository and var directories, what I would like to do is to create a local repository, and start several instances that use that repository. So I think I am after a structure like this: WASCE_HOME repo1 instance1 instance2 instance3 repo2 instance1 instance2 instance3 repo3 instance1 instance2 instance3 Is this possible? If so, how would I do this? I'm not sure why you want mutliple repositories. I think you can do what you want with only the default repository. We actually have sort of a sample of multiple servers sharing a repository. One version that may be usable is at http://people.apache.org/~djencks/failover2.tar.gz To build it yourself build serve/trunk, then checkout svn co https://svn.apache.org/repos/asf/geronimo/sandbox/failover and build the pieces independently. There's a linux script that makes a bunch of server copies (copying the var directory) and a couple scripts that start the servers on different ports. This sample works on plugins so you can see plugins installed on each of the servers. The first time a plugin is installed it actually gets into the repository and the installation process may unpack stuff into that server's var dir. When the plugin is installed on the other servers sharing the repo the only thing that happens is the unpacking into the var dir. You can do something similar with apps that you aren't thinking of as plugins by deploying the app into the appropriate first server, then starting the app in the other servers you want it running in. Productive use of this feature is just starting so please let us know what is unclear or if you run into problems or have more questions. many thanks david jencks The structure would be more like: WASCE_HOME customers customer1 customer1-repo instance1 var instance2 var customer2 customer2-repo instance1 var This would allow the deployment of multiple customers on 1 machine that use different databases to use the same database pool without having to deploy a second repository in each instance for the database pool. Is there a system property for the repository directory like there is for the var directory? -- View this message in context: http://www.nabble.com/Multiple-Instances-With-One-Repository-tp20001882s134p20016177.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[jira] Resolved: (GERONIMO-4356) search-plugins, list-targets, and list-modules commands fail using framework assembly
[ https://issues.apache.org/jira/browse/GERONIMO-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn resolved GERONIMO-4356. Resolution: Fixed Fix Version/s: 2.2 2.1.4 search-plugins, list-targets, and list-modules commands fail using framework assembly - Key: GERONIMO-4356 URL: https://issues.apache.org/jira/browse/GERONIMO-4356 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.2, 2.1.3, 2.1.4, 2.2 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.4, 2.2 Commands such as search-plugins, list-targets, list-modules, and perhaps others result in the following error but only when using the framework assembly. Using GERONIMO_BASE: /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2 Using GERONIMO_HOME: /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home org.apache.geronimo.kernel.GBeanNotFoundException: No GBeans found: [?#org.apache.geronimo.kernel.util.Main] at org.apache.geronimo.kernel.basic.BasicRegistry.getGBeanInstance(BasicRegistry.java:153) at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:286) at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:282) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:100) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:59) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4356) search-plugins, list-targets, and list-modules commands fail using framework assembly
[ https://issues.apache.org/jira/browse/GERONIMO-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn closed GERONIMO-4356. -- search-plugins, list-targets, and list-modules commands fail using framework assembly - Key: GERONIMO-4356 URL: https://issues.apache.org/jira/browse/GERONIMO-4356 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.2, 2.1.3, 2.1.4, 2.2 Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 2.1.4, 2.2 Commands such as search-plugins, list-targets, list-modules, and perhaps others result in the following error but only when using the framework assembly. Using GERONIMO_BASE: /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2 Using GERONIMO_HOME: /Users/bohn/g-images/2.1.2/geronimo-framework-2.1.2 Using GERONIMO_TMPDIR: var/temp Using JRE_HOME:/System/Library/Frameworks/JavaVM.framework/Home org.apache.geronimo.kernel.GBeanNotFoundException: No GBeans found: [?#org.apache.geronimo.kernel.util.Main] at org.apache.geronimo.kernel.basic.BasicRegistry.getGBeanInstance(BasicRegistry.java:153) at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:286) at org.apache.geronimo.kernel.basic.BasicKernel.getGBean(BasicKernel.java:282) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:100) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.getMain(MainConfigurationBootstrapper.java:59) at org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.java:38) at org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67) at org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: maven site generation genesis
In-line. Joe Bohn wrote: I've been making some changes to Genesis 1.5-SNAPSHOT to get maven site generation working a little bit better and fix a few other things. All of this is because there were still some maven site generation issues after releasing samples. I think I have things working better now ... but I have some questions: - Regarding the site.xml ... it looked to me like the original intent was to leverage completely the site.xml from genesis. However, I could never get this working correctly to include the header for the generated site. As a result ... I ended up including some of the same site.xml content in samples such as the skin and banner definition. Is that a problem? - Genesis: When we were getting samples out the door I ended up including some temporary junk in the sample pom/site. I've now removed this and made some minor changes to genesis/branches/genesis-1.x. Should I look at releasing Genesis 1.5 until 2.0 is complete or should we put all emphasis on 2.0? What is the current status of 2.0? BTW .. I also noticed that generating a site for genesis 2.0-SNAPSHOT itself has some issues something else to look into. Yes, we should release 1.5, so future maintenance releases of existing 2.0/2.1 server, samples and specs can use it (there will be a 2.1.4 Server release, just a mater of when...) - Specs: I've also made some similar changes locally for specs. I think these will produce more correct maven sites. However, the would require changes to depend on a newer Genesis and would require releasing a new specs-parent (1.6). I don't want to include these snapshot dependencies which would hinder the ability to release specs for now ... so I'm waiting on the Genesis decision. If we want to push out a Genesis 1.5 rc and get that up for vote. General: Is this really worth the effort? It seems that we haven't put much of an emphasis on maven sites. Is this because there were problems generating them or because we don't see much value? Most of what we have out there now is 2 years old (see http://cwiki.apache.org/GMOxDEV/maven-generated-documentation.html). It think there are some concerns of how useful these are, particularly for multi-project release (like server). The site information generated is per project and doesn't provide a good overview. IIUC, this can be aggregated for some if not all things (like javadoc). In the past we have provided independent javadoc in addition to the site (which I suspect is why, I suspect that the latest javadoc available for the server from our site if for 2.0.1). Should we focus energy on getting independent javadoc release, improve maven site generation and leverage that for javadoc/xrefs, or both? Some users have asked for updated javadoc, so lets give it one more try before we abandon site generation. Joe
Re: [VOTE RESULT] Release SAAJ 1.3 spec jar version 1.0.1
Ok. Just published it. Thanks, Jarek On Thu, Oct 16, 2008 at 2:31 PM, Joe Bohn [EMAIL PROTECTED] wrote: Jarek, I think it is OK to make the site public. It isn't perfect from an appearance perspective but all of the appropriate content is included. IMO it's better to have something than nothing. Joe Jarek Gawor wrote: Hi, This vote passes with 10 +1 votes. I'll push out the binaries today but will not publish the site as we discovered problems with it. Thanks, Jarek On Mon, Oct 13, 2008 at 10:56 AM, Jarek Gawor [EMAIL PROTECTED] wrote: Hi, This is a vote for SAAJ 1.3 spec jar version 1.0.1. There was only one change from version 1.0.0: https://issues.apache.org/jira/browse/GERONIMO-4289 Staging repo: http://people.apache.org/~gawor/staging-repo/specs/geronimo-saaj_1.3_spec/ Staging site: http://people.apache.org/~gawor/staging-site/specs/geronimo-saaj_1.3_spec/ The vote is open until Thursday (October 16th). [ ] +1 [ ] +0 [ ] -1 Jarek
[jira] Commented: (GERONIMO-4366) Non-ASCII chars in deployment plan xml files cause deployment failed with NPE on deployment time
[ https://issues.apache.org/jira/browse/GERONIMO-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640290#action_12640290 ] Donald Woods commented on GERONIMO-4366: How were these non-ASCII chars introduced? Did your svn client create locale specific values for the $date field? If so, this is a svn bug, as the XML files are marked with encoding=UTF-8 and should not contain any non-UTF8 chars. If you set your locale to en_US before running the svn co, does that fix the problem? Non-ASCII chars in deployment plan xml files cause deployment failed with NPE on deployment time Key: GERONIMO-4366 URL: https://issues.apache.org/jira/browse/GERONIMO-4366 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 2.1.3 Environment: Any platforms Reporter: Forrest Xia Steps to recur: 1. checkout AG samples 2.1.2 2. build them 3. install jms-mdb-xxx.ear with plan samples\jms-mdb\jms-mdb-tomcat\target\resources\META-INF\plan.xml in admin console You will get an NPE like this: java.lang.NullPointerException org.apache.geronimo.common.DeploymentException: java.lang.NullPointerException at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:275) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:867) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61) at java.lang.Thread.run(Thread.java:810) Caused by: java.lang.NullPointerException at org.apache.geronimo.deployment.CopyResourceContext.addFile(CopyResourceContext.java:144) at org.apache.geronimo.deployment.DeploymentContext.addFile(DeploymentContext.java:461) at org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.installModule(AbstractWebModuleBuilder.java:289) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.installModule(SwitchingModuleBuilder.java:153) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:586) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) ... 12 more To remove it, update all deployment plan files to remove any non-ascii chars, then rebuild and redeploy through admin console, it works! So I doubt AG does not support any non-ASCII chars in deployment plan. But for non-english environment, user might leave some comments including non-english chars in deployment plan, so it's necessary to take time to make our deployment plan could contain non-ASCII chars. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (GERONIMO-4353) An uniform way to show error messages on the console
Dojo should only get pulled into a server assembly if one of the installed pluginprofiles (or plugins) has a dependency on it. BTW - the following file addition in the patch concerns me - dojo/geronimo-dojo/src/main/appended-resources/dijit/form/GMessages.js This dijit directory is created at build time by extracting the Dojo 1.1.1 files so they can be packaged. We shouldn't be adding files in the Dojo plugin... Why is this not included in one of the console-* modules instead? -Donald Ivan wrote: Hi, Yes, in the last discussion, for currently no component uses the dojo (only plancreator uses the legacy dojo, I remember that it would migrate to the new dojo version ?), so we temporary removed it from the server. But dojo is really a good tool to improve the usability of the admin console, I guess we need it. And since a compact mini-dojo is created, it currently only contains those must files. The reason that dojo is used here is also due to some technical reason. For I want to display those messages on the portlets and wish it does not impact the current existing portlets, so I print the messages in a hidden html div tag and use dojo to load those messages. And so that the developers of the portlets do not need to take care too much on the message display, no extra work needs to done. Thanks for any comment ! 2008/10/16 Lin Sun (JIRA) [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/GERONIMO-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640040#action_12640040 https://issues.apache.org/jira/browse/GERONIMO-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640040#action_12640040 ] Lin Sun commented on GERONIMO-4353: --- Hi, I'd like to understand why dojo is needed here since this is a change to the base console. I am under the impression that we want to reduce server size (from discussion on dev list, dojo seems to have lots of files) and make some console components optional. Thanks Lin An uniform way to show error messages on the console Key: GERONIMO-4353 URL: https://issues.apache.org/jira/browse/GERONIMO-4353 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.3 Reporter: Ivan Attachments: Geronimo-4353.patch, snapshot.JPG Currently, different portlets uses different way to show those error messages to the end user. We need a uniform way to do it. The simliar issue is opened in GERONIMO-2621, but it was closed due to overwork on it in the past. I am trying to provide a solution, and will provide a demo in the next few days. Thanks ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Ivan
[jira] Updated: (GERONIMO-4365) Pull in TranQL Informix XA connector
[ https://issues.apache.org/jira/browse/GERONIMO-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4365: --- Fix Version/s: 2.2 2.1.4 add target fix releases Pull in TranQL Informix XA connector Key: GERONIMO-4365 URL: https://issues.apache.org/jira/browse/GERONIMO-4365 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: databases Affects Versions: 2.1.3, 2.2 Reporter: Rex Wang Fix For: 2.1.4, 2.2 We can pull in the patch in TranQL which provides informix XA connector. http://jira.codehaus.org/browse/TQL-12 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4353) An uniform way to show error messages on the console
[ https://issues.apache.org/jira/browse/GERONIMO-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640293#action_12640293 ] Donald Woods commented on GERONIMO-4353: -1 on the 20081014 patch. The following file addition in the patch concerns me - dojo/geronimo-dojo/src/main/appended-resources/dijit/form/GMessages.js This dijit directory is created at build time by extracting the Dojo 1.1.1 files so they can be packaged. We shouldn't be adding files in the Dojo plugin... Why is this not included in one of the console-* modules instead? An uniform way to show error messages on the console Key: GERONIMO-4353 URL: https://issues.apache.org/jira/browse/GERONIMO-4353 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.3 Reporter: Ivan Attachments: Geronimo-4353.patch, snapshot.JPG Currently, different portlets uses different way to show those error messages to the end user. We need a uniform way to do it. The simliar issue is opened in GERONIMO-2621, but it was closed due to overwork on it in the past. I am trying to provide a solution, and will provide a demo in the next few days. Thanks ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
How is the default-subject used in EJB security?
I have a stateless bean BankBean1 as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
public class BankBean1 implements Bank {
@RolesAllowed({customer, bank})
public Double getBalance(Integer account) {
return data.get(account);
}
@RolesAllowed({bank})
public Double creditAccount(Integer account, Double amt) {
...
return value;
}
@RolesAllowed({bank})
public Double debitAccount(Integer account, Double amt) {
...
return value;
}
}
I have a second stateless bean BankBean2 that has a reference injected to
BankBean1 and uses @RunAs as given below:
@Stateless
@DeclareRoles(value = {bank, customer})
@RunAs(value = bank)
public class BankBean2 implements Bank2 {
@EJB
private Bank bank; // BankBean1 gets injected here.
public Double getBalance(Integer account) {
return bank.getBalance(account);
}
public Double creditAccount(Integer account, Double amt) {
return bank.creditAccount(account, amt);
}
public Double debitAccount(Integer account, Double amt) {
return bank.debitAccount(account, amt);
}
}
In the security mapping in openejb-jar.xml, if I specify a run-as-subject
for bank role, BankBean2 is able to invoke BankBean1 as per that
run-as-subject specified. But if I don't specify a run-as-subject, but only
use a default-subject, BankBean2 is unable to invoke BankBean1 as per the
default-subject specified. I guess the default-subject is being ignored.
This is not the case with run-as-subject and default-subject used in
geronimo-web.xml. In the absence of run-as-subject I notice that
default-subject is used. I am wondering how the default-subject is used in
ejb security.
++Vamsi
source-repository (in plugin metadata) and default-repository (in plugin catalog)
Hi, We provide source-repository in plugin metadata and default-repository in plugin catalog. Currently, (I think this is how it works) when we install a plugin from a remote repo A, if the installation is not restricted to the particular repo A: If the plugin specifies 1+ source-repository, we'll use that and ignore the default-repository specified in plugin catalog. If the plugin doesn't specify any source-repository, we'll use the default-repository specified in the plugin catalog. I 'd like to change it to: If the plugin specifies 1+ source-repository, we'll use that AND the default-repository specified in plugin catalog. I think that would give us more flexibility. Thoughts? P.S. this is related to this thread on user list where a user wants to install active mq on top of little G env - http://www.nabble.com/how-to-add-activemq-to-little-g--to19837127s134.html Lin
Re: maven site generation genesis
Donald Woods wrote: In-line. Joe Bohn wrote: I've been making some changes to Genesis 1.5-SNAPSHOT to get maven site generation working a little bit better and fix a few other things. All of this is because there were still some maven site generation issues after releasing samples. I think I have things working better now ... but I have some questions: - Regarding the site.xml ... it looked to me like the original intent was to leverage completely the site.xml from genesis. However, I could never get this working correctly to include the header for the generated site. As a result ... I ended up including some of the same site.xml content in samples such as the skin and banner definition. Is that a problem? - Genesis: When we were getting samples out the door I ended up including some temporary junk in the sample pom/site. I've now removed this and made some minor changes to genesis/branches/genesis-1.x. Should I look at releasing Genesis 1.5 until 2.0 is complete or should we put all emphasis on 2.0? What is the current status of 2.0? BTW .. I also noticed that generating a site for genesis 2.0-SNAPSHOT itself has some issues something else to look into. Yes, we should release 1.5, so future maintenance releases of existing 2.0/2.1 server, samples and specs can use it (there will be a 2.1.4 Server release, just a mater of when...) I was leaning that way too. In my very poorly worded sentence below I intended to say I can create a Genesis 1.5 rc and get that up for a vote. I'll go ahead and do that now. If there are any objections to that we can deal with in the vote/discussion. - Specs: I've also made some similar changes locally for specs. I think these will produce more correct maven sites. However, the would require changes to depend on a newer Genesis and would require releasing a new specs-parent (1.6). I don't want to include these snapshot dependencies which would hinder the ability to release specs for now ... so I'm waiting on the Genesis decision. If we want to push out a Genesis 1.5 rc and get that up for vote. General: Is this really worth the effort? It seems that we haven't put much of an emphasis on maven sites. Is this because there were problems generating them or because we don't see much value? Most of what we have out there now is 2 years old (see http://cwiki.apache.org/GMOxDEV/maven-generated-documentation.html). It think there are some concerns of how useful these are, particularly for multi-project release (like server). The site information generated is per project and doesn't provide a good overview. IIUC, this can be aggregated for some if not all things (like javadoc). In the past we have provided independent javadoc in addition to the site (which I suspect is why, I suspect that the latest javadoc available for the server from our site if for 2.0.1). Should we focus energy on getting independent javadoc release, improve maven site generation and leverage that for javadoc/xrefs, or both? Some users have asked for updated javadoc, so lets give it one more try before we abandon site generation. FYI, I'm also looking into what we need to do to update the javadoc on the website (independent of the maven site). I'd love to eliminate one of these but in the until we can get a server site generated I think it makes sense to release some freah javadoc for 2.1.3. Joe
Re: source-repository (in plugin metadata) and default-repository (in plugin catalog)
Sounds good. That was the way I thought it was/should work. -Donald Lin Sun wrote: Hi, We provide source-repository in plugin metadata and default-repository in plugin catalog. Currently, (I think this is how it works) when we install a plugin from a remote repo A, if the installation is not restricted to the particular repo A: If the plugin specifies 1+ source-repository, we'll use that and ignore the default-repository specified in plugin catalog. If the plugin doesn't specify any source-repository, we'll use the default-repository specified in the plugin catalog. I 'd like to change it to: If the plugin specifies 1+ source-repository, we'll use that AND the default-repository specified in plugin catalog. I think that would give us more flexibility. Thoughts? P.S. this is related to this thread on user list where a user wants to install active mq on top of little G env - http://www.nabble.com/how-to-add-activemq-to-little-g--to19837127s134.html Lin
[jira] Resolved: (GERONIMO-4327) Upgrade Axis2 for JAX-WS 2.1 support
[ https://issues.apache.org/jira/browse/GERONIMO-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-4327. --- Resolution: Fixed Fix Version/s: 2.2 Trunk is now updated to the latest Axis2 version for JAX-WS 2.1 support. Upgrade Axis2 for JAX-WS 2.1 support Key: GERONIMO-4327 URL: https://issues.apache.org/jira/browse/GERONIMO-4327 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Affects Versions: 2.2 Reporter: Jarek Gawor Assignee: Jarek Gawor Fix For: 2.2 Upgrade to latest Axis2 version in order to get JAX-WS 2.1 support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
restart of tck08 on selene
FYI, The Xen domain tck08 on selene.apache.org crashed yesterday. 'xm log' showed that the domain had indeed crashed and that the subsequent attempt to restart the domain had failed because the domain already existed. When I looked, 'xm list' did not show tck08 as a domain that could be controlled (start, shutdown, etc). I finally ended up running 'xm create /etc/xen/tck08.cfg'. This seems to have restarted the domain. I'm able to log in to tck08, and everything looks ok. So, hopefully it's back in service. --kevan
Re: restart of tck08 on selene
Thanks for looking into that, Kevan. Was there any indicator of what caused the crash? Thanks On Thu, Oct 16, 2008 at 5:26 PM, Kevan Miller [EMAIL PROTECTED]wrote: FYI, The Xen domain tck08 on selene.apache.org crashed yesterday. 'xm log' showed that the domain had indeed crashed and that the subsequent attempt to restart the domain had failed because the domain already existed. When I looked, 'xm list' did not show tck08 as a domain that could be controlled (start, shutdown, etc). I finally ended up running 'xm create /etc/xen/tck08.cfg'. This seems to have restarted the domain. I'm able to log in to tck08, and everything looks ok. So, hopefully it's back in service. --kevan -- ~Jason Warner
Looking back to 2.0.x
Hello all, With the discussion of where the JEE 6 development will be done, I realized (again) that we never released 2.0.3. The only thing that kept us from releasing 2.0.3 was an exception that only occurred under stress testing the server (a ConcurrentModificationException). And, recently, when we added a number of security patches that were the driver for releasing 2.1.3 - the same security patches were put into the 2.0.x codestream as well. Should we put out one last release of 2.0.x and then officially encourage anyone on a level lower than 2.1.x to upgrade? I think that is probably what we should do. At this point, there is a range of work being applied to 2.0.x, 2.1.x, 2.2.x and soon 3.0.x (or however we version the upcoming JEE 6). Also, do we have an official 'support period'? Would it be worthwhile to discuss implementing one if we don't? Letting our users know that we intend to support a particular major.minor release (bug fixes only) would make it easier for them to plan which version they want to implement against and plan/schedule their server upgrades. Maybe we would specify a window of '12 months after the next higher minor release'. Version 2.1.0 was released this February, so 2.0.x 'official' support would end next February. Of course if someone felt like continuing to make fixes (and they had someone to run TCKs against them) then 'unofficial' support may run longer. Our resources are being spread -really- thin. And as a result, 2.0.x has been nearly abandoned. We have security fixes that were put in this September, but no release in the last 12 months. When 2.2.x is finally released and the JEE 6 work begins in earnest - I have a feeling that 2.1.x will begin to fall by the wayside as well. Regardless - I mainly wanted to know if anyone thought that we should go ahead and do a final release on 2.0.x. I think the security fixes make it worthwhile. But then, maybe we should officially set an end for 2.0. Any thoughts? Jay
Re: Looking back to 2.0.x
Hi, Jay. On Oct 16, 2008, at 8:28 PM, Jay D. McHugh wrote: Hello all, With the discussion of where the JEE 6 development will be done, I realized (again) that we never released 2.0.3. The only thing that kept us from releasing 2.0.3 was an exception that only occurred under stress testing the server (a ConcurrentModificationException). We scuttled the whole 1.2 release for similar reasons. Perhaps we should work on learning from our own history. And, recently, when we added a number of security patches that were the driver for releasing 2.1.3 - the same security patches were put into the 2.0.x codestream as well. Should we put out one last release of 2.0.x and then officially encourage anyone on a level lower than 2.1.x to upgrade? I think that is probably what we should do. At this point, there is a range of work being applied to 2.0.x, 2.1.x, 2.2.x and soon 3.0.x (or however we version the upcoming JEE 6). If you, and/or some other community member(s), are motivated to prepare a 2.0.3 release, you'd certainly have my support. I'm sure you'd have the community's support, also. Given the security fixes that you mention, I think it would be nice to have an actual release that contains them. Also, do we have an official 'support period'? Would it be worthwhile to discuss implementing one if we don't? Letting our users know that we intend to support a particular major.minor release (bug fixes only) would make it easier for them to plan which version they want to implement against and plan/schedule their server upgrades. Maybe we would specify a window of '12 months after the next higher minor release'. Version 2.1.0 was released this February, so 2.0.x 'official' support would end next February. Of course if someone felt like continuing to make fixes (and they had someone to run TCKs against them) then 'unofficial' support may run longer. We've never established an official support period. I'm not too sure that we need one. If you disagree, then I'm all ears. Or, if our user community feels that it would be helpful, then I'd certainly give it my consideration. Personally, I think we've done a pretty good job in merging fixes back into our older releases. I haven't seen that the lack of a support policy was inhibiting user adoption. As long as we have a stable newer release (e.g. 2.1.x) release to point to, shifting our focus towards our newer releases doesn't seem too bad to me. If there had been user requests for a 2.0.x release, I think we would have generated a new 2.0.x release. Our resources are being spread -really- thin. And as a result, 2.0.x has been nearly abandoned. We have security fixes that were put in this September, but no release in the last 12 months. When 2.2.x is finally released and the JEE 6 work begins in earnest - I have a feeling that 2.1.x will begin to fall by the wayside as well. I expect that you are correct. Personaly, I doubt that we'll ever maintain more than two release branches simultaneously (e.g. 2.0/2.1, or 2.1/2.2; etc). Regardless - I mainly wanted to know if anyone thought that we should go ahead and do a final release on 2.0.x. I think the security fixes make it worthwhile. But then, maybe we should officially set an end for 2.0. Any thoughts? I second the motion for Jay to be the release manager... ;-) --kevan
Re: [jira] Commented: (GERONIMO-4353) An uniform way to show error messages on the console
Thanks for the comments, Donald. 1. I am also working on improving the portlet usability by dojo, and it will be dependent by all the console plugins, If this solution is adopted :-) 2. Yes, it seems that I made a mistake about the placement of the GMessages.js file. For this js file is a dojo extension, which means it extends some js class from dojo, so I guess it should be in the dojo's folder. I am not familar with the assemblage mechanism, if putting it in one of the console-*modules, can it be in the dojo plugin folder ? Or may I package it to the dojo-min-1.1.1.zip in the repository folder ? 2008/10/17 Donald Woods (JIRA) [EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/GERONIMO-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640293#action_12640293] Donald Woods commented on GERONIMO-4353: -1 on the 20081014 patch. The following file addition in the patch concerns me - dojo/geronimo-dojo/src/main/appended-resources/dijit/form/GMessages.js This dijit directory is created at build time by extracting the Dojo 1.1.1 files so they can be packaged. We shouldn't be adding files in the Dojo plugin... Why is this not included in one of the console-* modules instead? An uniform way to show error messages on the console Key: GERONIMO-4353 URL: https://issues.apache.org/jira/browse/GERONIMO-4353 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 2.1.3 Reporter: Ivan Attachments: Geronimo-4353.patch, snapshot.JPG Currently, different portlets uses different way to show those error messages to the end user. We need a uniform way to do it. The simliar issue is opened in GERONIMO-2621, but it was closed due to overwork on it in the past. I am trying to provide a solution, and will provide a demo in the next few days. Thanks ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Ivan
Re: Continuous TCK Testing
Yup, might need to resurrect that stuff if we plan on using it again. --jason On Oct 16, 2008, at 10:39 PM, Jason Warner wrote: Whoops... just realized that this was actually removed and I was looking at a stickied revision of viewVC. Nevermind. On Thu, Oct 16, 2008 at 11:15 AM, Jason Warner [EMAIL PROTECTED] wrote: While we wait to hear back in regards to the license, I'm going to update the maven used in build-support. The server now requires 2.0.9 and the version currently used by build support is 2.0.5. I suppose we'll need to update ant, as well. What version of ant should we be using? 1.7.1? On Fri, Oct 10, 2008 at 11:25 AM, Kevan Miller [EMAIL PROTECTED] wrote: On Oct 8, 2008, at 11:56 PM, Kevan Miller wrote: On Oct 8, 2008, at 4:31 PM, Jason Warner wrote: We had some suggestions earlier for some alternate means of implementing this (Hudson, Conitnuum, etc...). Now that we've had Jason Dillon provide an overview of what we had in place before, does anyone have thoughts on what we should go with? I'm thinking we should stick with the AHP based solution. It will need to be updated most likely, but it's been tried and tested and shown to meet our needs. I'm wondering, though, why we stopped using it before. Was there a specific issue we're going to have to deal with again? IIRC, the overwhelming reason we stopped using it before was because of hosting issues -- spotty networking, hardware failures, poor colo support, etc. We shouldn't have any of these problems, now. If we do run into problems, they should now be fixable. I have no reason to favor Hudson/Continuum over AHP. So, if we can get AHP running easily, I'm all for it. There's only one potential issue, that I'm aware of. We previously had an Open Source License issued for our use of Anthill. Here's some of the old discussion -- http://www.nabble.com/Geronimo-build-automation-status-(longish)-tt7649902.html#a7649902 Although the board was aware of our usage of AntHill, since we weren't running AntHill on ASF hardware, I'm not sure the license was fully vetted by Infra. I don't see any issues, but I'll want to run this by Infra. Jason D, will the existing license cover the version of AntHill that we'll want to use? I'll run the license by Infra and will also describe the issue for review by the Board, in our quarterly report. IMO, I'd proceed with the assumption that we'll be using AHP. Just don't install it on Apache hardware, yet. I've requested a new license from Anthill. Will let you know when I get it. --kevan -- ~Jason Warner -- ~Jason Warner
