[jira] Created: (SM-334) getExtensionMBeanName is called before the component lifecycle has been initialized
getExtensionMBeanName is called before the component lifecycle has been initialized --- Key: SM-334 URL: http://jira.activemq.org/jira//browse/SM-334 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0-M1 Reporter: Guillaume Nodet Assigned to: Guillaume Nodet Fix For: 3.0-M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-334) getExtensionMBeanName is called before the component lifecycle has been initialized
[ http://jira.activemq.org/jira//browse/SM-334?page=all ] Guillaume Nodet resolved SM-334: Resolution: Fixed Author: gnodet Date: Sun Feb 26 15:59:21 2006 New Revision: 381202 URL: http://svn.apache.org/viewcvs?rev=381202view=rev Log: SM-334: getExtensionMBeanName is called before the component lifecycle has been initialized Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/framework/ComponentMBeanImpl.java incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/installation/InstallationTest.java getExtensionMBeanName is called before the component lifecycle has been initialized --- Key: SM-334 URL: http://jira.activemq.org/jira//browse/SM-334 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0-M1 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 3.0-M1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Removing attributes and refs from the config.xml
I agree that the end goal here is the user experience. When I was working with Jeff the other night the way to fix the logging problem at that point was to rebuild the server. IMHO a user would at most be required to edit the config.xml and at least be able to click a radio button for a binary operation like enable/disable logging. Anything beyond that and we will limit our user base as the server will be too expensive to work with. The other thinkg to avoid is multiple configuration files. As a user I want to find all config files in a single directory if possible (reduces my knowledge required to use the server) and then to have as few files as possible. Again, this all front-ended with a console that can manipulate all (or at least as many options as possible). I may not have captured this thought in my first post so apologies for repeating myself. Matt. Bruce Snyder wrote: I'm gonna go out on a limb here and ask why we're trying to make all of this more difficult for users instead of easier? Requiring a user to: 1) gain knowledge of the plans used to create the CARs, and 2) to create a brand new XML file (config.xml) to define new functionality or override existing functionality seems ridiculous. The proposed solution seems to be treating the symptoms rather than the real disease. IMHO, CARs need to either be made more dynamic or need to be replaced with something more dynamic. The trouble I have with CARs is that changing them requires them to be fully rebuilt which requires the Geronimo source. Average users don't have the knowledge or time to deal with this so we offered the config.xml which we're finding doesn't really solve the whole problem either. If I had my druthers, I'd leave CARs the way they are and work to offer something more dynamic as a long-term solution. The idea I have is to use a standard XML dialect for configuration files - like XBean which currently requires Spring. I'm sure that this idea won't have many fans, but it's an easy way to reuse an existing solution to deliver an easier experience for Geronimo users which, IMO, should be our ultimate goal. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: parents (imports) of configurations
The jmx-explorer is contained within GERONIMO-1163.The tweaks that I
made to get it to build were in the project.xml and the addition of a
maven.xml to build the war. Simon was going to incorporate these into
the patch and attach it to the JIRA, but I'll attach them to this note
as well.
Joe
John Sisson wrote:
Where can I find the jmx-explorer and have these tweaks you mentioned
been documented or a patch updated? It sounds like it will be useful
for others.
Thanks,
John
Joe Bohn wrote:
I was able to get the jmx-explorer working with some tweaks and some
offline conversations with Simon. It does show this information for
the currently running assembly and the set of configurations it
includes (although there were some oddities that Simon is checking
into). It would be good if we could get this updated utility live
sometime.
However, it still might be valuable to see this in totality (at least
it was for me when making changes that affect all of the assemblies)
with the parents of all configurations and not just those for a
particular assembly. It's also nice to have it in a graphical form.
But there is certainly *a lot* to be said for getting live information
and not maintaining another representation.
If nobody else finds this useful I'll just continue to use it myself.
Joe
Simon Godik wrote:
Joe Bohn wrote:
I'm not sure if these charts are helpful for anybody else or not. It's
a point in time snapshot that I created of parent (import) dependencies
between configurations at the moment (which some of the changes that I
have pending to clean up some dependencies).
The first page has the server configuration imports and the second page
includes the client and childless configs (configs not referenced as
parents by any other configuration).
If you think it's useful then I will try to find a location where we
can
keep this ... but I suspect it would get out of date fairly quickly.
Joe
In my long lost jmx explorer (still attached to some jira) I have
configuration tree that shows these relationships
Simon
--
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
?xml version=1.0 encoding=UTF-8?
!--
Copyright 2004 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an AS IS BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
--
project
pomVersion3/pomVersion
extend../../etc/project.xml/extend
nameGeronimo :: JMX Console/name
nameGeronimo :: JMX Explorer Webapp/name
idgeronimo-jmxexplorer/id
shortDescription/shortDescription
description/description
siteDirectory/siteDirectory
distributionDirectory/distributionDirectory
dependencies
!--
dependency
groupIdgeronimo-spec/groupId
artifactIdgeronimo-spec-servlet/artifactId
version${geronimo_spec_servlet_version}/version
/dependency
--
!-- @JAB added this spec instead of the previous one --
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-servlet_2.4_spec/artifactId
version${geronimo_spec_servlet_version}/version
/dependency
dependency
groupIdtaglibs/groupId
artifactIdstandard/artifactId
version${standard_taglibs_version}/version
properties
war.bundletrue/war.bundle
/properties
/dependency
dependency
groupIdjstl/groupId
artifactIdjstl/artifactId
version${jstl_version}/version
properties
war.bundletrue/war.bundle
/properties
/dependency
dependency
groupIdgeronimo/groupId
artifactIdgeronimo-kernel/artifactId
version${pom.currentVersion}/version
/dependency
dependency
groupIdmx4j/groupId
artifactIdmx4j/artifactId
version${mx4j_version}/version
urlhttp://mx4j.sourceforge.net/url
/dependency
/dependencies
build
sourceDirectorysrc/java/sourceDirectory
unitTestSourceDirectorysrc/test/unitTestSourceDirectory
resources
!-- @JAB added resource element --
resource
directory${basedir}/src/java/directory
includes
include**/*.xml/include
/includes
Re: Devtools web space (was: Re: Geronimo Eclipse Plugin released)
I agree. I think Hernan created the new devtools.html. Hernan, was devtools.html meant to be permanent? If not, I'd prefer it back in devtools as index.html - sachin On Feb 25, 2006, at 5:07 PM, Jacek Laskowski wrote: 2006/2/25, Bruce Snyder [EMAIL PROTECTED]: My only point is that there was a devtools.html *and* a devtools directory. I got your point and fully agree with you. There should only be one and I think devtools dir would be better than devtools.html. Unless I miss something, it could be done with devtools.html being renamed to index.html in devtools dir. But it appears that the devtools directory has already been removed. Just checked it out and it's still there, but only files are listed. Not very user-friendly ;) It does seem odd that the tab labeled 'Subprojects' links to a page that is only about the devtools subproject. Maybe the tab should be renamed 'Devtools'? Sure. It could point Devtools, ServiceMix, XBean. They all are subprojects, aren't they? But, then again, maybe I'm just out of my mind. If these ideas have appeared when you're in this state of mind, please don't cure it ;) They're all valid points. Bruce Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Created: (GERONIMO-1653) User friendly error message from GBeanInstance
User friendly error message from GBeanInstance -- Key: GERONIMO-1653 URL: http://issues.apache.org/jira/browse/GERONIMO-1653 Project: Geronimo Type: Wish Components: kernel Versions: 1.0.1 Environment: All Reporter: Anita Kulshreshtha Priority: Trivial Fix For: 1.0.1 When a GBean failes to start due to errors such as reference to a non existent GBean, the following message is given : GBeanInstance should already be stopped before die() is called. The user must be told that the GBean did not start. -- 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-1653) User friendly error message from GBeanInstance
[ http://issues.apache.org/jira/browse/GERONIMO-1653?page=all ] Anita Kulshreshtha updated GERONIMO-1653: - Attachment: kernel.patch The new message is : GBeanInstance should already be stopped before die() is called. This means that this GBean failed to start due to errors, e.g. reference to a badly named GBean : objectName=... User friendly error message from GBeanInstance -- Key: GERONIMO-1653 URL: http://issues.apache.org/jira/browse/GERONIMO-1653 Project: Geronimo Type: Wish Components: kernel Versions: 1.0.1 Environment: All Reporter: Anita Kulshreshtha Priority: Trivial Fix For: 1.0.1 Attachments: kernel.patch When a GBean failes to start due to errors such as reference to a non existent GBean, the following message is given : GBeanInstance should already be stopped before die() is called. The user must be told that the GBean did not start. -- 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: Removing attributes and refs from the config.xml
I completely agree with the assessment of the problem, but I don't think we have a good solution yet. Regardless of using the existing GBean code, Spring or xbean-reflect to wire services together, the user must have a fairly deep understanding of the code. Lets look into the future. Say that configurations use xml instead of object serialization for the persistence format. Say we even have a plugin based server where users can download, install, use and unload extensions to the server. In this case we could let users hack the raw xml files in the unpacked cars, but every time they upgrade their server, or a single plugin, they loose all configuration changes to the server or plugin. Where does that leave us. I think we need to have a two level configuration system, like most user land software and a lot of system software has. In this design, you have the default configuration that ships with an install or plugin and user preferences which override that configuration. This is what we currently have, but I don't think we have a very elegant solution. I have a few ideas for this area, but we are at least a few months from having xml based and downloadable plugins. -dain On Feb 25, 2006, at 6:11 PM, Bruce Snyder wrote: I'm gonna go out on a limb here and ask why we're trying to make all of this more difficult for users instead of easier? Requiring a user to: 1) gain knowledge of the plans used to create the CARs, and 2) to create a brand new XML file (config.xml) to define new functionality or override existing functionality seems ridiculous. The proposed solution seems to be treating the symptoms rather than the real disease. IMHO, CARs need to either be made more dynamic or need to be replaced with something more dynamic. The trouble I have with CARs is that changing them requires them to be fully rebuilt which requires the Geronimo source. Average users don't have the knowledge or time to deal with this so we offered the config.xml which we're finding doesn't really solve the whole problem either. If I had my druthers, I'd leave CARs the way they are and work to offer something more dynamic as a long-term solution. The idea I have is to use a standard XML dialect for configuration files - like XBean which currently requires Spring. I'm sure that this idea won't have many fans, but it's an easy way to reuse an existing solution to deliver an easier experience for Geronimo users which, IMO, should be our ultimate goal. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Removing attributes and refs from the config.xml
I think we are all past the old concerns. The problem now is how do we switch, which is not an easy problem. On my laptop I have about half of the server switched to use xbean-reflect, which is xml friendly, but I got sucked into the configId problem. -dain On Feb 25, 2006, at 11:17 PM, Bruce Snyder wrote: On 2/26/06, Jason Dillon [EMAIL PROTECTED] wrote: Why would anyone object to using XBean+Spring? I think that sounds like a good idea. Well the objection wasn't to XBean and Spring per se - they weren't even in the picture back then. The objection was to using XML as the configuraiton mechanism instead of CAR files. Way back when CARs were being suggested as the configuration mechanism, I entered the debate with the rationale that we should use XML instead because it's is easy to change, it's easy to understand, etc. At that time, there were objections to this line of reasoning because of the overhead of parsing the XML on every startup. The argument was made that CAR files would start up much faster. I have no idea if this is true or not but IMO the advantages of using XML (and a well known XML dialect like Spring) far outweigh the disadvantages, especially when it comes to offering users a simple but very powerful experience. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Changing Trunk to 1.2 in anticipation of 1.0.1 becoming 1.1
Trunk should now be completely changed to 1.2 in geronimo and 2.2 in openejb. The configid branch should be 1.1 for G and 2.1 for openejb. I still haven't merged the missing changes from branch 1.0 onto configid or renamed configid. -dain On Feb 26, 2006, at 1:31 AM, Matt Hogstrom wrote: Dain, Which part are you taking a crack at? I've done some of the HEAD work. Should I abandon that ? Matt Dain Sundstrom wrote: Matt is traveling again, so I'm going to take a crack at this. -dain On Feb 23, 2006, at 4:47 PM, Matt Hogstrom wrote: John, Life has been a travelling adventure lately so apologies for my tardy response. My thinking is as follows in order of steps: 1. Convert HEAD to 1.2 SNAPSHOT. This will be good as we need to get this story down to simply changing etc/project.properties or at least as close as possible. 2. Once HEAD is changed and building correctly hopefully Dain and David will have something to show. I know they've been bustin their chops working on this. We rename their branches/ configid to branches/1.1. We'd have to ensure that changes made to 1.0 since they started get moved into their branch and then we can delete the 1.0 branch since we have the 1.0.0.0 tag. 3. Apply the outstanding JIRA's I had previously identified. We need to figure out which ones are still important. I'd like to get the release out by the end of March. Is this clearer? Matt John Sisson wrote: Alan D. Cabrera wrote: On 2/20/2006 8:23 PM, Matt Hogstrom wrote: I was thinking that in order to expedite getting 1.1 our the door that it would make sense to move trunk to 1.2. Then we'll have to do the same in the 1.0 branch. I'm going to start working on that this week. Comments, suggestions, ? So what is in trunk now? What is in branches/1_0 now? Where is the work for 1_1 taking place? Matt, Could you please confirm the following.. AFAIK, work for the 1.1 release (that was previously going to be called the 1.0.1 release) should be done in the 1.0 branch (until we branch for 1.1?). Matt is proposing to change the version numbers in files in branches/1.0 to be 1.1. I assume you plan on doing this before we create the 1.1 branch? Once the configId changes are merged in to branches/1.0 and we are ready for a release we would create branches/1.1 from the 1.0 branch. If we are creating a 1.1 branch then does that mean there would be no further work happening in the 1.0 branch once the branch is made? Work for the 1.2 release should be done in trunk. I think Matt is proposing to change the version numbers in files in trunk to be 1.2. Are we releasing version 1.1 of all the specs for the 1.1 release? Thanks, John Regards, Alan
New Feature Idea
Hello, I'm from Mexico and I guess that Geronimo's spanish translation isn't a bad idea. I don't know if you have started that process, but I would like to contribute to it: create a Geronimo-with-spanish-text-and-doc like stuff/version. Anyway, continue with this great project!! Regards, Ing. Waldo Ramírez Montaño You can also contact me to this e-mail (it's from work): [EMAIL PROTECTED] - www.correo.unam.mx UNAMonos Comunicándonos
[jira] Commented: (GERONIMO-1639) Setup old version of CORBA specs
[ http://issues.apache.org/jira/browse/GERONIMO-1639?page=comments#action_12367844 ] Alan Cabrera commented on GERONIMO-1639: The bad jar should be replaced w/ the temporary good jar until the Yoko group can fix the specs. Simple changes in the POM dependencies will fix things. Setup old version of CORBA specs Key: GERONIMO-1639 URL: http://issues.apache.org/jira/browse/GERONIMO-1639 Project: Geronimo Type: Bug Components: CORBA Versions: 1.0, 1.0.1, 1.1, 1.x Reporter: Alan Cabrera Assignee: Kevan Miller Fix For: 1.1, 1.x Setup old version of CORBA specs for temporary use until the new CORBA specs can pass the TCK. -- 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: Removing attributes and refs from the config.xml
Commit it and let the community implement the rest... seems to have worked for at least one project I know of... sorta... kinda... um, well nevermind. --jason On Feb 26, 2006, at 9:29 AM, Dain Sundstrom wrote: I think we are all past the old concerns. The problem now is how do we switch, which is not an easy problem. On my laptop I have about half of the server switched to use xbean-reflect, which is xml friendly, but I got sucked into the configId problem. -dain On Feb 25, 2006, at 11:17 PM, Bruce Snyder wrote: On 2/26/06, Jason Dillon [EMAIL PROTECTED] wrote: Why would anyone object to using XBean+Spring? I think that sounds like a good idea. Well the objection wasn't to XBean and Spring per se - they weren't even in the picture back then. The objection was to using XML as the configuraiton mechanism instead of CAR files. Way back when CARs were being suggested as the configuration mechanism, I entered the debate with the rationale that we should use XML instead because it's is easy to change, it's easy to understand, etc. At that time, there were objections to this line of reasoning because of the overhead of parsing the XML on every startup. The argument was made that CAR files would start up much faster. I have no idea if this is true or not but IMO the advantages of using XML (and a well known XML dialect like Spring) far outweigh the disadvantages, especially when it comes to offering users a simple but very powerful experience. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED \!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Plugin version numbers
I think we have a problem with the current version numbering of plugins. We are using the following scheme to generate the version numbers: geronimo-major.geronimo-minor.plugin-build-number The first two match the geronimo version and the last is a number that is incremented with each change to the plugin (this forces maven to download the new version). I think this scheme will break as soon as we do a geronimo release that has a micro (3 dotted) revision. We haven't seen this problem yet in Geronimo but we almost saw it when we were working on geronimo 1.0.1. I propose we change to the following scheme: geronimo-major.geronimo-minor.geronimo-micro-plugin-build-number Using this scheme HEAD version plugin version numbers would be: geronimo_packaging_plugin_version=1.2.0-3 geronimo_assembly_plugin_version=1.2.0-8 geronimo_deployment_plugin_version=1.2.0-1 geronimo_dependency_plugin_version=1.2.0-1 branches/1.1 would become: geronimo_packaging_plugin_version=1.1.0-2 geronimo_assembly_plugin_version=1.1.0-8 geronimo_deployment_plugin_version=1.1.0-1 geronimo_dependency_plugin_version=1.1.0-1 We could optionally leave off the extra .0 before the dash but I think we should leave it in for clarity. I'd like to implement this quickly since the build is broken due to me changing the trunk version to 1.2 and not incrementing the plugins. So please let me know quickly if you have an issue with the changes[1]. -dain [1] We can always back the changes out but we could have published plugins that have bad version numbers, which is something I'd like to avoid.
Re: Plugin version numbers
I found the following Maven pages describing versions (I don't know if these are out of date): http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies In the 2nd URL above it says that the version section of a Maven version should be numeric. It describes a version being in the format: major.minor.revision([ -qualifier ] | [ -build ]). You are proposing that we have a '-' character in the revision section (using Maven's terminology) which doesn't agree with the numeric requirement. The doc also says that a revision is optional and will default to .0 if not set. So I'm not sure if Maven will see a non-numeric revision and then default the revision to .0 and then use the revision containing the '-' as a qualifier. If it is used as a qualifier, it looks like the qualifier is lexicographically compared, therefore geronimo_deployment_plugin_version=1.2.0-10 will be less than geronimo_deployment_plugin_version=1.2.0-2 . I haven't looked at the code to confirm any of this. Maybe one of the Maven guys could confirm what happens to your proposed geronimo-micro-plugin-build-number containing the '-' character. Regards, John Dain Sundstrom wrote: I think we have a problem with the current version numbering of plugins. We are using the following scheme to generate the version numbers: geronimo-major.geronimo-minor.plugin-build-number The first two match the geronimo version and the last is a number that is incremented with each change to the plugin (this forces maven to download the new version). I think this scheme will break as soon as we do a geronimo release that has a micro (3 dotted) revision. We haven't seen this problem yet in Geronimo but we almost saw it when we were working on geronimo 1.0.1. I propose we change to the following scheme: geronimo-major.geronimo-minor.geronimo-micro-plugin-build-number Using this scheme HEAD version plugin version numbers would be: geronimo_packaging_plugin_version=1.2.0-3 geronimo_assembly_plugin_version=1.2.0-8 geronimo_deployment_plugin_version=1.2.0-1 geronimo_dependency_plugin_version=1.2.0-1 branches/1.1 would become: geronimo_packaging_plugin_version=1.1.0-2 geronimo_assembly_plugin_version=1.1.0-8 geronimo_deployment_plugin_version=1.1.0-1 geronimo_dependency_plugin_version=1.1.0-1 We could optionally leave off the extra .0 before the dash but I think we should leave it in for clarity. I'd like to implement this quickly since the build is broken due to me changing the trunk version to 1.2 and not incrementing the plugins. So please let me know quickly if you have an issue with the changes[1]. -dain [1] We can always back the changes out but we could have published plugins that have bad version numbers, which is something I'd like to avoid.
[jira] Closed: (GERONIMO-1649) Invalid deployment descriptor error when deploying an EJB 2.0 MDB
[ http://issues.apache.org/jira/browse/GERONIMO-1649?page=all ] John Sisson closed GERONIMO-1649: - Resolution: Fixed Fixed. Changes merged to trunk. Invalid deployment descriptor error when deploying an EJB 2.0 MDB - Key: GERONIMO-1649 URL: http://issues.apache.org/jira/browse/GERONIMO-1649 Project: Geronimo Type: Bug Components: OpenEJB, deployment Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Blocker Fix For: 1.1, 1.0.1 Attachments: TEST-org.apache.geronimo.schema.SchemaConversionUtilsTest.txt There is a bug in org.apache.geronimo.schema.SchemaConversionUtils.convertBeans(..) for a EJB 2.0 MDB where the security-identity element is not moved to after the JNDIEnvironmentRefsGroup causing an error such as: org.apache.xmlbeans.XmlException: Invalid deployment descriptor: [error: cvc-complex-type.2.4b: Element not allowed: reso [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cvc-complex-type.2.4b: El ement not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee, error: cv c-complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element [EMAIL PROTECTED]://java.sun.com /xml/ns/j2ee, error: cvc-complex-type.2.4b: Element not allowed: [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee in element message-dri [EMAIL PROTECTED]://java.sun.com/xml/ns/j2ee] I will attach a test case to reproduce the problem tomorrow. -- 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] Closed: (GERONIMO-1603) shutdown.bat does not set ERRORLEVEL and does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables
[ http://issues.apache.org/jira/browse/GERONIMO-1603?page=all ] John Sisson closed GERONIMO-1603: - Resolution: Fixed shutdown.bat does not set ERRORLEVEL and does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables --- Key: GERONIMO-1603 URL: http://issues.apache.org/jira/browse/GERONIMO-1603 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Fix For: 1.0.1, 1.1 The shutdown.bat does not set ERRORLEVEL and does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables that the other batch files support. -- 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] Closed: (GERONIMO-1605) Display PID of started process when using geronimo.sh start or startup.sh
[ http://issues.apache.org/jira/browse/GERONIMO-1605?page=all ] John Sisson closed GERONIMO-1605: - Fix Version: 1.0.1 Resolution: Fixed Display PID of started process when using geronimo.sh start or startup.sh - Key: GERONIMO-1605 URL: http://issues.apache.org/jira/browse/GERONIMO-1605 Project: Geronimo Type: Improvement Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1, 1.0.1 Enchance geronimo.sh to display the PID of started process when Geronimo is started using geronimo.sh start or startup.sh. This is useful for developers who may have a number of Geronimo processes running. -- 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] Closed: (GERONIMO-1604) Output from deploy.sh/bat is inconsistent with other scripts - does not output info on environment variable settings (e.g. JAVA_HOME)
[ http://issues.apache.org/jira/browse/GERONIMO-1604?page=all ] John Sisson closed GERONIMO-1604: - Resolution: Fixed Output from deploy.sh/bat is inconsistent with other scripts - does not output info on environment variable settings (e.g. JAVA_HOME) - Key: GERONIMO-1604 URL: http://issues.apache.org/jira/browse/GERONIMO-1604 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Fix For: 1.0.1, 1.1 The other scripts/bat files output the following information prior to executing the command: Using GERONIMO_BASE: /home/sissonj/test/geronimo-1.0.1-SNAPSHOT Using GERONIMO_HOME: /home/sissonj/test/geronimo-1.0.1-SNAPSHOT Using GERONIMO_TMPDIR: /home/sissonj/test/geronimo-1.0.1-SNAPSHOT/var/temp Using JRE_HOME:/usr/j2se I will fix the deploy.sh and deploy.bat scripts so that they operate the same. It is worthwhile outputting this information to aid daignosis, especially for first time users. For advanced users who don't want to see this information when they use Geronimo's scripts, they can set the new environment variable GERONIMO_ENV_INFO to off (the default being on). The geronimo.bat, geronimo.sh, deploy.bat and deploy.sh files will check this environment variable. -- 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] Closed: (GERONIMO-1606) Display message indicating Geronimo is being started in another window when started with geronimo.bat start or startup.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1606?page=all ] John Sisson closed GERONIMO-1606: - Fix Version: 1.0.1 Resolution: Fixed Display message indicating Geronimo is being started in another window when started with geronimo.bat start or startup.bat -- Key: GERONIMO-1606 URL: http://issues.apache.org/jira/browse/GERONIMO-1606 Project: Geronimo Type: Improvement Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1, 1.0.1 Display a message indicating Geronimo is being started in another window in case the user does not notice that geronimo was started in another window when started with geronimo.bat start or startup.bat -- 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] Closed: (GERONIMO-1607) Allow user to specify arguments to be used on the Windows START command issued by geronimo.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1607?page=all ] John Sisson closed GERONIMO-1607: - Fix Version: 1.0.1 Resolution: Fixed Allow user to specify arguments to be used on the Windows START command issued by geronimo.bat -- Key: GERONIMO-1607 URL: http://issues.apache.org/jira/browse/GERONIMO-1607 Project: Geronimo Type: Improvement Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1, 1.0.1 Allow arguments to the Windows START command to be specified in an environment variable GERONIMO_WIN_START_ARGS. The Windows START command is used if Geronimo is started the following ways: geronimo.bat start startup.bat For example, the GERONIMO_WIN_START_ARGS environment variable could be set to /MIN to start Geronimo in a minimized window. -- 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] Closed: (GERONIMO-1609) Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1609?page=all ] John Sisson closed GERONIMO-1609: - Resolution: Fixed Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat - Key: GERONIMO-1609 URL: http://issues.apache.org/jira/browse/GERONIMO-1609 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 * Fix typo in geronimo.bat where it echos a message that it cannot find setclasspath.bat. It should read setjavaenv.bat -- 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] Closed: (GERONIMO-1612) Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh
[ http://issues.apache.org/jira/browse/GERONIMO-1612?page=all ] John Sisson closed GERONIMO-1612: - Resolution: Fixed Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh --- Key: GERONIMO-1612 URL: http://issues.apache.org/jira/browse/GERONIMO-1612 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 This was accidentally carried over from the Tomcat code the script was based upon. -- 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] Closed: (GERONIMO-1610) deploy.bat does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables
[ http://issues.apache.org/jira/browse/GERONIMO-1610?page=all ] John Sisson closed GERONIMO-1610: - Resolution: Fixed deploy.bat does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables - Key: GERONIMO-1610 URL: http://issues.apache.org/jira/browse/GERONIMO-1610 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 -- 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] Closed: (GERONIMO-1490) setjavaenv.bat is not called by deploy.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1490?page=all ] John Sisson closed GERONIMO-1490: - Resolution: Fixed setjavaenv.bat is not called by deploy.bat -- Key: GERONIMO-1490 URL: http://issues.apache.org/jira/browse/GERONIMO-1490 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Trivial Fix For: 1.0.1, 1.1 -- 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] Closed: (GERONIMO-1608) Improve Geronimo script documentation
[ http://issues.apache.org/jira/browse/GERONIMO-1608?page=all ] John Sisson closed GERONIMO-1608: - Resolution: Fixed Improve Geronimo script documentation - Key: GERONIMO-1608 URL: http://issues.apache.org/jira/browse/GERONIMO-1608 Project: Geronimo Type: Improvement Components: startup/shutdown, usability Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Trivial Fix For: 1.0.1, 1.1 * Describe relationship between geronimo.bat/sh ,startup.bat/sh and shutdown.bat/sh in the geronimo.bat/sh file * Make it clearer that users shouldn't have to edit script files just to set environment variables. They should be using the setenv.bat/sh files that are called by geronimo.bat/sh and deploy.bat/sh -- 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: [Vote] Release 1.0.0 of Eclipse Plugin?
+1 Sachin Patel wrote: Please vote on the release of the eclipse plugin for Geronimo 1.0.0. Keep in mind a update manager patch will be made available to support 1.0.1 after it is released. [+1] Release v1.0.0 of the eclipse plugin supporting G 1.0 [-1] Do not release, v1.0.0. - sachin
Re: [Vote] Release 1.0.0 of Eclipse Plugin?
+1 On Feb 23, 2006, at 3:41 PM, Sachin Patel wrote: Please vote on the release of the eclipse plugin for Geronimo 1.0.0. Keep in mind a update manager patch will be made available to support 1.0.1 after it is released. [+1] Release v1.0.0 of the eclipse plugin supporting G 1.0 [-1] Do not release, v1.0.0. - sachin
Re: Changing Trunk to 1.2 in anticipation of 1.0.1 becoming 1.1
I converted HEAD to 1.2 and updated the plugin version numbers. I also have completed merging the missing changes from the 1.0 branch into the configid branch. Finally, I renamed the configid branch to 1.1, and have updated the plugin versions in that branch also. -dain On Feb 26, 2006, at 1:31 AM, Matt Hogstrom wrote: Dain, Which part are you taking a crack at? I've done some of the HEAD work. Should I abandon that ? Matt Dain Sundstrom wrote: Matt is traveling again, so I'm going to take a crack at this. -dain On Feb 23, 2006, at 4:47 PM, Matt Hogstrom wrote: John, Life has been a travelling adventure lately so apologies for my tardy response. My thinking is as follows in order of steps: 1. Convert HEAD to 1.2 SNAPSHOT. This will be good as we need to get this story down to simply changing etc/project.properties or at least as close as possible. 2. Once HEAD is changed and building correctly hopefully Dain and David will have something to show. I know they've been bustin their chops working on this. We rename their branches/ configid to branches/1.1. We'd have to ensure that changes made to 1.0 since they started get moved into their branch and then we can delete the 1.0 branch since we have the 1.0.0.0 tag. 3. Apply the outstanding JIRA's I had previously identified. We need to figure out which ones are still important. I'd like to get the release out by the end of March. Is this clearer? Matt John Sisson wrote: Alan D. Cabrera wrote: On 2/20/2006 8:23 PM, Matt Hogstrom wrote: I was thinking that in order to expedite getting 1.1 our the door that it would make sense to move trunk to 1.2. Then we'll have to do the same in the 1.0 branch. I'm going to start working on that this week. Comments, suggestions, ? So what is in trunk now? What is in branches/1_0 now? Where is the work for 1_1 taking place? Matt, Could you please confirm the following.. AFAIK, work for the 1.1 release (that was previously going to be called the 1.0.1 release) should be done in the 1.0 branch (until we branch for 1.1?). Matt is proposing to change the version numbers in files in branches/1.0 to be 1.1. I assume you plan on doing this before we create the 1.1 branch? Once the configId changes are merged in to branches/1.0 and we are ready for a release we would create branches/1.1 from the 1.0 branch. If we are creating a 1.1 branch then does that mean there would be no further work happening in the 1.0 branch once the branch is made? Work for the 1.2 release should be done in trunk. I think Matt is proposing to change the version numbers in files in trunk to be 1.2. Are we releasing version 1.1 of all the specs for the 1.1 release? Thanks, John Regards, Alan
Re: Plugin version numbers
I have implemented the changes. -dain On 2/26/06, Dain Sundstrom [EMAIL PROTECTED] wrote: I think we have a problem with the current version numbering of plugins. We are using the following scheme to generate the version numbers: geronimo-major.geronimo-minor.plugin-build-number The first two match the geronimo version and the last is a number that is incremented with each change to the plugin (this forces maven to download the new version). I think this scheme will break as soon as we do a geronimo release that has a micro (3 dotted) revision. We haven't seen this problem yet in Geronimo but we almost saw it when we were working on geronimo 1.0.1. I propose we change to the following scheme: geronimo-major.geronimo-minor.geronimo-micro-plugin-build-number Using this scheme HEAD version plugin version numbers would be: geronimo_packaging_plugin_version=1.2.0-3 geronimo_assembly_plugin_version=1.2.0-8 geronimo_deployment_plugin_version=1.2.0-1 geronimo_dependency_plugin_version=1.2.0-1 branches/1.1 would become: geronimo_packaging_plugin_version=1.1.0-2 geronimo_assembly_plugin_version=1.1.0-8 geronimo_deployment_plugin_version=1.1.0-1 geronimo_dependency_plugin_version=1.1.0-1 We could optionally leave off the extra .0 before the dash but I think we should leave it in for clarity. I'd like to implement this quickly since the build is broken due to me changing the trunk version to 1.2 and not incrementing the plugins. So please let me know quickly if you have an issue with the changes[1]. -dain [1] We can always back the changes out but we could have published plugins that have bad version numbers, which is something I'd like to avoid.
Re: Plugin version numbers
2006/2/27, Dain Sundstrom [EMAIL PROTECTED]: I have implemented the changes. Hi Dain, Have you found an answer to John's question? -dain Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Itests in Maven2 ready !
Hi Aaron, Thanks for reminding me. Instructions on using this is needed even because it uses some bleeding edge Maven features :-) It uses yet to be released maven-site-plugin and maven-default-skins. So some amount of setup has to be done. Now that you have expressed interest, writing the doc for others to use it has jumped up the priority list. But before that a small instruction set will be posted here soon. The itests currently has some 6 testcases. They are - start/stop server, deploy/undeploy module start/stop module. They have are all wriiten as mojos. These mojos execute during the integration-test phase of the m2 cycle. The instructions will use those as examples if you choose to write plugin your own mojo. We should soon have a test using junit and bound to the test phase of the m2 cycle. That will also make a good example. Cheers Prasad On 2/24/06, Aaron Mulder [EMAIL PROTECTED] wrote: Can you post some instructions on how to add tests to this? There are a lot of places I've skipped tests because it required too much of the server to be running. Thanks, Aaron On 2/24/06, Prasad Kashyap [EMAIL PROTECTED] wrote: Thanks to Mavens, Jason Brett and Geronimo's Davids, Jencks and Blevins, the itests which were under OpenEJB earlier has now been converted to Maven2. It has also been enhanced to perform integration tests on other components and services. Other itests can now simply plug in their tests into this framework. When we move completely to Maven2, it can also be invoked during the integration phase of our build in our gbuild setup. Currently this setup is a basic testing infrastructure with a set of 6 test cases. More test cases can be plugged into it by anybody. From here, we could go just about anywhere. Some of the things we could do are : - plug in the openejb itests from the old maven1 build. - documentation about the itests subproject. - documentation for others to write and plug their own tests. - hook it up with Continuum for gbuild. - some simple feature enhancements cleanup. (some maven JIRAs have been opened for this). - publish results. awaiting a maven feature yet to be released - maven-default-skin. - (your idea goes here) - (your idea goes here) - - More ideas and participation in this are most welcome. Jacek, should I open a JIRA for this as a subtask under the M2 conversion effort ? Or should we keep this separate ? Cheers Prasad
