[BUILD] trunk: Failed for Revision: 794973
Geronimo Revision: 794973 built with tests included See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090717/build-0300.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090717/unit-test-reports -- 1 required artifact is missing. for artifact: org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) jtidy:jtidy:jar:8.0-20060801 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT 2) jtidy:jtidy:jar:8.0-20060801 -- 1 required artifact is missing. for artifact: org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) jtidy:jtidy:jar:8.0-20060801 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT 2) jtidy:jtidy:jar:8.0-20060801 -- 1 required artifact is missing. for artifact: org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT from the specified remote repositories: ibiblio.org (http://repo.exist.com/maven2), apache.snapshots (http://repository.apache.org/snapshots), codehaus.snapshots (http://snapshots.repository.codehaus.org) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1417) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:407) at org.apache.ma
[jira] Commented: (GERONIMO-4748) Security context is not cleared before the thread is returned to the pool for Tomcat
[ https://issues.apache.org/jira/browse/GERONIMO-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732347#action_12732347 ] David Jencks commented on GERONIMO-4748: For 2.2, rev 794963 simplifies default subject handling. AFAICT a subject is always set on the thread before the request is handled and removed after it's handled, so I don't see how there can be a problem with subjects left associated with threads. There are some additional problems with secure web service clients that I'm looking into but there should be no intermittent failures. > Security context is not cleared before the thread is returned to the pool for > Tomcat > > > Key: GERONIMO-4748 > URL: https://issues.apache.org/jira/browse/GERONIMO-4748 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.1.5, 2.2 >Reporter: Ivan >Assignee: David Jencks >Priority: Critical > Fix For: 2.1.5, 2.2 > > > We do some authentication in the TomcatGeronimoRealm, and set the security > context, but it is not cleared later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: branches/2.1 update
OK. Changes are committed. See GERONIMO-4751. All JUnit tests and testsuites were passing for me. Would be great for other people to try it out. --kevan On Jul 16, 2009, at 2:35 AM, Jack Cai wrote: +1 for the Tomcat upgrade and a 2.1.5 release. -Jack On Thu, Jul 16, 2009 at 5:05 AM, Kevan Miller wrote: On Jul 15, 2009, at 4:59 PM, Donald Woods wrote: +1 to a 2.1.5 release with Tomcat 6.0.20, which contains several security fixes. 0 for moving to Genesis 2.0, since we have yet to publish a server release with it Ya. I was thinking that we might want it for new Nexus repository setup. I might not have been thinking too clearly... --kevan
[jira] Closed: (GERONIMO-4751) Upgrade 2.1.x to Tomcat 6.0.20
[ https://issues.apache.org/jira/browse/GERONIMO-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller closed GERONIMO-4751. -- Resolution: Fixed Fix Version/s: 2.1.5 Committed updates. Builds and all testsuite tests passed. Please give it a try. Would be great if someone could kick off a branches/2.1 tck run... > Upgrade 2.1.x to Tomcat 6.0.20 > -- > > Key: GERONIMO-4751 > URL: https://issues.apache.org/jira/browse/GERONIMO-4751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller >Assignee: Kevan Miller > Fix For: 2.1.5 > > > We need to upgrade our branches/2.1 to use Tomcat 6.0.20. As we do this, we > should move to the new Geronimo External generated version. Rather than > create a new private repo version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ApacheCon '09 Geronimo Track Call for Papers
This years ApacheCon US Conference (Oakland, CA, USA - Nov 2 to 6 2009) will include a 1/2 day Geronimo Track. This is a call for session proposals. Please have submissions in by Monday 12 Noon EDT. We need to finalize the session contents early next week. Apache Geronimo is a lightweight, flexible, component-based server for building dynamic application server environments. Geronimo plugins can be assembled into a fully compliant Java EE Server. However, it can be easily assembled into a server providing a subset of functionality or a minimal subset required to meet the requirements of a set of applications. In addition to the Apache Geronimo Server, the Geronimo project is also comprised of a number of subprojects: Development Tools, XBean, Yoko, GShell, JavaMail, Connector/Transaction, etc. Potential topics for the Geronimo Track include, but are in no way limited to: * Geronimo architecture, * Systems management, * Custom server assemblies, * Application development and user experiences, * OSGi Blueprint, * Kernel restructuring, * Java EE 6, * etc. Please submit Talk proposals on this mail thread. Each suggestion should include: * Title * Speaker name(s) * Abstract (Short overview of the talk contents) Thanks! Look forward to seeing you at ApacheCon! --kevan
Re: Error: "unable to find valid certification path to requested target"
I would recommend reading/looking at http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug and enabling SSL debugging. That should tell you what exactly is going, which keystore is being used, etc. I agree with David that probably the client doesn't recognize/trust the ldap server's certificate. You'll need to import it into the right keystore. I'm pretty sure you will need to import the ldap server's cert into your JVM keystore (cacert) since by default that's what used for outbound connections. If you import it into Geronimo's keystore you will need to set the following properties when starting the server: -Djavax.net.ssl.trustStore=$GERONIMO_HOME/var/security/keystores/geronimo-default -Djavax.net.ssl.trustStorePassword=secret Jarek On Thu, Jul 16, 2009 at 5:08 PM, alehx wrote: > > I have searched google and the geronimo knowledge base far and wide and have > not been able to come up with a solution to my issue. > > We are developing a web application that requires LDAP authentication to 1) > Determine if the user exists and his/her credentials are correct 2) to serve > the correct pages and privileges to authenticated users. > > However, we have reached a road block. After implementing the security > realms, keystores, and web-specific deployment plans, we have been unable to > get past the authentication prompt for user credentials. > > No matter what I have tried, the error message is always > > ERROR [LDAPLoginModule] javax.naming.CommunicationException: simple bind > failed: my.ldap.server:636 [Root exception is > javax.net.ssl.SSLHandshakeException: > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target] > > WARN [log] AUTH FAILURE: user UserName > > I followed the keytool directives for obtaining a valid certificate and > created a new certificate via the Geronimo console. I have also tried > importing a valid certificate manually buy copy/paste and changes to the > config.xml file.. all to no avail. > > If the issue is the security realm, we have contacted the LDAP server > administrators and obtained the correct settings for our use. I have tried > creating a server via the console and via the geronimo-application.xml > > I'm not sure if the issue is the server believes the certificate is invalid > or it cannot find a matching certificate after the LDAP server is contacted. > > The keystore I am using is in the geronimo var/security/keystore directory > and also registered in the system wide java keystore (cacerts.) > > If anyone could suggest some things to get geronimo to accept the > certificates in my keystore or to somehow link them so they will be of use > would be great. > > Thanks > -- > View this message in context: > http://www.nabble.com/Error%3A-%22unable-to-find-valid-certification-path-to-requested-target%22-tp24524543s134p24524543.html > Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com. > >
[jira] Updated: (GERONIMODEVTOOLS-580) Servlet/JSP update forces a complete redeploy of a WAR
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai updated GERONIMODEVTOOLS-580: --- Attachment: 580.patch Hi, I create a patch for this JIRA. It provide an option "Not redeploy JSP files" in server instance. If this option is selected, then JSP update in normal Web project won't trigger a redeploy, instead, it will just copy the jsp files to target position. But there are some limitations for this 1) It only works for local server 2) Besides the option, user has to set "development" of "JSPServlet" in catalina.xml to "true" Could anyone help to review it? Thanks a lot! > Servlet/JSP update forces a complete redeploy of a WAR > -- > > Key: GERONIMODEVTOOLS-580 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-580 > Project: Geronimo-Devtools > Issue Type: Improvement >Affects Versions: 2.0.x, 2.2.0 >Reporter: Kevan Miller >Assignee: Tim McConnell > Fix For: 2.2.0 > > Attachments: 580.patch > > > I've had several users comment to me that application development with GEP is > not as fast as it should be. Basic scenario is create an application, deploy, > test, update, test, update, etc... IIUC, for each update, GEP is repackaging > the WAR and running a redeploy. Repackaging/redeploy can take some time (for > large apps > 30 seconds). IIUC, we could be updating the appropriate > JSP/Servlet classes directly and greatly improving this behavior. I don't > know how this works, however. Anybody interested in looking at this? I'd like > to see this improved in 2.2. If it's something that could be fixed in 2.1.x, > that would be great. But that might depend on how extensive the changes > are... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4751) Upgrade 2.1.x to Tomcat 6.0.20
[ https://issues.apache.org/jira/browse/GERONIMO-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevan Miller reassigned GERONIMO-4751: -- Assignee: Kevan Miller > Upgrade 2.1.x to Tomcat 6.0.20 > -- > > Key: GERONIMO-4751 > URL: https://issues.apache.org/jira/browse/GERONIMO-4751 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Reporter: Kevan Miller >Assignee: Kevan Miller > > We need to upgrade our branches/2.1 to use Tomcat 6.0.20. As we do this, we > should move to the new Geronimo External generated version. Rather than > create a new private repo version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Apache Con US '09 Geronimo Track
On Jul 16, 2009, at 2:33 AM, Jack Cai wrote: Is "Geronimo performance tuning" a good topic to cover? I guess we don't have some nice materials on this topic currently? Sure. All good potential topics. We don't have to list all potential topics. Thanks for the feedback, all. --kevan
[jira] Updated: (GERONIMO-4750) port dojo-legacy external
[ https://issues.apache.org/jira/browse/GERONIMO-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4750: --- Attachment: screenshot-1.jpg > port dojo-legacy external > - > > Key: GERONIMO-4750 > URL: https://issues.apache.org/jira/browse/GERONIMO-4750 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: Rex Wang >Assignee: Rex Wang > Fix For: 2.2 > > Attachments: GERONIMO-4750.patch, geronimo-dojo-0.4.3.patch, > screenshot-1.jpg > > > the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4750) port dojo-legacy external
[ https://issues.apache.org/jira/browse/GERONIMO-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732302#action_12732302 ] Rex Wang commented on GERONIMO-4750: Hi David, which icon is missing in your screen? "+"/"-" or a tree node like in attachment? If the latter, that should be part of debugviews plugin. They are shown correctly from my side... I will make a whole build later to have a try. -Rex > port dojo-legacy external > - > > Key: GERONIMO-4750 > URL: https://issues.apache.org/jira/browse/GERONIMO-4750 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: Rex Wang >Assignee: Rex Wang > Fix For: 2.2 > > Attachments: GERONIMO-4750.patch, geronimo-dojo-0.4.3.patch > > > the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 794915
Geronimo Revision: 794915 built with tests included See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716/build-2100.log See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716/unit-test-reports -- 1 required artifact is missing. for artifact: org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots), ibiblio.org (http://repo.exist.com/maven2) [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) jtidy:jtidy:jar:8.0-20060801 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT 2) jtidy:jtidy:jar:8.0-20060801 -- 1 required artifact is missing. for artifact: org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots), ibiblio.org (http://repo.exist.com/maven2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing: -- 1) jtidy:jtidy:jar:8.0-20060801 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=jtidy -DartifactId=jtidy -Dversion=8.0-20060801 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT 2) jtidy:jtidy:jar:8.0-20060801 -- 1 required artifact is missing. for artifact: org.apache.geronimo.buildsupport:testsuite-maven-plugin:maven-plugin:2.2-SNAPSHOT from the specified remote repositories: codehaus.snapshots (http://snapshots.repository.codehaus.org), apache.snapshots (http://repository.apache.org/snapshots), ibiblio.org (http://repo.exist.com/maven2) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1417) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:407) at
Re: Which dojo?... and which dwr
On Jul 16, 2009, at 7:42 AM, Rex Wang wrote:
I opened a jira https://issues.apache.org/jira/browse/GERONIMO-4750
to upload my patches, please see my comment there.
I applied these patches and it looks to me as if the stuff is pretty
much working but the trees lack icons at the beginnings of lines (to
show the tree structure). Could you investigate if we left out
some .gifs or something like that?
I thought we were done but realized we also still have dwr to deal
with. Could someone take a look at what happens? I think all that is
needed is to edit the root pom
org.directwebremoting
dwr
2.0.5
to
org.directwebremoting
dwr
3.0.M1
I opened GERONIMO-4753 for this one.
thanks!
david jencks
-Rex
2009/7/16 David Jencks
On Jul 16, 2009, at 12:04 AM, Rex Wang wrote:
yes, the size of two dojo.js is very different. I guess we should
first build the checked out codes. I am looking into the
buildscripts of it, but can not make a build successfully:-(, still
investigating...
I worried about how much time it would take to figure out the build
and decided that at least if the dojo.js was the only file needed we
should just put the "compiled" version in svn
Even though we need more I think it may well be worthwhile to save
time and just put everything in svn that we need. Either that or
the compiled dojo.js (as I did already) and fish the src/ files out
of dojo svn.
Remember this is hopefully a short-term dependency.
thanks
david jencks
-Rex
2009/7/16 David Jencks
On Jul 15, 2009, at 7:47 PM, Rex Wang wrote:
I think the main reason why the new war has the different
structure with the old one is:
in the pom.xml of ext\trunk\geronimo-dojo-0.4.3, only check out
the files in "src" to target/resource
checkout
generate-resources
checkout
${project.basedir}/
target/resources
scm:svn:http://svn.dojotoolkit.org/src/tags/release-0.4.3/src/
I just tried "scm:svn:http://svn.dojotoolkit.org/src/tags/release-0.4.3/
", and the JMX and LDAP portlet seems working correctly, but the
other three still have some problems to show the tree.
I couldn't figure out what the dojo build.xml or build shell
scripts were doing, but it looked to me like the dojo.js in our war
file was really different from the dojo.js in svn. I was hoping
that only the dojo.js was actually used but obviously I was
wrong.
Unless you can figure out a better svn-checkout-from-dojo solution
I think I'd try putting all the dojo files we need into src/main/
resources in the externals project. I can do this pretty easily,
probably more easily than from a patch let me know.
thanks
david jencks
-Rex
2009/7/16 David Jencks
On Jul 15, 2009, at 6:27 AM, Rex Wang wrote:
tried it.
1.
svn co
https://svn.apache.org/repos/asf/geronimo/external/trunk/geronimo-dojo-0.4.3
mvn clean install
success!
2.
modify the plugins/dojo-legacy stuff
the patch in attachment shows the modification.
build successfully
3.
I did not build the entire server, but just remove the old one,
and install the new one.
I believe only the debug-views portlets use this legacy dojo,
because when I stop the dojo-legacy-tomcat plugin, only the
debugviews-console-tomcat web project stopped autoly. and I also
searched all the jsps underneath plugins folder in the server
build tree, only show the ones from debugviews holding reference
to "/dojo/0.4/dojo.js"
results:
Unfortunately, the debugviews portlet don't display corretly...
I make some screen shot. Shall we open a jira for this so that I
can upload them, which apparently shows dojo not work correctly?
Or we could try to fix them :-)
I looked at the two war files and they are different and I wonder
what we actually use.
old war (geronimo-dojo-legacy):
-rw-r--r--151841 15-May-2007 02:11:02 dojo.js
-rw-r--r--326567 15-May-2007 02:11:04
dojo.js.uncompressed.js
-rw-r--r-- 1170 15-May-2007 02:06:02 flash6_gateway.swf
-rw-r--r-- 2364 15-May-2007 02:06:02 iframe_history.html
-rw-r--r-- 11346 15-May-2007 02:06:02 LICENSE
-rw-r--r-- 13133 14-Jul-2009 15:01:02 META-INF/LICENSE
-rw-r--r-- 587 14-Jul-2009 15:01:02 META-INF/NOTICE
-rw-r--r-- 1609 15-May-2007 02:11:32 src/a11y.js
..
everything else is under src/
new war (geronimo-dojo-0.4.3):
just the contents of src from geronimo-dojo-legacy.
So what do we actually use here? if its just dojo.js we can
shrink it by leaving out the uncompressed.js and all the little
files. If its just the li
[jira] Created: (GERONIMO-4753) Upgrade dwr to 3.0.M1 or figure out why it won't work
Upgrade dwr to 3.0.M1 or figure out why it won't work - Key: GERONIMO-4753 URL: https://issues.apache.org/jira/browse/GERONIMO-4753 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem, console Affects Versions: 2.2 Reporter: David Jencks Fix For: 2.2 The last artifact in the svn repo is dwr. We need to upgrade to 3.0.M1 which is available through maven or figure out some other strategy, possibly trying to convince the dwr team to release 2.0.5 through maven. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4750) port dojo-legacy external
[ https://issues.apache.org/jira/browse/GERONIMO-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732236#action_12732236 ] David Jencks commented on GERONIMO-4750: external war changes rev 794787. geronimo patched rev 794898, use the new war, remove unused jars from svn repo, remove unused geronimo-dojo-legacy war project. The dojo trees in the console viewer portlets look like they basically work but like some images are missing -- the trees don't seem to have the symbols at the start of each line. Rex, could you investigate? > port dojo-legacy external > - > > Key: GERONIMO-4750 > URL: https://issues.apache.org/jira/browse/GERONIMO-4750 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: Rex Wang >Assignee: Rex Wang > Fix For: 2.2 > > Attachments: GERONIMO-4750.patch, geronimo-dojo-0.4.3.patch > > > the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r794791 - /geronimo/specs/branches/geronimo-validation_1.0_spec-1.0-EA/pom.xml
Is this really necessary? I'm under the impression that m2eclipse works a lot better than the maven-eclipse-plugin and if possible I'd like to avoid adding ide-specific goo to our poms. thanks david jencks On Jul 16, 2009, at 12:28 PM, dwo...@apache.org wrote: Author: dwoods Date: Thu Jul 16 19:28:48 2009 New Revision: 794791 URL: http://svn.apache.org/viewvc?rev=794791&view=rev Log: GERONIMO-4619 Include version in maven-eclipse-plugin generated .project name Modified: geronimo/specs/branches/geronimo-validation_1.0_spec-1.0-EA/pom.xml Modified: geronimo/specs/branches/geronimo-validation_1.0_spec-1.0- EA/pom.xml URL: http://svn.apache.org/viewvc/geronimo/specs/branches/geronimo-validation_1.0_spec-1.0-EA/pom.xml?rev=794791&r1=794790&r2=794791&view=diff = = = = = = = = == --- geronimo/specs/branches/geronimo-validation_1.0_spec-1.0-EA/ pom.xml (original) +++ geronimo/specs/branches/geronimo-validation_1.0_spec-1.0-EA/ pom.xml Thu Jul 16 19:28:48 2009 @@ -57,4 +57,18 @@ http://svn.apache.org/viewcvs.cgi/geronimo/specs/branches/geronimo-validation_1.0_spec-1.0-EA/ + + + + +org.apache.maven.plugins +maven-eclipse-plugin + +trueaddVersionToProjectName> + + + + + +
Re: Error: "unable to find valid certification path to requested target"
On Jul 16, 2009, at 2:08 PM, alehx wrote: I have searched google and the geronimo knowledge base far and wide and have not been able to come up with a solution to my issue. We are developing a web application that requires LDAP authentication to 1) Determine if the user exists and his/her credentials are correct 2) to serve the correct pages and privileges to authenticated users. However, we have reached a road block. After implementing the security realms, keystores, and web-specific deployment plans, we have been unable to get past the authentication prompt for user credentials. No matter what I have tried, the error message is always ERROR [LDAPLoginModule] javax.naming.CommunicationException: simple bind failed: my.ldap.server:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] WARN [log] AUTH FAILURE: user UserName I followed the keytool directives for obtaining a valid certificate and created a new certificate via the Geronimo console. I have also tried importing a valid certificate manually buy copy/paste and changes to the config.xml file.. all to no avail. If the issue is the security realm, we have contacted the LDAP server administrators and obtained the correct settings for our use. I have tried creating a server via the console and via the geronimo-application.xml I'm not sure if the issue is the server believes the certificate is invalid or it cannot find a matching certificate after the LDAP server is contacted. The keystore I am using is in the geronimo var/security/keystore directory and also registered in the system wide java keystore (cacerts.) If anyone could suggest some things to get geronimo to accept the certificates in my keystore or to somehow link them so they will be of use would be great. I think this is a user list question. I think the absolute minimum information anyone would need to start guessing at what is wrong would be - the entire stack trace from the exception - details of how you are trying to connect to the ldap server. In particular... is this an ssl connection? tls? does the ldap server expect the client to authenticate with a client side certificate or user/password? Despite the lack of this information I'd guess that you are connecting over ssl and the geronimo truststore does not have a certificate to enable it to trust the certificate from the ldap server. david jencks Thanks -- View this message in context: http://www.nabble.com/Error%3A-%22unable-to-find-valid-certification-path-to-requested-target%22-tp24524543s134p24524543.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Error: "unable to find valid certification path to requested target"
I have searched google and the geronimo knowledge base far and wide and have not been able to come up with a solution to my issue. We are developing a web application that requires LDAP authentication to 1) Determine if the user exists and his/her credentials are correct 2) to serve the correct pages and privileges to authenticated users. However, we have reached a road block. After implementing the security realms, keystores, and web-specific deployment plans, we have been unable to get past the authentication prompt for user credentials. No matter what I have tried, the error message is always ERROR [LDAPLoginModule] javax.naming.CommunicationException: simple bind failed: my.ldap.server:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] WARN [log] AUTH FAILURE: user UserName I followed the keytool directives for obtaining a valid certificate and created a new certificate via the Geronimo console. I have also tried importing a valid certificate manually buy copy/paste and changes to the config.xml file.. all to no avail. If the issue is the security realm, we have contacted the LDAP server administrators and obtained the correct settings for our use. I have tried creating a server via the console and via the geronimo-application.xml I'm not sure if the issue is the server believes the certificate is invalid or it cannot find a matching certificate after the LDAP server is contacted. The keystore I am using is in the geronimo var/security/keystore directory and also registered in the system wide java keystore (cacerts.) If anyone could suggest some things to get geronimo to accept the certificates in my keystore or to somehow link them so they will be of use would be great. Thanks -- View this message in context: http://www.nabble.com/Error%3A-%22unable-to-find-valid-certification-path-to-requested-target%22-tp24524543s134p24524543.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
[BUILD] trunk: Failed for Revision: 794771
Geronimo Revision: 794771 built with tests included
See the full build-1500.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716/build-1500.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 41 minutes 26 seconds
[INFO] Finished at: Thu Jul 16 15:46:15 EDT 2009
[INFO] Final Memory: 402M/1015M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716/logs-1500-tomcat/
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-tomcat6-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-tomcat6-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-tomcat6-javaee5/2.2-SNAPSHOT/geronimo-tomcat6-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:46.517
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/testing/testsuite-testing.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:20.257)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:34.910)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:40.957)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:20.498)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:33.010)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced SUCCESS (0:01:44.800)
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:02:02.986)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:53.381)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:01:03.459)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:46.552)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:34.197)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:36.239)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:35.938)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:01:11.936)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:01:00.415)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:50.617)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:30.709)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:54.273)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:50.432)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:33.127)
[INFO] web-testsuite/test-2.5-servletsRUNNING
[INFO] web-testsuite/test-2.5-servletsSUCCESS (0:00:31.145)
[INFO] web-testsuite/test-myfaces RUNNING
[INFO] web-testsuite/test-myfaces SUCCESS (0:00:33.167)
[INFO] web-testsuite/test-tomcat RUNNING
[INFO] web-testsuite/test-tomcat
[jira] Commented: (GERONIMO-4619) JSR-303 Bean Validation Spec API
[ https://issues.apache.org/jira/browse/GERONIMO-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732114#action_12732114 ] Donald Woods commented on GERONIMO-4619: geronimo-validation updated for 1.0 CR3, a EA3 branch created and artifacts published - Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-validation_1.0_spec/1.0-EA3-SNAPSHOT/geronimo-validation_1.0_spec-1.0-EA3-20090716.193828-1.jar > JSR-303 Bean Validation Spec API > > > Key: GERONIMO-4619 > URL: https://issues.apache.org/jira/browse/GERONIMO-4619 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: specs >Reporter: Donald Woods >Assignee: Donald Woods > Fix For: Wish List > > > Provide a clean-room implementation covered by ASL 2.0 of the JSR-303 Bean > Validation API as required by the JPA 2.0, JSF 2.0 and Java EE 6 specs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4744) Database pool wizard improvements
[ https://issues.apache.org/jira/browse/GERONIMO-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732108#action_12732108 ] Jürgen Weber commented on GERONIMO-4744: (b) For the Oracle thin driver there is a JDBC URL field on the Edit-Page of the DataSource, so I thought it should be on the New-Page, too. > Database pool wizard improvements > - > > Key: GERONIMO-4744 > URL: https://issues.apache.org/jira/browse/GERONIMO-4744 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Jürgen Weber >Priority: Minor > > a) > "The JAR(s) should already be installed under GERONIMO/repository/ " > Please add a hint like: "(via Services/Repository on the console)" > b) > It should be possible to optionally directly enter a JDBC URL instead of > having to enter separate parts as in the case for oracle thin: Host, SID, Port > Usually you get a complete URL without knowing the URL parts. > This would be consistent to editing the pool where you edit the JDBC Connect > URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4748) Security context is not cleared before the thread is returned to the pool for Tomcat
[ https://issues.apache.org/jira/browse/GERONIMO-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reassigned GERONIMO-4748: -- Assignee: David Jencks > Security context is not cleared before the thread is returned to the pool for > Tomcat > > > Key: GERONIMO-4748 > URL: https://issues.apache.org/jira/browse/GERONIMO-4748 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.1.5, 2.2 >Reporter: Ivan >Assignee: David Jencks >Priority: Critical > Fix For: 2.1.5, 2.2 > > > We do some authentication in the TomcatGeronimoRealm, and set the security > context, but it is not cleared later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4748) Security context is not cleared before the thread is returned to the pool for Tomcat
[ https://issues.apache.org/jira/browse/GERONIMO-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732075#action_12732075 ] David Jencks commented on GERONIMO-4748: I think this is only a problem for ejb web services, the PolicyContextBeforeAfter should be taking care of this for web apps and pojo web services. Fixes for 2.1 and 2.2 will have to be very different due to tomcat security rewrite in 2.2 > Security context is not cleared before the thread is returned to the pool for > Tomcat > > > Key: GERONIMO-4748 > URL: https://issues.apache.org/jira/browse/GERONIMO-4748 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.1.5, 2.2 >Reporter: Ivan >Priority: Critical > Fix For: 2.1.5, 2.2 > > > We do some authentication in the TomcatGeronimoRealm, and set the security > context, but it is not cleared later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4744) Database pool wizard improvements
[ https://issues.apache.org/jira/browse/GERONIMO-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732073#action_12732073 ] David Jencks commented on GERONIMO-4744: I like (a) For (b), we are constrained by what properties the DataSource implemenation in the driver provides. Generally we expose all the DataSource properties or as many as we can figure out. > Database pool wizard improvements > - > > Key: GERONIMO-4744 > URL: https://issues.apache.org/jira/browse/GERONIMO-4744 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 2.2 >Reporter: Jürgen Weber >Priority: Minor > > a) > "The JAR(s) should already be installed under GERONIMO/repository/ " > Please add a hint like: "(via Services/Repository on the console)" > b) > It should be possible to optionally directly enter a JDBC URL instead of > having to enter separate parts as in the case for oracle thin: Host, SID, Port > Usually you get a complete URL without knowing the URL parts. > This would be consistent to editing the pool where you edit the JDBC Connect > URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4619) JSR-303 Bean Validation Spec API
[ https://issues.apache.org/jira/browse/GERONIMO-4619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732055#action_12732055 ] Donald Woods commented on GERONIMO-4619: r794769 - Spec changes between Validation 1.0 CR2 and 1.0 CR3 levels: - The 4 descriptor class were moved into a javax.validation.metadata package. - A new javax.validation.Path was introduced for iterable nodes, which replaces some String usage in ConstraintViolation and - Constraints and @Valid - now supports constructor and parameter targets - ConstraintValidatorContext - several new Interfaces and method chnages - ConstraintViolation - getPropertyPAth() now returns a Path instead of a String - ConstraintViolationException - getConstraintViolations() now returns Set> instead of Set - MessageInterpolator - static removed from internal Context interface - ValidationProvider - now extends Configuration and createSpecializedConfiguration() method has changed - TraversableResolver - method params have changed - Validation - changes in some method params and static class impls - ValidationProviderResolver - getValidationProviders() now returns List> instead of List - Validator - new unwrap() method - ValidatorFactory - new unwrap() method > JSR-303 Bean Validation Spec API > > > Key: GERONIMO-4619 > URL: https://issues.apache.org/jira/browse/GERONIMO-4619 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: specs >Reporter: Donald Woods >Assignee: Donald Woods > Fix For: Wish List > > > Provide a clean-room implementation covered by ASL 2.0 of the JSR-303 Bean > Validation API as required by the JPA 2.0, JSF 2.0 and Java EE 6 specs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4752) Implement jaspic support for tomcat
[ https://issues.apache.org/jira/browse/GERONIMO-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732041#action_12732041 ] David Jencks commented on GERONIMO-4752: Initial implementation in rev 794752. I didn't try running the jaspic tck on it yet but don't see problems with regular web security. > Implement jaspic support for tomcat > --- > > Key: GERONIMO-4752 > URL: https://issues.apache.org/jira/browse/GERONIMO-4752 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, web, webservices >Affects Versions: 2.2 >Reporter: David Jencks >Assignee: David Jencks > Fix For: 2.2 > > > I wasn't really planning jaspic support for tomcat for 2.2 but thinking about > trying to fix the gap in http method coverage that became apparent working on > GERONIMO-4645 and looking at the gaps in jacc suppot in tomcat led me to > reimplement tomcat security. > The reimplementation seems to work for regular and ejb ws security but I > haven't actually tested any jaspic support yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4626) Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing
[ https://issues.apache.org/jira/browse/GERONIMO-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-4626: --- Patch Info: [Patch Available] Fix Version/s: 2.2 > Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk > routing > > > Key: GERONIMO-4626 > URL: https://issues.apache.org/jira/browse/GERONIMO-4626 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.1.4 >Reporter: Gianny Damour >Assignee: Gianny Damour > Fix For: 2.1.5, 2.2 > > > It is not possible to fulfill session affinity with Apache mod_jk as the > value of the JSESSIONID cookie does not embed a jvmRoute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (GERONIMO-4626) Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk routing
[ https://issues.apache.org/jira/browse/GERONIMO-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reopened GERONIMO-4626: This was never applied to the 2.1.x branch > Tomcat Clustering with WADI - JSESSIONID with jvmRoute to support mod_jk > routing > > > Key: GERONIMO-4626 > URL: https://issues.apache.org/jira/browse/GERONIMO-4626 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Clustering >Affects Versions: 2.1.4 >Reporter: Gianny Damour >Assignee: Gianny Damour > Fix For: 2.1.5 > > > It is not possible to fulfill session affinity with Apache mod_jk as the > value of the JSESSIONID cookie does not embed a jvmRoute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4752) Implement jaspic support for tomcat
Implement jaspic support for tomcat --- Key: GERONIMO-4752 URL: https://issues.apache.org/jira/browse/GERONIMO-4752 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat, web, webservices Affects Versions: 2.2 Reporter: David Jencks Assignee: David Jencks Fix For: 2.2 I wasn't really planning jaspic support for tomcat for 2.2 but thinking about trying to fix the gap in http method coverage that became apparent working on GERONIMO-4645 and looking at the gaps in jacc suppot in tomcat led me to reimplement tomcat security. The reimplementation seems to work for regular and ejb ws security but I haven't actually tested any jaspic support yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r794318 - in /geronimo/server/trunk/plugins: cxf/geronimo-cxf/ cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/ j2ee/geronimo-naming-builder/src/main/xsd/ jaxws/geronim
Yes. I'll fix that in a minute or two. Thanks. Jarek On Thu, Jul 16, 2009 at 12:07 PM, David Jencks wrote: > Is it possible that this change causes this NPE? > > at > org..apache..geronimo..jaxws..builder.EndpointInfoBuilder.getProperties(EndpointInfoBuilder.java:282) > at > org..apache..geronimo..jaxws.builder.EndpointInfoBuilder.build(EndpointInfoBuilder.java:246) > at > org..apache..geronimo..axis2..builder..Axis2ServiceRefBuilder.createService(Axis2ServiceRefBuilder.java:66) > at > org..apache..geronimo..jaxws..builder..JAXWSServiceRefBuilder.buildNaming(JAXWSServiceRefBuilder.java:164) > at > org..apache..geronimo..jaxws..builder..JAXWSServiceRefBuilder.buildNaming(JAXWSServiceRefBuilder.java:103) > at > org..apache..geronimo..naming..deployment..SwitchingServiceRefBuilder..buildNaming(SwitchingServiceRefBuilder.java:133) > at > org..apache..geronimo..j2ee..deployment..NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:69) > at > org..apache..geronimo..web25..deployment..AbstractWebModuleBuilder..configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:614) > at > org..apache..geronimo..tomcat..deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:349) > at > org..apache..geronimo..j2ee..deployment..SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) > at > org..apache..geronimo..j2ee..deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:652) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257) > > > > On Jul 15, 2009, at 9:08 AM, ga...@apache.org wrote: > >> Author: gawor >> Date: Wed Jul 15 16:08:51 2009 >> New Revision: 794318 >> >> URL: http://svn.apache.org/viewvc?rev=794318&view=rev >> Log: >> 1) set arbitrary port properties for service-references in geronimo plan >> and 2) recognize wss4j properties to enable ws-security for >> service-references (using CXF provider). Based on patch/work of Rahul Mehta >> (GERONIMO-4642) >> >> Added: >> >> geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPasswordHandler.java >> (with props) >> >> geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPortMethodInterceptor.java >> (with props) >> Modified: >> geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml >> >> geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFServiceReference.java >> >> geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/src/main/xsd/geronimo-naming-1.2.xsd >> >> geronimo/server/trunk/plugins/jaxws/geronimo-jaxws-builder/src/main/java/org/apache/geronimo/jaxws/builder/EndpointInfoBuilder.java >> >> geronimo/server/trunk/plugins/jaxws/geronimo-jaxws/src/main/java/org/apache/geronimo/jaxws/client/EndpointInfo.java >> >> geronimo/server/trunk/plugins/jaxws/geronimo-jaxws/src/main/java/org/apache/geronimo/jaxws/client/PortMethodInterceptor.java >> >> Modified: geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml >> URL: >> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml?rev=794318&r1=794317&r2=794318&view=diff >> >> == >> --- geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml (original) >> +++ geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml Wed Jul 15 >> 16:08:51 2009 >> @@ -61,6 +61,11 @@ >> org.apache.cxf >> cxf-rt-transports-http >> >> + >> + >> + org.apache.cxf >> + cxf-rt-ws-security >> + >> >> >> org.apache.geronimo.specs >> >> Added: >> geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPasswordHandler.java >> URL: >> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPasswordHandler.java?rev=794318&view=auto >> >> == >> --- >> geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPasswordHandler.java >> (added) >> +++ >> geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPasswordHandler.java >> Wed Jul 15 16:08:51 2009 >> @@ -0,0 +1,44 @@ >> +/** >> + * Licensed to the Apache Software Foundation (ASF) under one or more >> + * contributor license agreements. See the NOTICE file distributed with >> + * this work for additional information regarding copyright ownership. >> + * The ASF licenses this file to You 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 agr
Re: svn commit: r794318 - in /geronimo/server/trunk/plugins: cxf/geronimo-cxf/ cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/ j2ee/geronimo-naming-builder/src/main/xsd/ jaxws/geronimo-
Is it possible that this change causes this NPE? at org ..apache ..geronimo ..jaxws ..builder.EndpointInfoBuilder.getProperties(EndpointInfoBuilder.java:282) at org ..apache ..geronimo ..jaxws.builder.EndpointInfoBuilder.build(EndpointInfoBuilder.java:246) at org ..apache ..geronimo ..axis2 ..builder ..Axis2ServiceRefBuilder.createService(Axis2ServiceRefBuilder.java:66) at org ..apache ..geronimo ..jaxws ..builder ..JAXWSServiceRefBuilder.buildNaming(JAXWSServiceRefBuilder.java:164) at org ..apache ..geronimo ..jaxws ..builder ..JAXWSServiceRefBuilder.buildNaming(JAXWSServiceRefBuilder.java:103) at org ..apache ..geronimo ..naming ..deployment ..SwitchingServiceRefBuilder ..buildNaming(SwitchingServiceRefBuilder.java:133) at org ..apache ..geronimo ..j2ee ..deployment ..NamingBuilderCollection.buildNaming(NamingBuilderCollection.java:69) at org ..apache ..geronimo ..web25 ..deployment ..AbstractWebModuleBuilder ..configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:614) at org ..apache ..geronimo ..tomcat ..deployment.TomcatModuleBuilder.addGBeans(TomcatModuleBuilder.java:349) at org ..apache ..geronimo ..j2ee ..deployment ..SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) at org ..apache ..geronimo ..j2ee ..deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java: 652) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257) On Jul 15, 2009, at 9:08 AM, ga...@apache.org wrote: Author: gawor Date: Wed Jul 15 16:08:51 2009 New Revision: 794318 URL: http://svn.apache.org/viewvc?rev=794318&view=rev Log: 1) set arbitrary port properties for service-references in geronimo plan and 2) recognize wss4j properties to enable ws-security for service-references (using CXF provider). Based on patch/work of Rahul Mehta (GERONIMO-4642) Added: geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/ apache/geronimo/cxf/client/CXFPasswordHandler.java (with props) geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/ apache/geronimo/cxf/client/CXFPortMethodInterceptor.java (with props) Modified: geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/ apache/geronimo/cxf/client/CXFServiceReference.java geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/src/ main/xsd/geronimo-naming-1.2.xsd geronimo/server/trunk/plugins/jaxws/geronimo-jaxws-builder/src/ main/java/org/apache/geronimo/jaxws/builder/EndpointInfoBuilder.java geronimo/server/trunk/plugins/jaxws/geronimo-jaxws/src/main/java/ org/apache/geronimo/jaxws/client/EndpointInfo.java geronimo/server/trunk/plugins/jaxws/geronimo-jaxws/src/main/java/ org/apache/geronimo/jaxws/client/PortMethodInterceptor.java Modified: geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml?rev=794318&r1=794317&r2=794318&view=diff = = = = = = = = == --- geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml (original) +++ geronimo/server/trunk/plugins/cxf/geronimo-cxf/pom.xml Wed Jul 15 16:08:51 2009 @@ -61,6 +61,11 @@ org.apache.cxf cxf-rt-transports-http + + +org.apache.cxf +cxf-rt-ws-security + org.apache.geronimo.specs Added: geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/ org/apache/geronimo/cxf/client/CXFPasswordHandler.java URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/apache/geronimo/cxf/client/CXFPasswordHandler.java?rev=794318&view=auto = = = = = = = = == --- geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/ apache/geronimo/cxf/client/CXFPasswordHandler.java (added) +++ geronimo/server/trunk/plugins/cxf/geronimo-cxf/src/main/java/org/ apache/geronimo/cxf/client/CXFPasswordHandler.java Wed Jul 15 16:08:51 2009 @@ -0,0 +1,44 @@ +/** + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You 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 specifi
Re: Do we want to apply genesis 2.0 resource filtering best practice ?
On Jul 16, 2009, at 1:52 AM, Shawn Jiang wrote:
Thanks for your replies, I'll go ahead to submit patches on this.
Can you do this in the form of patches for pom files and a file of svn
mv commands for actually moving the resources? That way we won't lose
the svn history of the resources.
thanks
david jencks
On Thu, Jul 16, 2009 at 2:19 PM, Jason Dillon
wrote:
Me too :-) I guess that is why I put that in there, just never
updated projects to use it.
--jason
On Jul 16, 2009, at 1:08 PM, David Jencks wrote:
On Jul 15, 2009, at 10:46 PM, Shawn Jiang wrote:
I noticed there's a maven resource best practice defined in
genesis-default-flava-2.0.pom.
1, Put normal resource under : ${project.basedir}/ src/main/
resources
2, Put the resource that needs filtering under: ${project.basedir}/
src/main/filtered-resources
At the same time, many projects in Geronimo does not follow this
practice. A JIRA was opened for this : https://issues.apache.org/jira/browse/GERONIMO-4737
If no objection, I'm going to use GERONIMO-4737 to fix this kind
of problems in current code base. Any comments ?
Looks like a good idea to me!
thanks
david jencks
--
Shawn
--
Shawn
Re: About Geronimo EJB Cluster and JMS Cluster
On Jul 16, 2009, at 2:25 AM, Lu Zhongda wrote: All: As I know, geronimo only supports web cluster with WADI by now. EJB cluster and JMS cluster are not supported yet. I believe jms clustering is done through activemq. At least in 2.2- SNAPSHOT you can configure activemq with the standard amq xml configuration so anything amq supports can be run inside geronimo. I don't recall when we added this feature, it might be in 2.1.x also. We also have stateful ejb replication through wadi in at least 2.2. I don't think this includes ejb client failover for stateful session beans. We also have ejb client failover using a cluster whose membership is maintained through multicast in 2.2. This is separate from the wadi replication support. We could probably use better docs and samples for this stuff :-) thanks david jencks Is my information correct? If it was true, any plans to support these features. Any information about this is appreciated. Thanks. Best Regards. Michael Lu
Re: Which dojo?
I opened a jira https://issues.apache.org/jira/browse/GERONIMO-4750 to
upload my patches, please see my comment there.
-Rex
2009/7/16 David Jencks
>
> On Jul 16, 2009, at 12:04 AM, Rex Wang wrote:
>
> yes, the size of two dojo.js is very different. I guess we should first
> build the checked out codes. I am looking into the buildscripts of it, but
> can not make a build successfully:-(, still investigating...
>
>
> I worried about how much time it would take to figure out the build and
> decided that at least if the dojo.js was the only file needed we should just
> put the "compiled" version in svn
>
> Even though we need more I think it may well be worthwhile to save time and
> just put everything in svn that we need. Either that or the compiled
> dojo.js (as I did already) and fish the src/ files out of dojo svn.
>
> Remember this is hopefully a short-term dependency.
>
> thanks
> david jencks
>
>
> -Rex
>
> 2009/7/16 David Jencks
>
>>
>> On Jul 15, 2009, at 7:47 PM, Rex Wang wrote:
>>
>> I think the main reason why the new war has the different structure with
>> the old one is:
>> in the pom.xml of ext\trunk\geronimo-dojo-0.4.3, only check out the files
>> in "src" to target/resource
>>
>> checkout
>> generate-resources
>>
>> checkout
>>
>>
>>
>> ${project.basedir}/target/resources
>> scm:svn:
>> http://svn.dojotoolkit.org/src/tags/release-0.4.3/*src/*
>>
>>
>>
>> I just tried "scm:svn:http://svn.dojotoolkit.org/src/tags/release-0.4.3/";,
>> and the JMX and LDAP portlet seems working correctly, but the other three
>> still have some problems to show the tree.
>>
>>
>> I couldn't figure out what the dojo build.xml or build shell scripts were
>> doing, but it looked to me like the dojo.js in our war file was really
>> different from the dojo.js in svn. I was hoping that only the dojo.js was
>> actually used but obviously I was wrong.
>>
>> Unless you can figure out a better svn-checkout-from-dojo solution I think
>> I'd try putting all the dojo files we need into src/main/resources in the
>> externals project. I can do this pretty easily, probably more easily than
>> from a patch let me know.
>>
>> thanks
>> david jencks
>>
>>
>> -Rex
>>
>> 2009/7/16 David Jencks
>>
>>>
>>> On Jul 15, 2009, at 6:27 AM, Rex Wang wrote:
>>>
>>> tried it.
>>>
>>> 1.
>>> svn co
>>> https://svn.apache.org/repos/asf/geronimo/external/trunk/geronimo-dojo-0.4.3
>>> mvn clean install
>>> success!
>>>
>>> 2.
>>> modify the plugins/dojo-legacy stuff
>>> the patch in attachment shows the modification.
>>> build successfully
>>>
>>> 3.
>>> I did not build the entire server, but just remove the old one, and
>>> install the new one.
>>> I believe only the debug-views portlets use this legacy dojo, because
>>> when I stop the dojo-legacy-tomcat plugin, only the
>>> debugviews-console-tomcat web project stopped autoly. and I also searched
>>> all the jsps underneath plugins folder in the server build tree, only show
>>> the ones from debugviews holding reference to "/dojo/0.4/dojo.js"
>>>
>>> results:
>>> Unfortunately, the debugviews portlet don't display corretly...
>>>
>>> I make some screen shot. Shall we open a jira for this so that I can
>>> upload them, which apparently shows dojo not work correctly?
>>>
>>>
>>> Or we could try to fix them :-)
>>>
>>> I looked at the two war files and they are different and I wonder what we
>>> actually use.
>>>
>>> old war (geronimo-dojo-legacy):
>>> -rw-r--r--151841 15-May-2007 02:11:02 dojo.js
>>> -rw-r--r--326567 15-May-2007 02:11:04 dojo.js.uncompressed.js
>>> -rw-r--r-- 1170 15-May-2007 02:06:02 flash6_gateway.swf
>>> -rw-r--r-- 2364 15-May-2007 02:06:02 iframe_history.html
>>> -rw-r--r-- 11346 15-May-2007 02:06:02 LICENSE
>>> -rw-r--r-- 13133 14-Jul-2009 15:01:02 META-INF/LICENSE
>>> -rw-r--r-- 587 14-Jul-2009 15:01:02 META-INF/NOTICE
>>> -rw-r--r-- 1609 15-May-2007 02:11:32 src/a11y.js
>>> ..
>>> everything else is under src/
>>>
>>> new war (geronimo-dojo-0.4.3):
>>> just the contents of src from geronimo-dojo-legacy.
>>>
>>> So what do we actually use here? if its just dojo.js we can shrink it by
>>> leaving out the uncompressed.js and all the little files. If its just the
>>> little files under src we can use the new war and change the references to
>>> leave out the "src/" bit. Maybe I can come up with an alternate profile to
>>> build a war with just dojo.js in it??
>>>
>>> wishing I understood javascript delivery even a little bit...
>>> david jencks
>>>
>>>
>>> HTH
>>> Rex.
>>>
>>>
>>> 2009/7/15 Rex Wang
>>>
I'd like to try it :-)
-Rex
2009/7/15 David Jencks
Jay -- many thanks for trying out the patch and co
[jira] Commented: (GERONIMO-4750) port dojo-legacy external
[ https://issues.apache.org/jira/browse/GERONIMO-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731962#action_12731962 ] Rex Wang commented on GERONIMO-4750: Before current solution, which copied all the worked js files to the external dojo 0.4.3 project, I tried to build the http://svn.dojotoolkit.org/src/tags/release-0.4.3/. Unfortunately, although the build can be run successfully, it requires to install 3 ant libs to /.ant/lib firstly, otherwise will shows: ~ -check-config: -fix-config: [copy] Copying 3 files to C:\Documents and Settings\Rex\.ant\lib [echo] [echo] ++ [echo] | Due to some horrendous design decisions by the authors | [echo] | of Ant, it has been necessary to install some jar | [echo] | files to your ~/.ant/ directory. Given the nature of | [echo] | the problem, it will be necessary for you to re-run | [echo] | your build command.| [echo] || [echo] | The Dojo team apologies for this inconvenience.| [echo] || [echo] | The system will now exit. | [echo] ++ [echo] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An Ant BuildException has occured: The following error occurred while executing this line: D:\_g\ext\trunk\geronimo-dojo-0.4.3\target\resources\buildscripts\build.xml:198: Sorry, please re-run your build command, it should work now. ~ That means the ant script firstly check : if not, it will autoly add the libs to your ant/lib and require you to re-run this script. That is really frustrating. I also tried to fish the src/ files out of dojo svn, but that not worked with the dojo.js correctly. So, the current solution is the only choice. -Rex > port dojo-legacy external > - > > Key: GERONIMO-4750 > URL: https://issues.apache.org/jira/browse/GERONIMO-4750 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: Rex Wang >Assignee: Rex Wang > Fix For: 2.2 > > Attachments: GERONIMO-4750.patch, geronimo-dojo-0.4.3.patch > > > the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4751) Upgrade 2.1.x to Tomcat 6.0.20
Upgrade 2.1.x to Tomcat 6.0.20 -- Key: GERONIMO-4751 URL: https://issues.apache.org/jira/browse/GERONIMO-4751 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Kevan Miller We need to upgrade our branches/2.1 to use Tomcat 6.0.20. As we do this, we should move to the new Geronimo External generated version. Rather than create a new private repo version. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4750) port dojo-legacy external
[ https://issues.apache.org/jira/browse/GERONIMO-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang reassigned GERONIMO-4750: -- Assignee: Rex Wang > port dojo-legacy external > - > > Key: GERONIMO-4750 > URL: https://issues.apache.org/jira/browse/GERONIMO-4750 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: Rex Wang >Assignee: Rex Wang > Fix For: 2.2 > > Attachments: GERONIMO-4750.patch, geronimo-dojo-0.4.3.patch > > > the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4750) port dojo-legacy external
[ https://issues.apache.org/jira/browse/GERONIMO-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4750: --- Attachment: GERONIMO-4750.patch GERONIMO-4750.patch update the server trunk\plugins\dojo-legacy to use the external dojo0.4.3 > port dojo-legacy external > - > > Key: GERONIMO-4750 > URL: https://issues.apache.org/jira/browse/GERONIMO-4750 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: Rex Wang > Fix For: 2.2 > > Attachments: GERONIMO-4750.patch, geronimo-dojo-0.4.3.patch > > > the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4750) port dojo-legacy external
[ https://issues.apache.org/jira/browse/GERONIMO-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rex Wang updated GERONIMO-4750: --- Attachment: geronimo-dojo-0.4.3.patch the geronimo-dojo-0.4.3.patch added all the worked js underneath "src" and the dojo.js into the "external\trunk\geronimo-dojo-0.4.3\src\main\webapp" > port dojo-legacy external > - > > Key: GERONIMO-4750 > URL: https://issues.apache.org/jira/browse/GERONIMO-4750 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 2.2 >Reporter: Rex Wang > Fix For: 2.2 > > Attachments: geronimo-dojo-0.4.3.patch > > > the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4750) port dojo-legacy external
port dojo-legacy external - Key: GERONIMO-4750 URL: https://issues.apache.org/jira/browse/GERONIMO-4750 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.2 Reporter: Rex Wang Fix For: 2.2 the last artifact in our svn repo is the dojo 0.4.3, we need port it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4749) resource type should be car if creating via console wizard
resource type should be car if creating via console wizard -- Key: GERONIMO-4749 URL: https://issues.apache.org/jira/browse/GERONIMO-4749 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: console Affects Versions: 2.1.5, 2.2 Environment: Any Reporter: Chi Runhua Priority: Minor By default, the resource type created via console wizard is rar. In this case, the user is not able to convert the resource into a geronimo plugin via console. And the description on portlet *Create Plugin* is confusing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
About Geronimo EJB Cluster and JMS Cluster
All: As I know, geronimo only supports web cluster with WADI by now. EJB cluster and JMS cluster are not supported yet. Is my information correct? If it was true, any plans to support these features. Any information about this is appreciated. Thanks. Best Regards. Michael Lu
Re: Should we filter those unimportant log out from current server log ?
Can anyone give any comments to the patch to G-4712 ? On Mon, Jul 13, 2009 at 2:32 PM, Shawn Jiang wrote: > I upload a patch to remove some extra log here: > > https://issues.apache.org/jira/browse/GERONIMO-4712 > > Can anyone give any comments ? Thanks in advance. > > > > On Thu, Jun 25, 2009 at 1:53 PM, Shawn Jiang wrote: > >> For those log in specific class or package. We can remove them through >> log4j config file. >> But for those we want to remove part of them in a class. We have to >> modify the code. I've opened a JIRA: >> https://issues.apache.org/jira/browse/GERONIMO-4712 to track this. >> >> >> On Thu, Jun 25, 2009 at 12:12 PM, Jack Cai wrote: >> >>> I agree. Some "INFO" in the current log are not very useful. >>> >>> Other than changing the log level in the code, another option is to >>> modify the default log4j configuration file, which might be easier to do. >>> >>> -Jack >>> >>> >>> On Tue, Jun 23, 2009 at 11:39 PM, Shawn Jiang wrote: >>> I believe there are some log that needs to be filtered out from current server log because they are not good/useful information as part of default INFO in log. All these kind of log messages could do is to bury the useful info or to mislead the new users. Some sample of them are: 2009-06-12 16:53:55,171 INFO [PortletContextManager] Registering 24 portlets for context /console-base 2009-06-12 16:53:55,203 INFO [PortletContextManager] Portlet application with application id '/console-base' already registered. 2009-06-12 16:53:55,203 INFO [PortletContextManager] Registering 24 portlets for context /console-base 2009-06-12 16:53:55,234 INFO [PortletContextManager] Portlet application with application id '/console-base' already registered. 2009-06-12 16:53:55,234 INFO [PortletContextManager] Registering 24 portlets for context /console-base 2009-06-12 16:53:55,265 INFO [PortletContextManager] Portlet application with application id '/console-base' already registered. . 2009-06-23 13:22:36,484 INFO [XSRFHandler] Created session for uid=null with sessionId=2486E123C24B5E399859E9F5BAFD95BD, uniqueId=-7432393335768912086 2009-06-23 13:22:36,546 INFO [XSRFHandler] Updated HTML content with XSRF JavaScript for requestURI=/ Maybe we could just redirect them to another log file or just change these kind of message to DEBUG from current INFO. Anyway, we must make sure the default log be *concise *and only contain important info *that users want to know*. Any comments ? -- Shawn >>> >>> >> >> >> -- >> Shawn >> > > > > -- > Shawn > -- Shawn
Re: Do we want to apply genesis 2.0 resource filtering best practice ?
Thanks for your replies, I'll go ahead to submit patches on this.
On Thu, Jul 16, 2009 at 2:19 PM, Jason Dillon wrote:
> Me too :-) I guess that is why I put that in there, just never updated
> projects to use it.
> --jason
>
>
> On Jul 16, 2009, at 1:08 PM, David Jencks wrote:
>
>
> On Jul 15, 2009, at 10:46 PM, Shawn Jiang wrote:
>
> I noticed there's a maven resource best practice defined in
> genesis-default-flava-2.0.pom.
>
> 1, Put normal resource under : ${project.basedir}/ src/main/resources
> 2, Put the resource that needs filtering under: ${project.basedir}/
> src/main/filtered-resources
>
> At the same time, many projects in Geronimo does not follow this practice.
> A JIRA was opened for this :
> https://issues.apache.org/jira/browse/GERONIMO-4737
>
> If no objection, I'm going to use GERONIMO-4737 to fix this kind of
> problems in current code base. Any comments ?
>
>
> Looks like a good idea to me!
> thanks
> david jencks
>
> --
> Shawn
>
>
>
>
--
Shawn
[jira] Updated: (GERONIMO-4668) Parse XML error after deploying a EJB security jar
[ https://issues.apache.org/jira/browse/GERONIMO-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu updated GERONIMO-4668: --- Comment: was deleted (was: This problem is fixed in latest build.So close it.) > Parse XML error after deploying a EJB security jar > -- > > Key: GERONIMO-4668 > URL: https://issues.apache.org/jira/browse/GERONIMO-4668 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.2 > Environment: OS:suse 10 Sp2 64bit >Reporter: viola.lu > Attachments: EJBSecurity.zip, openejb-jar.xml > > > 1.Copy attached dw_groups and dw_user files to $server_home/var/security > 2.Deploy attached security realm plan xml to server > 3.Deploy attached ejb run as jar to server, parse error popsup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[BUILD] trunk: Failed for Revision: 794543
Geronimo Revision: 794543 built with tests included
See the full build-0300.log file at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716/build-0300.log
Download the binaries from
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 41 minutes 13 seconds
[INFO] Finished at: Thu Jul 16 03:45:04 EDT 2009
[INFO] Final Memory: 431M/972M
[INFO]
TESTSUITE RESULTS (Failures only)
=
Assembly: tomcat
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716/logs-0300-tomcat/
Assembly: jetty
=
See full test results and logs at
http://people.apache.org/builds/geronimo/server/binaries/trunk/20090716/logs-0300-jetty/
[INFO] snapshot
org.apache.geronimo.assemblies:geronimo-jetty7-javaee5:2.2-SNAPSHOT: checking
for updates from apache.snapshots
[INFO] Using assembly artifact:
org.apache.geronimo.assemblies:geronimo-jetty7-javaee5:zip:bin:2.2-SNAPSHOT:provided
[INFO] Using geronimoHome:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-jetty7-javaee5-2.2-SNAPSHOT
[INFO] Installing assembly...
[INFO] Expanding:
/home/geronimo/.m2/repository/org/apache/geronimo/assemblies/geronimo-jetty7-javaee5/2.2-SNAPSHOT/geronimo-jetty7-javaee5-2.2-SNAPSHOT-bin.zip
into /home/geronimo/geronimo/trunk/testsuite/target
[INFO] Starting Geronimo server...
[INFO] Selected option set: default
[INFO] Redirecting output to:
/home/geronimo/geronimo/trunk/testsuite/target/geronimo-logs/org.apache.geronimo.mavenplugins.geronimo.server.StartServerMojo.log
[INFO] Waiting for Geronimo server...
[INFO] Geronimo server started in 0:00:49.854
[INFO] [shitty:install {execution: default}]
[INFO] Installing /home/geronimo/geronimo/trunk/testsuite/pom.xml to
/home/geronimo/.m2/repository/org/apache/geronimo/testsuite/testsuite/testing/testsuite-testing.pom
[INFO] [shitty:test {execution: default}]
[INFO] Starting 36 test builds
[INFO]
[INFO]
---
[INFO]
[INFO] commands-testsuite/deploy RUNNING
[INFO] commands-testsuite/deploy SUCCESS (0:01:16.001)
[INFO] commands-testsuite/gshell RUNNING
[INFO] commands-testsuite/gshell SUCCESS (0:00:35.656)
[INFO] commands-testsuite/jaxws RUNNING
[INFO] commands-testsuite/jaxws SUCCESS (0:00:41.499)
[INFO] commands-testsuite/shutdownRUNNING
[INFO] commands-testsuite/shutdownSUCCESS (0:00:21.786)
[INFO] concurrent-testsuite/concurrent-basic RUNNING
[INFO] concurrent-testsuite/concurrent-basic SUCCESS (0:06:24.254)
[INFO] console-testsuite/advanced RUNNING
[INFO] console-testsuite/advanced FAILURE (0:00:22.320) Java
returned: 1
[INFO] console-testsuite/basicRUNNING
[INFO] console-testsuite/basicSUCCESS (0:02:13.560)
[INFO] corba-testsuite/corba-helloworld RUNNING
[INFO] corba-testsuite/corba-helloworld SUCCESS (0:00:53.809)
[INFO] corba-testsuite/corba-marshal RUNNING
[INFO] corba-testsuite/corba-marshal SUCCESS (0:00:56.879)
[INFO] corba-testsuite/corba-mytime RUNNING
[INFO] corba-testsuite/corba-mytime SUCCESS (0:00:47.816)
[INFO] deployment-testsuite/deployment-tests RUNNING
[INFO] deployment-testsuite/deployment-tests SUCCESS (0:00:34.681)
[INFO] deployment-testsuite/jca-cms-tests RUNNING
[INFO] deployment-testsuite/jca-cms-tests SUCCESS (0:00:34.370)
[INFO] deployment-testsuite/manifestcp-tests RUNNING
[INFO] deployment-testsuite/manifestcp-tests SUCCESS (0:00:36.756)
[INFO] enterprise-testsuite/ejb-tests RUNNING
[INFO] enterprise-testsuite/ejb-tests SUCCESS (0:00:46.991)
[INFO] enterprise-testsuite/jms-tests RUNNING
[INFO] enterprise-testsuite/jms-tests SUCCESS (0:01:00.133)
[INFO] enterprise-testsuite/jpa-tests RUNNING
[INFO] enterprise-testsuite/jpa-tests SUCCESS (0:00:46.449)
[INFO] enterprise-testsuite/sec-clientRUNNING
[INFO] enterprise-testsuite/sec-clientSUCCESS (0:00:31.614)
[INFO] enterprise-testsuite/sec-tests RUNNING
[INFO] enterprise-testsuite/sec-tests SUCCESS (0:00:53.633)
[INFO] security-testsuite/test-security RUNNING
[INFO] security-testsuite/test-security SUCCESS (0:00:50.893)
[INFO] web-testsuite/test-2.1-jspsRUNNING
[INFO] web-testsuite/test-2.1-jspsSUCCESS (0:00:34.372)
[INFO] web-testsuite/test-2.5
[jira] Reopened: (GERONIMO-4668) Parse XML error after deploying a EJB security jar
[ https://issues.apache.org/jira/browse/GERONIMO-4668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] viola.lu reopened GERONIMO-4668: > Parse XML error after deploying a EJB security jar > -- > > Key: GERONIMO-4668 > URL: https://issues.apache.org/jira/browse/GERONIMO-4668 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 2.2 > Environment: OS:suse 10 Sp2 64bit >Reporter: viola.lu > Attachments: EJBSecurity.zip, openejb-jar.xml > > > 1.Copy attached dw_groups and dw_user files to $server_home/var/security > 2.Deploy attached security realm plan xml to server > 3.Deploy attached ejb run as jar to server, parse error popsup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4748) Security context is not cleared before the thread is returned to the pool for Tomcat
Security context is not cleared before the thread is returned to the pool for Tomcat Key: GERONIMO-4748 URL: https://issues.apache.org/jira/browse/GERONIMO-4748 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1.5, 2.2 Reporter: Ivan Priority: Critical Fix For: 2.1.5, 2.2 We do some authentication in the TomcatGeronimoRealm, and set the security context, but it is not cleared later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Security configuration principal-role mapping
In the online schema http://geronimo.apache.org/xml/ns/security-2.0 , there is no definition for . But I really find the attribute in /schema/geronimo-security-2.0.xsd. Dose the online schema need to be updated? -- Best Regards, Rodger.
[jira] Created: (GERONIMODEVTOOLS-583) and coexistence results in error in geronimo-application deployment plan on eclipse 3.5
and coexistence results in error in geronimo-application deployment plan on eclipse 3.5 -- Key: GERONIMODEVTOOLS-583 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-583 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Environment: os:win 2003 eclipse: 3.5 JDK: 1.5 Reporter: viola.lu Assignee: Delos Dai Priority: Minor 1.Install GEP in eclipse 3.5 , and create an enterprise application project, add admin in application.xml deployment descriptor, 2.Open geronimo-application.xml , add: to it, but there is an error in deployment plan. This problem doesn't exist in eclipse 3.4.* -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Which dojo?
On Jul 16, 2009, at 12:04 AM, Rex Wang wrote:
yes, the size of two dojo.js is very different. I guess we should
first build the checked out codes. I am looking into the
buildscripts of it, but can not make a build successfully:-(, still
investigating...
I worried about how much time it would take to figure out the build
and decided that at least if the dojo.js was the only file needed we
should just put the "compiled" version in svn
Even though we need more I think it may well be worthwhile to save
time and just put everything in svn that we need. Either that or the
compiled dojo.js (as I did already) and fish the src/ files out of
dojo svn.
Remember this is hopefully a short-term dependency.
thanks
david jencks
-Rex
2009/7/16 David Jencks
On Jul 15, 2009, at 7:47 PM, Rex Wang wrote:
I think the main reason why the new war has the different structure
with the old one is:
in the pom.xml of ext\trunk\geronimo-dojo-0.4.3, only check out the
files in "src" to target/resource
checkout
generate-resources
checkout
${project.basedir}/
target/resources
scm:svn:http://svn.dojotoolkit.org/src/tags/release-0.4.3/src/
I just tried "scm:svn:http://svn.dojotoolkit.org/src/tags/release-0.4.3/
", and the JMX and LDAP portlet seems working correctly, but the
other three still have some problems to show the tree.
I couldn't figure out what the dojo build.xml or build shell scripts
were doing, but it looked to me like the dojo.js in our war file was
really different from the dojo.js in svn. I was hoping that only
the dojo.js was actually used but obviously I was wrong.
Unless you can figure out a better svn-checkout-from-dojo solution I
think I'd try putting all the dojo files we need into src/main/
resources in the externals project. I can do this pretty easily,
probably more easily than from a patch let me know.
thanks
david jencks
-Rex
2009/7/16 David Jencks
On Jul 15, 2009, at 6:27 AM, Rex Wang wrote:
tried it.
1.
svn co
https://svn.apache.org/repos/asf/geronimo/external/trunk/geronimo-dojo-0.4.3
mvn clean install
success!
2.
modify the plugins/dojo-legacy stuff
the patch in attachment shows the modification.
build successfully
3.
I did not build the entire server, but just remove the old one,
and install the new one.
I believe only the debug-views portlets use this legacy dojo,
because when I stop the dojo-legacy-tomcat plugin, only the
debugviews-console-tomcat web project stopped autoly. and I also
searched all the jsps underneath plugins folder in the server
build tree, only show the ones from debugviews holding reference
to "/dojo/0.4/dojo.js"
results:
Unfortunately, the debugviews portlet don't display corretly...
I make some screen shot. Shall we open a jira for this so that I
can upload them, which apparently shows dojo not work correctly?
Or we could try to fix them :-)
I looked at the two war files and they are different and I wonder
what we actually use.
old war (geronimo-dojo-legacy):
-rw-r--r--151841 15-May-2007 02:11:02 dojo.js
-rw-r--r--326567 15-May-2007 02:11:04
dojo.js.uncompressed.js
-rw-r--r-- 1170 15-May-2007 02:06:02 flash6_gateway.swf
-rw-r--r-- 2364 15-May-2007 02:06:02 iframe_history.html
-rw-r--r-- 11346 15-May-2007 02:06:02 LICENSE
-rw-r--r-- 13133 14-Jul-2009 15:01:02 META-INF/LICENSE
-rw-r--r-- 587 14-Jul-2009 15:01:02 META-INF/NOTICE
-rw-r--r-- 1609 15-May-2007 02:11:32 src/a11y.js
..
everything else is under src/
new war (geronimo-dojo-0.4.3):
just the contents of src from geronimo-dojo-legacy.
So what do we actually use here? if its just dojo.js we can shrink
it by leaving out the uncompressed.js and all the little files. If
its just the little files under src we can use the new war and
change the references to leave out the "src/" bit. Maybe I can
come up with an alternate profile to build a war with just dojo.js
in it??
wishing I understood javascript delivery even a little bit...
david jencks
HTH
Rex.
2009/7/15 Rex Wang
I'd like to try it :-)
-Rex
2009/7/15 David Jencks
Jay -- many thanks for trying out the patch and committing it.
I think the last artifact in our svn repo is the dojo 0.4.3. I
can't find it released anywhere but the source code is in a handy
svn repo. I cooked up a modification of our war-packaging for it
that uses the maven scm plugin to check out the source so it can
be packaged easily. I wonder if someone could try this out and
see if it works?
-- check out new war project and build it
svn co
https://svn.apache.org/repos/asf/geronimo/external/trunk/geronimo-dojo-0
Re: Which dojo?
yes, the size of two dojo.js is very different. I guess we should first
build the checked out codes. I am looking into the buildscripts of it, but
can not make a build successfully:-(, still investigating...
-Rex
2009/7/16 David Jencks
>
> On Jul 15, 2009, at 7:47 PM, Rex Wang wrote:
>
> I think the main reason why the new war has the different structure with
> the old one is:
> in the pom.xml of ext\trunk\geronimo-dojo-0.4.3, only check out the files
> in "src" to target/resource
>
> checkout
> generate-resources
>
> checkout
>
>
>
> ${project.basedir}/target/resources
> scm:svn:
> http://svn.dojotoolkit.org/src/tags/release-0.4.3/*src/*
>
>
>
> I just tried "scm:svn:http://svn.dojotoolkit.org/src/tags/release-0.4.3/";,
> and the JMX and LDAP portlet seems working correctly, but the other three
> still have some problems to show the tree.
>
>
> I couldn't figure out what the dojo build.xml or build shell scripts were
> doing, but it looked to me like the dojo.js in our war file was really
> different from the dojo.js in svn. I was hoping that only the dojo.js was
> actually used but obviously I was wrong.
>
> Unless you can figure out a better svn-checkout-from-dojo solution I think
> I'd try putting all the dojo files we need into src/main/resources in the
> externals project. I can do this pretty easily, probably more easily than
> from a patch let me know.
>
> thanks
> david jencks
>
>
> -Rex
>
> 2009/7/16 David Jencks
>
>>
>> On Jul 15, 2009, at 6:27 AM, Rex Wang wrote:
>>
>> tried it.
>>
>> 1.
>> svn co
>> https://svn.apache.org/repos/asf/geronimo/external/trunk/geronimo-dojo-0.4.3
>> mvn clean install
>> success!
>>
>> 2.
>> modify the plugins/dojo-legacy stuff
>> the patch in attachment shows the modification.
>> build successfully
>>
>> 3.
>> I did not build the entire server, but just remove the old one, and
>> install the new one.
>> I believe only the debug-views portlets use this legacy dojo, because when
>> I stop the dojo-legacy-tomcat plugin, only the debugviews-console-tomcat web
>> project stopped autoly. and I also searched all the jsps underneath plugins
>> folder in the server build tree, only show the ones from debugviews holding
>> reference to "/dojo/0.4/dojo.js"
>>
>> results:
>> Unfortunately, the debugviews portlet don't display corretly...
>>
>> I make some screen shot. Shall we open a jira for this so that I can
>> upload them, which apparently shows dojo not work correctly?
>>
>>
>> Or we could try to fix them :-)
>>
>> I looked at the two war files and they are different and I wonder what we
>> actually use.
>>
>> old war (geronimo-dojo-legacy):
>> -rw-r--r--151841 15-May-2007 02:11:02 dojo.js
>> -rw-r--r--326567 15-May-2007 02:11:04 dojo.js.uncompressed.js
>> -rw-r--r-- 1170 15-May-2007 02:06:02 flash6_gateway.swf
>> -rw-r--r-- 2364 15-May-2007 02:06:02 iframe_history.html
>> -rw-r--r-- 11346 15-May-2007 02:06:02 LICENSE
>> -rw-r--r-- 13133 14-Jul-2009 15:01:02 META-INF/LICENSE
>> -rw-r--r-- 587 14-Jul-2009 15:01:02 META-INF/NOTICE
>> -rw-r--r-- 1609 15-May-2007 02:11:32 src/a11y.js
>> ..
>> everything else is under src/
>>
>> new war (geronimo-dojo-0.4.3):
>> just the contents of src from geronimo-dojo-legacy.
>>
>> So what do we actually use here? if its just dojo.js we can shrink it by
>> leaving out the uncompressed.js and all the little files. If its just the
>> little files under src we can use the new war and change the references to
>> leave out the "src/" bit. Maybe I can come up with an alternate profile to
>> build a war with just dojo.js in it??
>>
>> wishing I understood javascript delivery even a little bit...
>> david jencks
>>
>>
>> HTH
>> Rex.
>>
>>
>> 2009/7/15 Rex Wang
>>
>>> I'd like to try it :-)
>>> -Rex
>>>
>>> 2009/7/15 David Jencks
>>>
>>> Jay -- many thanks for trying out the patch and committing it.
I think the last artifact in our svn repo is the dojo 0.4.3. I can't
find it released anywhere but the source code is in a handy svn repo. I
cooked up a modification of our war-packaging for it that uses the maven
scm
plugin to check out the source so it can be packaged easily. I wonder if
someone could try this out and see if it works?
-- check out new war project and build it
svn co
https://svn.apache.org/repos/asf/geronimo/external/trunk/geronimo-dojo-0.4.3
cd geronimo-dojo-0.4.3
mvn clean install
-- modify the plugins/dojo-legacy stuff so that
geronimo-dojo-legacy is not built
the dojo-legacy-jetty and dojo-legacy-tomcat plugins use the
geronimo-dojo-0.4.3-1.0-SNAPSHOT war file instead of the
geronimo-dojo-legac
