[jira] Updated: (GERONIMO-597) Access failure ,message does not need to log stacktrace
[ http://issues.apache.org/jira/browse/GERONIMO-597?page=all ] Matt Hogstrom updated GERONIMO-597: --- Fix Version/s: Verification Required (was: 1.2) Access failure ,message does not need to log stacktrace --- Key: GERONIMO-597 URL: http://issues.apache.org/jira/browse/GERONIMO-597 Project: Geronimo Issue Type: Improvement Components: OpenEJB Reporter: Jeremy Boynes Assigned To: David Blevins Priority: Minor Fix For: Verification Required EJBSecurityInterceptor currently logs a full stacktrace when it denies access - it should just log a warning message. -- 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-629) Misleading error when ra.xml is included in the RAR jar as well as the RAR
[ http://issues.apache.org/jira/browse/GERONIMO-629?page=all ] Matt Hogstrom updated GERONIMO-629: --- Fix Version/s: Wish List (was: 1.2) Misleading error when ra.xml is included in the RAR jar as well as the RAR -- Key: GERONIMO-629 URL: http://issues.apache.org/jira/browse/GERONIMO-629 Project: Geronimo Issue Type: Bug Components: connector Affects Versions: 1.0-M3 Reporter: Ross Mason Assigned To: David Jencks Priority: Minor Fix For: Wish List If someone accidentlly builds a jar with the ra.xml included and then includes that jar in a rar and tries to deploy it, the following error occurs - Caused by: java.lang.ClassFormatError: Repetitive interface name in class file org/mule/ra/MuleConnectionFactory$$Enhanc erByCGLIB$$3a4c63ea at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) ... 64 more While the ra.xml should not be in the jar in the first place, a more meaningful error could be given. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-631) Package Derby tools with Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ] Matt Hogstrom closed GERONIMO-631. -- Fix Version/s: 1.1 (was: 1.2) Resolution: Fixed Old issue Package Derby tools with Geronimo - Key: GERONIMO-631 URL: http://issues.apache.org/jira/browse/GERONIMO-631 Project: Geronimo Issue Type: Improvement Components: databases Affects Versions: 1.0-M4 Reporter: John Sisson Assigned To: John Sisson Priority: Minor Fix For: 1.1 IBM now has donated the JDBC network driver code to the Derby project (as a patch) and it is under review (not committed). Once it has been accepted and included in a formal Derby release, it would be worthwhile including it with Geronimo, along with some simple scripts to invoke Derby's ij tool, so Geronimo users can easily manage the embedded Derby database(s). FYI.. the donated JDBC network driver supports XA. Here is a mail thread titled Provision of derby tools JAR and JDBC network driver JAR from the dev list... [EMAIL PROTECTED] wrote: If a Java application (not J2EE app) provides a database creation utility and expects to be able to use a JDBC network driver to connect to the Derby network server embedded in Geronimo, then currently the command line application (the database creation utility) needs access (assuming the IBM Universal Driver is used) to db2jcc.jar and db2jcc_license_c.jar . On the Derby lists I saw that IBM is planning on donating a JDBC network driver sometime in March. Q1. Would it make sense to place this driver jar and the derbytools jar in the geronimo/repository/incubator-derby/jars directory to accompany the other derby jars so we provide all the required jars needed for connecting to and administering the Derby database embedded in Geronimo (even though the driver or tools won't be loaded by Geronimo)? Yes - we already configure and start the network server so having the client jars available would make sense. These could also be used to connect to a Derby instance in a different JVM. Q2. Even if we do provide all the JARs in the repository, users of a command line Java application (running on the same machine) would probably have to edit their classpath to point to the correct version of JDBC driver that matches the version of Derby embedded in Geronimo. Any suggestions on how this could be automated (determining the version and getting the driver JAR)? I think it would depend on how the client app expected this to work and whether it relied on having them in the system classpath or did some fancy uber-jar type thing. One option would be to deploy the client along with the server (EAR) as a J2EE Application Client. IIRC the app client can have a plan associated with it where they can specify dependencies just like with server-side modules. -- Jeremy -- 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-646) Servlet calling HttpServletRequest.isUserInRole(null) causes NPE using Jetty container
[ http://issues.apache.org/jira/browse/GERONIMO-646?page=comments#action_12449846 ] Matt Hogstrom commented on GERONIMO-646: Jeff...is this still an issue? Servlet calling HttpServletRequest.isUserInRole(null) causes NPE using Jetty container -- Key: GERONIMO-646 URL: http://issues.apache.org/jira/browse/GERONIMO-646 Project: Geronimo Issue Type: Bug Components: web Affects Versions: 1.0-M4 Environment: All Reporter: Tom McQueeney Assigned To: Alan Cabrera Priority: Minor Fix For: 1.2 Attachments: JAASJettyRealm-patch.txt, WebRoleRefPermission-patch.txt, WebRoleRefPermissionTest-patch.txt The servlet isUserInRole call eventually gets delegated to org.apache.geronimo.jetty.JAASJettyRealm.isUserInRole, which causes a NPE in javax.security.jacc.WebRoleRefPermission.hashCode(). JAASJettyRealm.isUserInRole creates a WebRoleRefPermission, passing it the null role that it was passed, then delegates the role check to java.security.AccessControlContext.checkPermission, passing it the WebRoleRefPermission. When the web role ref permission gets checked, eventually its hashcode method is called, which tries to compute the hash by getting the hashcode of the (null) role name, which throws the NPE. -- 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: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ http://issues.apache.org/jira/browse/DAYTRADER-25?page=comments#action_12449883 ] Matt Hogstrom commented on DAYTRADER-25: I noticed the creep as well in the values. We should probably look at changing the algorthm for change so the numbers don't grow unbounded :) Update decimal precision and indexes in ddl --- Key: DAYTRADER-25 URL: http://issues.apache.org/jira/browse/DAYTRADER-25 Project: DayTrader Issue Type: Improvement Reporter: Christopher James Blythe Priority: Minor While working with previous versions of Trade, I found that the monetary values stored in the database could overrun the decimal precision defined in the schema (10,2) if allowed to run for an extended period of time. This would result in SQL exceptions related to data conversion. To prevent this we increased the decimal presion to (14,2) We also found that some of the indexs were not necessary and that others should be added. In addition to the primary keys, here are the indexes we found to be the most useful... CREATE INDEX a.profile_userid on accountejb(profile_userid); CREATE INDEX h.account_accountid on holdingejb(account_accountid); CREATE INDEX o.account_accountid on orderejb(account_accountid); CREATE INDEX o.holding_holdingid on orderejb(holding_holdingid); CREATE INDEX o.closed_orders on orderejb(account_accountid,orderstatus); Will wait to submit a patch until the fate of Daytrader-14 is determined. -- 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: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ http://issues.apache.org/jira/browse/DAYTRADER-22?page=comments#action_12449378 ] Matt Hogstrom commented on DAYTRADER-22: Sounds good Piyush. So this raises the $64k dollar question about what modes shoud run and how do they get loaded? In direct mode I think it would be beneficial to not require any EJBs but still use JMS. Perhaps we should open a separate JIRA to address the decoupling of components in DT. Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: http://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: Daytrader-22.patch Currently the publishQuotePriceChange is set to False in the ejb-jar.xml and this causes the TradeStreamerMDB to NOT be accessed during the Daytrader trading runs. The TradeStreamerMDB listens to the JMS messages and invokes the logging code to log the debug and trace messages during the runs. Updating the flag to true enables this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ http://issues.apache.org/jira/browse/DAYTRADER-22?page=all ] Matt Hogstrom closed DAYTRADER-22. -- Fix Version/s: 1.2 Resolution: Won't Fix Assignee: Matt Hogstrom I changed it to false. I would rather add a configuration property so people can explicitly turn this feature on and off. I don't like things buried in .xml files as they are a PITA to change. Also, many people don't use JMS so I'd prefer to the leave the defaults to what 80%+ of the people are interested in. Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: http://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: Daytrader-22.patch Currently the publishQuotePriceChange is set to False in the ejb-jar.xml and this causes the TradeStreamerMDB to NOT be accessed during the Daytrader trading runs. The TradeStreamerMDB listens to the JMS messages and invokes the logging code to log the debug and trace messages during the runs. Updating the flag to true enables this functionality. -- 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: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ http://issues.apache.org/jira/browse/DAYTRADER-22?page=comments#action_12448828 ] Matt Hogstrom commented on DAYTRADER-22: Thanks Piyush...I should add that it was confusing about what a particular runtime mode was actually composed of. There is JDBC mode, EJB mode, long run, no long run, JMS pulishing or not, etc. I think as we noodle on this we should probably add a Runtime Settings: that would allow people to get a summary of the modes in effect. Thanks for thinking about this. Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: http://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: Daytrader-22.patch Currently the publishQuotePriceChange is set to False in the ejb-jar.xml and this causes the TradeStreamerMDB to NOT be accessed during the Daytrader trading runs. The TradeStreamerMDB listens to the JMS messages and invokes the logging code to log the debug and trace messages during the runs. Updating the flag to true enables this functionality. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-21) Indicate that MDB primitives are not intended for performance testing
[ http://issues.apache.org/jira/browse/DAYTRADER-21?page=all ] Matt Hogstrom closed DAYTRADER-21. -- Fix Version/s: 1.1.1 1.2 Resolution: Fixed Assignee: Matt Hogstrom Applied...thanks Chris...this makes it clearer for those that are testing. Indicate that MDB primitives are not intended for performance testing - Key: DAYTRADER-21 URL: http://issues.apache.org/jira/browse/DAYTRADER-21 Project: DayTrader Issue Type: Improvement Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.1.1, 1.2 Attachments: daytrader-21.patch The MDB primitives, PingServlet2MDBQueue and PingServlet2MDBTopic, are not suited for testing MDB performance. The problem stems from a difference in how fast messages can be placed on the queue/topic by the JMS client versus how fast the MDBs can process them. Generally, the messages can be created much faster than they can be consumed. This in turn leads to problems when the maximum queue/topic sizes are reached. -- 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: (DAYTRADER-18) Changing trunk to 2.0-SNAPSHOT and reinstating 1.2 less JPA changes to branches/1.2
Changing trunk to 2.0-SNAPSHOT and reinstating 1.2 less JPA changes to branches/1.2 --- Key: DAYTRADER-18 URL: http://issues.apache.org/jira/browse/DAYTRADER-18 Project: DayTrader Issue Type: Task Affects Versions: 1.2 Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.2 I am moving trunk version 1.2 to branches/1.2 so we have a clear J2EE 1.4 version of DayTrader and allow for Java EE 5.0 functionality to be built in trunk. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-18) Changing trunk to 2.0-SNAPSHOT and reinstating 1.2 less JPA changes to branches/1.2
[ http://issues.apache.org/jira/browse/DAYTRADER-18?page=all ] Matt Hogstrom closed DAYTRADER-18. -- Resolution: Fixed Complete Changing trunk to 2.0-SNAPSHOT and reinstating 1.2 less JPA changes to branches/1.2 --- Key: DAYTRADER-18 URL: http://issues.apache.org/jira/browse/DAYTRADER-18 Project: DayTrader Issue Type: Task Affects Versions: 1.2 Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.2 I am moving trunk version 1.2 to branches/1.2 so we have a clear J2EE 1.4 version of DayTrader and allow for Java EE 5.0 functionality to be built in trunk. -- 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: (DAYTRADER-14) Include sql script in the ear and use a gbean to create tables etc
[ http://issues.apache.org/jira/browse/DAYTRADER-14?page=comments#action_12443523 ] Matt Hogstrom commented on DAYTRADER-14: The challenge as you pointed out is to somehow invalidate the KeySequence SLSBs. Since their most likely pooled it makes it a bit more tricky. The simplest way to do this which is non-standard would be to use a static int or some other fingerprint on the integrity of the tables. However, this doesn't help the situation when your running a cluster of the application so its applicability would be really to a single server. One possibility is to put in a timestamp as static that indicates the last time the table was valid. Then, for each SLSB keep a last used time and compare the two. If the last used is less than the valid then the beans need to be refreshed so all values could be reset at that time. The easiest solution I think is to allow the tables to be created...if they already exist warn the user that they need to recycle their environment. I'd be happy with that solution as its way better than what we have. If someone is repopulating...they should be fine with recycling. If possible, I'd add some text when a duplicate key exception occurs that would tip off the user of the possible problem with the Key entity. Include sql script in the ear and use a gbean to create tables etc -- Key: DAYTRADER-14 URL: http://issues.apache.org/jira/browse/DAYTRADER-14 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Reporter: David Jencks Attachments: d-j-plan.xml, DAYTRADER-14.patch You can use the DatabaseIntitializationGBean (GERONIMO-2396) in a g. plan and include the sql script in the ejb module so the database will get created if not already present. This is way better than the previous hack of including a pre-built database in the car file. -- 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: (DAYTRADER-14) Include sql script in the ear and use a gbean to create tables etc
[ http://issues.apache.org/jira/browse/DAYTRADER-14?page=comments#action_12443686 ] Matt Hogstrom commented on DAYTRADER-14: I'm open to other ideas but I think that is clear and makes life the easiest. Include sql script in the ear and use a gbean to create tables etc -- Key: DAYTRADER-14 URL: http://issues.apache.org/jira/browse/DAYTRADER-14 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Reporter: David Jencks Attachments: d-j-plan.xml, DAYTRADER-14.patch You can use the DatabaseIntitializationGBean (GERONIMO-2396) in a g. plan and include the sql script in the ejb module so the database will get created if not already present. This is way better than the previous hack of including a pre-built database in the car file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-11) AccountProfile field password conflicts with DB2 v9.1 keyword
[ http://issues.apache.org/jira/browse/DAYTRADER-11?page=all ] Matt Hogstrom closed DAYTRADER-11. -- Fix Version/s: 1.2 Resolution: Fixed Applied to trunk as it changes schemas and is inappropriate for 1.x releases. AccountProfile field password conflicts with DB2 v9.1 keyword --- Key: DAYTRADER-11 URL: http://issues.apache.org/jira/browse/DAYTRADER-11 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 1.1, 1.1.1 Environment: DB2 v9.1 Reporter: Christopher James Blythe Priority: Minor Fix For: 1.2 Attachments: daytrader-11.txt The DB2 v9.1 documentation now states that password is a reserved word that should not be used for table/column names, etc. In the AccountProfile ejb we use a password field that is mapped directly to a password column in the database. http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/r0001095.htm In order to prevent this keyword clash, I have modified the AccountProfile field from password to passwd and made the necessary changes in the ejb source, TradeDirect, sql schema, and plan files. The associated patch is attached... -- 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: (DAYTRADER-1) [Daytrader] ejb module should not depend on wsappclient module
[ http://issues.apache.org/jira/browse/DAYTRADER-1?page=comments#action_12437972 ] Matt Hogstrom commented on DAYTRADER-1: --- I did not expose it Chris because it required some additional scrubbing and wasn't my primary concern. I think the standalone app could easily disappear. I['m not sure about the SoapProxy as there is no good way to test WS that I'm aware of. Personally though, I'm not big on WS anyway. Perhaps DJencks has some opinion here. [Daytrader] ejb module should not depend on wsappclient module -- Key: DAYTRADER-1 URL: http://issues.apache.org/jira/browse/DAYTRADER-1 Project: DayTrader Issue Type: Bug Components: EJB Tier Reporter: Vincent Massol Assigned To: Matt Hogstrom There is dependency on the wsappclient jar in the ejb module. That doesn't look right. Does it mean the wsappclient should be split into 2 modules? I haven't investigated more but it smells like a circular depdency somewhere. -- 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-1557) When you enter the url of a web service in the console You should get a page showing the service name
[ http://issues.apache.org/jira/browse/GERONIMO-1557?page=comments#action_12436213 ] Matt Hogstrom commented on GERONIMO-1557: - Applied to trunk: Sending geronimo-axis/src/main/java/org/apache/geronimo/axis/server/AxisWebServiceContainer.java Sending geronimo-axis-builder/src/main/java/org/apache/geronimo/axis/builder/AxisServiceBuilder.java Transmitting file data .. Committed revision 448154. When you enter the url of a web service in the console You should get a page showing the service name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Affects Versions: 1.0 Environment: All Reporter: Manu T George Assigned To: David Jencks Priority: Minor Fix For: 1.1.1, 1.2 Attachments: AxisServiceBuilder.patch, AxisServiceBuilder.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- 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-1557) When you enter the url of a web service in the console You should get a page showing the service name
[ http://issues.apache.org/jira/browse/GERONIMO-1557?page=all ] Matt Hogstrom reassigned GERONIMO-1557: --- Assignee: Matt Hogstrom (was: David Jencks) When you enter the url of a web service in the console You should get a page showing the service name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Affects Versions: 1.0 Environment: All Reporter: Manu T George Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.1.1, 1.2 Attachments: AxisServiceBuilder.patch, AxisServiceBuilder.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1557) When you enter the url of a web service in the console You should get a page showing the service name
[ http://issues.apache.org/jira/browse/GERONIMO-1557?page=all ] Matt Hogstrom closed GERONIMO-1557. --- Fix Version/s: 1.2 Resolution: Fixed When you enter the url of a web service in the console You should get a page showing the service name - Key: GERONIMO-1557 URL: http://issues.apache.org/jira/browse/GERONIMO-1557 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Affects Versions: 1.0 Environment: All Reporter: Manu T George Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.1.1, 1.2 Attachments: AxisServiceBuilder.patch, AxisServiceBuilder.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch, AxisWebServiceContainer.patch When you type the URL of a web service in a browser without the ?wsdl parameter what happens is that a SOAPFault is thrown. Instead we should show a HTML page with the message This is a web service followed by the service name. -- 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-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=comments#action_12436216 ] Matt Hogstrom commented on GERONIMO-2329: - Applied to trunk Sending modules/geronimo-jetty/src/main/java/org/apache/geronimo/jetty/connector/JettyConnector.java Sending modules/geronimo-tomcat/src/main/java/org/apache/geronimo/tomcat/ConnectorGBean.java Transmitting file data .. Committed revision 448163. Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Fix For: 1.2, 1.1.1 Attachments: G2329-1.1.1.patch The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- 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-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=all ] Matt Hogstrom updated GERONIMO-2329: Fix Version/s: (was: 1.1.1) Affects Version/s: 1.1.1 1.1.2 1.1.x Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 1.1.1, 1.1.x, 1.1.2 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Fix For: 1.2 Attachments: G2329-1.1.1.patch The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=all ] Matt Hogstrom closed GERONIMO-2329. --- Resolution: Fixed Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 1.1.1, 1.1.x, 1.1.2 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Fix For: 1.2 Attachments: G2329-1.1.1.patch The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- 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-2169) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch)
[ http://issues.apache.org/jira/browse/GERONIMO-2169?page=comments#action_12436218 ] Matt Hogstrom commented on GERONIMO-2169: - Mistake repeated...changing version to trunk. ug Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) --- Key: GERONIMO-2169 URL: http://issues.apache.org/jira/browse/GERONIMO-2169 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1.1, 1.1.2 Reporter: Kevan Miller Assigned To: Matt Hogstrom Fix For: 1.2 The m:co goal in tags/1.1.0 will checkout the branches/2.1 version of OpenEJB. It should be checking out tags/v2_1. We need to fix in Geronimo 1.1.1. The release process should be updated to insure we don't repeat this mistake in the future. -- 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-2169) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch)
[ http://issues.apache.org/jira/browse/GERONIMO-2169?page=all ] Matt Hogstrom updated GERONIMO-2169: Fix Version/s: 1.2 (was: 1.1.1) Affects Version/s: 1.1.2 Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) --- Key: GERONIMO-2169 URL: http://issues.apache.org/jira/browse/GERONIMO-2169 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1.1, 1.1.2 Reporter: Kevan Miller Assigned To: Matt Hogstrom Fix For: 1.2 The m:co goal in tags/1.1.0 will checkout the branches/2.1 version of OpenEJB. It should be checking out tags/v2_1. We need to fix in Geronimo 1.1.1. The release process should be updated to insure we don't repeat this mistake in the future. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom closed GERONIMO-2307. --- Resolution: Fixed Assignee: Matt Hogstrom (was: Geir Magnusson Jr) Fixed through David's addition of the schema changes in geronimo-tck. The schemas are now generated from there and the jars are distributed. We no longer include the Sun Schemas Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Matt Hogstrom Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1492) Many org/apache/geronimo configIds still live in source tree
[ http://issues.apache.org/jira/browse/GERONIMO-1492?page=all ] Matt Hogstrom closed GERONIMO-1492. --- Resolution: Fixed Many org/apache/geronimo configIds still live in source tree -- Key: GERONIMO-1492 URL: http://issues.apache.org/jira/browse/GERONIMO-1492 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1, 1.0 Reporter: Aaron Mulder Assigned To: Sachin Patel Priority: Blocker Fix For: 1.1.1 Attachments: annotated-grep-output.txt, GERONIMO-1492-1.patch, GERONIMO-1492.diff I created a couple separate issues, but beyond those a quick search brought up a few more in magic G ball and day trader -- I stopped before it went any further, but we should grep for that and try to eliminate all the references to old-style config IDs. -- 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-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] Matt Hogstrom updated GERONIMO-2308: Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(/)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\daytrader| | |(/)|(/)|(/)|applications\demo| | |(/)|(/)|(/)|applications\ldap-realm-demo| | |(/)|(/)|(/)|applications\magicGball| | |(/)|(/)|(/)|applications\project.properties| | |(/)|(/)|(/)|applications\remote-deploy| | |(/)|(/)|(/)|applications\remote-deploy-lib| | |(/)|(/)|(/)|applications\uddi-db| | |(/)|(/)|(/)|applications\uddi-server| | |(/)|(/)|(/)|applications\welcome| | |(/)|(/)|(/)|modules\activation| | |(/)|(/)|(/)|modules\activemq-embedded-rar| | |(/)|(/)|(/)|modules\axis| | |(/)|(/)|(/)|modules\axis-builder| | |(/)|(/)|(/)|modules\client| | |(/)|(/)|(/)|modules\client-builder| | |(/)|(/)|(/)|modules\common| | |(/)|(/)|(/)|modules\connector| | |(/)|(/)|(/)|modules\connector-builder| | |(/)|(/)|(/)|modules\console-web| (Won't fix in trunk) | |(/)|(/)|(/)|modules\converter| | |(/)|(/)|(/)|modules\core| | |(/)|(/)|(/)|modules\deploy-config| | |(/)|(/)|(/)|modules\deploy-jsr88| | |(/)|(/)|(/)|modules\deploy-tool| | |(/)|(/)|(/)|modules\deployment| | |(/)|(/)|(/)|modules\derby| | |(/)|(/)|(/)|modules\directory| | |(/)|(/)|(/)|modules\hot-deploy| | |(/)|(/)|(/)|modules\installer-processing| | |(/)|(/)|(/)|modules\installer-support| | |(/)|(/)|(/)|modules\j2ee| | |(/)|(/)|(/)|modules\j2ee-builder| | |(/)|(/)|(/)|modules\j2ee-schema| | |(/|(/)|(/)|modules\javamail-transport| (No longer in trunk) | |(/)|(/)|(/)|modules\jetty| | |(/)|(/)|(/)|modules\jetty-builder| | |(/)|(/)|(/)|modules\jmx-remoting| | |(/)|(/)|(/)|modules\kernel| | |(/)|(/)|(/)|modules\mail| | |(/)|(/)|(/)|modules\management| | |(/)|(/)|(/)|modules\naming| | |(/)|(/)|(/)|modules\naming-builder| | |(/)|(/)|(/)|modules\scripts| (Not distributed) | |(/)|(/)|(/)|modules\security| | |(/)|(/)|(/)|modules\security-builder| | |(/)|(/)|(/)|modules\service-builder| | |(/)|(/)|(/)|modules\system| | |(/)|(/)|(/)|modules\test-ddbean| | |(/)|(/)|(/)|modules\timer| | |(/)|(/)|(/)|modules\tomcat| | |(/)|(/)|(/)|modules\tomcat-builder| | |(/)|(/)|(/)|modules\transaction| | |(/)|(/)|(/)|modules\upgrade| | |(/)|(/)|(/)|modules\util| | |(/)|(/)|(/)|modules\web-builder| | |(/)|(/)|(/)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\daytrader| | |(x)|(/)|(/)|applications\demo| | |(x)|(/)|(/)|applications\ldap-realm-demo| | |(x)|(/)|(/)|applications\magicGball| | |(x)|(/)|(/)|applications\project.properties| | |(x)|(/)|(/)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(/)|(/)|applications\uddi-db| |
[jira] Updated: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] Matt Hogstrom updated GERONIMO-2308: Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(/)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\daytrader| | |(/)|(/)|(/)|applications\demo| | |(/)|(/)|(/)|applications\ldap-realm-demo| | |(/)|(/)|(/)|applications\magicGball| | |(/)|(/)|(/)|applications\project.properties| | |(/)|(/)|(/)|applications\remote-deploy| | |(/)|(/)|(/)|applications\remote-deploy-lib| | |(/)|(/)|(/)|applications\uddi-db| | |(/)|(/)|(/)|applications\uddi-server| | |(/)|(/)|(/)|applications\welcome| | |(/)|(/)|(/)|modules\activation| | |(/)|(/)|(/)|modules\activemq-embedded-rar| | |(/)|(/)|(/)|modules\axis| | |(/)|(/)|(/)|modules\axis-builder| | |(/)|(/)|(/)|modules\client| | |(/)|(/)|(/)|modules\client-builder| | |(/)|(/)|(/)|modules\common| | |(/)|(/)|(/)|modules\connector| | |(/)|(/)|(/)|modules\connector-builder| | |(/)|(/)|(/)|modules\console-web| (Won't fix in trunk) | |(/)|(/)|(/)|modules\converter| | |(/)|(/)|(/)|modules\core| | |(/)|(/)|(/)|modules\deploy-config| | |(/)|(/)|(/)|modules\deploy-jsr88| | |(/)|(/)|(/)|modules\deploy-tool| | |(/)|(/)|(/)|modules\deployment| | |(/)|(/)|(/)|modules\derby| | |(/)|(/)|(/)|modules\directory| | |(/)|(/)|(/)|modules\hot-deploy| | |(/)|(/)|(/)|modules\installer-processing| | |(/)|(/)|(/)|modules\installer-support| | |(/)|(/)|(/)|modules\j2ee| | |(/)|(/)|(/)|modules\j2ee-builder| | |(/)|(/)|(/)|modules\j2ee-schema| | |(/)|(/)|(/)|modules\javamail-transport| (No longer in trunk) | |(/)|(/)|(/)|modules\jetty| | |(/)|(/)|(/)|modules\jetty-builder| | |(/)|(/)|(/)|modules\jmx-remoting| | |(/)|(/)|(/)|modules\kernel| | |(/)|(/)|(/)|modules\mail| | |(/)|(/)|(/)|modules\management| | |(/)|(/)|(/)|modules\naming| | |(/)|(/)|(/)|modules\naming-builder| | |(/)|(/)|(/)|modules\scripts| (Not distributed) | |(/)|(/)|(/)|modules\security| | |(/)|(/)|(/)|modules\security-builder| | |(/)|(/)|(/)|modules\service-builder| | |(/)|(/)|(/)|modules\system| | |(/)|(/)|(/)|modules\test-ddbean| | |(/)|(/)|(/)|modules\timer| | |(/)|(/)|(/)|modules\tomcat| | |(/)|(/)|(/)|modules\tomcat-builder| | |(/)|(/)|(/)|modules\transaction| | |(/)|(/)|(/)|modules\upgrade| | |(/)|(/)|(/)|modules\util| | |(/)|(/)|(/)|modules\web-builder| | |(/)|(/)|(/)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(/)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\daytrader| | |(/)|(/)|(/)|applications\demo| | |(/)|(/)|(/)|applications\ldap-realm-demo| | |(/)|(/)|(/)|applications\magicGball| | |(/)|(/)|(/)|applications\project.properties| | |(/)|(/)|(/)|applications\remote-deploy| | |(/)|(/)|(/)|applications\remote-deploy-lib| | |(/)|(/)|(/)|applications\uddi-db| |
[jira] Closed: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] Matt Hogstrom closed GERONIMO-2308. --- Resolution: Fixed All updates complete All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file -- Key: GERONIMO-2308 URL: http://issues.apache.org/jira/browse/GERONIMO-2308 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1, 1.0 Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 1.1.1 Attachments: activation-converter.patch, core-installersupport.patch, j2ee-management.patch, naming-tomcat.patch, tomcatbuilder-webservices.patch Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording Redistribution and use of this software in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(/)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(/)|(/)|(/)|applications\daytrader| | |(/)|(/)|(/)|applications\demo| | |(/)|(/)|(/)|applications\ldap-realm-demo| | |(/)|(/)|(/)|applications\magicGball| | |(/)|(/)|(/)|applications\project.properties| | |(/)|(/)|(/)|applications\remote-deploy| | |(/)|(/)|(/)|applications\remote-deploy-lib| | |(/)|(/)|(/)|applications\uddi-db| | |(/)|(/)|(/)|applications\uddi-server| | |(/)|(/)|(/)|applications\welcome| | |(/)|(/)|(/)|modules\activation| | |(/)|(/)|(/)|modules\activemq-embedded-rar| | |(/)|(/)|(/)|modules\axis| | |(/)|(/)|(/)|modules\axis-builder| | |(/)|(/)|(/)|modules\client| | |(/)|(/)|(/)|modules\client-builder| | |(/)|(/)|(/)|modules\common| | |(/)|(/)|(/)|modules\connector| | |(/)|(/)|(/)|modules\connector-builder| | |(/)|(/)|(/)|modules\console-web| (Won't fix in trunk) | |(/)|(/)|(/)|modules\converter| | |(/)|(/)|(/)|modules\core| | |(/)|(/)|(/)|modules\deploy-config| | |(/)|(/)|(/)|modules\deploy-jsr88| | |(/)|(/)|(/)|modules\deploy-tool| | |(/)|(/)|(/)|modules\deployment| | |(/)|(/)|(/)|modules\derby| | |(/)|(/)|(/)|modules\directory| | |(/)|(/)|(/)|modules\hot-deploy| | |(/)|(/)|(/)|modules\installer-processing| | |(/)|(/)|(/)|modules\installer-support| | |(/)|(/)|(/)|modules\j2ee| | |(/)|(/)|(/)|modules\j2ee-builder| | |(/)|(/)|(/)|modules\j2ee-schema| | |(/)|(/)|(/)|modules\javamail-transport| (No longer in trunk) | |(/)|(/)|(/)|modules\jetty| | |(/)|(/)|(/)|modules\jetty-builder| | |(/)|(/)|(/)|modules\jmx-remoting| | |(/)|(/)|(/)|modules\kernel| | |(/)|(/)|(/)|modules\mail| | |(/)|(/)|(/)|modules\management| | |(/)|(/)|(/)|modules\naming| | |(/)|(/)|(/)|modules\naming-builder| | |(/)|(/)|(/)|modules\scripts| (Not distributed) | |(/)|(/)|(/)|modules\security| | |(/)|(/)|(/)|modules\security-builder| | |(/)|(/)|(/)|modules\service-builder| | |(/)|(/)|(/)|modules\system| | |(/)|(/)|(/)|modules\test-ddbean| | |(/)|(/)|(/)|modules\timer| | |(/)|(/)|(/)|modules\tomcat| | |(/)|(/)|(/)|modules\tomcat-builder| | |(/)|(/)|(/)|modules\transaction| | |(/)|(/)|(/)|modules\upgrade| | |(/)|(/)|(/)|modules\util| | |(/)|(/)|(/)|modules\web-builder| | |(/)|(/)|(/)|modules\webservices| | -- 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-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: Description: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(/)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| was: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes||
[jira] Updated: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: Description: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(x)|(x)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| was: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes||
[jira] Updated: (GERONIMO-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=all ] Matt Hogstrom updated GERONIMO-2329: Affects Version/s: 1.1.x 1.2 (was: 1.0) (was: 1.1) (was: 1.1.1) Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2, 1.1.x Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Fix For: 1.2, 1.1.1 Attachments: G2329-1.1.1.patch The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2313) Subject not propagated correctly between web app and ejb
[ http://issues.apache.org/jira/browse/GERONIMO-2313?page=all ] Matt Hogstrom closed GERONIMO-2313. --- Resolution: Fixed Subject not propagated correctly between web app and ejb Key: GERONIMO-2313 URL: http://issues.apache.org/jira/browse/GERONIMO-2313 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1, 1.1.1, 1.1.x Reporter: David Jencks Assigned To: David Jencks Fix For: 1.1.1, 1.1.2, 1.2 Attachments: ejbrefsec-ear-1.0-SNAPSHOT.ear, ejbrefsec.src.jar, GERONIMO-2313-openejb.diff, GERONIMO-2313.diff With a web app with security, that calls an ejb, isCallerInRole in the ejb always returns false. this is caused by the web app not setting nextCaller and the ejb interceptors shifting nextCaller to currentCaller, so when the isCallerInRole is tested there is a null subject so it returns false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2372) Build failure on branches/1.1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2372?page=all ] Matt Hogstrom closed GERONIMO-2372. --- Resolution: Fixed Build failure on branches/1.1.1 --- Key: GERONIMO-2372 URL: http://issues.apache.org/jira/browse/GERONIMO-2372 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1.1 Environment: Win XP, Sun JDK 1.4.2_08, Maven 1.1-beta-2 Reporter: Vamsavardhana Reddy Assigned To: Tim McConnell Fix For: 1.1.1 Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Console output given below. + | geronimo and geronimo-plugins Geronimo :: Security | Memory: 17M/29M + DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. WARNING: Failed to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee-jacc_1.0_spec-1.1.1.jar -- 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-2329) Remote-deploy failures between Windows and Linux machines
[ http://issues.apache.org/jira/browse/GERONIMO-2329?page=all ] Matt Hogstrom updated GERONIMO-2329: Affects Version/s: (was: 1.1.x) Remote-deploy failures between Windows and Linux machines - Key: GERONIMO-2329 URL: http://issues.apache.org/jira/browse/GERONIMO-2329 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.2 Environment: Geronimo 1.1.1 using Tomcat with IBM 1.4.2 SR5 or 1.5.0 SR2 SDK between Win2003 server and SLES9 Reporter: Donald Woods Fix For: 1.2, 1.1.1 Attachments: G2329-1.1.1.patch The remote-deployer is not returning fully qualified hostnames. This can be easily observed when starting the server with --long and looking as the web URLs being displayed at startup. Simple fix, is to switch the following in the modules/tomcat//ConnectorGBean.java and modules/jetty//JettyConnector.java from host = address.getHostName(); to host = address.getCanonicalHostName(); -- 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-2411) CAR, WAR and EAR artifacts are missing NOTICE and LICENSE files.
[ http://issues.apache.org/jira/browse/GERONIMO-2411?page=all ] Matt Hogstrom updated GERONIMO-2411: Affects Version/s: 1.1 1.0 1.1.1 1.1.2 1.1.x 1.2 1.x CAR, WAR and EAR artifacts are missing NOTICE and LICENSE files. Key: GERONIMO-2411 URL: http://issues.apache.org/jira/browse/GERONIMO-2411 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1, 1.0, 1.1.1, 1.1.2, 1.1.x, 1.2, 1.x Reporter: Matt Hogstrom Fix For: 1.2 For release of these artifacts they need to include the LICENSE and NOTICE files. Currently the build does not automatically include them. The M2 build needs to be updated to include these artifacts in the build process. -- 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-2411) CAR, WAR and EAR artifacts are missing NOTICE and LICENSE files.
CAR, WAR and EAR artifacts are missing NOTICE and LICENSE files. Key: GERONIMO-2411 URL: http://issues.apache.org/jira/browse/GERONIMO-2411 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Reporter: Matt Hogstrom Fix For: 1.2 For release of these artifacts they need to include the LICENSE and NOTICE files. Currently the build does not automatically include them. The M2 build needs to be updated to include these artifacts in the build process. -- 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-2388) JMS Server portlet improvement - field validation, reset button and show current task
[ http://issues.apache.org/jira/browse/GERONIMO-2388?page=comments#action_12433904 ] Matt Hogstrom commented on GERONIMO-2388: - +1 JMS Server portlet improvement - field validation, reset button and show current task - Key: GERONIMO-2388 URL: http://issues.apache.org/jira/browse/GERONIMO-2388 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.1.1 Environment: Win XP, G 1.1.1-rc2 Reporter: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2388.patch JMS Server portlet improvements: 1. Add new listener/edit listener page does not show any information on what listener is being added or edited. If the use is in doubt, he/she will have to go back to the previous page and start a fresh which might result in generating the page if the user chooses to click on List JMS Connectors link instead of the back button. This can be avoided by showing the current task in the edit page. 2. Form field validation using javascript for name, host (check for empty string) and port (check for numeric value). 3. Reset button. One useful little button will not do any harm. -- 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-2383) Replace ENCConfigBuilder with a pluggable set of NamingBuilders
[ http://issues.apache.org/jira/browse/GERONIMO-2383?page=comments#action_12433993 ] Matt Hogstrom commented on GERONIMO-2383: - +1 ... apply away Replace ENCConfigBuilder with a pluggable set of NamingBuilders --- Key: GERONIMO-2383 URL: http://issues.apache.org/jira/browse/GERONIMO-2383 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Attachments: GERONIMO-2383-openejb-v2.patch, GERONIMO-2383-v2.patch (Previously part of GERONIMO-2349) The ENCConfigBuilder is way too hardcoded into what it accepts and how. It won't let you add things like a persistence-ref builder very easily. We can replace it with a set of NamingBuilders somewhat similar to NamespaceDrivenBuilders. -- 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-903) Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.13
[ http://issues.apache.org/jira/browse/GERONIMO-903?page=comments#action_12433553 ] Matt Hogstrom commented on GERONIMO-903: I think we should upgrade. Is this fixing a specific issue Donald or are you just looking at getting current? Update Log4J usage from 1.2.8 to latest maintenance version of 1.2.13 - Key: GERONIMO-903 URL: http://issues.apache.org/jira/browse/GERONIMO-903 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: common Affects Versions: 1.0-M5, 1.1, 1.0, 1.1.1, 1.1.x, 1.2 Environment: All Reporter: Donald Woods Assigned To: Jason Dillon Priority: Trivial Fix For: 1.2 Attachments: GERONIMO-903.diff Upgrade to the latest log4j maintenance version, which is 1.2.11and is available to maven on ibiblio - http://www.ibiblio.org/maven/log4j/jars/log4j-1.2.11.jar Updates required in project.properties for Geronimo and OpenEJB and any project.xml which is currently hardcoded to use log4j-1.2.8 -- 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-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12433172 ] Matt Hogstrom commented on GERONIMO-2332: - I think this patch is complete and we can close it out :) Do you want the honors David? RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all Key: GERONIMO-2332 URL: http://issues.apache.org/jira/browse/GERONIMO-2332 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: specs Affects Versions: 1.1.1, 1.1.2, 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.1.1, 1.1.2, 1.2 Attachments: GERONIMO-2332-1.1-openejb-v2.patch, GERONIMO-2332-1.1-v2.patch, GERONIMO-2332-1.1.patch, GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk-v2.patch, GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip See GERONIMO-2307. It seems that the option with the least legal exposure is to not distribute and sun schema files and not have any in our svn. This is a proposed spec module that uses a m2 profile to pull the schemas from suns website (where they are freely available), run xmlbeans on them, and remove the copies of the schemas that xmlbeasn helpfully tries to include in the output. We can then check this stuff into svn. A normal non-profile build then just builds these sources into a jar. We can replace the xmlbeans step in j2ee-schema with a geronimo dependency on this new spec jar. -- 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-2364) Update geronimo to use ActiveMQ 4.1.x
[ http://issues.apache.org/jira/browse/GERONIMO-2364?page=comments#action_12432904 ] Matt Hogstrom commented on GERONIMO-2364: - +1 Update geronimo to use ActiveMQ 4.1.x - Key: GERONIMO-2364 URL: http://issues.apache.org/jira/browse/GERONIMO-2364 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: ActiveMQ Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 1.2 Attachments: GERONIMO-2364.patch -- 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-2372) Build failure on branches/1.1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2372?page=comments#action_12432923 ] Matt Hogstrom commented on GERONIMO-2372: - This isn't a bug. The build is in a transitionary state as we vote out the final release. The spec jar you are missing can be built manually from specs or it cvan be downloaded and placed in your local maven repo. Here is the link http://people.apache.org/~hogstrom/1.1.1-rc2/geronimo-j2ee-jacc_1.0_spec-1.1.1-rc2.jar. Don't forget to rename it and lose the rc2. Build failure on branches/1.1.1 --- Key: GERONIMO-2372 URL: http://issues.apache.org/jira/browse/GERONIMO-2372 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1.1 Environment: Win XP, Sun JDK 1.4.2_08, Maven 1.1-beta-2 Reporter: Vamsavardhana Reddy Assigned To: Tim McConnell Fix For: 1.1.1 Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Console output given below. + | geronimo and geronimo-plugins Geronimo :: Security | Memory: 17M/29M + DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml DEPRECATED: the default goal should be specified in the build section of proje ct.xml instead of maven.xml build:end: Attempting to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. WARNING: Failed to download geronimo-j2ee-jacc_1.0_spec-1.1.1.jar. BUILD FAILED File.. C:\g111\maven.xml Element... maven:reactor Line.. 43 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-j2ee-jacc_1.0_spec-1.1.1.jar -- 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-2318) Database path validation not present
[ http://issues.apache.org/jira/browse/GERONIMO-2318?page=all ] Matt Hogstrom updated GERONIMO-2318: Fix Version/s: 1.1.2 (was: 1.1.1) 1.1.1 is closed. Database path validation not present Key: GERONIMO-2318 URL: http://issues.apache.org/jira/browse/GERONIMO-2318 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1, 1.1.2 Environment: All Supported Platforms Reporter: Manu T George Fix For: 1.2, 1.1.2 Attachments: G2318-1.1.1.patch On deploying pools referring to derby databases. Deployment is shown to be sucessful but the pool does not start. Steps are given below (1)Logged into Administrative Console. (2)Clicked Database Pools. (3) Next, clicked Create a new database pool: Using the Geronimo database pool wizard. (4)Entered Name of Database Pool: CPRO and Database Type: Derby Embedded. Then clicked Next. (5)Thereafter entered the following:- JDBC Driver Class: org.apache.derby.jdbc.EmbeddedDriver Driver JAR: org.apache.derby/derby/10.1.2.ibm/jar DB Username: cpro DB Password: cpro Database: c:\cprodb\cprodb_COSMO\csdb Then clicked Next. (5)The next screen showed:- JDBC Connection URL: jdbc:derby:c:cprodbcprodb_COSMOcsdb (This being incorrect, it was changed to jdbc:derby:c:\cprodb\cprodb_COSMO\csdb). (6)Driver Status: Loaded successfully (7)Now clicked Test Connection. This showed:- Test Result: Connected to Apache Derby 10.1.2.4 (8)Finally clicked Deploy It appears that this step was successful because:- (i)The DOS window showed Deployment completed successfully! Even though this happens when we refer to this DB Pool in an application error occurs. Thus there is no handling of '\' character in these two fields Giving '/' instead of '\' solves this issue -- 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-2348) Tomcat ConnectorGBean does not handle attribute values properly
[ http://issues.apache.org/jira/browse/GERONIMO-2348?page=comments#action_12430522 ] Matt Hogstrom commented on GERONIMO-2348: - If there is a problem with Tomcat then this patch needs to be taken to the Tomcat dev list. I suggest opening a bugzilla report over there and providing the Tomcat patch over there. Tomcat ConnectorGBean does not handle attribute values properly --- Key: GERONIMO-2348 URL: http://issues.apache.org/jira/browse/GERONIMO-2348 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0, 1.1, 1.1.1 Environment: Win XP, Geronimo Tomcat 1.1.1-SNAPSHOT Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.2, 1.1.x, 1.1.2 Attachments: GERONIMO-2348.patch, http11protocol.patch Tomcat ConnectorGBean does not handle the following attributes properly. 1. hostLookupEnabled 2. redirectPort 3. maxSavePostSize 4. useBodyEncodingForURI There may be other attributes that are not handled properly as well. So, far I have confirmed the above list. I will continue investigation and update the list. A similar problem GERONIMO-2343 is observed and fixed by Krishnakumar B. And the fix is also similar. -- 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: (DAYTRADER-10) Update the import statements of Quote.java and QuoteHome.java
[ http://issues.apache.org/jira/browse/DAYTRADER-10?page=comments#action_12429737 ] Matt Hogstrom commented on DAYTRADER-10: Thanks Slava...applied Sending trunk/modules/ejb/src/main/java/org/apache/geronimo/samples/daytrader/ejb/Quote.java Sending trunk/modules/ejb/src/main/java/org/apache/geronimo/samples/daytrader/ejb/QuoteHome.java Transmitting file data .. Committed revision 433666. Update the import statements of Quote.java and QuoteHome.java - Key: DAYTRADER-10 URL: http://issues.apache.org/jira/browse/DAYTRADER-10 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Environment: All Reporter: Slava Priority: Minor Fix For: 1.2 Attachments: FixForDaytrader-10.patch Java 5 EE introduces a new javax.ejb.Remote interface. Currently Daytrader EJBs Quote.java and QuoteHome.java import Java packages with wild cards. For example: import javax.ejb.*; import java.math.BigDecimal; import com.ibm.websphere.samples.trade.*; import java.rmi.*; Prior to Java 5 EE there was only one Remote interface (java.rmi.Remote). Therefore it is clear that Quote.java and QuoteHome.java extend the java.rmi.Remote interface. When we start to support Java 5EE however, there will be two Remote interfaces (java.rmi.Remote and javax.ejb.Remote. That will cause confusion for the java compiler during the ejbdeploy. The solution is really simple: to provide the full interface name/path during imports. I know that this is not a problem for Daytrader yet but it will become. So lets be proactive, fix the imports now and avoid the problem in the future. I am providing a fix for this issue. -- 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: (DAYTRADER-10) Update the import statements of Quote.java and QuoteHome.java
[ http://issues.apache.org/jira/browse/DAYTRADER-10?page=all ] Matt Hogstrom reassigned DAYTRADER-10: -- Assignee: Matt Hogstrom Update the import statements of Quote.java and QuoteHome.java - Key: DAYTRADER-10 URL: http://issues.apache.org/jira/browse/DAYTRADER-10 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Environment: All Reporter: Slava Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.2 Attachments: FixForDaytrader-10.patch Java 5 EE introduces a new javax.ejb.Remote interface. Currently Daytrader EJBs Quote.java and QuoteHome.java import Java packages with wild cards. For example: import javax.ejb.*; import java.math.BigDecimal; import com.ibm.websphere.samples.trade.*; import java.rmi.*; Prior to Java 5 EE there was only one Remote interface (java.rmi.Remote). Therefore it is clear that Quote.java and QuoteHome.java extend the java.rmi.Remote interface. When we start to support Java 5EE however, there will be two Remote interfaces (java.rmi.Remote and javax.ejb.Remote. That will cause confusion for the java compiler during the ejbdeploy. The solution is really simple: to provide the full interface name/path during imports. I know that this is not a problem for Daytrader yet but it will become. So lets be proactive, fix the imports now and avoid the problem in the future. I am providing a fix for this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-10) Update the import statements of Quote.java and QuoteHome.java
[ http://issues.apache.org/jira/browse/DAYTRADER-10?page=all ] Matt Hogstrom closed DAYTRADER-10. -- Fix Version/s: 1.2 Resolution: Fixed Update the import statements of Quote.java and QuoteHome.java - Key: DAYTRADER-10 URL: http://issues.apache.org/jira/browse/DAYTRADER-10 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Environment: All Reporter: Slava Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.2 Attachments: FixForDaytrader-10.patch Java 5 EE introduces a new javax.ejb.Remote interface. Currently Daytrader EJBs Quote.java and QuoteHome.java import Java packages with wild cards. For example: import javax.ejb.*; import java.math.BigDecimal; import com.ibm.websphere.samples.trade.*; import java.rmi.*; Prior to Java 5 EE there was only one Remote interface (java.rmi.Remote). Therefore it is clear that Quote.java and QuoteHome.java extend the java.rmi.Remote interface. When we start to support Java 5EE however, there will be two Remote interfaces (java.rmi.Remote and javax.ejb.Remote. That will cause confusion for the java compiler during the ejbdeploy. The solution is really simple: to provide the full interface name/path during imports. I know that this is not a problem for Daytrader yet but it will become. So lets be proactive, fix the imports now and avoid the problem in the future. I am providing a fix for this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1692) Creating Web Connectors using Console
[ http://issues.apache.org/jira/browse/GERONIMO-1692?page=all ] Matt Hogstrom closed GERONIMO-1692. --- Closing per Vamsi's comments Creating Web Connectors using Console - Key: GERONIMO-1692 URL: http://issues.apache.org/jira/browse/GERONIMO-1692 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Environment: WinXP SP2, J2SDK 1.4.2_10, Geronimo with Tomcat Reporter: Ilya Kanonirov When creating any type of Web Connector at the Web Server page in the Geronimo Console, the parameter Max Threads is always saved to var/config/config.xml with default value 50. -- 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-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all
[ http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12429479 ] Matt Hogstrom commented on GERONIMO-2332: - I like this approach but it sounds like there are some kinks to be worked out. What if we re-type the specs by hand and then check them into branches/1.1.1. We'll cary that notion forward for the 1.1.x tree and address this larger problem in trunk. Thoughts? RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all Key: GERONIMO-2332 URL: http://issues.apache.org/jira/browse/GERONIMO-2332 Project: Geronimo Issue Type: RTC Security Level: public(Regular issues) Components: specs Affects Versions: 1.2, 1.1.1, 1.1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 1.1.1, 1.1.2 Attachments: GERONIMO-2332-1.1.patch, GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, geronimo-schema_1.4_spec-src.zip See GERONIMO-2307. It seems that the option with the least legal exposure is to not distribute and sun schema files and not have any in our svn. This is a proposed spec module that uses a m2 profile to pull the schemas from suns website (where they are freely available), run xmlbeans on them, and remove the copies of the schemas that xmlbeasn helpfully tries to include in the output. We can then check this stuff into svn. A normal non-profile build then just builds these sources into a jar. We can replace the xmlbeans step in j2ee-schema with a geronimo dependency on this new spec jar. -- 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-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: Description: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| was: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes||
[jira] Created: (GERONIMO-2331) Remove Maven 1 Artificats from Trunk and Reorganize Directories to Conform to Maven 2 Layouts
Remove Maven 1 Artificats from Trunk and Reorganize Directories to Conform to Maven 2 Layouts - Key: GERONIMO-2331 URL: http://issues.apache.org/jira/browse/GERONIMO-2331 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Affects Versions: 1.2 Reporter: Matt Hogstrom Assigned To: Jason Dillon Pending vote on Dev list -- 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-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: Description: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(?)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| was: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes||
[jira] Updated: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: If we need to create these then create these we must. Here are the files that I know of in our development tree that need to have substitutes created. Not sure if they exist or not. I took the files and found their location in the source tree to make finding them easier. I've modified the description with the files and using the nice markup we have I placed them in the description of this JIRA. Volunteers welcome :) 1.1.1 and other releases are stalled until we get this resolved. Geir, how does this impact previous releases of Geronimo? Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- 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-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: Description: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| was: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. Include appropriate license for the Sun j2ee schema files that are redistributed
[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12428897 ] Matt Hogstrom commented on GERONIMO-2307: - My understanding is that you crack open the Spec and type in the elements that need to be specific and either omit things like comments and the like or reword them to avoid copying them verbatim. Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(x)|(x)|(x)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| -- 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-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] Matt Hogstrom updated GERONIMO-2307: Description: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/application-client_1_4.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/application_1_4.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/connector_1_5.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/ejb-jar_2_1.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_1_4.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_jaxrpc_mapping_1_1.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_1_1.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/j2ee_web_services_client_1_1.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/jsp_2_0.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/j2ee_1_4schema/web-app_2_4.xsd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application-client_1_2.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/application_1_2.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/ejb-jar_1_1.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-app_2_2.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_2dtd/web-jsptaglibrary_1_1.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application-client_1_3.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/application_1_3.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/connector_1_0.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/ejb-jar_2_0.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-app_2_3.dtd|| |(/)|(/)|(/)|./j2ee-schema/src/resources/schemaorg_apache_xmlbeans/src/modules/j2ee-schema/src/j2ee_1_3dtd/web-jsptaglibrary_1_2.dtd|| was: Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes||
[jira] Commented: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=comments#action_12427532 ] Matt Hogstrom commented on GERONIMO-2307: - Here is a list of other files that are in the build that we need to consider. application-client_1_2.dtd application-client_1_3.dtd application-client_1_4.xsd application_1_2.dtd application_1_3.dtd application_1_4.xsd connector_1_0.dtd connector_1_5.xsd ejb-jar_1_1.dtd ejb-jar_2_0.dtd ejb-jar_2_1.xsd j2ee_1_4.xsd j2ee_jaxrpc_mapping_1_1.xsd j2ee_web_services_1_1.xsd j2ee_web_services_client_1_1.xsd jsp_2_0.xsd web-app_2_2.dtd web-app_2_3.dtd web-app_2_4.xsd web-jsptaglibrary_1_1.dtd web-jsptaglibrary_1_2.dtd Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0, 1.1 Reporter: John Sisson Assigned To: Geir Magnusson Jr Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- 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-2015) Let's replace JKS to PKCS12 key store type
[ http://issues.apache.org/jira/browse/GERONIMO-2015?page=comments#action_12427290 ] Matt Hogstrom commented on GERONIMO-2015: - Oops...my bad on the 2.0. I'll create one although there is no content there yet :) I'd like to get Aaron's and DJencks input on this as they are more familiar with the security aspects than I. One of your earlier comments indicated that JKS is not supported on IBM VMs (I didn't hear anything about JRockit and they should probably be part of the discussion as well). The earlier posts have me a bit confused about what works with what. Some say it works with BouncyCastle but BouncyCastle isn't required. Here is one about changing VMs as an issue Vamsavardhana Reddy [16/May/06 06:37 AM]. Is it possible to post a comprehensive proposal of what works with what, etc? Forgive my ignorance in the security area. I think my earlier recommendation to defer this might have been flawed. Let's replace JKS to PKCS12 key store type -- Key: GERONIMO-2015 URL: http://issues.apache.org/jira/browse/GERONIMO-2015 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Reporter: Nikolay Chugunov Fix For: 1.2 Attachments: JKSToPKCS12.java, jksToPKCS12.patch, keystore Hello Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key store and Geronimo may not work on non-Sun VMs. To fix this problem I have created the patch for Geronimo sources. In brief the patch (attached) replaces JKS to PKCS12 key store type in configurations files. PKCS12 format of key store file is not java-specific and can be created and read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is Sun specific key store and does not exist in Bouncy Castle. Also it is needed to replace JKS to PKCS12 keystore file (attached) to assemblies/j2ee-tomcat-server/src/var/security, assemblies/j2ee-installer/src/var/security, assemblies/j2ee-jetty-server/src/var/security directories. Key store file was generating using JKSToPKCS12 class (attached). This class transfers key and certificate of Geronimo from JKS to PKCS12. After I apply this patch to Geronimo 1.0 sources and build Geronimo I can login to Geronimo console over https. -- 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: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build
[ http://issues.apache.org/jira/browse/XBEAN-31?page=comments#action_12426977 ] Matt Hogstrom commented on XBEAN-31: Guillaume, I tried the patch and it didn't work. Since it was fairly small I went ahead and manually applied the changes. And I think this will work. The patch is applied from geronimo/xbean/trunk via patch -p0 XBEAN-31.matt.diff I also corrected a typo in one of the System.outs for AsArtifactId. Since this is your patch, I'll reset the vote and give this my +1 Cheers. [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build Key: XBEAN-31 URL: http://issues.apache.org/jira/browse/XBEAN-31 Project: XBean Issue Type: Wish Components: maven-plugin Reporter: james strachan Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff So that the XSD and HTML reference would be automatically deployed into the m2 repository. See the attach-artifact for how to do it manually in each POM. But given how many projects are using the m2 plugin it would simplify our lives if the m2 plugin did this for us http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build
[ http://issues.apache.org/jira/browse/XBEAN-31?page=all ] Matt Hogstrom updated XBEAN-31: --- Attachment: XBEAN-31.matt.diff [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build Key: XBEAN-31 URL: http://issues.apache.org/jira/browse/XBEAN-31 Project: XBean Issue Type: Wish Components: maven-plugin Reporter: james strachan Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff So that the XSD and HTML reference would be automatically deployed into the m2 repository. See the attach-artifact for how to do it manually in each POM. But given how many projects are using the m2 plugin it would simplify our lives if the m2 plugin did this for us http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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] Reopened: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build
[ http://issues.apache.org/jira/browse/XBEAN-31?page=all ] Matt Hogstrom reopened XBEAN-31: Resetting vote. [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build Key: XBEAN-31 URL: http://issues.apache.org/jira/browse/XBEAN-31 Project: XBean Issue Type: Wish Components: maven-plugin Reporter: james strachan Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff So that the XSD and HTML reference would be automatically deployed into the m2 repository. See the attach-artifact for how to do it manually in each POM. But given how many projects are using the m2 plugin it would simplify our lives if the m2 plugin did this for us http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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: (XBEAN-19) [RTC] Enable inverse classloading with the classpath element
[ http://issues.apache.org/jira/browse/XBEAN-19?page=comments#action_12426983 ] Matt Hogstrom commented on XBEAN-19: +1...applied and tested. Need one more vote. [RTC] Enable inverse classloading with the classpath element Key: XBEAN-19 URL: http://issues.apache.org/jira/browse/XBEAN-19 Project: XBean Issue Type: New Feature Components: server Affects Versions: 2.4 Reporter: Guillaume Nodet Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-19.patch We could do something like classpath delegation=child | parent the default being parent -- 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-2248) Applications portlets: List Parent and Child components against each component
[ http://issues.apache.org/jira/browse/GERONIMO-2248?page=comments#action_12426984 ] Matt Hogstrom commented on GERONIMO-2248: - I think this is fine for inclusion in 1.1.2. Although it is an improvement it improves server usability. My +1 for 1.1.2 Vamsi, can you rework the patch to spit out a stack trace when the Should Not Occur issue arises :) Applications portlets: List Parent and Child components against each component -- Key: GERONIMO-2248 URL: http://issues.apache.org/jira/browse/GERONIMO-2248 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1 Reporter: Vamsavardhana Reddy Fix For: 1.2 Attachments: GERONIMO-2248.patch Applications portlets currently provide component status and links to start/stop/restart/uninstall. They do not provide a listing of parent components and child components. If child components are listed, a user will immediatley know what all configurations will be stopped if a particular component is stopped. How is it useful? I have stopped geronimo/system-database/1.1.1-SNAPSHOT/car to test something. Only after an error HTTP 404 was displayed next, I realized that the admin console had a dependency on geronimo/system-database/1.1.1-SNAPSHOT/car. Had there been a Child Components listing next to geronimo/system-database/1.1.1-SNAPSHOT/car, it would have avoided the surprise. -- 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-1716) Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1716?page=all ]
Matt Hogstrom updated GERONIMO-1716:
Fix Version/s: 1.1.2
1.2
(was: 1.1.1)
Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
Key: GERONIMO-1716
URL: http://issues.apache.org/jira/browse/GERONIMO-1716
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: security
Affects Versions: 1.0, 1.1, 1.2
Environment: Any
Reporter: Donald Woods
Assigned To: Donald Woods
Priority: Minor
Fix For: 1.1.2, 1.2
Attachments: Geronimo-1716.patch
Enhancement to the default PropertiesFileLoginModule and Console to encrypt
user passwords in users.properties.
To do this, PropertiesFileLoginModule and Console will be updated to use the
SimpleEncryption utility class, just like the deployer, to read/write
passwords that have the {Simple} key in front of encrypted passwords.
The loadProperties() method in PropertiesFileLoginModule will also be updated
to rewrite the users.properties file if it detects unencrypted passwords,
which will allow users to manually edit the file to update a password and
then have it automatically encrypted when the next login event occurs.
--
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-1917) repository doesn't deal well with case insensitive file systems
[ http://issues.apache.org/jira/browse/GERONIMO-1917?page=all ] Matt Hogstrom updated GERONIMO-1917: Fix Version/s: 1.1.2 1.2 (was: 1.1.1) Affects Version/s: 1.1.1 1.1.2 1.1.x Moving to 1.1.2 for rework and inclusion. repository doesn't deal well with case insensitive file systems --- Key: GERONIMO-1917 URL: http://issues.apache.org/jira/browse/GERONIMO-1917 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1, 1.1.1, 1.1.x, 1.1.2 Reporter: David Jencks Fix For: 1.1.2, 1.2 If you've installed a configuration A/B/1/car and then look for a/b/1/car, the repository will claim it's there on a case insensitive file system, but then further logic in the config store/ manager blows up because those are different artifacts. Solution appears to be to check when locating an artifact that the case from the file system matches the case you are asking for. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2269) Error after redeploy (with no version in module ID)
[ http://issues.apache.org/jira/browse/GERONIMO-2269?page=all ] Matt Hogstrom closed GERONIMO-2269. --- Fix Version/s: 1.1.2 1.2 Resolution: Fixed Sending 1.1.1/modules/kernel/src/java/org/apache/geronimo/kernel/config/SimpleConfigurationManager.java Transmitting file data . Committed revision 430135. Decided to include in 1.1.1 since we're waiting for another blocker patch to come in. Error after redeploy (with no version in module ID) --- Key: GERONIMO-2269 URL: http://issues.apache.org/jira/browse/GERONIMO-2269 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, kernel Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1.1, 1.1.2, 1.2 Attachments: 2269-fix-jndi-while-reloading.patch, 2269-fix-jndi-while-reloading.patch I deployed a web application (including a resource-ref to a database pool) successfully, with a module ID containing only an artifact element. I changed the web.xml and redeployed it. It failed due to a syntax error in web.xml (I changed the login page to not start with a / and it complained; apparently the / is necessary). The application still appeared to be running, though I didn't test it. I fixed the web.xml and redeployed it. It failed with the following error. It seems that after the redeploy the JNDI entry for the data source was invalid? UPDATE: a simple redeploy of the working application causes the error -- it's not necessary to have the failed redeploy in between. 11:57:44,865 ERROR [ContextLoader] Context initialization failed org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'DataSource' defined in resource [/WEB-INF/applicationContext.xml] of ServletContext: Initialization of bean failed; nested exception is javax.naming.NamingException: Could not look up : env/jdbc/Database javax.naming.NamingException: Could not look up : env/jdbc/Database [Root exception is org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid] at org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:59) at org.apache.geronimo.naming.enc.CachingReference.get(CachingReference.java:45) at org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:86) at org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:51) at javax.naming.InitialContext.lookup(InitialContext.java:347) at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:120) at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:85) at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:117) at org.springframework.jndi.AbstractJndiLocator.lookup(AbstractJndiLocator.java:181) at org.springframework.jndi.AbstractJndiLocator.afterPropertiesSet(AbstractJndiLocator.java:171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:801) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:249) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:177) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:159) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:177) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:268) at org.springframework.web.context.support.XmlWebApplicationContext.refresh(XmlWebApplicationContext.java:131) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:156) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:97) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48) at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:401) at org.mortbay.util.Container.start(Container.java:72) at org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:389) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at
[jira] Assigned: (GERONIMO-2169) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch)
[ http://issues.apache.org/jira/browse/GERONIMO-2169?page=all ] Matt Hogstrom reassigned GERONIMO-2169: --- Assignee: Matt Hogstrom (was: Kevan Miller) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch) --- Key: GERONIMO-2169 URL: http://issues.apache.org/jira/browse/GERONIMO-2169 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.1.1 Reporter: Kevan Miller Assigned To: Matt Hogstrom Fix For: 1.1.1 The m:co goal in tags/1.1.0 will checkout the branches/2.1 version of OpenEJB. It should be checking out tags/v2_1. We need to fix in Geronimo 1.1.1. The release process should be updated to insure we don't repeat this mistake in the future. -- 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-2270) Redeploy broken in 1.1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2270?page=all ] Matt Hogstrom reassigned GERONIMO-2270: --- Assignee: Matt Hogstrom Redeploy broken in 1.1.1 Key: GERONIMO-2270 URL: http://issues.apache.org/jira/browse/GERONIMO-2270 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1 Reporter: Aaron Mulder Assigned To: Matt Hogstrom Priority: Blocker Fix For: 1.1.1 Attachments: 2270-fix-redeploy-no-type.patch Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. Appears to happen when the moduleId includes a group/artifact/version but no type. Did not happen when all of group, artifact, version, and type were specified. -- 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-2270) Redeploy broken in 1.1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2270?page=comments#action_12426678 ] Matt Hogstrom commented on GERONIMO-2270: - Applied to branches/1.1.1 Sending 1.1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/ConfigIDExtractor.java Sending 1.1.1/modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/RedeployCommand.java Transmitting file data .. Committed revision 429783. Redeploy broken in 1.1.1 Key: GERONIMO-2270 URL: http://issues.apache.org/jira/browse/GERONIMO-2270 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1 Reporter: Aaron Mulder Assigned To: Matt Hogstrom Priority: Blocker Fix For: 1.1.1 Attachments: 2270-fix-redeploy-no-type.patch Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. Appears to happen when the moduleId includes a group/artifact/version but no type. Did not happen when all of group, artifact, version, and type were specified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2270) Redeploy broken in 1.1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2270?page=all ] Matt Hogstrom closed GERONIMO-2270. --- Fix Version/s: 1.1.2 1.2 Resolution: Fixed Redeploy broken in 1.1.1 Key: GERONIMO-2270 URL: http://issues.apache.org/jira/browse/GERONIMO-2270 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.1.1 Reporter: Aaron Mulder Assigned To: Matt Hogstrom Priority: Blocker Fix For: 1.1.1, 1.1.2, 1.2 Attachments: 2270-fix-redeploy-no-type.patch Tried to redeploy a WAR in 1.1.1. Got the following (note, I did actually redeploy): No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Attempting to use ModuleID 'aaron/IIIQuotes/1.0/' Error: Operation failed: Module aaron/IIIQuotes/1.0/war already exists in the server. Try to undeploy it first or use the redeploy command. Appears to happen when the moduleId includes a group/artifact/version but no type. Did not happen when all of group, artifact, version, and type were specified. -- 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: (XBEAN-31) [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build
[ http://issues.apache.org/jira/browse/XBEAN-31?page=comments#action_12426682 ] Matt Hogstrom commented on XBEAN-31: +1 ... [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build Key: XBEAN-31 URL: http://issues.apache.org/jira/browse/XBEAN-31 Project: XBean Issue Type: Wish Components: maven-plugin Reporter: james strachan Assigned To: Guillaume Nodet Fix For: 2.6 Attachments: XBEAN-31.diff So that the XSD and HTML reference would be automatically deployed into the m2 repository. See the attach-artifact for how to do it manually in each POM. But given how many projects are using the m2 plugin it would simplify our lives if the m2 plugin did this for us http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=comments#action_12426788 ] Matt Hogstrom commented on GERONIMO-2277: - I've looked at the merge and concur +1 Remove TransactionContextManager Key: GERONIMO-2277 URL: http://issues.apache.org/jira/browse/GERONIMO-2277 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Fix For: 1.2 Attachments: GERONIMO-2277.patch If you use the Geronimo TransactionContextManager, you can't use the TransactionManager interface directly since the TCM needs to know about all TM calls. Additionally, to use the TCM you must demarcate all changes in component context by starting an unspecified transaction context. This is all quite invasive and makes it hard to use our code in third part environments such as Spring or plain old Tomcat. I propose we remove the TransactionContextManager and replaced all uses with a plain old TransactionManager. This will also allow us to removed all code from web containers, app client and timer that was simply demarcating an unspecified transaction context, which is no longer needed. -- 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-2216) Use JLine API to get password interactivly when using shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-2216?page=comments#action_12426833 ] Matt Hogstrom commented on GERONIMO-2216: - +1 ... this is a bug...go ahead and apply it. Use JLine API to get password interactivly when using shutdown -- Key: GERONIMO-2216 URL: http://issues.apache.org/jira/browse/GERONIMO-2216 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.2 Reporter: Jason Dillon Assigned To: Jason Dillon Priority: Minor Attachments: GERONIMO-2216.diff Sometimes when interactively entering a password for shutdown, if the password is typed too fast, some of the chars are visible for a brief period. JLine provides the ability to mask the input as it is read (or omit it all together): * http://jline.sourceforge.net/#reading_password -- 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-1563) [RTC] Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12426835 ] Matt Hogstrom commented on GERONIMO-1563: - David, I understand what you are doing and agree. Given the magnitude of the change I wasn't able to test it but I am comfortable integrating it. +1 [RTC] Make the JACC implementation pluggable Key: GERONIMO-1563 URL: http://issues.apache.org/jira/browse/GERONIMO-1563 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: security Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Attachments: GERONIMO-1563-step2.1-v1-openejb.diff, GERONIMO-1563-step2.1-v1.diff, GERONIMO-1563-step2.1-v2-openejb.diff, GERONIMO-1563-step2.1-v2.diff, GERONIMO-1563-step2.1-v4-openejb.diff, GERONIMO-1563-step2.1-v4.diff Currently we are hardcoded into using our JACC implementation. This means we can't use third party authorization/security servers such as Tivoli AM. The runtime hardcoding is that the installation of the spec permissions into the policy configuration is mixed in with pushing our proprietary principal-role mapping into the policy configuration. The build time hardcoding is that the only proprietary security configuration we accept is our own xml for principal-role mapping, and we insist on it being present. Some steps for this: 1. make separate gbeans for the spec and proprietary access to the policy configuration. These should be connected by an interface, and the spec gbean should control the proprietary gbean and pass it the contextIds in the current application. 2. The security builder should be partly namespace driven, with the proprietary xml interpretation driven by the namespace. 2.a the base security builder should construct the ApplicationPolicyConfigurationGBean and hand off to the namespace-selected gbean for the proprietary stuff. 2.b the proprietary-xml builder should install the role-mapper gbean with the info needed for e.g. principal-role mapping. When we're done with this we should be able to support e.g. IBM pluggable JACC implementations that support their role-mapping capabilities by just writing an xml format and a gbean that pushes role mapping info into their interfaces. The ibm interfaces are explained here: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rsec_jaccspis.html If anyone knows how other app servers configure the non-spec part of JACC references would be very much appreciated. -- 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: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12426011 ]
Matt Hogstrom commented on XBEAN-36:
+1
[RTC] Support annotating properties with the ProperyEditor that should be
used when wiring in the value.
Key: XBEAN-36
URL: http://issues.apache.org/jira/browse/XBEAN-36
Project: XBean
Issue Type: New Feature
Components: spring
Reporter: Hiram Chirino
Assigned To: Hiram Chirino
Fix For: 2.6
Attachments: XBEAN-36.patch
This patch allows you to configure a PropertyEditor for any property. For
example, if you annotate a property as follows:
/**
* Sets the amount of beer remaining in the keg (in ml)
*
* @org.apache.xbean.Property
propertyEditor=org.apache.xbean.spring.example.MilliLittersPropertyEditor
* @param remaining
*/
public void setRemaining(long remaining) {
this.remaining = remaining;
}
Then when you configure the value of the 'remaining' property in xbean then
the MilliLittersPropertyEditor will be used to convert the string value to a
long. In the test case, our MilliLittersPropertyEditor can handle converting
different units of measurement to ml. For example:
beans xmlns:x=http://xbean.apache.org/schemas/pizza;
x:keg id=ml1000 remaining=1000 ml/
x:keg id=pints5 remaining=5 pints/
x:keg id=liter20 remaining=20 liter/
x:keg id=empty remaining=0/
/beans
--
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-1862) Provide Ability to enable pass-by-reference semantics for EJB calls
[ http://issues.apache.org/jira/browse/GERONIMO-1862?page=all ] Matt Hogstrom reassigned GERONIMO-1862: --- Assignee: Matt Hogstrom (was: David Blevins) Provide Ability to enable pass-by-reference semantics for EJB calls --- Key: GERONIMO-1862 URL: http://issues.apache.org/jira/browse/GERONIMO-1862 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Environment: All Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.1 Need to enable the ability to either globally for an EJB.jar to disable pass-by-value semantics or on a selective basis for the individual beans. This is a feature that is available all commercial and most open source AppServers. The default should be Pass-By-Value to remain compliance with the EJB specification. -- 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-2224) Add a geronimo specific system property for controlling dom, sax, and transformer creation
[ http://issues.apache.org/jira/browse/GERONIMO-2224?page=comments#action_12425821 ] Matt Hogstrom commented on GERONIMO-2224: - I was reminded that we have a 1.1.2 that this can go into. Dain, given I had a disconnect with you this should be put into branches/1.1 (1.1.2-SNAPSHOT) and not branches/1.1.1 Add a geronimo specific system property for controlling dom, sax, and transformer creation -- Key: GERONIMO-2224 URL: http://issues.apache.org/jira/browse/GERONIMO-2224 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Fix For: 1.2, 1.1.x Attachments: factory.patch It is common for poorly coded application to set the javax.xml.parsers.DocumentBuilderFactory, javax.xml.parsers.SAXParserFactory, or javax.xml.transform.TransformerFactory properties directly. If the value of these system properties do not point to a modern xml parser such as xerces, critical Geronimo services such as the LocalAttributeManager will stop working. This due to only modern parsers supporting the setAttribute method on the factory (specifically crimson throws an exception). The attached patch redirects all call to DocumentBuilderFactory.newInstance(), SAXParserFactory.newInstance() and TransformerFactory.newInstance() to a Geronimo XmlUtil class. This class checks the property geronimo.xml.parsers.DocumentBuilderFactory, geronimo.xml.parsers.SAXParserFactory, or geronimo.xml.transform.TransformerFactor, and if present creates that factory. Otherwise the code simply delegates to the default newInstance implementation. Once this patch has been committed the server can be launched with a full xml factory declaration using the following command: java \ -Dgeronimo.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl \ -Dgeronimo.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl \ -Dgeronimo.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl \ -jar bin/server.jar * This patch includes a test case for the new functionality. * This patch includes two new classes which must be svn added. -- 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-2224) Add a geronimo specific system property for controlling dom, sax, and transformer creation
[ http://issues.apache.org/jira/browse/GERONIMO-2224?page=comments#action_12425651 ] Matt Hogstrom commented on GERONIMO-2224: - Let's add this. Its a bug :)...I'll pop it in. Add a geronimo specific system property for controlling dom, sax, and transformer creation -- Key: GERONIMO-2224 URL: http://issues.apache.org/jira/browse/GERONIMO-2224 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Fix For: 1.2, 1.1.x Attachments: factory.patch It is common for poorly coded application to set the javax.xml.parsers.DocumentBuilderFactory, javax.xml.parsers.SAXParserFactory, or javax.xml.transform.TransformerFactory properties directly. If the value of these system properties do not point to a modern xml parser such as xerces, critical Geronimo services such as the LocalAttributeManager will stop working. This due to only modern parsers supporting the setAttribute method on the factory (specifically crimson throws an exception). The attached patch redirects all call to DocumentBuilderFactory.newInstance(), SAXParserFactory.newInstance() and TransformerFactory.newInstance() to a Geronimo XmlUtil class. This class checks the property geronimo.xml.parsers.DocumentBuilderFactory, geronimo.xml.parsers.SAXParserFactory, or geronimo.xml.transform.TransformerFactor, and if present creates that factory. Otherwise the code simply delegates to the default newInstance implementation. Once this patch has been committed the server can be launched with a full xml factory declaration using the following command: java \ -Dgeronimo.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl \ -Dgeronimo.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl \ -Dgeronimo.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl \ -jar bin/server.jar * This patch includes a test case for the new functionality. * This patch includes two new classes which must be svn added. -- 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-2224) Add a geronimo specific system property for controlling dom, sax, and transformer creation
[ http://issues.apache.org/jira/browse/GERONIMO-2224?page=comments#action_12425655 ] Matt Hogstrom commented on GERONIMO-2224: - This is actually a bug. A user reported that the server became unstable when they set this property and we could no longer update the config.xml because of a missing parser exception. This provides a fix to protect the server. We probably need something more sophisticated to do this in the future so the user doesn't have to specify anything but this patch works for now. This should be applied now to branches/1.1.1 and 1.1. My bad for missing this . Thanks Dain! Add a geronimo specific system property for controlling dom, sax, and transformer creation -- Key: GERONIMO-2224 URL: http://issues.apache.org/jira/browse/GERONIMO-2224 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: core Reporter: Dain Sundstrom Assigned To: Dain Sundstrom Fix For: 1.2, 1.1.x Attachments: factory.patch It is common for poorly coded application to set the javax.xml.parsers.DocumentBuilderFactory, javax.xml.parsers.SAXParserFactory, or javax.xml.transform.TransformerFactory properties directly. If the value of these system properties do not point to a modern xml parser such as xerces, critical Geronimo services such as the LocalAttributeManager will stop working. This due to only modern parsers supporting the setAttribute method on the factory (specifically crimson throws an exception). The attached patch redirects all call to DocumentBuilderFactory.newInstance(), SAXParserFactory.newInstance() and TransformerFactory.newInstance() to a Geronimo XmlUtil class. This class checks the property geronimo.xml.parsers.DocumentBuilderFactory, geronimo.xml.parsers.SAXParserFactory, or geronimo.xml.transform.TransformerFactor, and if present creates that factory. Otherwise the code simply delegates to the default newInstance implementation. Once this patch has been committed the server can be launched with a full xml factory declaration using the following command: java \ -Dgeronimo.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl \ -Dgeronimo.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl \ -Dgeronimo.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl \ -jar bin/server.jar * This patch includes a test case for the new functionality. * This patch includes two new classes which must be svn added. -- 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-2251) Add Proxy variables to geronimo.bat geronimo.sh
[ http://issues.apache.org/jira/browse/GERONIMO-2251?page=all ] Matt Hogstrom reassigned GERONIMO-2251: --- Assignee: John Sisson Add Proxy variables to geronimo.bat geronimo.sh - Key: GERONIMO-2251 URL: http://issues.apache.org/jira/browse/GERONIMO-2251 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown, console, Plugins Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: John Sisson Fix For: 1.1.x Reported by a user whose machine is behind a web proxy: I have tested the setting of the proxy through the JVM and found that the following works when included in the JAVA_OPTS environment variable: -DproxySet=true -DproxyHost=proxy.local -DproxyPort=8080 It would be great to have PROXY_HOST and PROXY_PORT variables in the big list of variables at the front of these scripts, and if the PROXY_HOST is set, turn that into the string of arguments above and append them to JAVA_OPTS. (The proxy would be used for downloading JDBC drivers, browsing and installing plugins, etc.) -- 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-2264) Created branches/1.1.1 to start release process
Created branches/1.1.1 to start release process --- Key: GERONIMO-2264 URL: http://issues.apache.org/jira/browse/GERONIMO-2264 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Affects Versions: 1.1.1 Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.1.1 svn cp https://svn.apache.org/repos/asf/geronimo/branches/1.1 https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 Committed revision 428093. -- 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-2264) Created branches/1.1.1 to start release process
[ http://issues.apache.org/jira/browse/GERONIMO-2264?page=comments#action_12425364 ] Matt Hogstrom commented on GERONIMO-2264: - svn commit -m GERONIMO-2264 Updated versions to 1.1.2-SNAPSHOT in branches/1.1 Sending1.1/etc/explicit_versions.properties Sending1.1/etc/project.properties Sending1.1/plugins/geronimo-assembly-plugin/project.properties Sending1.1/plugins/geronimo-assembly-plugin/project.xml Sending1.1/plugins/geronimo-dependency-plugin/project.properties Sending1.1/plugins/geronimo-dependency-plugin/project.xml Sending1.1/plugins/geronimo-deployment-plugin/project.properties Sending1.1/plugins/geronimo-deployment-plugin/project.xml Sending1.1/plugins/geronimo-izpack-plugin/project.properties Sending1.1/plugins/geronimo-izpack-plugin/project.xml Sending1.1/plugins/geronimo-packaging-plugin/plugin.properties Sending1.1/plugins/geronimo-packaging-plugin/project.properties Sending1.1/plugins/geronimo-packaging-plugin/project.xml Sending1.1/plugins/geronimo-packaging-plugin/src/test-resources/plan.xml Sending 1.1/plugins/geronimo-packaging-plugin/src/test-resources/result.xml Created branches/1.1.1 to start release process --- Key: GERONIMO-2264 URL: http://issues.apache.org/jira/browse/GERONIMO-2264 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 1.1.1 Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.1.1 svn cp https://svn.apache.org/repos/asf/geronimo/branches/1.1 https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 Committed revision 428093. -- 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-2264) Created branches/1.1.1 to start release process
[ http://issues.apache.org/jira/browse/GERONIMO-2264?page=comments#action_12425366 ] Matt Hogstrom commented on GERONIMO-2264: - Transmitting file data ... Committed revision 428127. Created branches/1.1.1 to start release process --- Key: GERONIMO-2264 URL: http://issues.apache.org/jira/browse/GERONIMO-2264 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Affects Versions: 1.1.1 Reporter: Matt Hogstrom Assigned To: Matt Hogstrom Fix For: 1.1.1 svn cp https://svn.apache.org/repos/asf/geronimo/branches/1.1 https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 Committed revision 428093. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-9) MarketSummary fix for NPE with less than 106 quotes
[ http://issues.apache.org/jira/browse/DAYTRADER-9?page=all ] Matt Hogstrom closed DAYTRADER-9. - Fix Version/s: 1.2 Resolution: Fixed Assignee: Matt Hogstrom Thanks Slava...patches applied and tested. Cheers. Sending trunk/modules/ejb/src/main/java/org/apache/geronimo/samples/daytrader/direct/TradeDirect.java Sending trunk/modules/ejb/src/main/java/org/apache/geronimo/samples/daytrader/ejb/TradeBean.java Transmitting file data .. Committed revision 426057. MarketSummary fix for NPE with less than 106 quotes --- Key: DAYTRADER-9 URL: http://issues.apache.org/jira/browse/DAYTRADER-9 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.1 Environment: All OS / all platforms Reporter: Slava Assigned To: Matt Hogstrom Fix For: 1.2 Attachments: DAYTRADER-9.patch, DAYTRADER-9_updated.patch This is a fix for the NPE in the MarketSummary.jsp and TradeHome.jsp thrown when the Daytrader database contains only 100 or less quotes. (see http://issues.apache.org/jira/browse/GERONIMO-1674) The current default configuration is 200 users and 400 quotes. As previously discussed, it takes long time to populate Daytrader database with as many user/quotes. This fix solves that problem. No NPE will be thrown if the database is populated with less than 105 quotes. This will speed up significantly the functional test with Daytrader. However, to retrieve market summary data you still need to have more than 106 quotes in the database. Therefore for performance measurments with Daytrader should be done using higher number of users/quotes. Slava -- 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-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[
http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423921
]
Matt Hogstrom commented on GERONIMO-2219:
-
Ok,
That's 3 +1's from PMC membersgo do your vodoo.
[RTC] Merge m2migration (functional m2 build) to trunk
--
Key: GERONIMO-2219
URL: http://issues.apache.org/jira/browse/GERONIMO-2219
Project: Geronimo
Issue Type: RTC
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Jason Dillon
Priority: Critical
Fix For: 1.2
h3. Overview
For the past few weeks we have been busy at work getting Geronimo
1.2-SNAPSHOT to build with Maven 2. As I have noted before in email, the
process is almost complete. At this point the work done so far results in a
functional server for the following assemblies:
* geronimo-jetty-j2ee
* geronimo-jetty-minimal
* geronimo-tomcat-j2ee
* geronimo-tomcat-minimal
The work to implement has been applied to a branch in the sandbox, and
includes many submitted patches from those contributors and commiters that
had been helping with the effort.
My recommendation is that we _merge_ this change to trunk and not generate a
diff and then patch. There are a few changes which patch does not handle
well and will cause failed chunks when applied, and there are a few files
moved and copied, which when patched will cause loss of that history.
As I mentioned this work is _almost complete_, there are still a few pending
issues, please see the section below for more details.
h3. Recommend Action Post RTC
Once we have the required RTC +1's to allow this work to be merged, this is
what I recommend:
# Merge m2migration to trunk as described below
# Deprecate the Maven1 build; meaning leave the m1 files, but strongly urge
developers to use the m2 build
# Enable the TCK _automated_ testing in GBuild using the m2 build
# Remove the m1 build (and related files)
These steps will probably take a few weeks post-merge to complete.
h3. About the Branch
The main branch which should be used for review is:
* https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
I have been using SVK ( http://svk.elixus.org/ ) to keep this m2migration
branch up to date with the latest changes that have been made to trunk (with
a few exceptions). I have been staging the merge as follows:
* merge from {{trunk}} to {{sandbox/svkmerge/trunk}}
* merge from {{sandbox/svkmerge/trunk}} {{sandbox/svkmerge/m2migration}}
This has worked out very well and I have found that using SVK dramatically
reduces to complexity of performing full tree (or partial tree merges). I
have been verifying that the SVK {{smerge}} is indeed doing the right thing
and I have a good deal of confidence in it at this point.
The idea is to merge m2migration back to trunk using SVK as follows:
* merge from {{sandbox/svkmerge/m2migration}} to {{sandbox/svkmerge/trunk}}
* merge from {{sandbox/svkmerge/trunk}} to {{trunk}}
This is the opposite of what I am performing now on a regular basis to sync
this development branch. Normally the additional branch (svkmerge/trunk)
would not be needed, but it exists to help ensure that the merge is indeed
_doing the right thing_.
h3. Recommended Review Steps
{noformat}
svn co https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
cd m2migration
./bootstrap
gunzip -c
m2-assemblies/geronimo-jetty-j2ee/target/geronimo-jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz
| tar xf -
./geronimo-jetty-j2ee/bin/startup.sh tail -f
geronimo-jetty-j2ee/var/log/geronimo.out
./geronimo-jetty-j2ee/bin/shutdown.sh --user system --password manager
{noformat}
*NOTE:* Windows users need to run {{bootstrap}} from a Cygwin environment and
should probably run these steps from the root of a drive (c:, d:, etc) to
better ensure that the long filename problem is not an issue when testing.
*WARNING:* The {{bootstrap}} script will remove your local Maven2 repository
cache and will take maybe 30 minutes or so to run... more or less depending
on how fast your network connection is.
You should define a mirror for the {{central}} m2 repository before
running... otherwise you will almost certainly get repository failures
downloading from ibiblio. This is what I am using (in ~/.m2/settings.xml):
{code:xml}
?xml version=1.0?
settings
mirrors
mirror
idrepo.mergere.com/id
urlhttp://repo.mergere.com/maven2/url
mirrorOfcentral/mirrorOf
/mirror
/mirrors
/settings
{code}
Also, due to the coupling of Geronimo and OpenEJB2, OpenEJB2 must be checked
out and built in the middle of the bootstrapping. Once G is hooked up to CI
and snapshots are being automatically
[jira] Commented: (GERONIMO-2223) [RTC] Move genesis out of the sandbox
[
http://issues.apache.org/jira/browse/GERONIMO-2223?page=comments#action_12423979
]
Matt Hogstrom commented on GERONIMO-2223:
-
+1...go forth and be fruitful
[RTC] Move genesis out of the sandbox
-
Key: GERONIMO-2223
URL: http://issues.apache.org/jira/browse/GERONIMO-2223
Project: Geronimo
Issue Type: RTC
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Jason Dillon
Priority: Critical
Fix For: 1.2
h3. Overview
Genesis, which provides common build configuration and plugin modules, is
needed by the main Maven2 build to function.
The project is here:
* http://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis/
You need to use the {{build}} or {{bootstrap}} scripts for the first build.
The later will nuke the previous genesis artifacts from the repo to ensure a
clean build (only genesis is removed from the repo).
h3. Recommended Post RTC
{noformat}
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/tags
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/branches
svn mv https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis
http://svn.apache.org/repos/asf/geronimo/genesis/trunk
{noformat}
--
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-2237) Filtering of springframework.org in TomcatDeployer plan creates CNF Exceptions in Ears
[ http://issues.apache.org/jira/browse/GERONIMO-2237?page=comments#action_12423981 ] Matt Hogstrom commented on GERONIMO-2237: - This makes sense for 1.1.1. I think Dain's changes will make us implement Aaron's suggestion later but that is another JIRA. Filtering of springframework.org in TomcatDeployer plan creates CNF Exceptions in Ears -- Key: GERONIMO-2237 URL: http://issues.apache.org/jira/browse/GERONIMO-2237 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.1 Reporter: Jeff Genender Priority: Blocker Fix For: 1.1.1 Filtering of springframework.org in TomcatDeployer plan creates ClassNotFound Exceptions in Ears when it tries to use a component that uses Spring in the EAR. We originally filtered this to automatically prevent Spring clashing with a server based Spring (from 1.0). This was fine for wars but when used iun an ear, the web container is blocked from using the EAR version. I recommend we remove these filters as SPrin is not usable in an EAR. Recommended patch for configs/tomcat-deployer: Index: src/plan/plan.xml === --- src/plan/plan.xml (revision 426203) +++ src/plan/plan.xml (working copy) @@ -46,10 +46,7 @@ typecar/type /dependency /dependencies -hidden-classes -filterantlr./filter -filterorg.springframework./filter -/hidden-classes +hidden-classes/ non-overridable-classes filterjava./filter filterjavax./filter -- 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: (DAYTRADER-9) MarketSummary fix for NPE with less than 106 quotes
[
http://issues.apache.org/jira/browse/DAYTRADER-9?page=comments#action_12423753
]
Matt Hogstrom commented on DAYTRADER-9:
---
Slava,
there is an if in the patch
+if ( (topGainersData.size() 0) || (topGainersData.size() 0)){
I'm not sure why the comparison is duplicated. Did you mean to have another
value for the comparison? I expect we only need one of the comparisons but
wanted to check.
MarketSummary fix for NPE with less than 106 quotes
---
Key: DAYTRADER-9
URL: http://issues.apache.org/jira/browse/DAYTRADER-9
Project: DayTrader
Issue Type: Improvement
Components: EJB Tier
Affects Versions: 1.1
Environment: All OS / all platforms
Reporter: Slava
Attachments: DAYTRADER-9.patch
This is a fix for the NPE in the MarketSummary.jsp and TradeHome.jsp thrown
when the Daytrader database contains only 100 or less quotes. (see
http://issues.apache.org/jira/browse/GERONIMO-1674)
The current default configuration is 200 users and 400 quotes. As previously
discussed, it takes long time to populate Daytrader database with as many
user/quotes.
This fix solves that problem. No NPE will be thrown if the database is
populated with less than 105 quotes. This will speed up significantly the
functional test with Daytrader.
However, to retrieve market summary data you still need to have more than 106
quotes in the database. Therefore for performance measurments with Daytrader
should be done using higher number of users/quotes.
Slava
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-7) [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere
[ http://issues.apache.org/jira/browse/DAYTRADER-7?page=all ] Matt Hogstrom closed DAYTRADER-7. - Fix Version/s: 1.2 Resolution: Fixed Assignee: Matt Hogstrom Removed JSPC precompilation from modules/web. After considering the issues I am more concerned with people having to monkey around with the ear which will make performance comparisons more difficult for released versions. If this issue causes grief for Windows users due to long pathnames I will reverse this change. Sendingmodules/web/pom.xml Transmitting file data . Committed revision 425415. [Daytrader] Precompiled jsp prevents Daytrader EAR from running on other J2EE servers like WebSphere Key: DAYTRADER-7 URL: http://issues.apache.org/jira/browse/DAYTRADER-7 Project: DayTrader Issue Type: Bug Affects Versions: 1.1 Reporter: Piyush Agarwal Assigned To: Matt Hogstrom Fix For: 1.2 In Daytrader1.1 ear file, JspC (Jasper) compiler has been used to precompile the JSPs and it adds these compiled JSP to servlet mappings in the web.xml file and places the compiled classes in the ear file. These precompiled JSPs extend and implement JspC specific classes. This EAR deploys successfully on WebSphere which doesn't use the JspC compiler for compilation. But when the precompiled JSPs are requested from the browser it causes application server to load the precompiled JSP classes which throw exceptions as it cannot find the Jasper specific classes in the classpath. The only way I have been able to fix this problem is to remove the rules in the pom.xml which cause the precompilation of the JSPs and places the precompiled JSP to servlet mapping in the web.xml and then rebuild the EAR file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DAYTRADER-8) Small difference in sync order processing between Direct and EJB mode
[ http://issues.apache.org/jira/browse/DAYTRADER-8?page=all ]
Matt Hogstrom closed DAYTRADER-8.
-
Fix Version/s: 1.2
Resolution: Fixed
Thanks for the patch Chris...applied.
Sending
modules/ejb/src/main/java/org/apache/geronimo/samples/daytrader/direct/TradeDirect.java
Transmitting file data .
Committed revision 425477.
Small difference in sync order processing between Direct and EJB mode
-
Key: DAYTRADER-8
URL: http://issues.apache.org/jira/browse/DAYTRADER-8
Project: DayTrader
Issue Type: Bug
Components: EJB Tier
Affects Versions: 1.1
Reporter: Christopher James Blythe
Priority: Minor
Fix For: 1.2
Attachments: orderPatch.diff
I have noticed a slight difference in the behavior of synchronous buy/sell
operations between EJB and JDBC mode. For example, in Sync/Direct mode, if
you perform a buy operation the resulting output of the NewOrder pages will
look something like the following...
271002open2006-07-19 17:04:50.921 null24.95 buy
s:0 100.0
If I perform the same operation in Sync/EJB mode, I get the following...
272002closed 2006-07-19 17:12:25.156 2006-07-19
17:12:25.156 24.95 buy s:1 100.0
Notice the differences between the two...
- the status (closed vs. open)
- the completion date (null vs an actual value)
I have looked into the code for this and it seems that the EJB version
actually returns a refreshed version of the bean (as performed by the ejb
container). However, in the JDBC/Direct code we perform the necessary updates
to the order via the order processing apis, but we never update the actual
local copy of the order bean before returning this.
I realize this may be a minor detail, but it does point out a slight
difference between the execution of Direct/EJB mode. The simple solution is
to re-fetch the order data before the buy/sell operations are completed in
the TradeDirect.java code, similar to the following...
orderData = getOrderData(conn, orderData.getOrderID().intValue());
if (txn != null) {
if ( Log.doTrace() )
Log.trace(TradeDirect:sell committing global transaction);
txn.commit();
setInGlobalTxn(false);
}
else
commit(conn);
Will attach a patch with this code tomorrow morning...
--
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: (DAYTRADER-8) Small difference in sync order processing between Direct and EJB mode
[ http://issues.apache.org/jira/browse/DAYTRADER-8?page=all ]
Matt Hogstrom reassigned DAYTRADER-8:
-
Assignee: Matt Hogstrom
Small difference in sync order processing between Direct and EJB mode
-
Key: DAYTRADER-8
URL: http://issues.apache.org/jira/browse/DAYTRADER-8
Project: DayTrader
Issue Type: Bug
Components: EJB Tier
Affects Versions: 1.1
Reporter: Christopher James Blythe
Assigned To: Matt Hogstrom
Priority: Minor
Fix For: 1.2
Attachments: orderPatch.diff
I have noticed a slight difference in the behavior of synchronous buy/sell
operations between EJB and JDBC mode. For example, in Sync/Direct mode, if
you perform a buy operation the resulting output of the NewOrder pages will
look something like the following...
271002open2006-07-19 17:04:50.921 null24.95 buy
s:0 100.0
If I perform the same operation in Sync/EJB mode, I get the following...
272002closed 2006-07-19 17:12:25.156 2006-07-19
17:12:25.156 24.95 buy s:1 100.0
Notice the differences between the two...
- the status (closed vs. open)
- the completion date (null vs an actual value)
I have looked into the code for this and it seems that the EJB version
actually returns a refreshed version of the bean (as performed by the ejb
container). However, in the JDBC/Direct code we perform the necessary updates
to the order via the order processing apis, but we never update the actual
local copy of the order bean before returning this.
I realize this may be a minor detail, but it does point out a slight
difference between the execution of Direct/EJB mode. The simple solution is
to re-fetch the order data before the buy/sell operations are completed in
the TradeDirect.java code, similar to the following...
orderData = getOrderData(conn, orderData.getOrderID().intValue());
if (txn != null) {
if ( Log.doTrace() )
Log.trace(TradeDirect:sell committing global transaction);
txn.commit();
setInGlobalTxn(false);
}
else
commit(conn);
Will attach a patch with this code tomorrow morning...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1451) A new TCP listener for ActiveMQ is not persisting across server startups
[ http://issues.apache.org/jira/browse/GERONIMO-1451?page=all ] Matt Hogstrom closed GERONIMO-1451. --- Fix Version/s: 1.0 (was: 1.1.1) Resolution: Fixed According to Vamsavardhana Reddy's e-mail on 7/20 this issue seems to be resolved. If this is not correct please reopen with comments. A new TCP listener for ActiveMQ is not persisting across server startups - Key: GERONIMO-1451 URL: http://issues.apache.org/jira/browse/GERONIMO-1451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 1.1 Environment: Windows 2003, Sun JVM java version 1.4.2_09 Reporter: Phani Balaji Madgula Priority: Critical Fix For: 1.0 Attachments: ActiveMQConnectorGBean.patch, ActiveMQManagerGBean.patch When we click on Add new tcp listener on JMS Network Listeners portlet, console asks for details of listener and when submitted with proper values, it creates a TCP listener and starts it. But, when we shutdown and restart the server, the listener is not shown in JMS Network Listeners portlet. The problem is that, I guess, the GBean pertaining to the new TCP listener is not saved to config.xml. But the same functionality is working fine for tomcat HTTP listeners. This problem is similar to GERONIMO-1070. -- 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-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=comments#action_12423080 ] Matt Hogstrom commented on GERONIMO-1695: - Rick, what is the state of this JIRA? CORBA for EJB with Local interface only causes NPE -- Key: GERONIMO-1695 URL: http://issues.apache.org/jira/browse/GERONIMO-1695 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Kevan Miller Priority: Critical Fix For: 1.2, 1.1.1 Attachments: GERONIMO-1695.diff-1.1.1, GERONIMO-1695.diff-1.2, GERONIMO-1695.diff-1.2a I have an EJB with a local interface and I tried applying CORBA settings. It blows up during deployment. My guess is that it wants a remote interface to be there, but somehow, the checks in StandardServant:126 are not working and the interface just comes up as null. Caused by: java.lang.NullPointerException at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) at org.openejb.corba.util.Util.getAllMethods(Util.java:815) at org.openejb.corba.util.Util.iiopMap(Util.java:608) at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) at org.openejb.corba.StandardServant.init(StandardServant.java:135) at org.openejb.corba.StandardServant.init(StandardServant.java:116) at org.openejb.corba.Adapter.init(Adapter.java:100) ... 67 more -- 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-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[
http://issues.apache.org/jira/browse/GERONIMO-2219?page=comments#action_12423230
]
Matt Hogstrom commented on GERONIMO-2219:
-
Here is my 2c.
I tested the build out tonight and was able to get a runnable server. IMHO
this change is way too complicated for a patch and is taking far too long (no
offense to anyone working on the conversion but more of a comment on our
current process).
I'm inclined to +1 the work Jason has done and move this to trunk. Then we all
work through the issues. Jason and others have been very diligent in working
on this conversion (which is in several months now I think).
Based on the responsiveness of Jason, Prasad and Anita I don't see a
tremendopus amount of harm in doing the merge and getting this done in trunk.
Its not ideal but one doesn't rework the entire build system every release.
I propose we +1 it...suck it up...and work with Jason to get this done. It
will be painful for everyone but I think right now Jason, Prasad and Anita are
suffering way too much.
This isn't a server feature...this is a build system. Its bigger than a bread
box. We all know what we're doing and its time to get this done.
Things will be broken...and they will get fixed.
[RTC] Merge m2migration (functional m2 build) to trunk
--
Key: GERONIMO-2219
URL: http://issues.apache.org/jira/browse/GERONIMO-2219
Project: Geronimo
Issue Type: RTC
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Jason Dillon
Priority: Critical
Fix For: 1.2
h3. Overview
For the past few weeks we have been busy at work getting Geronimo
1.2-SNAPSHOT to build with Maven 2. As I have noted before in email, the
process is almost complete. At this point the work done so far results in a
functional server for the following assemblies:
* geronimo-jetty-j2ee
* geronimo-jetty-minimal
* geronimo-tomcat-j2ee
* geronimo-tomcat-minimal
The work to implement has been applied to a branch in the sandbox, and
includes many submitted patches from those contributors and commiters that
had been helping with the effort.
My recommendation is that we _merge_ this change to trunk and not generate a
diff and then patch. There are a few changes which patch does not handle
well and will cause failed chunks when applied, and there are a few files
moved and copied, which when patched will cause loss of that history.
As I mentioned this work is _almost complete_, there are still a few pending
issues, please see the section below for more details.
h3. Recommend Action Post RTC
Once we have the required RTC +1's to allow this work to be merged, this is
what I recommend:
# Merge m2migration to trunk as described below
# Deprecate the Maven1 build; meaning leave the m1 files, but strongly urge
developers to use the m2 build
# Enable the TCK _automated_ testing in GBuild using the m2 build
# Remove the m1 build (and related files)
These steps will probably take a few weeks post-merge to complete.
h3. About the Branch
The main branch which should be used for review is:
* https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
I have been using SVK ( http://svk.elixus.org/ ) to keep this m2migration
branch up to date with the latest changes that have been made to trunk (with
a few exceptions). I have been staging the merge as follows:
* merge from {{trunk}} to {{sandbox/svkmerge/trunk}}
* merge from {{sandbox/svkmerge/trunk}} {{sandbox/svkmerge/m2migration}}
This has worked out very well and I have found that using SVK dramatically
reduces to complexity of performing full tree (or partial tree merges). I
have been verifying that the SVK {{smerge}} is indeed doing the right thing
and I have a good deal of confidence in it at this point.
The idea is to merge m2migration back to trunk using SVK as follows:
* merge from {{sandbox/svkmerge/m2migration}} to {{sandbox/svkmerge/trunk}}
* merge from {{sandbox/svkmerge/trunk}} to {{trunk}}
This is the opposite of what I am performing now on a regular basis to sync
this development branch. Normally the additional branch (svkmerge/trunk)
would not be needed, but it exists to help ensure that the merge is indeed
_doing the right thing_.
h3. Recommended Review Steps
{noformat}
svn co https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
cd m2migration
./bootstrap
gunzip -c
m2-assemblies/geronimo-jetty-j2ee/target/geronimo-jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz
| tar xf -
./geronimo-jetty-j2ee/bin/startup.sh tail -f
geronimo-jetty-j2ee/var/log/geronimo.out
./geronimo-jetty-j2ee/bin/shutdown.sh --user system --password manager
{noformat}
*NOTE:* Windows users need to run {{bootstrap}} from a Cygwin
[jira] Updated: (GERONIMO-1986) TranQL Connector doesn't check Driver Class during deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1986?page=all ] Matt Hogstrom updated GERONIMO-1986: Affects Version/s: 1.1.1 (was: 1.1) Assignee: Matt Hogstrom TranQL Connector doesn't check Driver Class during deployment - Key: GERONIMO-1986 URL: http://issues.apache.org/jira/browse/GERONIMO-1986 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector, deployment Affects Versions: 1.1.1 Reporter: Aaron Mulder Assigned To: Matt Hogstrom Fix For: 1.2, 1.1.x Attachments: db-plan-no-deps.xml, tranql-1986-updated.patch, tranql-1986.patch If you deploy the attached plan with the TranQL connector RAR, the distribute phase is successful, but it fails during start because the driver class is not available. It would be much better to find a way to validate the driver class during distribution. I'm not sure how complex this will be; it may involve instanting things during distribution that normally aren't instantiated until start time. But the current behavior is definitely not desirable. -- 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-2204) ProxyMethodInterceptor doesn't handle finalize appropriately
[
http://issues.apache.org/jira/browse/GERONIMO-2204?page=comments#action_12422323
]
Matt Hogstrom commented on GERONIMO-2204:
-
I think its worth fixing given that it pops up frequently and doesn't help
developers.
Serializable Noop sounds workable.
ProxyMethodInterceptor doesn't handle finalize appropriately
Key: GERONIMO-2204
URL: http://issues.apache.org/jira/browse/GERONIMO-2204
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: kernel
Affects Versions: 1.1
Reporter: David Jencks
Assigned To: Dain Sundstrom
Priority: Minor
A user noticed that while debugging in eclipse (or idea with
break-on-exceptions turned on) this method from ProxyMethodInterceptor throws
UnsupportedOperationException when finalize is called on a proxy object:
public final Object intercept(final Object object, final Method method,
final Object[] args, final MethodProxy proxy) throws Throwable {
ProxyInvoker gbeanInvoker;
int interfaceIndex = proxy.getSuperIndex();
synchronized (this) {
if (gbeanInvokers == null) {
throw new DeadProxyException(Proxy is no longer valid);
}
gbeanInvoker = gbeanInvokers[interfaceIndex];
}
if (gbeanInvoker == null) {
throw new UnsupportedOperationException(No implementation
method: objectName= + abstractName + , method= + method);
}
return gbeanInvoker.invoke(abstractName, args);
}
This appears to be harmless since the proxy doesn't implement finalize, but
annoying. We could fix this by explicitly ignoring the finalize method in
the code above, possibly by installing a suitable FinalizeInvoker, or by
using a CallbackFilter with a Noop or SerizializableNoop callback (the
strategy used by spring aop).
Is this worth fixing? Which way would be best?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1582) NPE for EJB webservices.xml with bad jaxrpc-mapping-file
[ http://issues.apache.org/jira/browse/GERONIMO-1582?page=all ] Matt Hogstrom closed GERONIMO-1582. --- Sachin applied the patch: URL: https://svn.apache.org/repos/asf/geronimo/branches/1.1/modules/axis-builder/src/java/org/apache/geronimo/axis/builder/WSDescriptorParser.java Repository Root: https://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 423590 Node Kind: file Schedule: normal Last Changed Author: sppatel Last Changed Rev: 423475 Last Changed Date: 2006-07-19 10:40:06 -0400 (Wed, 19 Jul 2006) Text Last Updated: 2006-07-19 22:25:47 -0400 (Wed, 19 Jul 2006) Properties Last Updated: 2006-07-19 16:34:21 -0400 (Wed, 19 Jul 2006) Checksum: 02c35ba1784f386d3f83d631a0f3925b NPE for EJB webservices.xml with bad jaxrpc-mapping-file -- Key: GERONIMO-1582 URL: http://issues.apache.org/jira/browse/GERONIMO-1582 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB, webservices Affects Versions: 1.1.x Reporter: Aaron Mulder Assigned To: Sachin Patel Priority: Critical Fix For: 1.1.1 Attachments: WSDescriptorParser.patch If the jaxrpc-mapping-file points to an invalid location, a NullPointerException is produced. It should instead give a DeploymentException with a message like: webservices.xml for EJB JAR points to jaxrpc-mapping-file 'META-INF/foo.map' for service 'bar' but that file is not found. 11:47:01,051 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.deployment.util.NestedJarFile.getInputStream(NestedJarFile.java:187) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:95) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:88) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:315) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at
[jira] Updated: (GERONIMO-2128) Allow user to specify the Isolation Level for a CMP bean's SQL access
[ http://issues.apache.org/jira/browse/GERONIMO-2128?page=all ] Matt Hogstrom updated GERONIMO-2128: Fix Version/s: 1.2 (was: 1.1.x) Allow user to specify the Isolation Level for a CMP bean's SQL access - Key: GERONIMO-2128 URL: http://issues.apache.org/jira/browse/GERONIMO-2128 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Matt Hogstrom Fix For: 1.2 Currently CMP beans all execute in the default isolation level of the datasource. This means that in many situations higher level locks are required for the database access than are required. This improvement will allow the user to specify a new attribute on a CMP entity bean isolation-level that will be the isolation level used for database access on this entity bean. This will require updates to OpenEJB and TranQL. -- 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-2129) Allow user to specify the pool size for Stateless Session beans
[ http://issues.apache.org/jira/browse/GERONIMO-2129?page=all ] Matt Hogstrom updated GERONIMO-2129: Fix Version/s: 1.2 (was: 1.1.x) Allow user to specify the pool size for Stateless Session beans --- Key: GERONIMO-2129 URL: http://issues.apache.org/jira/browse/GERONIMO-2129 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Reporter: Matt Hogstrom Fix For: 1.2 OpenEJB has code implemented to Pool Stateless session beans. This support is currently hardcoded to a cache size of one which eliminates any performance benefit of caching. A new attribute will be added to the OpenEJB XSD that will allow the user to specify the pool size to be used for a deployed stateless session bean. The attribute will be poolsize and will take an integer value as its argument. -- 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-2127) Expose the ability to use Select for Update on CMP entity beans
[ http://issues.apache.org/jira/browse/GERONIMO-2127?page=all ] Matt Hogstrom updated GERONIMO-2127: Fix Version/s: 1.2 (was: 1.1.x) Expose the ability to use Select for Update on CMP entity beans --- Key: GERONIMO-2127 URL: http://issues.apache.org/jira/browse/GERONIMO-2127 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Environment: All Reporter: Matt Hogstrom Fix For: 1.2 Currently TranQL supports the generation sql to execute a select for update. Unfortunately, OpenEJB does not expose the ability in the current XSD to support this. As a result the CMP implementation we have does pass CTS but lacks the ability to deploy an application that is performant and provides for data consistency. This improvement will add an attribute into the XSD for OpenEJB so a new attribute will be added select-for-update that is an indicator to use a select for update on a query so database locking can be employed. Changes will be made to TranQL (Syntax Factories) to create the correct SQL as well as OpenEJB's CMP builders to honor the request. -- 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
