Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 3, 2009, at 11:47 PM, Ivan wrote: I remember that in server.xml, datasouce could be defined. While importing the xml file, shall we also need to create rar configuration for them? I doubt it. I'm currently thinking that we will keep letting geronimo construct all of the jndi context for the web app. thanks david jencks Ivan 2009/6/4 Kevan Miller kevan.mil...@gmail.com On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... --kevan -- Ivan
Re: Possible for G to directly consume a Tomcat server config w/o changes?
On Jun 3, 2009, at 10:35 PM, Kevan Miller wrote: On Jun 2, 2009, at 6:46 PM, David Jencks wrote: snip I played with something like this on the plane today. it might not take more that a couple days to get _something_ working that interprets server.xml files. It turns out there's no schema for tomcat configurations so it may be an adventure interpreting the same files they do. We might be able to copy their digester configuration but replace defaults with geronimo classes instead of tomcat classes. I find digester grammar so hard to understand however that I started by generating a schema from a sample file and modifying it to fit the digeter rules. My current idea is to have a TomcatServerGBean that has a server.xml as an attribute, which it reads into a jaxb tree, which we call a construct(ClassLoader cl) method on to set up the tomcat objects. If this works it should be fairly easy no idea if it will actually work though. Next step would be a builder that, given a server.xml, sets up such a gbean. Sounds interesting. IIUC, this embedded Tomcat instance replaces our current embedded Tomcat. It improves our ability to configure this instance -- it's native Tomcat config. Are you thinking about all configuration files? E.g. WEB-INF/ context.xml, conf/context.xml? There are catalina.policy, catalina.properties, tomcat-users.xml, also. Hmm. gets a little messier... I have enough working now so I can run the admin console on a server set up this way. I haven't looked at any files other than server.xml yet. Some like tomcat-users.xml are for a security realm we aren't going to use or, probably, support using. Not sure about the others. thanks david jencks --kevan
[jira] Updated: (GERONIMO-4674) Need a sample about developing applications on Geronimo with AJAX and JSF
[ https://issues.apache.org/jira/browse/GERONIMO-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ying Tang updated GERONIMO-4674: Summary: Need a sample about developing applications on Geronimo with AJAX and JSF (was: Need to document how to develop applications on Geronimo with AJAX and JSF) Need a sample about developing applications on Geronimo with AJAX and JSF - Key: GERONIMO-4674 URL: https://issues.apache.org/jira/browse/GERONIMO-4674 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: documentation Affects Versions: 2.1, 2.2 Reporter: Ying Tang Priority: Minor Fix For: 2.2 Need to write a sample application using AJAX and JSF. http://cwiki.apache.org/confluence/display/GMOxDOC22/Developing+applications+with+AJAX+and+JSF -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [BUILD] trunk: Failed for Revision: 779702
Hi everyone, Please use this patch to disable the dependencies change
checking until the problem is resolved.
On Fri, May 29, 2009 at 10:20 PM, Ivan xhh...@gmail.com wrote:
In the dependencies.removed.xml file, it wrote that xbean-finder shoud be
removed.
I attached the treeListing.xml file.
Ivan
2009/5/29 David Jencks david_jen...@yahoo.com
On May 29, 2009, at 9:45 AM, Shawn Jiang wrote:
I'm looking for a way to shutdown the dependencies checking because I saw:
- keeps historical dependencies in src/main/history/dependencies.xml
- if the file is missing, it creates it with current dependency info
- if the file is there, it compares with current dependency info and
if it's changed writes out dependences.added.xml and
dependencies.removed.xml
- *by default it fails on changes, although this can be turned off.*
- respects current useTransitiveDependencies flag setting.
in https://issues.apache.org/jira/browse/GERONIMO-4248. Is there a way
to turn off the default fail behavior temporarily ?
I do
find . -name dependencies.xml | xargs rm
but I prefer to find and fix the cause. If someone could send me the
dependencies.*.xml and treeListing.xml files from one of these failed client
builds I'd appreciate it.
thanks
david jencks
On Fri, May 29, 2009 at 8:05 PM, Ivan xhh...@gmail.com wrote:
I tried it on the tck machine, got the same error :-(
2009/5/29 Joe Bohn joe.b...@earthlink.net
Building openejb didn't change the result on my system. I'm not sure why
we are seeing different results.
Joe
Joe Bohn wrote:
No, I didn't build openejb so perhaps that is the difference. I'll
give it a try. If it works I guess it would be helpful to get a new
snapshot of openejb published.
Joe
David Jencks wrote:
On May 28, 2009, at 8:53 PM, Joe Bohn wrote:
I'm hitting this same failure on my mac. Perhaps you have something
different in your local repo ... perhaps an older private build of
xbean? I
hit it after updating xbean trunk, rebuilding xbean, and then rebuilding
Geronimo. Mine shows that xbean-finder is no longer a dependency of the
client plugin.
IIRC I built xbean, openejb, and then geronimo without problems. Did
you build openejb?
thanks
david jencks
Joe
David Jencks wrote:
I'm not seeing this error and can't figure out how to see the files
indicating the problem.
Is there any documentation about how these builds work? A short
description on
http://cwiki.apache.org/confluence/display/GMOxDEV/would be great.
Do we also run builds on the tck machines? Are the results there
accessible to, well, me?
thanks
david jencks
On May 28, 2009, at 2:36 PM, ga...@apache.org wrote:
Geronimo Revision: 779702 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090528/build-1500.log
See the unit test reports at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090528/unit-test-reports
[INFO]
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/client/geronimo-client/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 5 source files to
/home/geronimo/geronimo/trunk/plugins/client/geronimo-client/target/classes
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/home/geronimo/geronimo/trunk/plugins/client/geronimo-client/src/test/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/geronimo/geronimo/trunk/plugins/client/geronimo-client/target/surefire-reports
---
T E S T S
---
There are no tests to run.
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
/home/geronimo/geronimo/trunk/plugins/client/geronimo-client/target/geronimo-client-2.2-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: geronimo-client-2.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
/home/geronimo/geronimo/trunk/plugins/client/geronimo-client/target/geronimo-client-2.2-SNAPSHOT.jar
to
/home/geronimo/.m2/repository/org/apache/geronimo/modules/geronimo-client/2.2-SNAPSHOT/geronimo-client-2.2-SNAPSHOT.jar
[INFO]
[jira] Commented: (GERONIMO-4671) Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly
[ https://issues.apache.org/jira/browse/GERONIMO-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716533#action_12716533 ] Ralf Baumhof commented on GERONIMO-4671: As in geronimo 2.1.3 the datasource was configured through console dialog. During deployment the first exception is thrown. Error on Oracle XA Datasource deployment or server startup thow the datasource works correctly -- Key: GERONIMO-4671 URL: https://issues.apache.org/jira/browse/GERONIMO-4671 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: persistence Affects Versions: 2.1.4 Environment: java 1.6 update 14, windows Reporter: Ralf Baumhof Priority: Minor We have configured oracle xa datasource with the following settings (see also http://www.nabble.com/Configure-Oracle-XA-Datasource-with-Oracle-XE-(10g-Express)-in-console-dialog-to23707396s134.html#a23858245) User Name: oracleuser(schema name) Service Name: xe Password:XXX Confirm Password: XXX Port:1521 Data Source Name: oracle.jdbc.xa.client.OracleXADataSource Network Protocol: TCP Database Name: xe TNS Entry Name: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(Host = localhost)(Port = 1521))(CONNECT_DATA = (SID = xe))) Driver Type: thin Server Name: localhost The datasource works, and with geronimo 2.1.3 (java 1.5 update 16 on windows, linux) no errors have been reported. Now we are switching to geronimo 2.1.4 and during deployment an exception is thrown. This exception is also thrown on every server startup. Exception during deployment: Geronimo Application Server started 2009-06-03 21:09:45,921 WARN [XSRFHandler] Blocked due to invalid HttpServletRe quest parameter. 2009-06-03 21:09:45,921 ERROR [XSSXSRFFilter] XSSXSRFFilter blocked HttpServletR equest due to invalid FORM content. 2009-06-03 21:12:57,468 ERROR [RecoveryController] Recovery error javax.transaction.xa.XAException at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:705) at org.apache.geronimo.transaction.manager.WrapperNamedXAResource.recove r(WrapperNamedXAResource.java:74) at org.apache.geronimo.transaction.manager.RecoveryImpl.recoverResourceM anager(RecoveryImpl.java:98) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.recove rResourceManager(TransactionManagerImpl.java:352) at org.apache.geronimo.connector.outbound.AbstractConnectionManager.doRe covery(AbstractConnectionManager.java:70) at org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrappe r.doStart(ManagedConnectionFactoryWrapper.java:166) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanI nstance.java:998) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.j ava:541) at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GB eanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDepe ndency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDepe ndency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEve nt(BasicLifecycleMonitor.java:176) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(Bas icLifecycleMonitor.java:44) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBr oadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart (GBeanInstanceState.java:294) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInsta nceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(G BeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanI nstance.java:555) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(Basi cKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguratio nGBeans(ConfigurationUtil.java:456) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(Ke rnelConfigurationManager.java:188) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCon figuration(SimpleConfigurationManager.java:563) at
[jira] Created: (GERONIMO-4675) Duplicate Key in config-substitutions.properties
Duplicate Key in config-substitutions.properties Key: GERONIMO-4675 URL: https://issues.apache.org/jira/browse/GERONIMO-4675 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: common, documentation, general Affects Versions: 2.1.4 Reporter: Christian Burger Duplicate Key in config-substitutions.properties: ClusterName=DEFAULT_CLUSTER AND clusterName=CLUSTER_NAME Different cases! But if it's the same key, you should probably remove one and correct the code correspondingly, or? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4676) Incorrect USAGE_MSG of cxf-tools script
Incorrect USAGE_MSG of cxf-tools script
---
Key: GERONIMO-4676
URL: https://issues.apache.org/jira/browse/GERONIMO-4676
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: commands
Affects Versions: 2.2
Environment: Ubuntu 8.0.4+JDK 1.6.0
Reporter: Chi Runhua
1. run ./cxf-tools.sh in terminal;
2. Usage of cxf-tools shows up as followed:
{color:white}
{noformat:borderStyle=solid|bgColor=#00}
Usage: jaxws-tools toolName tool options
where toolName is:
java2ws - generate portable artifacts from class
wsdl2java - generate portable artifacts from WSDL
{noformat}
{color}
I'm providing a patch for this issue. please help to commit if it's correct.
Jeff C
Expected result: the message should be
Usage: {color:red}cxf-tools{color} toolName tool options
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4676) Incorrect USAGE_MSG of cxf-tools script
[
https://issues.apache.org/jira/browse/GERONIMO-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chi Runhua updated GERONIMO-4676:
-
Attachment: GERONIMO-4676.patch
Incorrect USAGE_MSG of cxf-tools script
---
Key: GERONIMO-4676
URL: https://issues.apache.org/jira/browse/GERONIMO-4676
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.2
Environment: Ubuntu 8.0.4+JDK 1.6.0
Reporter: Chi Runhua
Attachments: GERONIMO-4676.patch
1. run ./cxf-tools.sh in terminal;
2. Usage of cxf-tools shows up as followed:
{color:white}
{noformat:borderStyle=solid|bgColor=#00}
Usage: jaxws-tools toolName tool options
where toolName is:
java2ws - generate portable artifacts from class
wsdl2java - generate portable artifacts from WSDL
{noformat}
{color}
I'm providing a patch for this issue. please help to commit if it's correct.
Jeff C
Expected result: the message should be
Usage: {color:red}cxf-tools{color} toolName tool options
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4677) GShell jaxws commands should provide help in a uniform way
GShell jaxws commands should provide help in a uniform way -- Key: GERONIMO-4677 URL: https://issues.apache.org/jira/browse/GERONIMO-4677 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.2 Environment: Geronimo 2.2 + Windows XP + Sun JDK 1.6.0 Reporter: Ying Tang Priority: Trivial Fix For: 2.2 All GShell commands except jaxws/wsgen, jasws/java2ws, jaxws/wsdl2java, and jaxws/wsimport, provide help in this way: -h or --help. For example: deploy/deploy --help deploy/deploy -h But jaxws commands only support -h or -help. If you use jasws/java2ws --help, an error will occur: Unexpected option: --help. This might be a little inconvenient for users. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4676) Incorrect USAGE_MSG of cxf-tools script
[
https://issues.apache.org/jira/browse/GERONIMO-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chi Runhua updated GERONIMO-4676:
-
Description:
1. run ./cxf-tools.sh in terminal;
2. Usage of cxf-tools shows up as followed:
{color:white}
{noformat:borderStyle=solid|bgColor=#00}
Usage: jaxws-tools toolName tool options
where toolName is:
java2ws - generate portable artifacts from class
wsdl2java - generate portable artifacts from WSDL
{noformat}
{color}
Expected result: the message should be
Usage: {color:red}cxf-tools{color} toolName tool options
I'm providing a patch for this issue. please help to commit if it's correct.
Jeff C
was:
1. run ./cxf-tools.sh in terminal;
2. Usage of cxf-tools shows up as followed:
{color:white}
{noformat:borderStyle=solid|bgColor=#00}
Usage: jaxws-tools toolName tool options
where toolName is:
java2ws - generate portable artifacts from class
wsdl2java - generate portable artifacts from WSDL
{noformat}
{color}
I'm providing a patch for this issue. please help to commit if it's correct.
Jeff C
Expected result: the message should be
Usage: {color:red}cxf-tools{color} toolName tool options
Priority: Minor (was: Major)
Incorrect USAGE_MSG of cxf-tools script
---
Key: GERONIMO-4676
URL: https://issues.apache.org/jira/browse/GERONIMO-4676
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.2
Environment: Ubuntu 8.0.4+JDK 1.6.0
Reporter: Chi Runhua
Priority: Minor
Attachments: GERONIMO-4676.patch
1. run ./cxf-tools.sh in terminal;
2. Usage of cxf-tools shows up as followed:
{color:white}
{noformat:borderStyle=solid|bgColor=#00}
Usage: jaxws-tools toolName tool options
where toolName is:
java2ws - generate portable artifacts from class
wsdl2java - generate portable artifacts from WSDL
{noformat}
{color}
Expected result: the message should be
Usage: {color:red}cxf-tools{color} toolName tool options
I'm providing a patch for this issue. please help to commit if it's correct.
Jeff C
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4675) Duplicate Key in config-substitutions.properties
[ https://issues.apache.org/jira/browse/GERONIMO-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Burger updated GERONIMO-4675: --- Priority: Minor (was: Major) Duplicate Key in config-substitutions.properties Key: GERONIMO-4675 URL: https://issues.apache.org/jira/browse/GERONIMO-4675 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: common, documentation, general Affects Versions: 2.1.4 Reporter: Christian Burger Priority: Minor Duplicate Key in config-substitutions.properties: ClusterName=DEFAULT_CLUSTER AND clusterName=CLUSTER_NAME Different cases! But if it's the same key, you should probably remove one and correct the code correspondingly, or? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 2.2 docs index confusion?
Hi all, Can someone help trigger the export for Confluence documents periodically? Or do we need a script to build documents every day ? If possible, I may help with this task. Best Regards, Ying Tang 2009/1/5 Ying Tang yingtang1...@gmail.com Thanks, Donald. It worked well after the autoexport. Unfortunately we found that our latest changes did not appear on that index page Maybe we have to manually trigger the autoexport from time to time? 2009/1/1 Donald Woods dwo...@apache.org I just manually ran the autoexport plugin on GMOxDOC22, so give it 1-2 hours to see if the static webpages reflect the live Confluence content... -Donald Ying Tang wrote: From this page http://cwiki.apache.org/, we were told that the index page http://cwiki.apache.org/GMOxDOC22/ http://cwiki.apache.org/GMOxDOC22/ was last modified on Nov 19, 2008. The index page is in fact a link to the documentation page http://cwiki.apache.org/confluence/display/GMOxDOC22/Documentation. All changes to the documentation page after Nov 19 are not available on the index page. We guess this index page cannot be updated by Confluence automatically, as it is a copy on the server. Maybe someone can help trigger the build on the server, so that the latest changes will take effect. 2008/12/31 chi runhua chirun...@gmail.com mailto:chirun...@gmail.com Looks like the wiki server keeps 2 copies of GMOXDOC22, changes of doc structure was not synchronized. Jeff On Wed, Dec 31, 2008 at 7:33 AM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: I''m confused. Starting on http://cwiki.apache.org/GMOxDOC22/ I see... # * Custom server assemblies o Buidling,installing plugins and extracting a server from an exsiting server o Assembling a server using Maven but the link for the first line shows a sub-index that doesn't include either of the items beneath it, it has 3 unrelated entries. ??? More seriously when I try to edit the page http://cwiki.apache.org/GMOxDOC22/buidlinginstalling-plugins-and-extracting-a-server-from-an-exsiting-server.htmlto correct the spelling I get to the page http://cwiki.apache.org/confluence/pages/editpage.action?pageId=101843 which is Assembling a server via command line ??? ??? ??? thanks david jencks
Compiling current GEP 2.2 version
Sorry for cross-posting, I have posted that in the user-group before. I try to compile the current GEP 2.2 source against the Elicpse 3.5 RC2. On compilation I get, when the tests are enabled, the errors below. It seems those packages needed for geronimo 2.0.2 are not longer available on the maven repositories. Are those packages available somwhere for manual download? Best regards, Johannes [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.ws.scout:jaxr-api:jar:SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.ws.scout -DartifactId=jaxr-api -Dversion=SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.ws.scout -DartifactId=jaxr-api -Dversion=SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 2) org.apache.geronimo.assemblies:geronimo-tomcat6-jee5:zip:bin:2.0.2 3) org.apache.geronimo.configs:axis:car:2.0.2 4) org.apache.ws.scout:scout:jar:1.0rc1 5) org.apache.ws.scout:jaxr-api:jar:SNAPSHOT 2) org.apache.tomcat:catalina:jar:6.0.13-G543818 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=catalina -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=catalina -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 2) org.apache.geronimo.assemblies:geronimo-tomcat6-jee5:zip:bin:2.0.2 3) org.apache.geronimo.configs:tomcat6:car:2.0.2 4) org.apache.geronimo.modules:geronimo-tomcat6:jar:2.0.2 5) org.apache.tomcat:catalina:jar:6.0.13-G543818 3) org.apache.tomcat:jasper:jar:6.0.13-G543818 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=jasper -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=jasper -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 2) org.apache.geronimo.assemblies:geronimo-tomcat6-jee5:zip:bin:2.0.2 3) org.apache.geronimo.configs:jasper:car:2.0.2 4) org.apache.tomcat:jasper:jar:6.0.13-G543818 -- 3 required artifacts are missing. for artifact: org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository/), java.net (http://download.java.net/maven/1/), releases.openqa.org (http://archiva.openqa.org/repository/releases), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), snapshots.openqa.org (http://archiva.openqa.org/repository/snapshots), codehaus-snapshots (http://snapshots.repository.codehaus.org) Am 20.05.2009 17:10, schrieb Jack Cai: Yes we will be looking at this. -Jack 2009/5/19 Johannes Weberhofer, Weberhofer GmbH off...@weberhofer.at mailto:off...@weberhofer.at The first release candidate of Eclipse 3.5 has been released. Are there any plans to support this version with the Plugin in the near future? Best regards, Johannes Weberhofer -- |- | weberhofer GmbH | Johannes Weberhofer | information technologies | Austria, 1080 Wien, Blindengasse 52/3 | | Firmenbuch: 225566s, Handelsgericht Wien | UID: ATU55277701 | | phone : +43 (0)1 5454421 0| email: off...@weberhofer.at | fax : +43 (0)1 5454421 19 | web : http://weberhofer.at | mobile: +43 (0)699 11998315 |---
[jira] Updated: (GERONIMODEVTOOLS-576) Can't find setManagedForm sysbol error when build GEP 2.2.0 trunk
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMODEVTOOLS-576: -- Attachment: ServerPluginPage.patch Can't find setManagedForm sysbol error when build GEP 2.2.0 trunk - Key: GERONIMODEVTOOLS-576 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-576 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: os:win2003 Reporter: viola.lu Assignee: Tim McConnell Attachments: ServerPluginPage.patch 1.Build GEP 2.2.0 trunk, and in file $GEP \plugins\org.apache.geronimo.st.v21.ui\src\main\java\org\apache\geronimo\st\v21\ui\pages\ServerPluginPage.java there is a setMangedForm method not existing. So build failure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-576) Can't find setManagedForm sysbol error when build GEP 2.2.0 trunk
Can't find setManagedForm sysbol error when build GEP 2.2.0 trunk - Key: GERONIMODEVTOOLS-576 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-576 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: os:win2003 Reporter: viola.lu Assignee: Tim McConnell Attachments: ServerPluginPage.patch 1.Build GEP 2.2.0 trunk, and in file $GEP \plugins\org.apache.geronimo.st.v21.ui\src\main\java\org\apache\geronimo\st\v21\ui\pages\ServerPluginPage.java there is a setMangedForm method not existing. So build failure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Compiling current GEP 2.2 version
OK, svn up your copy of devtools trunk and try it again. I added a repo pointer to the private repo in the 2.0.2 Server svn tag (which contains the 2 Tomcat jars) and added the missing scout depends. You may need to delete any existing org/apache/ws/scout/jax-api artifacts from your local .m2 repo or just replace them with the ones from - https://svn.apache.org/repos/asf/geronimo/server/tags/2.0.2/repository/ as the externally published pom has an incorrect dependency on jaxr-api-SANPSHOT which is no longer available (instead of 1.0rc1 as the updated copy in the 2.0.2 repo). -Donald Johannes Weberhofer, Weberhofer GmbH wrote: Sorry for cross-posting, I have posted that in the user-group before. I try to compile the current GEP 2.2 source against the Elicpse 3.5 RC2. On compilation I get, when the tests are enabled, the errors below. It seems those packages needed for geronimo 2.0.2 are not longer available on the maven repositories. Are those packages available somwhere for manual download? Best regards, Johannes [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.ws.scout:jaxr-api:jar:SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.ws.scout -DartifactId=jaxr-api -Dversion=SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.ws.scout -DartifactId=jaxr-api -Dversion=SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 2) org.apache.geronimo.assemblies:geronimo-tomcat6-jee5:zip:bin:2.0.2 3) org.apache.geronimo.configs:axis:car:2.0.2 4) org.apache.ws.scout:scout:jar:1.0rc1 5) org.apache.ws.scout:jaxr-api:jar:SNAPSHOT 2) org.apache.tomcat:catalina:jar:6.0.13-G543818 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=catalina -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=catalina -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 2) org.apache.geronimo.assemblies:geronimo-tomcat6-jee5:zip:bin:2.0.2 3) org.apache.geronimo.configs:tomcat6:car:2.0.2 4) org.apache.geronimo.modules:geronimo-tomcat6:jar:2.0.2 5) org.apache.tomcat:catalina:jar:6.0.13-G543818 3) org.apache.tomcat:jasper:jar:6.0.13-G543818 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.tomcat -DartifactId=jasper -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=jasper -Dversion=6.0.13-G543818 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 2) org.apache.geronimo.assemblies:geronimo-tomcat6-jee5:zip:bin:2.0.2 3) org.apache.geronimo.configs:jasper:car:2.0.2 4) org.apache.tomcat:jasper:jar:6.0.13-G543818 -- 3 required artifacts are missing. for artifact: org.apache.geronimo.devtools:testsuite-eclipse:pom:2.2.0 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.incubator (http://people.apache.org/repo/m2-incubating-repository/), java.net (http://download.java.net/maven/1/), releases.openqa.org (http://archiva.openqa.org/repository/releases), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), snapshots.openqa.org (http://archiva.openqa.org/repository/snapshots), codehaus-snapshots (http://snapshots.repository.codehaus.org) Am 20.05.2009 17:10, schrieb Jack Cai: Yes we will be looking at this. -Jack 2009/5/19 Johannes Weberhofer, Weberhofer GmbH off...@weberhofer.at mailto:off...@weberhofer.at The first release candidate of Eclipse 3.5 has been released. Are there any plans to support this version with the Plugin in the near future? Best regards, Johannes Weberhofer
[jira] Updated: (GERONIMO-3389) console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR HTTP Connector
[ https://issues.apache.org/jira/browse/GERONIMO-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-3389: --- Patch Info: [Patch Available] Fix Version/s: 2.2 2.1.5 console: java.lang.UnsatisfiedLinkError is thrown when create a Tomcat APR HTTP Connector - Key: GERONIMO-3389 URL: https://issues.apache.org/jira/browse/GERONIMO-3389 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: documentation, Tomcat Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.1.x, 2.2 Environment: Windows xp sp2, IE, Firefox Reporter: Song Assignee: Shawn Jiang Fix For: 2.1.5, 2.2 Attachments: G3389_g21.patch, G3389_trunk.patch Click on Save button after entering all necessary parameters for creating a new Tomcat APR HTTP Connector test_APR_HTTP, it returned to the Network Listeners list page. However,the Protocol for test_APR_HTTP is empty, State is failed. And java.lang.UnsatisfiedLinkError is thrown from the server started console and server.log. Same error to creating Tomcat APR HTTPS Connetor. Detailed error as below: -- 13:33:46,515 WARN [ConnectorGBean] test_APR_HTTP connector failed 13:33:46,515 ERROR [Connector] Coyote connector has not been started 13:33:46,515 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0-SNAPSHOT/car,j2eeType=GBean,name=test_APR_HTTP java.lang.UnsatisfiedLinkError: org/apache/tomcat/jni/Pool.create(J)J at org.apache.tomcat.util.net.AprEndpoint.init(AprEndpoint.java:579) at org.apache.coyote.http11.Http11AprProtocol.init(Http11AprProtocol.java:121) at org.apache.catalina.connector.Connector.initialize(Connector.java:1059) at org.apache.catalina.core.StandardService.addConnector(StandardService.java:267) at org.apache.catalina.startup.Embedded.addConnector(Embedded.java:327) at org.apache.geronimo.tomcat.TomcatContainer.addConnector(TomcatContainer.java:383) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$fa3733e1.addConnector(generated) at org.apache.geronimo.tomcat.connector.ConnectorGBean.doStart(ConnectorGBean.java:95) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java:365) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.connector.Http11APRProtocol$$EnhancerByCGLIB$$abc46ac2.startRecursive(generated) at org.apache.geronimo.console.webmanager.ConnectorPortlet.processAction(ConnectorPortlet.java:146) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at
Re: 2.2 docs index confusion?
I just triggered an export. Unfortunately, this can only be done by a Confluence Admin Not sure why it's not happening after edits. Have you verified that the following location is updated within a couple minutes after editing, which is the autoexport stagging location, before the files are copied to the normal docs location? http://cwiki.apache.org/GMOxDOC22/ -Donald Ying Tang wrote: Hi all, Can someone help trigger the export for Confluence documents periodically? Or do we need a script to build documents every day ? If possible, I may help with this task. Best Regards, Ying Tang 2009/1/5 Ying Tang yingtang1...@gmail.com mailto:yingtang1...@gmail.com Thanks, Donald. It worked well after the autoexport. Unfortunately we found that our latest changes did not appear on that index page Maybe we have to manually trigger the autoexport from time to time? 2009/1/1 Donald Woods dwo...@apache.org mailto:dwo...@apache.org I just manually ran the autoexport plugin on GMOxDOC22, so give it 1-2 hours to see if the static webpages reflect the live Confluence content... -Donald Ying Tang wrote: From this page http://cwiki.apache.org/, we were told that the index page http://cwiki.apache.org/GMOxDOC22/ http://cwiki.apache.org/GMOxDOC22/ was last modified on Nov 19, 2008. The index page is in fact a link to the documentation page http://cwiki.apache.org/confluence/display/GMOxDOC22/Documentation. All changes to the documentation page after Nov 19 are not available on the index page. We guess this index page cannot be updated by Confluence automatically, as it is a copy on the server. Maybe someone can help trigger the build on the server, so that the latest changes will take effect. 2008/12/31 chi runhua chirun...@gmail.com mailto:chirun...@gmail.com mailto:chirun...@gmail.com mailto:chirun...@gmail.com Looks like the wiki server keeps 2 copies of GMOXDOC22, changes of doc structure was not synchronized. Jeff On Wed, Dec 31, 2008 at 7:33 AM, David Jencks david_jen...@yahoo.com mailto:david_jen...@yahoo.com mailto:david_jen...@yahoo.com mailto:david_jen...@yahoo.com wrote: I''m confused. Starting on http://cwiki.apache.org/GMOxDOC22/ I see... # * Custom server assemblies o Buidling,installing plugins and extracting a server from an exsiting server o Assembling a server using Maven but the link for the first line shows a sub-index that doesn't include either of the items beneath it, it has 3 unrelated entries. ??? More seriously when I try to edit the page http://cwiki.apache.org/GMOxDOC22/buidlinginstalling-plugins-and-extracting-a-server-from-an-exsiting-server.html to correct the spelling I get to the page http://cwiki.apache.org/confluence/pages/editpage.action?pageId=101843 which is Assembling a server via command line ??? ??? ??? thanks david jencks
[jira] Updated: (GERONIMODEVTOOLS-576) Can't find setManagedForm error when build GEP 2.2.0 trunk
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMODEVTOOLS-576: -- Summary: Can't find setManagedForm error when build GEP 2.2.0 trunk (was: Can't find setManagedForm sysbol error when build GEP 2.2.0 trunk) Can't find setManagedForm error when build GEP 2.2.0 trunk -- Key: GERONIMODEVTOOLS-576 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-576 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: os:win2003 Reporter: viola.lu Assignee: Tim McConnell Attachments: ServerPluginPage.patch 1.Build GEP 2.2.0 trunk, and in file $GEP \plugins\org.apache.geronimo.st.v21.ui\src\main\java\org\apache\geronimo\st\v21\ui\pages\ServerPluginPage.java there is a setMangedForm method not existing. So build failure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-576) Can't find setManagedForm error when build GEP 2.2.0 trunk
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716641#action_12716641 ] Delos Dai commented on GERONIMODEVTOOLS-576: I build the trunk code, with no problem in ServerPluginPage.java. The method setMangedForm is in its parent class ServerEditorPart. I'm not clear why you failed. Maybe you can try to clean it again, and paste your build log. Thanks! Can't find setManagedForm error when build GEP 2.2.0 trunk -- Key: GERONIMODEVTOOLS-576 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-576 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0 Environment: os:win2003 Reporter: viola.lu Assignee: Tim McConnell Attachments: ServerPluginPage.patch 1.Build GEP 2.2.0 trunk, and in file $GEP \plugins\org.apache.geronimo.st.v21.ui\src\main\java\org\apache\geronimo\st\v21\ui\pages\ServerPluginPage.java there is a setMangedForm method not existing. So build failure. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMODEVTOOLS-575) GEP errors that are logged to the Eclipse error log are not always seen by end-user
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716658#action_12716658 ] Tim McConnell commented on GERONIMODEVTOOLS-575: After looking at this problem more thoroughly I think I finally see what's going on. Ideally as a best practice the GEP should strive to convey error and/or exception messages (to the end user) in a consistent manner when interactions with the Geronimo server are involved. Unfortunately, this is not the case as there seems to be multiples paths in the GEP that entail interactions with the server that do not handle exceptions in a consistent, well-behaved manner. A relatively good implementation of a usage scenario is when artifacts get deployed/undeployed to the server. The GEP in most cases throws CoreExceptions (with nested exceptions and statuses) that results in a Problem Occurred dialog with detailed information about the problem/exception. One nice aspect of this approach is that it is fairly standard in Eclipse and is the same approach used by WTP. Although this is the best example in the GEP, even this implementation is far from perfect; there are at least three scenarios that are not handled correctly. One is the case where WAR file can be deployed to the server that results in deployment errors that are not conveyed to the end-user -- they are only written to the Eclipse Error log file. The other case is the GERONIMODEVTOOLS-575 JIRA just opened where a WAR file without a geroniom-web.xml not only doesn't deploy, it doesn't convey anything to the end-user (not good), nor does it write anything to the Eclipse Error log file. The third is the case where a Target Module ID cannot be found on the server (i.e., TargetModuleIdNotFoundException) and is essentially ignored by the GEP (again not good). Two other scenarios that involve interactions with the Geronimo server seem to be inconsistently implemented. Errors starting and/or stopping the server don't do much other than log exceptions to the Eclipse error log and depends upon WTP to throw the CoreException. But these CoreExceptions are too generic to be of much value to the end-user. This can be seen when we try to start the server with incorrect security credentials. The CoreException just conveys that the server failed to start, which is all that WTP about knows. The GEP knows the root cause but only writes it to Eclipse Error log, which is not normally visible to the end-user. Similarly, errors connecting and/or disconnecting to/from the server are inconsistently handled which makes diagnosis somewhat confusing or problematic for the end-user. My recommendation is that we refactor the code that interacts with the Geronimo server to consistently throw CoreExceptions (with nested Exceptions and MultiStatus objects) and open Error Dialogs when anything needs to be conveyed to the end-user. As noted above we do some of this already, but not well-enough. Of the three typical usage scenarios I've mentioned (connecting/disconnecting, starting/stopping, deploying/undeploying) I would think that starting/stopping the server would be the easiest and most straightforward. This is just a guess at this point though. Once that is accomplished I think that doing the same for the connecting/disconnecting scenarios would be fairly easy, and hopefully we'd learn enough to then plug the existing holes in the deploying/undeploying scenarios. Then finally as a last resort, if there are cases where it is just impossible to throw a CoreExcpetion (and display an Error Dialog) to convey information to the end-user we can then exercise the new code that I just recently added to the GEP to display the Eclipse Error log. GEP errors that are logged to the Eclipse error log are not always seen by end-user --- Key: GERONIMODEVTOOLS-575 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-575 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.2.0, 2.1.4 Reporter: Tim McConnell Assignee: Tim McConnell For example, when deploying an erroneous war file to the Geronimo server will result in the following to the Eclispe.log that the end-user may not likely see. !ENTRY org.apache.geronimo.st.core 4 0 2009-05-31 15:09:17.859 !MESSAGE Distribution of module failed. See log for details. !SUBENTRY 1 org.apache.geronimo.st.core 4 0 2009-05-31 15:09:17.859 !MESSAGE Unable to resolve resource reference 'jdbc/users' (Could not auto-map to resource. Try adding a resource-ref mapping to your Geronimo deployment plan. !SUBENTRY 1 org.apache.geronimo.st.core 4 0 2009-05-31 15:09:17.859 !MESSAGE Search conducted in
