[jira] Commented: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1466?page=comments#action_12362774 ] David Jencks commented on GERONIMO-1466: I don't understand your question. We have fixed a bug in geronimo (jetty security problem, requiring changing jetty version number) therefore we need a new geronimo version, currently 1.0.1-SNAPSHOT. Since openejb depends on geronimo, we have to up the openejb version number also. What other choice do we have? If we had version ranges in our dependencies we could avoid changing the openejb version number until we changed openejb code, but we don't at this point. If we had version ranges we wouldn't need 1.0.1 for the jetty version change either. Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: David Jencks Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1466?page=all ] David Jencks reassigned GERONIMO-1466: -- Assign To: Alan Cabrera (was: David Jencks) Also, please don't change the assignment of an issue to ask a question. The mailing list is more appropriate for that IMO. When you are done responding, please reassing to matt. thanks david jencks Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: Alan Cabrera Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Release and Version Philosophy [Discussion]
Matt Hogstrom wrote: First, I see there is a structure for versioning like: v.r.m[.f] where: v = Version r = Release m = modification f = fix (optional) Another minor point - these names are a bit unwieldy and it is difficult to say: 1.0 is the version of a Version release. 1.0.1 is the version of a modification release. 1.1 is the version of a Release release. So how about M.f.u[.p] where: M = major f = feature u = update p = patch (optional) Thus we have: 1.0 is the version of a Major release 1.0.1 is the version of an update release 1.1 is the version of a feature release. cheers
Re: Release and Version Philosophy [Discussion]
Matt, good initiative! I would like to see the philosophy include a bit of process about how a version is create. For example a believe a fix release should definitely be created by the application of a few carefully QA'd patches to an existing released branch of the code. More over, I would like to argue that modification versions, like 1.0.1 should be created in the same way. Ie, they should not be created by a wholesale copy from trunk and then a stabilazation period. I would argue that anything that is to difficult to QA as a few patches would thus self exlcude itself from a modification release. Plus if done without a copy from trunk, all modules would not need to synchronize their development cycles for a modification release like 1.0.1 A Version or Release release should be made from a copy from trunk followed by a stabilazation period. cheers Matt Hogstrom wrote: I've seen several posts about the upcoming 1.0.x release and 1.1 and 2.0 etc. lately and I think its great that we're having these discussions. I'd like to use this thread to aggregate people's thoughts about this topic in a single thread for reference and clarification as we make forward progress. So I'd like to clarify some terminology (at least post what the terms mean to me) so we can make some meaningful plans for our various efforts going forward. This is a strawman so don't get too revved up. I think we need to balance between structure and fluidity and I'm not sure exactly how to do that; input welcome. First, I see there is a structure for versioning like: v.r.m[.f] where: v = Version r = Release m = modification f = fix (optional) Version --- - Represents a significant set of improvements in Geronimo and a definite milestone for our users. - New features are introduced that may break compatibility and require users to have to modify their existing applications that ran on previous Versions. (Although we should strive to not force them to change immediately but rather provide something like a V-1 or -2 compatibility story. -2 Would be excellent but that might be too optimistic given the rate of change. - Things like JEE 5 would be found in a version change. - Goes through a formal Release Candidate process for user feedback and has broad coverage in terms of announcement. (Not just the Dev List) - Release Candidates look something like Geronimo-2.0-RC1/2/3 etc. Release --- - Can include significant new features / improvements. - Should not break existing applications (lot's of traffic from users saying something worked on M5 but doesn't on 1.0) - Includes bug fixes and the like. - It would be hard to justify moving to JEE 5 based on a release change. - Has broad announcement - Does not go through formal Release Candidate Process but does make interim release attempts based on a dated binary release (ala Geronimo-jetty-1.1-rc20060315) Modification - Incremental release that builds on the goals of the V.R its based on. - Can include new features - Cannot disrupt existing application deployments - Includes multiple bug fixes Fix --- - Focused release that addresses a specific critical bug. - We're no where near this now but it would be nice to release specific bug fixes and not whole server releases. - An example of this would be something like a fix to the recent problem Jetty uncovered related to security. A fix in this context would be a simple packaging change to get the new Jetty Jar into the build and wouldn't require a whole new server to be spun off. Thoughts?
Dev branches?
I would like to create a dev branch to start working on some 1.1 and 2.0 stuff. But I don't think it is appropriate to pollute /branch with private branches as it will be good to be able to go there and see all the official branches: /branch/1.0 /branch/1.1 without seeing /branch/djencks /branch/gregw /branch/dain etc. etc. So I would like to propose a secondary location for development branches /devbranch. Moreover, I don't think that development branches should be considered private branches as this would encourage many branches and discourage cooperative development. I think they should be named for the features they are trying to develop. So we would have things like /devbranch/servlet-2.5 /devbranch/openejb-3 /devbranch/kernel I think the policy should be that anything targeted for an x.0 release should be developed in a /devbranch. Anything for a x.y branch can be developed in /trunk or in a /devbranch if it's development may take longer than a single x.y cycle or if it's inclusion in an x.y release is up for debate. Anything for a x.y.z branch can be developed in trunk but should be stabilized in the /branch/x.y
[jira] Created: (GERONIMO-1474) Cross site scripting vulnerabilites
Cross site scripting vulnerabilites
---
Key: GERONIMO-1474
URL: http://issues.apache.org/jira/browse/GERONIMO-1474
Project: Geronimo
Type: Bug
Components: console
Versions: 1.0
Reporter: Greg Wilkins
Fix For: 1.0.1
Reported by oliver karow:
The Web-Access-Log viewer does no filtering for html-/script-tags, and
therefore allows attacks against the user of the admin-console:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert(document.cookie)/script
Also reported:
The first one is a classical cross-site scripting in the jsp-examples:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert('Gotcha')/script
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Geronimo/Jetty 1.0 - CSS and persistent HTML-Injection
oliver karow wrote: I played arround with geronimo 1.0 / Jetty 5.1.9 on Windows platform and found two vulnerabilities: thanks. I've created http://issues.apache.org/jira/browse/GERONIMO-1474 cheers
[jira] Updated: (GERONIMO-1474) Cross site scripting vulnerabilites
[ http://issues.apache.org/jira/browse/GERONIMO-1474?page=all ]
Aaron Mulder updated GERONIMO-1474:
---
Component: security
Fix Version: 1.1
Description:
Reported by oliver karow:
The Web-Access-Log viewer does no filtering for html-/script-tags, and
therefore allows attacks against the user of the admin-console:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert(document.cookie)/script
Also reported:
The first one is a classical cross-site scripting in the jsp-examples:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert('Gotcha')/script
was:
Reported by oliver karow:
The Web-Access-Log viewer does no filtering for html-/script-tags, and
therefore allows attacks against the user of the admin-console:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert(document.cookie)/script
Also reported:
The first one is a classical cross-site scripting in the jsp-examples:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert('Gotcha')/script
Cross site scripting vulnerabilites
---
Key: GERONIMO-1474
URL: http://issues.apache.org/jira/browse/GERONIMO-1474
Project: Geronimo
Type: Bug
Components: console, security
Versions: 1.0
Reporter: Greg Wilkins
Fix For: 1.0.1, 1.1
Reported by oliver karow:
The Web-Access-Log viewer does no filtering for html-/script-tags, and
therefore allows attacks against the user of the admin-console:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert(document.cookie)/script
Also reported:
The first one is a classical cross-site scripting in the jsp-examples:
http://10.10.10.10:8080/jsp-examples/cal/cal2.jsp?time=/scriptalert('Gotcha')/script
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Infiniband
On 14 Jan 2006, at 22:27, lichtner wrote: On Fri, 13 Jan 2006, James Strachan wrote: The infiniband transport would be native code, so you could use JNI. However, it would definitely be worth it. Agreed! I'd *love* a Java API to Infiniband! Have wanted one for ages google every once in a while to see if one shows up :) It looks like MPI has support for Infiniband; would it be worth trying to wrap that in JNI? http://www-unix.mcs.anl.gov/mpi/ http://www-unix.mcs.anl.gov/mpi/mpich2/ I did find that HP has a Java interface for MPI. However, to me it doesn't necessarily seem that this is the way to go. I think for writing distributed computations it would be the right choice, but I think that the people who write those choose to work in a natively compiled language, and I think that this may be the reason why this Java mpi doesn't appear to be that well-known. However I did find something which might work for us, namely UDAPL from the DAT Collaborative. A consortium created a spec for interface to anything that provides RDMA capabilities: http://www.datcollaborative.org/udapl.html The header files and the spec are right there. I downloaded the only release made by infiniband.sf.net and they claim that it only works with kernel 2.4, and that for 2.6 you have to use openib.org. The latter claims to provide an implementation of UDAPL: http://openib.org/doc.html The wiki has a lot of info. From the mailing list archive you can tell that this project has a lot of momentum: http://openib.org/pipermail/openib-general/ Awesome! Thanks for all the links I think the next thing to do would be to prove that using RDMA as opposed to udp is worthwhile. I think it is, because JITs are so fast now, but I think that before planning anything long-term I would get two infiniband-enabled boxes and write a little prototype. Agreed; the important issue is gonna be, can Java with JNI (or Unsafe or one of the alternatives to JNI: http://weblog.janek.org/Archive/ 2005/07/28/AlternativestoJavaNativeI.html) work with RDMA using native ByteBuffers so that the zero copy is avoided and so that things perform better than just using some Infiniband-optimised TCP/ IP implementation. Though to be able to test this we need to make a prototype Java API to RDMA :) But it is definitely well worth the experiment IMHO The main big win is obviously avoiding the double copy of working with TCP/IP though there are other benefits like improved flow control (you know that you can send a message to a consumer how much capacity it has at any point in time so there is no need to worry about slow/dead consumer detection) another is concurrency; in a point-cast model, sending to multiple consumers in 1 thread is trivial (and multi-threading definitely slows down messaging as we found in ActiveMQ). In ActiveMQ the use of RDMA would allow us to do straight through processing for messages which could dramatically cut down on the number of objects created per message the GC overhead. (Indeed we've been musing that it might be possible to avoid most per-message dispatch object allocations if selectors are not used and we wrote a custom RDMA friendly version of ActiveMQMessage; we should also be able to optimise the use of the Journal as we can just pass around the ByteBuffer rather than using OpenWire marshalling. I think Appro sells infiniband blades with Mellanox hcas. There is also IBM's proprietary API for clustering mainframes, the Coupling Facility: http://www.research.ibm.com/journal/sj36-2.html There are some amazing articles there. Great stuff - thanks for the link! Personally I also think there is value in implementing replication using udp (process groups libraries such as evs4j), so I would pursue both at the same time. Yeah; like many things in distributed systems messaging; it all depends on what you are doing as to what solution is the best for your scenario. Certainly both technologies are useful tools to have in your bag when creating middleware. I personally see RDMA as a possible faster alternative for TCP/IP inside message brokers such as ActiveMQ as well as for request-response messaging such as in openejb. James --- http://radio.weblogs.com/0112098/ ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Release and Version Philosophy [Discussion]
Matt Hogstrom wrote, On 1/14/2006 9:02 PM: I've seen several posts about the upcoming 1.0.x release and 1.1 and 2.0 etc. lately and I think its great that we're having these discussions. I'd like to use this thread to aggregate people's thoughts about this topic in a single thread for reference and clarification as we make forward progress. So I'd like to clarify some terminology (at least post what the terms mean to me) so we can make some meaningful plans for our various efforts going forward. This is a strawman so don't get too revved up. I think we need to balance between structure and fluidity and I'm not sure exactly how to do that; input welcome. First, I see there is a structure for versioning like: v.r.m[.f] where: v = Version r = Release m = modification f = fix (optional) Version --- - Represents a significant set of improvements in Geronimo and a definite milestone for our users. - New features are introduced that may break compatibility and require users to have to modify their existing applications that ran on previous Versions. (Although we should strive to not force them to change immediately but rather provide something like a V-1 or -2 compatibility story. -2 Would be excellent but that might be too optimistic given the rate of change. - Things like JEE 5 would be found in a version change. - Goes through a formal Release Candidate process for user feedback and has broad coverage in terms of announcement. (Not just the Dev List) - Release Candidates look something like Geronimo-2.0-RC1/2/3 etc. Release --- - Can include significant new features / improvements. - Should not break existing applications (lot's of traffic from users saying something worked on M5 but doesn't on 1.0) - Includes bug fixes and the like. - It would be hard to justify moving to JEE 5 based on a release change. - Has broad announcement - Does not go through formal Release Candidate Process but does make interim release attempts based on a dated binary release (ala Geronimo-jetty-1.1-rc20060315) Modification - Incremental release that builds on the goals of the V.R its based on. - Can include new features - Cannot disrupt existing application deployments - Includes multiple bug fixes Fix --- - Focused release that addresses a specific critical bug. - We're no where near this now but it would be nice to release specific bug fixes and not whole server releases. - An example of this would be something like a fix to the recent problem Jetty uncovered related to security. A fix in this context would be a simple packaging change to get the new Jetty Jar into the build and wouldn't require a whole new server to be spun off. Thoughts? I see this as a two dimensional problem. How do we communicate to our end users what can be expected and how we go about fulfilling those expectations during our engineering effort. The initial touch point is version numbers. I think that end users are only concerned with how things are compatible when they look at version numbers, not the process that was used to meet those compatibility expectations. I think that you've mixed the two together, which is why you have a Release and Modification. I'm thinking: - merge R and M, having that granularity seems confusing and I cannot think of a compelling scenario that we would need to support to justify it. - remove the last statement of Release; *all* code released, be it V, R, M, or F, by Geronimo needs to go through a formal release candidates. The nomenclature that I would use would be: Major.Minor.Patch(-RC#)+ I'm fleshing out my ideas at http://opensource.atlassian.com/confluence/oss/x/Wgs Regards, Alan
[jira] Assigned: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1466?page=all ] Alan Cabrera reassigned GERONIMO-1466: -- Assign To: Matt Hogstrom (was: Alan Cabrera) Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1466?page=comments#action_12362790 ] Alan Cabrera commented on GERONIMO-1466: You have updated the OpenEJB version during the course of your work to fix the problem reported in GERONIMO-1433. When you checked in that work, you attributed the work to GERONIMO-1446. Should it not have been attributed to GERONIMO-1433? Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dev branches?
Greg Wilkins wrote, On 1/15/2006 4:21 AM: I would like to create a dev branch to start working on some 1.1 and 2.0 stuff. But I don't think it is appropriate to pollute /branch with private branches as it will be good to be able to go there and see all the official branches: /branch/1.0 /branch/1.1 without seeing /branch/djencks /branch/gregw /branch/dain etc. etc. So I would like to propose a secondary location for development branches /devbranch. Moreover, I don't think that development branches should be considered private branches as this would encourage many branches and discourage cooperative development. I think they should be named for the features they are trying to develop. So we would have things like /devbranch/servlet-2.5 /devbranch/openejb-3 /devbranch/kernel I think the policy should be that anything targeted for an x.0 release should be developed in a /devbranch. Anything for a x.y branch can be developed in /trunk or in a /devbranch if it's development may take longer than a single x.y cycle or if it's inclusion in an x.y release is up for debate. Anything for a x.y.z branch can be developed in trunk but should be stabilized in the /branch/x.y Isn't this what a sandbox is for? I see that the sandbox is in geronimo/trunk/sandbox hence, it is improperly versioned. I say improperly because I don't see a reason to version sandbox work. I propose that we move the sandbox to geronimo/sandbox. Regards, Alan
Re: Dev branches?
I support your idea. Making branches for new feature development is a common practice. Were you thinking of doing it for every single change request, or only for big ones? On Sun, 15 Jan 2006, Greg Wilkins wrote: I would like to create a dev branch to start working on some 1.1 and 2.0 stuff. But I don't think it is appropriate to pollute /branch with private branches as it will be good to be able to go there and see all the official branches: /branch/1.0 /branch/1.1 without seeing /branch/djencks /branch/gregw /branch/dain etc. etc. So I would like to propose a secondary location for development branches /devbranch. Moreover, I don't think that development branches should be considered private branches as this would encourage many branches and discourage cooperative development. I think they should be named for the features they are trying to develop. So we would have things like /devbranch/servlet-2.5 /devbranch/openejb-3 /devbranch/kernel I think the policy should be that anything targeted for an x.0 release should be developed in a /devbranch. Anything for a x.y branch can be developed in /trunk or in a /devbranch if it's development may take longer than a single x.y cycle or if it's inclusion in an x.y release is up for debate. Anything for a x.y.z branch can be developed in trunk but should be stabilized in the /branch/x.y
Re: Release and Version Philosophy [Discussion]
APR's versioning guidelines are an awfully good practice, in my experience. http://apr.apache.org/versioning.html -Brian On Jan 15, 2006, at 10:42 AM, Alan D. Cabrera wrote: Matt Hogstrom wrote, On 1/14/2006 9:02 PM: I've seen several posts about the upcoming 1.0.x release and 1.1 and 2.0 etc. lately and I think its great that we're having these discussions. I'd like to use this thread to aggregate people's thoughts about this topic in a single thread for reference and clarification as we make forward progress. So I'd like to clarify some terminology (at least post what the terms mean to me) so we can make some meaningful plans for our various efforts going forward. This is a strawman so don't get too revved up. I think we need to balance between structure and fluidity and I'm not sure exactly how to do that; input welcome. First, I see there is a structure for versioning like: v.r.m[.f] where: v = Version r = Release m = modification f = fix (optional) Version --- - Represents a significant set of improvements in Geronimo and a definite milestone for our users. - New features are introduced that may break compatibility and require users to have to modify their existing applications that ran on previous Versions. (Although we should strive to not force them to change immediately but rather provide something like a V-1 or -2 compatibility story. -2 Would be excellent but that might be too optimistic given the rate of change. - Things like JEE 5 would be found in a version change. - Goes through a formal Release Candidate process for user feedback and has broad coverage in terms of announcement. (Not just the Dev List) - Release Candidates look something like Geronimo-2.0-RC1/2/3 etc. Release --- - Can include significant new features / improvements. - Should not break existing applications (lot's of traffic from users saying something worked on M5 but doesn't on 1.0) - Includes bug fixes and the like. - It would be hard to justify moving to JEE 5 based on a release change. - Has broad announcement - Does not go through formal Release Candidate Process but does make interim release attempts based on a dated binary release (ala Geronimo-jetty-1.1-rc20060315) Modification - Incremental release that builds on the goals of the V.R its based on. - Can include new features - Cannot disrupt existing application deployments - Includes multiple bug fixes Fix --- - Focused release that addresses a specific critical bug. - We're no where near this now but it would be nice to release specific bug fixes and not whole server releases. - An example of this would be something like a fix to the recent problem Jetty uncovered related to security. A fix in this context would be a simple packaging change to get the new Jetty Jar into the build and wouldn't require a whole new server to be spun off. Thoughts? I see this as a two dimensional problem. How do we communicate to our end users what can be expected and how we go about fulfilling those expectations during our engineering effort. The initial touch point is version numbers. I think that end users are only concerned with how things are compatible when they look at version numbers, not the process that was used to meet those compatibility expectations. I think that you've mixed the two together, which is why you have a Release and Modification. I'm thinking: - merge R and M, having that granularity seems confusing and I cannot think of a compelling scenario that we would need to support to justify it. - remove the last statement of Release; *all* code released, be it V, R, M, or F, by Geronimo needs to go through a formal release candidates. The nomenclature that I would use would be: Major.Minor.Patch(-RC#)+ I'm fleshing out my ideas at http://opensource.atlassian.com/confluence/oss/x/Wgs Regards, Alan
Re: Infiniband
I think I have found some information which if I had hardware available would lead me to skip the prototyping stage entirely: This paper benchmarks the performance of infiniband through 1) UDAPL and 2) Sockets Direct Protocol (SDP) - also available from openib.org: Sockets Direct Protocol over Infiniband Clusters: Is it Beneficial? Balaji et al. I think the value of SDP over UDAPL is that it looks like a socket interface, which means porting applications over could even be trivial. However, I think that SDP in that paper does not have zero copy, and that is why the paper shows that UDAPL is faster. However, Mellanox has a zero-copy SDP: Transparently Achieving Superior Socket Performance Using Zero Copy Socket Direct Protocol over 20Gb/s Infiniband Links Goldenberg et al. It's just enlightening to see the two main sources of waste in network applications be removed one at a time, namely 1) context switches and 2) copies. Using zero-copy SDP from Java should be pretty easy, although interfacing with UDAPL would also be valuable. I have found evidence that Sun was planning to include support for Sockets Direct Protocol in jdk 1.6, but that they gave up because infiniband is not mainstream hardware (yet). I think IBM may have put some of this in WebSphere 6: http://domino.research.ibm.com/comm/research.nsf/pages/r.distributed.innovation.html?Openprintable That would be just typical of IBM, understating or flat out hiding important achievements. When Parallex Sysplex came out IBM did a test with 100% data sharing, meaning _all_ reads and writes where remote (to the CF), and measured the scalability, and it's basically linear, but off the diagonal by (only) 13%. Instead of understanding that mainframes now scaled horizontally, the press focused on the overhead. This prompted Lou Goestner that if he invited the press to his house and showcased his dog walking on water the press would report Goestner buys dog that can't swim. I think if I had a few thousand dollars to spare I would definitely get a couple of opteron boxes and get this off the ground. I think from the numbers you can conclude that even where a person wants to be perverse and keep using object serialization, they will still get much better throughput (if not better latency) because half the cpu can be spent executing the jvm rather than switching context and copying data from the memory to itself. I hope somebody with a budget picks this up soon. Guglielmo On Sun, 15 Jan 2006, James Strachan wrote: On 14 Jan 2006, at 22:27, lichtner wrote: On Fri, 13 Jan 2006, James Strachan wrote: The infiniband transport would be native code, so you could use JNI. However, it would definitely be worth it. Agreed! I'd *love* a Java API to Infiniband! Have wanted one for ages google every once in a while to see if one shows up :) It looks like MPI has support for Infiniband; would it be worth trying to wrap that in JNI? http://www-unix.mcs.anl.gov/mpi/ http://www-unix.mcs.anl.gov/mpi/mpich2/ I did find that HP has a Java interface for MPI. However, to me it doesn't necessarily seem that this is the way to go. I think for writing distributed computations it would be the right choice, but I think that the people who write those choose to work in a natively compiled language, and I think that this may be the reason why this Java mpi doesn't appear to be that well-known. However I did find something which might work for us, namely UDAPL from the DAT Collaborative. A consortium created a spec for interface to anything that provides RDMA capabilities: http://www.datcollaborative.org/udapl.html The header files and the spec are right there. I downloaded the only release made by infiniband.sf.net and they claim that it only works with kernel 2.4, and that for 2.6 you have to use openib.org. The latter claims to provide an implementation of UDAPL: http://openib.org/doc.html The wiki has a lot of info. From the mailing list archive you can tell that this project has a lot of momentum: http://openib.org/pipermail/openib-general/ Awesome! Thanks for all the links I think the next thing to do would be to prove that using RDMA as opposed to udp is worthwhile. I think it is, because JITs are so fast now, but I think that before planning anything long-term I would get two infiniband-enabled boxes and write a little prototype. Agreed; the important issue is gonna be, can Java with JNI (or Unsafe or one of the alternatives to JNI: http://weblog.janek.org/Archive/ 2005/07/28/AlternativestoJavaNativeI.html) work with RDMA using native ByteBuffers so that the zero copy is avoided and so that things perform better than just using some Infiniband-optimised TCP/ IP implementation. Though to be able to test this we need to make a prototype Java API to RDMA :) But it is definitely well worth the experiment IMHO The main big win is obviously avoiding
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
David, To paraphrase what you said (if I understand correctly), the choices are to either back clustering out of geronimo for the 1.0.1 release and work on it for a future release, or to make minimal changes to it to make it work in geronimo as is. I think it's unlikely that there will be a significant rush to production with a 1.0 release of geronimo, so there is probably a bit of latitude for less-than-optimal functioning in terms of 2nd order functionality such as clustering if it were to be left in. It would be good to get Jules' input on the state of WADI on this point. However, if we leave clustering in the way it is implemented at the moment, then the disadvantages are: 1. clustering is enabled differently for tomcat and jetty and a basic tenet of geronimo is to make the webcontainers interchangeable 2. clustering is enabled in the webapp descriptors instead of the container 3. users that use the 1.0.1 clustering will have to change each webapp to use it on future releases. If we roll forward again to the most recent clustering changes: 1. clustering interface is uniform for both tomcat and jetty 2. clustering is enabled in the container 3. no geronimo webapp descriptor changes necessary Of course, the most recent changes are not the final clustering solution, so there would be changes to the container plans in the future (eg in 1.1). But changes to the plans could probably be expected for any geronimo services between releases, no? I don't like the option of leaving the clustering with per-webapp geronimo descriptor configuration because it's just simply the wrong way to do it and will be a pain in the neck for users when we change to a better way in future releases. I think it would be better to take clustering out than to release 1.0.1 with it like it is. So, the two options I see for 1.0.1 are: 1. take the clustering out and release in 1.1 after more discussion 2. leave clustering in, roll forward again and fix any issues I really don't have a preference either way - I think both are meritworthy. regards Jan I think that it would be better to work on clustering in head and not try to hurry to get something that we know will change and has not been well tested into 1.0.1. I have no experience with actual clustering. Will people who want to use it expect something well tested and stable? Will they be willing to work off snapshot builds to pick up the latest fixes? What would the reaction be to something that only sort of works in an official release? thanks david jencks On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade the log.info to a log.debug I will remove the axion dependency. I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, they will have it. They will implement a simple, unified solution to the issue for all existing cases and get it in to Geronimo 1.0.1 I simply want a speedy, painless resolution so we can continue forward. If everyone else is happy with these terms, then here is my '+1' Jules Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I threw in our .02 on how to integrate the clustering. I would appreciate you discuss code ideas and changes that have such a drastic impact on the Geronimo code base. Here are the issues with your check in: 1) I explained before for Jetty, and obviously now I need to do it for Tomcat, a -1 on Axion as a dependency. There should not be any web application dependencies injected at the container level. This means there is a severe architectural issue with WADI when we are injecting these dependencies into the container. 2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the distributablesession manager in the TomcatContainer. Hardcoding a pluggable session engine is very bad, and defeats the pluggability of a configuration that we requested. 3) You placed log.info() in the code, and Aaron worked pretty hard to clean those up. 4) Your integration of setting the
Re: Dev branches?
lichtner wrote: Were you thinking of doing it for every single change request, or only for big ones? I don't think it is needed for every single change request. Anything that is destined for the next release can be done in trunk. But a good place for dev branches would be great for anything that will be unusally disruptive, not destined for the next release or of an experimental or dubious nature. cheers
[jira] Commented: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1466?page=comments#action_12362793 ] David Jencks commented on GERONIMO-1466: I assume you in the previous comment means me, david jencks. I personally had nothing to do with fixing 1433, and fixing 1433 has no code impact on openejb AFAIK. Starting work on 1.0.1 means we need a new openejb version as well. I assume more work than 1433 is going into 1.0.1, such as the installer, so I don't see the point in tracking the build changes needed to move to 1.0.1-SNAPSHOT in 1433. IMO these build/version changes should have been done the moment 1.0 was released before any code changes were made, such as to fix 1433. I don't understand why you think this is associated in any way with 1433. Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Improvement Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1475) Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed
[ http://issues.apache.org/jira/browse/GERONIMO-1475?page=comments#action_12362794 ] David Jencks commented on GERONIMO-1475: Won't this break the packaging build from configs? These use the same configurations, and rely on the jars being in the local maven repository. Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed --- Key: GERONIMO-1475 URL: http://issues.apache.org/jira/browse/GERONIMO-1475 Project: Geronimo Type: Bug Components: common Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun 1.4.2_08 Reporter: Donald Woods Assignee: Donald Woods Priority: Trivial Fix For: 1.1, 1.0.1 Attachments: Geronimo-1475.patch The following Configs need to be updated so Xerces is not duplicated into the repository, since is already included under lib\endorsed - client-system j2ee-system by removing the following from the 2 Xerces dependencies - properties geronimo.dependencytrue/geronimo.dependency /properties -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1475) Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed
[ http://issues.apache.org/jira/browse/GERONIMO-1475?page=all ] Donald Woods updated GERONIMO-1475: --- Attachment: Geronimo-1475.patch attaching patch for client-system and j2ee-system to not duplicate Xerces files into Repository Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed --- Key: GERONIMO-1475 URL: http://issues.apache.org/jira/browse/GERONIMO-1475 Project: Geronimo Type: Bug Components: common Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun 1.4.2_08 Reporter: Donald Woods Assignee: Donald Woods Priority: Trivial Fix For: 1.1, 1.0.1 Attachments: Geronimo-1475.patch The following Configs need to be updated so Xerces is not duplicated into the repository, since is already included under lib\endorsed - client-system j2ee-system by removing the following from the 2 Xerces dependencies - properties geronimo.dependencytrue/geronimo.dependency /properties -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1476) Changes to default log4j.rootCategory are not dynamic
Changes to default log4j.rootCategory are not dynamic - Key: GERONIMO-1476 URL: http://issues.apache.org/jira/browse/GERONIMO-1476 Project: Geronimo Type: Bug Components: Logging Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun JDK 1.4.2_08 Reporter: Donald Woods Assigned to: Donald Woods Fix For: 1.1, 1.0.1 Changes to the log4j.rootCategory value in server-log4j.properties while the server is running has no effect. If you change the default - log4j.rootCategory=INFO, CONSOLE, FILE to log4j.rootCategory=ALL, CONSOLE, FILE none of the Log4J loggers are updated to emit the additional log levels of Debug, Trace and All. Updating the following appender - log4j.appender.FILE.threshold=INFO to ALL is dynamic for already set components, so the timer thread to pickup changes to server-log4j.properties is working, but the rootCategory is never updated if changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1466?page=all ] Alan Cabrera updated GERONIMO-1466: --- type: Task (was: Improvement) Preparing 1.0 branch for development of 1.0.1 - Key: GERONIMO-1466 URL: http://issues.apache.org/jira/browse/GERONIMO-1466 Project: Geronimo Type: Task Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.0.1 Update the 1.0 Branch with the changes to prepare it for 1.0.1 This JIRA will be used to track all changes required to version for 1.0.1 so moving from SNAPSHOT to a release will be a bit simpler. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1457) Change trunk version to 1.1-SNAPSHOT
[ http://issues.apache.org/jira/browse/GERONIMO-1457?page=comments#action_12362801 ] David Jencks commented on GERONIMO-1457: I don't see exactly how this can be related to the version change, but 2 spec jars that are needed in lib weren't getting copied there. This might be related more to some maven version issue. Sendingassemblies/j2ee-jetty-server/project.xml Sendingassemblies/j2ee-tomcat-server/project.xml Transmitting file data .. Committed revision 369300. Change trunk version to 1.1-SNAPSHOT Key: GERONIMO-1457 URL: http://issues.apache.org/jira/browse/GERONIMO-1457 Project: Geronimo Type: Bug Components: buildsystem Versions: 1.1 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1 Set geronimo_version to 1.1-SNAPSHOT. Try to reduce the number of places it is found. I guess, set openejb version to 2.1-SNAPSHOT. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1396) Provide consistent look and feel for table views in the web console across all portlets
[ http://issues.apache.org/jira/browse/GERONIMO-1396?page=all ] Alan Cabrera updated GERONIMO-1396: --- Fix Version: 1.1 1.x (was: 1.0.1) This is not a fix for a bug. It needs to go into trunk. Provide consistent look and feel for table views in the web console across all portlets --- Key: GERONIMO-1396 URL: http://issues.apache.org/jira/browse/GERONIMO-1396 Project: Geronimo Type: Improvement Components: console Versions: 1.0 Environment: Win XP, IE, firefox Reporter: Joe Bohn Assignee: Joe Bohn Fix For: 1.1, 1.x Attachments: Tables.patch At the moment some of the admin console tables have a Epiq look (blue header, alternately shaded white/grey rows) and some do not. This JIRA is to get a number of these tables implemented with the new look and feel. The changes affect: Web Server - Network Listeners JMS - Server Manager JMS - Network Listeners Database Pools JMS - Connection Factories JMS - Destination Manager Console Realm - Users Console Realm - Groups Security Realm - Users Security Realm - Groups Keystore ( also removed the empty table until the ksitems value is once again set.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1182) Connector portlet improvement (delete connector confirmation, more form buttons)
[ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Alan Cabrera updated GERONIMO-1182: --- Fix Version: 1.1 1.x (was: 1.0.1) This is not a fix for a bug. It needs to go into trunk. Connector portlet improvement (delete connector confirmation, more form buttons) Key: GERONIMO-1182 URL: http://issues.apache.org/jira/browse/GERONIMO-1182 Project: Geronimo Type: Improvement Components: console Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assignee: Aaron Mulder Priority: Minor Fix For: 1.1, 1.x Attachments: GERONIMO-1182.patch Minor improvements to Connector portlet. 1. User confirmation on clicking delete link to delete a connector. 2. Add Reset and Cancel buttons to edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1477) JMX debug tool should not be loaded in the supplied config.xml
JMX debug tool should not be loaded in the supplied config.xml -- Key: GERONIMO-1477 URL: http://issues.apache.org/jira/browse/GERONIMO-1477 Project: Geronimo Type: Bug Components: security Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun JDK 1.4.2_08 Reporter: Donald Woods Assigned to: Donald Woods Fix For: 1.0.1, 1.1 The JMX debugtool application should not be loaded and running on a built server by default. The config.xml for each assembly should be updated to include the load=false attribute. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1448) debug-tool does not work on Tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1448?page=all ] Donald Woods updated GERONIMO-1448: --- Attachment: Geronimo-1448.patch Attaching patch created against latest AG 1.0 branch code for 1.0.1, which fixed this on my local Tomcat build and assembly. Seems that is was related to comments left in the geronimo-web.xml and needing to set UTF-8 in the servlet init-params. debug-tool does not work on Tomcat -- Key: GERONIMO-1448 URL: http://issues.apache.org/jira/browse/GERONIMO-1448 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0 Environment: Geronimo-1.0 Reporter: Kevan Miller Fix For: 1.0.1 Attachments: Geronimo-1448.patch The debug console doesn't work when running Tomcat. The base page loads successfully. However, when you click on a GBean, you get a 404: HTTP Status 404 - /index.vm type Status report message /index.vm description The requested resource (/index.vm) is not available. Apache Tomcat/5.5.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1448) debug-tool does not work on Tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1448?page=all ] Donald Woods updated GERONIMO-1448: --- Geronimo Info: [Patch Available] Fix Version: 1.1 Assign To: Donald Woods debug-tool does not work on Tomcat -- Key: GERONIMO-1448 URL: http://issues.apache.org/jira/browse/GERONIMO-1448 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0 Environment: Geronimo-1.0 Reporter: Kevan Miller Assignee: Donald Woods Fix For: 1.0.1, 1.1 Attachments: Geronimo-1448.patch The debug console doesn't work when running Tomcat. The base page loads successfully. However, when you click on a GBean, you get a 404: HTTP Status 404 - /index.vm type Status report message /index.vm description The requested resource (/index.vm) is not available. Apache Tomcat/5.5.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Lets make something clear here... There are two facets of clustering in Geronimo right now. WADI and Tomcat clustering. The Tomcat clustering uses the Tomcat clustering objects and GBeans and they work and have been tested including a full howto in Confluence: http://opensource2.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Clustering+Example I am completely open to making WADI available in 1.0.1, and will be happy to go along with it being a 1.1 release if that is consensus. I support it in its entirety and where needed. But I do not believe the Tomcat objects should be removed and should be categorized differently, as these have been confirmed as working and ready for use. So when we talk about clustering, I think we need to be more succinct in stating which clustering we are talking about. Jeff Jan Bartel wrote: David, To paraphrase what you said (if I understand correctly), the choices are to either back clustering out of geronimo for the 1.0.1 release and work on it for a future release, or to make minimal changes to it to make it work in geronimo as is. I think it's unlikely that there will be a significant rush to production with a 1.0 release of geronimo, so there is probably a bit of latitude for less-than-optimal functioning in terms of 2nd order functionality such as clustering if it were to be left in. It would be good to get Jules' input on the state of WADI on this point. However, if we leave clustering in the way it is implemented at the moment, then the disadvantages are: 1. clustering is enabled differently for tomcat and jetty and a basic tenet of geronimo is to make the webcontainers interchangeable 2. clustering is enabled in the webapp descriptors instead of the container 3. users that use the 1.0.1 clustering will have to change each webapp to use it on future releases. If we roll forward again to the most recent clustering changes: 1. clustering interface is uniform for both tomcat and jetty 2. clustering is enabled in the container 3. no geronimo webapp descriptor changes necessary Of course, the most recent changes are not the final clustering solution, so there would be changes to the container plans in the future (eg in 1.1). But changes to the plans could probably be expected for any geronimo services between releases, no? I don't like the option of leaving the clustering with per-webapp geronimo descriptor configuration because it's just simply the wrong way to do it and will be a pain in the neck for users when we change to a better way in future releases. I think it would be better to take clustering out than to release 1.0.1 with it like it is. So, the two options I see for 1.0.1 are: 1. take the clustering out and release in 1.1 after more discussion 2. leave clustering in, roll forward again and fix any issues I really don't have a preference either way - I think both are meritworthy. regards Jan I think that it would be better to work on clustering in head and not try to hurry to get something that we know will change and has not been well tested into 1.0.1. I have no experience with actual clustering. Will people who want to use it expect something well tested and stable? Will they be willing to work off snapshot builds to pick up the latest fixes? What would the reaction be to something that only sort of works in an official release? thanks david jencks On Jan 14, 2006, at 3:46 AM, Jules Gosnell wrote: OK, Folks - here is how I see it - Everyone knows that they are right and the other guy is wrong. Result - DEADLOCK - everyone loses. Solution - release locks, back off, coordinate, retry. Releasing locks involves us all making concessions : I suggest - Jan, Greg and I conceded that Jeff could have been more involved in discussion before this change went in. Jeff concedes that Jan, Greg and I should have been involved in discussion before he backed the change out. We all agree to overlook all current technical differences. We all agree to put aside whatever bad feelings may have arisen from this incident. OK - locks released, backing-off complete. Now, coordination : WADI side : I will downgrade the log.info to a log.debug I will remove the axion dependency. I will resubmit the change as a patch to Jan and Jeff. Jetty/Tomcat side : Jan and Jeff will take this patch, and all relevant input. If they feel that they need further discussion, they will have it. They will implement a simple, unified solution to the issue for all existing cases and get it in to Geronimo 1.0.1 I simply want a speedy, painless resolution so we can continue forward. If everyone else is happy with these terms, then here is my '+1' Jules Jeff Genender wrote: Hi Jules. A few comments. First, you made changes without discussing them on the dev lists. As per the discussions in the past, both Aaron and David Jencks, as well as I
Re: Geronimo w/ WebSphere MQ 5.3 XA
hi Jason, I have tried without XA to keep it simple. XA would also work without any issues. You can try this for XA support ( https://genericjmsra.dev.java.net/docs/userguide/userguide.html ). With some modifications this works on geronimo. Regards Krishnakumar B On 1/14/06, Jason Dillon [EMAIL PROTECTED] wrote: Has anyone had any luck getting Geronimo to work with WebSphere MQ 5.3 w/XA? --jason
[jira] Commented: (GERONIMO-1475) Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed
[ http://issues.apache.org/jira/browse/GERONIMO-1475?page=comments#action_12362814 ] Donald Woods commented on GERONIMO-1475: David, I confirmed that my attached patch worked on WinXP by deleting my local .maven directory and running the build again from scratch. Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed --- Key: GERONIMO-1475 URL: http://issues.apache.org/jira/browse/GERONIMO-1475 Project: Geronimo Type: Bug Components: common Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun 1.4.2_08 Reporter: Donald Woods Assignee: Donald Woods Priority: Trivial Fix For: 1.1, 1.0.1 Attachments: Geronimo-1475.patch The following Configs need to be updated so Xerces is not duplicated into the repository, since is already included under lib\endorsed - client-system j2ee-system by removing the following from the 2 Xerces dependencies - properties geronimo.dependencytrue/geronimo.dependency /properties -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1477) JMX debug tool should not be loaded in the supplied config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1477?page=comments#action_12362817 ] David Jencks commented on GERONIMO-1477: Fixed in head: Sendingassemblies/j2ee-jetty-server/src/var/config/config.xml Sendingassemblies/j2ee-tomcat-server/src/var/config/config.xml Transmitting file data .. Committed revision 369381. I don't think this is exactly a bug that we can justify changing in 1.0.1. If anyone feels really strongly otherwise, speak up. Otherwise I will close this. JMX debug tool should not be loaded in the supplied config.xml -- Key: GERONIMO-1477 URL: http://issues.apache.org/jira/browse/GERONIMO-1477 Project: Geronimo Type: Bug Components: security Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun JDK 1.4.2_08 Reporter: Donald Woods Assignee: Donald Woods Fix For: 1.0.1, 1.1 The JMX debugtool application should not be loaded and running on a built server by default. The config.xml for each assembly should be updated to include the load=false attribute. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1477) JMX debug tool should not be loaded in the supplied config.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1477?page=all ] David Jencks resolved GERONIMO-1477: Resolution: Fixed Assign To: David Jencks (was: Donald Woods) Marking resolved pending discussion on port to 1.0.1 JMX debug tool should not be loaded in the supplied config.xml -- Key: GERONIMO-1477 URL: http://issues.apache.org/jira/browse/GERONIMO-1477 Project: Geronimo Type: Bug Components: security Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun JDK 1.4.2_08 Reporter: Donald Woods Assignee: David Jencks Fix For: 1.0.1, 1.1 The JMX debugtool application should not be loaded and running on a built server by default. The config.xml for each assembly should be updated to include the load=false attribute. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1448) debug-tool does not work on Tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1448?page=comments#action_12362820 ] David Jencks commented on GERONIMO-1448: Applied to trunk, although since geronimo-web.xml is not used I removed it. (it has been replaced by the plans in config/jmxdebug-*) Deleting applications/jmxdebug/src/webapp/WEB-INF/geronimo-web.xml Sendingapplications/jmxdebug/src/webapp/WEB-INF/web.xml Transmitting file data . Committed revision 369383. debug-tool does not work on Tomcat -- Key: GERONIMO-1448 URL: http://issues.apache.org/jira/browse/GERONIMO-1448 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0 Environment: Geronimo-1.0 Reporter: Kevan Miller Assignee: Donald Woods Fix For: 1.0.1, 1.1 Attachments: Geronimo-1448.patch The debug console doesn't work when running Tomcat. The base page loads successfully. However, when you click on a GBean, you get a 404: HTTP Status 404 - /index.vm type Status report message /index.vm description The requested resource (/index.vm) is not available. Apache Tomcat/5.5.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
