[jira] Created: (GERONIMO-4614) Overloaded WSDL operations are not supported
Overloaded WSDL operations are not supported
Key: GERONIMO-4614
URL: https://issues.apache.org/jira/browse/GERONIMO-4614
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: webservices
Affects Versions: 2.1.4
Reporter: Christopher James Blythe
Priority: Blocker
Performing certification testing for SpecjEnt benchmark on Geronimo 2.1.4, ran
in the following issue.
2009-04-03 15:39:16,576 ERROR [Axis2WebServiceContainer] Exception occurred
while trying to invoke service method doService()
javax.xml.ws.WebServiceException: More than one operation found. Overloaded
WSDL operations are not supported. WSDL Operation name:
{http://session.mfg.ejb.jappserver.spec.org/}checkForRequestedWork
at
org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:172)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:69)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:117)
at
org.apache.geronimo.axis2.ejb.EJBMessageReceiver.getOperationDescription(EJBMessageReceiver.java:138)
at
org.apache.geronimo.axis2.ejb.EJBMessageReceiver.receive(EJBMessageReceiver.java:68)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:145)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.processXMLRequest(Axis2WebServiceContainer.java:404)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.processPOSTRequest(Axis2WebServiceContainer.java:353)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.doService2(Axis2WebServiceContainer.java:282)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.doService(Axis2WebServiceContainer.java:217)
at
org.apache.geronimo.axis2.Axis2WebServiceContainer.invoke(Axis2WebServiceContainer.java:177)
at
org.apache.geronimo.tomcat.TomcatEJBWebServiceContext$EJBWebServiceValve.invoke(TomcatEJBWebServiceContext.java:182)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:735)
Based on some feedback from colleagues, the issues stems from...
the problem was that the application uses 3 levels of inheritence...
interface 1 (annotated web service)
interface 2 (extends interface1, not a web service)
implementor (web service)
it can handle the
interface 1 (web service)
implementor (web service)
case, but the non-web-service in the middle caused it to blow up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-56) Register of duplicate userid in EJB 3 mode not handled correctly
[ https://issues.apache.org/jira/browse/DAYTRADER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-56. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Christopher James Blythe Fixed Register of duplicate userid in EJB 3 mode not handled correctly Key: DAYTRADER-56 URL: https://issues.apache.org/jira/browse/DAYTRADER-56 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Fix For: 2.0 If you attempt to register a userid that already exists in the database, the resulting error is not handled gracefully. In Direct mode, we catch the resulting DuplicateKeyException and ensure that a warning is propagated to the web-tier (by displaying a message on the register page). The register method in the TradeSLSBBean needs to be revised to handle this gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-56) Register of duplicate userid in EJB 3 mode not handled correctly
Register of duplicate userid in EJB 3 mode not handled correctly Key: DAYTRADER-56 URL: https://issues.apache.org/jira/browse/DAYTRADER-56 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe If you attempt to register a userid that already exists in the database, the resulting error is not handled gracefully. In Direct mode, we catch the resulting DuplicateKeyException and ensure that a warning is propagated to the web-tier (by displaying a message on the register page). The register method in the TradeSLSBBean needs to be revised to handle this gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DAYTRADER-56) Register of duplicate userid in EJB 3 mode not handled correctly
[ https://issues.apache.org/jira/browse/DAYTRADER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532248 ] Christopher James Blythe commented on DAYTRADER-56: --- Spoke to some of the JPA developers and got the skinny on exceptions thrown by the persist method. According to them, the EntityExistsException during persist() will only happen if the Entity already exists in the PersistenceContext. Otherwise, the only way to detect this condition is at flush/commit time (which occurs once the session bean method completes). Consequently, the only graceful way to do this is to check and see if an entity with the same ID exists prior (using the find() method) prior to calling persist(). Register of duplicate userid in EJB 3 mode not handled correctly Key: DAYTRADER-56 URL: https://issues.apache.org/jira/browse/DAYTRADER-56 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe If you attempt to register a userid that already exists in the database, the resulting error is not handled gracefully. In Direct mode, we catch the resulting DuplicateKeyException and ensure that a warning is propagated to the web-tier (by displaying a message on the register page). The register method in the TradeSLSBBean needs to be revised to handle this gracefully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-55) Missing logic in EJB mode to detect holdings that have already been sold
[ https://issues.apache.org/jira/browse/DAYTRADER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-55. - Resolution: Fixed Fix Version/s: 2.0 Missing logic in EJB mode to detect holdings that have already been sold Key: DAYTRADER-55 URL: https://issues.apache.org/jira/browse/DAYTRADER-55 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Fix For: 2.0 During the port from EJB 2.1 to 3.0 it appears that logic to detect if a holding has already been sold was dropped out of the sell method. This scenario can occur in two circumstances... - When the same user is logged in twice and both attempt to sell the same holding - In Async mode, if a sell is attempted on the same holding before the original sell request is handled by the MDB -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-53) Remove EJB 2.1 components from Daytrader 2.0
[ https://issues.apache.org/jira/browse/DAYTRADER-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-53. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Christopher James Blythe Remove EJB 2.1 components from Daytrader 2.0 Key: DAYTRADER-53 URL: https://issues.apache.org/jira/browse/DAYTRADER-53 Project: DayTrader Issue Type: Task Components: EJB Tier, J2EE Application Clients, Web Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Fix For: 2.0 A while back I started some discussion around whether or not the old EJB 2.1 components should continue to be maintained in DayTrader 2.0. Their are arguments for and against; however, I still feel removing the legacy components is the best option. The only argument for leaving the EJB 2.1 components in is that you can easily switch between 2.1 and 3.0 without restarting the server or installing another app. In my opinion, this is far out-weighed by the cons which include the following factors... - complexity - maintainability - portability Removing the EJB 2.1 components simplifies the application considerably since two versions of the components no longer have to be maintained in the same application. Furthermore, it highlights the usability factor that was a major focus for EJB 3. For instance, if I remove the 2.1 components, I no longer need to place anything in the ejb-jar.xml DD. That's a far cry from the EJB 2.1 days... The EJB 2.1 components should be maintained for comparison purposes; however, they should reside in DayTrader 1.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-55) Missing logic in EJB mode to detect holdings that have already been sold
Missing logic in EJB mode to detect holdings that have already been sold Key: DAYTRADER-55 URL: https://issues.apache.org/jira/browse/DAYTRADER-55 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe During the port from EJB 2.1 to 3.0 it appears that logic to detect if a holding has already been sold was dropped out of the sell method. This scenario can occur in two circumstances... - When the same user is logged in twice and both attempt to sell the same holding - In Async mode, if a sell is attempted on the same holding before the original sell request is handled by the MDB -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-24) Clean up plan files in 1.2 branch
[ https://issues.apache.org/jira/browse/DAYTRADER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-24. - Resolution: Fixed Clean up plan files in 1.2 branch - Key: DAYTRADER-24 URL: https://issues.apache.org/jira/browse/DAYTRADER-24 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 Attachments: daytrader-24.1120.patch, daytrader-24.patch The plan files in the 1.2 branch are are based on Geronimo 1.0 and need to be updated (similar to what is in the Daytrader 1.1 branch). It would also be nice if we could add plan files for Oracle and DB2 data sources. However, it looks like we do not include the necessary Tranql rars in Geronimo to support this out of the box. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-54) PingServlet2Include primitive broken
[ https://issues.apache.org/jira/browse/DAYTRADER-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-54. - Resolution: Fixed Fix Version/s: 2.0 1.2 Fixed PingServlet2Include primitive broken Key: DAYTRADER-54 URL: https://issues.apache.org/jira/browse/DAYTRADER-54 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 While running through the primitives, found that the PingServlet2Include primitive is broken. Took a look at the web.xml and just need to make some modifications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-54) PingServlet2Include primitive broken
PingServlet2Include primitive broken Key: DAYTRADER-54 URL: https://issues.apache.org/jira/browse/DAYTRADER-54 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor While running through the primitives, found that the PingServlet2Include primitive is broken. Took a look at the web.xml and just need to make some modifications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3436) DayTrader streamer and web services (Swing) clients terminate unexpectedly
DayTrader streamer and web services (Swing) clients terminate unexpectedly
--
Key: GERONIMO-3436
URL: https://issues.apache.org/jira/browse/GERONIMO-3436
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: application client
Affects Versions: 2.0.x
Reporter: Christopher James Blythe
Description from devlist...
All...
I'm still working with the DayTrader streamer client and have run into another
issue I cannot explain. Both the streamer and ws app client create Swing-based
GUIs. I am in no way a Swing expert; however, all of the docs that I have read
indicate that the GUI thread should remain up and running (along with the JVM)
after main completes. Here is an example...
public class JFrameExample {
public static void main(String[] args) {
JFrame f = new JFrame(This is a test);
...
f.addWindowListener(new ExitListener());
f.setVisible(true);
}
}
From what I have seen all Swing apps use some variation of this, as do the
DayTrader streamer and ws app clients.
Unfortunately, when I try to run these clients in under Geronimo 2.0.1, the
apps terminate when the main thread completes. I have added a Thread.sleep() to
the main just to verify that the GUI remains up while the main thread is still
active.
Does anyone have any thoughts as to why the JVM is terminating with main while
the GUI threads are still active and have not been closed? I've tried a SUN and
IBM JVM and both result in early termination. The only thing I can think of is
that something in the Geronimo client or the manner in which Geronimo packages
the client that is changing the behavior.
Response from David Jencks...
I remember fixing this once
My guess is that it got broken again when gianny added the bootstrap
repository. A JIRA would be good I think. I suspect if you look
around at the various command line classes you can see the code that
shuts down the client from a shutdown hook and see why it isn't
getting used.
I'll try to find some time to take a look at this if you don't beat
me to it.
thanks
david jencks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-52) Replace low-level EJB3 primitives with primitives that can be compared to existing EJB 2.1 primitives
[ https://issues.apache.org/jira/browse/DAYTRADER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-52. - Resolution: Fixed Fix Version/s: 2.0 Replace low-level EJB3 primitives with primitives that can be compared to existing EJB 2.1 primitives - Key: DAYTRADER-52 URL: https://issues.apache.org/jira/browse/DAYTRADER-52 Project: DayTrader Issue Type: Improvement Components: EJB Tier, Web Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Fix For: 2.0 The EJB 3 primitives that were initially added to DayTrader 2.0 are extremely low-level and cannot be compared to the existing EJB 2.1 primitives. Therefore, removing the current EJB3 primitives and replacing them with primitives that are equivalent to the EJB 2.1 primitives. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-53) Remove EJB 2.1 components from Daytrader 2.0
Remove EJB 2.1 components from Daytrader 2.0 Key: DAYTRADER-53 URL: https://issues.apache.org/jira/browse/DAYTRADER-53 Project: DayTrader Issue Type: Task Components: EJB Tier, J2EE Application Clients, Web Tier Affects Versions: 2.0 Reporter: Christopher James Blythe A while back I started some discussion around whether or not the old EJB 2.1 components should continue to be maintained in DayTrader 2.0. Their are arguments for and against; however, I still feel removing the legacy components is the best option. The only argument for leaving the EJB 2.1 components in is that you can easily switch between 2.1 and 3.0 without restarting the server or installing another app. In my opinion, this is far out-weighed by the cons which include the following factors... - complexity - maintainability - portability Removing the EJB 2.1 components simplifies the application considerably since two versions of the components no longer have to be maintained in the same application. Furthermore, it highlights the usability factor that was a major focus for EJB 3. For instance, if I remove the 2.1 components, I no longer need to place anything in the ejb-jar.xml DD. That's a far cry from the EJB 2.1 days... The EJB 2.1 components should be maintained for comparison purposes; however, they should reside in DayTrader 1.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-52) Replace low-level EJB3 primitives with primitives that can be compared to existing EJB 2.1 primitives
Replace low-level EJB3 primitives with primitives that can be compared to existing EJB 2.1 primitives - Key: DAYTRADER-52 URL: https://issues.apache.org/jira/browse/DAYTRADER-52 Project: DayTrader Issue Type: Improvement Components: EJB Tier, Web Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe The EJB 3 primitives that were initially added to DayTrader 2.0 are extremely low-level and cannot be compared to the existing EJB 2.1 primitives. Therefore, removing the current EJB3 primitives and replacing them with primitives that are equivalent to the EJB 2.1 primitives. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-48) Remove TradeJPA mode (replaced by full EJB 3 mode)
[ https://issues.apache.org/jira/browse/DAYTRADER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-48. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Christopher James Blythe Completed removal of TradeJPA Remove TradeJPA mode (replaced by full EJB 3 mode) -- Key: DAYTRADER-48 URL: https://issues.apache.org/jira/browse/DAYTRADER-48 Project: DayTrader Issue Type: Task Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 2.0 The EJB 3 code that was recently committed provides a full EJB 3 implementation of the DayTrader workload using EJB 3 entities, sessions and MDBs. This improves upon the original Trade JPA mode (from which the business logic was originally ported) that used EJB 2.1 based session and MDBs. Furthermore, minor modifications were made to improve data consistency and performance (via eager/lazy loading of the entities). I see no real need for the original JPA mode to stick around and feel it should be removed. Any objections? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-50) UserID shows up as null on Home page in EJB 3 mode
UserID shows up as null on Home page in EJB 3 mode -- Key: DAYTRADER-50 URL: https://issues.apache.org/jira/browse/DAYTRADER-50 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Priority: Minor The userID shows up as null on the Home page while in EJB 3 mode. Need to populate transient field in AccountDataBean with profile userid. Also, using this opportunity to add a TransactionalAttribute of NOT_SUPPORTED as an annotation on the resetTrade method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-49) Add EJB 3 based Session-to-Direct mode
[ https://issues.apache.org/jira/browse/DAYTRADER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-49. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Christopher James Blythe Completed Add EJB 3 based Session-to-Direct mode -- Key: DAYTRADER-49 URL: https://issues.apache.org/jira/browse/DAYTRADER-49 Project: DayTrader Issue Type: New Feature Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Fix For: 2.0 This JIRA was opened to address the need for an EJB 3 based Stateless Session Bean to Direct JDBC mode (similar to what was added to the EJB 2.1 implementation in DAYTRADER-15). The code changes are relatively straight forward and simply require a new session bean which calls the service methods via TradeDirect. As previously mentioned in DAYTRADER-15. This is known to be a common method for managing transactions commits/rollbacks for EJB 2.1 applications. I imagine this will not change for EJB 3.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-50) UserID shows up as null on Home page in EJB 3 mode
[ https://issues.apache.org/jira/browse/DAYTRADER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-50. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Christopher James Blythe Completed UserID shows up as null on Home page in EJB 3 mode -- Key: DAYTRADER-50 URL: https://issues.apache.org/jira/browse/DAYTRADER-50 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 2.0 The userID shows up as null on the Home page while in EJB 3 mode. Need to populate transient field in AccountDataBean with profile userid. Also, using this opportunity to add a TransactionalAttribute of NOT_SUPPORTED as an annotation on the resetTrade method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-38) Cleanup ejb-jar.xml by removing one-phase remnants and fixing spec compliance warnings
[ https://issues.apache.org/jira/browse/DAYTRADER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-38. - Resolution: Fixed Fix Version/s: 2.0 1.2 Fixes now applied to both DayTrader 1.2 and 2.0 Cleanup ejb-jar.xml by removing one-phase remnants and fixing spec compliance warnings -- Key: DAYTRADER-38 URL: https://issues.apache.org/jira/browse/DAYTRADER-38 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 While working to deploy Daytrader 1.2 on Sun Server 9 (Glassfish) with NetBeans 5.5, the NetBeans validation utilities pointed out several errors and spec compliance warnings in the ejb-jar.xml. To remove these warnings and errors, the following changes were necessary... - Remove remnants of one-phase methods in the container transactions section - Remove the result-type-mapping tags from the query definitions - Add the messaging-type tag to the MDB definitions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-40) Add vendor specific DDs for deployment on Sun Java System Application Server Platform Edition 9
[ https://issues.apache.org/jira/browse/DAYTRADER-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-40: -- Affects Version/s: (was: 2.0) Making this a 1.2 only item. May revisit this in the 2.0 time frame later. Add vendor specific DDs for deployment on Sun Java System Application Server Platform Edition 9 --- Key: DAYTRADER-40 URL: https://issues.apache.org/jira/browse/DAYTRADER-40 Project: DayTrader Issue Type: New Feature Components: EJB Tier, J2EE Application Clients, Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 1.2 Add the vendor specific deployment descriptors required to deploy Daytrader on Sun Java System Application Server Platform Edition 9. Since these do not impact the based J2EE deployment descriptors in any way, they can coexist in the project without impacting Geronimo, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-40) Add vendor specific DDs for deployment on Sun Java System Application Server Platform Edition 9
[ https://issues.apache.org/jira/browse/DAYTRADER-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-40. - Resolution: Fixed Fix Version/s: 1.2 Completed in 1.2 Add vendor specific DDs for deployment on Sun Java System Application Server Platform Edition 9 --- Key: DAYTRADER-40 URL: https://issues.apache.org/jira/browse/DAYTRADER-40 Project: DayTrader Issue Type: New Feature Components: EJB Tier, J2EE Application Clients, Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 1.2 Add the vendor specific deployment descriptors required to deploy Daytrader on Sun Java System Application Server Platform Edition 9. Since these do not impact the based J2EE deployment descriptors in any way, they can coexist in the project without impacting Geronimo, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-39) Revise exception handling in EJB-tier to comply with spec
[ https://issues.apache.org/jira/browse/DAYTRADER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-39: -- Affects Version/s: (was: 2.0) Making this a 1.2 only item for the time being. May revisit in 2.0. Revise exception handling in EJB-tier to comply with spec - Key: DAYTRADER-39 URL: https://issues.apache.org/jira/browse/DAYTRADER-39 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 1.2 While working to deploy Daytrader 1.2 on Sun Server 9 (Glassfish) with NetBeans 5.5, the NetBeans validation utilities pointed out spec violations associated with the exceptions thrown by classes in the EJB tier. To comply with the spec, the following high level rules were followed... - TradeServices.java - all methods should throw Exception and RemoteException - Trade.java - all methods should throw Exception and RemoteException - TradeBean and TradeJDBCBean - methods should simply throw Exception (not RemoteException) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-39) Revise exception handling in EJB-tier to comply with spec
[ https://issues.apache.org/jira/browse/DAYTRADER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-39. - Resolution: Fixed Fix Version/s: 1.2 Revise exception handling in EJB-tier to comply with spec - Key: DAYTRADER-39 URL: https://issues.apache.org/jira/browse/DAYTRADER-39 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Assignee: Christopher James Blythe Priority: Minor Fix For: 1.2 While working to deploy Daytrader 1.2 on Sun Server 9 (Glassfish) with NetBeans 5.5, the NetBeans validation utilities pointed out spec violations associated with the exceptions thrown by classes in the EJB tier. To comply with the spec, the following high level rules were followed... - TradeServices.java - all methods should throw Exception and RemoteException - Trade.java - all methods should throw Exception and RemoteException - TradeBean and TradeJDBCBean - methods should simply throw Exception (not RemoteException) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-47) Add full EJB 3 runtime mode (including EJB 3 based stateless session bean and MDBs)
Add full EJB 3 runtime mode (including EJB 3 based stateless session bean and MDBs) --- Key: DAYTRADER-47 URL: https://issues.apache.org/jira/browse/DAYTRADER-47 Project: DayTrader Issue Type: New Feature Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Fix For: 2.0 This code was committed into trunk in revision 559535 on 7/25/07 The following information was posted to the dev list regarding the changes. Since this basically replaces the existing TradeJPA implementation, I think it should be removed (will address this in another JIRA). All, As it currently stands, DayTrader 2.0 does not provide what I would consider a viable showcase application for Java EE 5 technology. The JPA mode that was added uses EJB3/JPA based entities; however, the mode still lacks a few key elements... - EJB 3 based stateless session bean providing the business logic (current impl still uses EJB 2.1 session beans) - EJB 3 based MDBs for Quote streamer and async order processing - Improvements to JPA mode to ensure data consistency and improve performance I have added a new EJB3 runtime mode that exposes the following... - TradeSLSBBean (new EJB 3 based session bean for business logic) - DTBroker3MDB (new EJB 3 based MDB for async order processing) - DTStreamer3MDB (new EJB 3 based MDB for quote streamer) I have made these updates and plan to commit them shortly, I have left the existing TradeJPA bean as is, in addition to the legacy Direct and EJB 2.1 modes. I have pulled yesterday's build of Geronimo 2.0 and verified that the new EJB3 mode functionally works along with the legacy modes. The next step is load testing, so stay tuned... Thanks... Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-47) Add full EJB 3 runtime mode (including EJB 3 based stateless session bean and MDBs)
[ https://issues.apache.org/jira/browse/DAYTRADER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-47. - Resolution: Fixed Add full EJB 3 runtime mode (including EJB 3 based stateless session bean and MDBs) --- Key: DAYTRADER-47 URL: https://issues.apache.org/jira/browse/DAYTRADER-47 Project: DayTrader Issue Type: New Feature Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Fix For: 2.0 This code was committed into trunk in revision 559535 on 7/25/07 The following information was posted to the dev list regarding the changes. Since this basically replaces the existing TradeJPA implementation, I think it should be removed (will address this in another JIRA). All, As it currently stands, DayTrader 2.0 does not provide what I would consider a viable showcase application for Java EE 5 technology. The JPA mode that was added uses EJB3/JPA based entities; however, the mode still lacks a few key elements... - EJB 3 based stateless session bean providing the business logic (current impl still uses EJB 2.1 session beans) - EJB 3 based MDBs for Quote streamer and async order processing - Improvements to JPA mode to ensure data consistency and improve performance I have added a new EJB3 runtime mode that exposes the following... - TradeSLSBBean (new EJB 3 based session bean for business logic) - DTBroker3MDB (new EJB 3 based MDB for async order processing) - DTStreamer3MDB (new EJB 3 based MDB for quote streamer) I have made these updates and plan to commit them shortly, I have left the existing TradeJPA bean as is, in addition to the legacy Direct and EJB 2.1 modes. I have pulled yesterday's build of Geronimo 2.0 and verified that the new EJB3 mode functionally works along with the legacy modes. The next step is load testing, so stay tuned... Thanks... Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-48) Remove TradeJPA mode (replaced by full EJB 3 mode)
Remove TradeJPA mode (replaced by full EJB 3 mode) -- Key: DAYTRADER-48 URL: https://issues.apache.org/jira/browse/DAYTRADER-48 Project: DayTrader Issue Type: Task Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Priority: Minor The EJB 3 code that was recently committed provides a full EJB 3 implementation of the DayTrader workload using EJB 3 entities, sessions and MDBs. This improves upon the original Trade JPA mode (from which the business logic was originally ported) that used EJB 2.1 based session and MDBs. Furthermore, minor modifications were made to improve data consistency and performance (via eager/lazy loading of the entities). I see no real need for the original JPA mode to stick around and feel it should be removed. Any objections? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-49) Add EJB 3 based Session-to-Direct mode
Add EJB 3 based Session-to-Direct mode -- Key: DAYTRADER-49 URL: https://issues.apache.org/jira/browse/DAYTRADER-49 Project: DayTrader Issue Type: New Feature Components: EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe This JIRA was opened to address the need for an EJB 3 based Stateless Session Bean to Direct JDBC mode (similar to what was added to the EJB 2.1 implementation in DAYTRADER-15). The code changes are relatively straight forward and simply require a new session bean which calls the service methods via TradeDirect. As previously mentioned in DAYTRADER-15. This is known to be a common method for managing transactions commits/rollbacks for EJB 2.1 applications. I imagine this will not change for EJB 3.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3354) Exception thrown by MDB involved in XA transaction
Exception thrown by MDB involved in XA transaction -- Key: GERONIMO-3354 URL: https://issues.apache.org/jira/browse/GERONIMO-3354 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: transaction manager Affects Versions: 2.0 Environment: Geronimo 2.0 (tomcat) build from 07/24 (http://people.apache.org/~prasad/binaries/20070724/) DayTrader 1.2 or 2.0 (any runtime mode) with asyn order processing enabled Reporter: Christopher James Blythe Priority: Critical The async order processing in DayTrader uses the TradeBrokerMDB to handle complete order operations whenever a buy or sell is performed. When these transactions are executed, the transaction appears to complete; however, the following exception is written to the console and log file. According to Jencks, this seems to indicate that the tx info is not being written to the transaction log. 22:59:18,421 ERROR [Transaction] Please correct the integration and supply a NamedXAResource java.lang.IllegalStateException : Cannot log transactions as [EMAIL PROTECTED] is not a NamedXAResource. at org.apache.geronimo.transaction.manager.TransactionImpl$TransactionBranch.getResourceName(TransactionImpl.java :697) at org.apache.geronimo.transaction.log.HOWLLog.prepare(HOWLLog.java:254) at org.apache.geronimo.transaction.log.HOWLLog$$FastClassByCGLIB$$7315be2e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke (FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:830) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.gbean.GBeanLifecycle$$EnhancerByCGLIB$$ba0af455.prepare(generated) at org.apache.geronimo.transaction.manager.TransactionImpl.internalPrepare(TransactionImpl.java :444) at org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:316) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:238) at org.apache.openejb.core.transaction.TransactionPolicy.commitTransaction(TransactionPolicy.java:139) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:75) at org.apache.openejb.core.mdb.MdbContainer.afterDelivery (MdbContainer.java:375) at org.apache.openejb.core.mdb.EndpointHandler.afterDelivery(EndpointHandler.java:274) at org.apache.openejb.core.mdb.EndpointHandler.invoke(EndpointHandler.java:164) at $Proxy36.afterDelivery(Unknown Source) at org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.afterDelivery(MessageEndpointProxy.java:126) at org.apache.activemq.ra.MessageEndpointProxy.afterDelivery(MessageEndpointProxy.java:65) at org.apache.activemq.ra.ServerSessionImpl.afterDelivery(ServerSessionImpl.java:216) at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:751) at org.apache.activemq.ra.ServerSessionImpl.run( ServerSessionImpl.java:165) at org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:290) at org.apache.geronimo.connector.work.pool.NamedRunnable.run(NamedRunnable.java:32) at org.apache.geronimo.pool.ThreadPool$1.run (ThreadPool.java:201) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:331) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:801) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-43) Reset fails in Session Direct mode
[ https://issues.apache.org/jira/browse/DAYTRADER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-43. - Resolution: Fixed Fix Version/s: 2.0 1.2 Assignee: Christopher James Blythe Applied fixes to 1.2 and 2.0 Reset fails in Session Direct mode -- Key: DAYTRADER-43 URL: https://issues.apache.org/jira/browse/DAYTRADER-43 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 If you attempt to reset Daytrader in Session Direct mode, the container will throw in exception. Took a closer look and have a quick fix. The ejb DDL defines resetTrade as TRANSACTION NOT SUPPORTED. Therefore, the reset code must perform the commits and not rely on the container to do it. This can be accomplished by setting the inSession flag to false when creating a new instance of TradeDirect for the resetTrade method in TradeJDBCBean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-4) DayTrader README file out of date
[ https://issues.apache.org/jira/browse/DAYTRADER-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-4: - Assignee: Christopher James Blythe Affects Version/s: (was: 1.1) 1.2 DayTrader README file out of date - Key: DAYTRADER-4 URL: https://issues.apache.org/jira/browse/DAYTRADER-4 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: John Sisson Assigned To: Christopher James Blythe This issue has been moved from GERONIMO-1436 - Currently the instructions say to run maven in the same directory as the README file, but just running maven from there does not do anything AFAIK. Also the instructions regarding creating the database seem to be old. Need input as to what the current installation instructions are. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-4) DayTrader README file out of date
[ https://issues.apache.org/jira/browse/DAYTRADER-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-4. Resolution: Fixed Fix Version/s: 1.2 DayTrader README file out of date - Key: DAYTRADER-4 URL: https://issues.apache.org/jira/browse/DAYTRADER-4 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: John Sisson Assigned To: Christopher James Blythe Fix For: 1.2 This issue has been moved from GERONIMO-1436 - Currently the instructions say to run maven in the same directory as the README file, but just running maven from there does not do anything AFAIK. Also the instructions regarding creating the database seem to be old. Need input as to what the current installation instructions are. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-38) Cleanup ejb-jar.xml by removing one-phase remnants and fixing spec compliance warnings
Cleanup ejb-jar.xml by removing one-phase remnants and fixing spec compliance warnings -- Key: DAYTRADER-38 URL: https://issues.apache.org/jira/browse/DAYTRADER-38 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor While working to deploy Daytrader 1.2 on Sun Server 9 (Glassfish) with NetBeans 5.5, the NetBeans validation utilities pointed out several errors and spec compliance warnings in the ejb-jar.xml. To remove these warnings and errors, the following changes were necessary... - Remove remnants of one-phase methods in the container transactions section - Remove the result-type-mapping tags from the query definitions - Add the messaging-type tag to the MDB definitions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-39) Revise exception handling in EJB-tier to comply with spec
Revise exception handling in EJB-tier to comply with spec - Key: DAYTRADER-39 URL: https://issues.apache.org/jira/browse/DAYTRADER-39 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor While working to deploy Daytrader 1.2 on Sun Server 9 (Glassfish) with NetBeans 5.5, the NetBeans validation utilities pointed out spec violations associated with the exceptions thrown by classes in the EJB tier. To comply with the spec, the following high level rules were followed... - TradeServices.java - all methods should throw Exception and RemoteException - Trade.java - all methods should throw Exception and RemoteException - TradeBean and TradeJDBCBean - methods should simply throw Exception (not RemoteException) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-40) Add vendor specific DDs for deployment on Sun Java System Application Server Platform Edition 9
Add vendor specific DDs for deployment on Sun Java System Application Server Platform Edition 9 --- Key: DAYTRADER-40 URL: https://issues.apache.org/jira/browse/DAYTRADER-40 Project: DayTrader Issue Type: New Feature Components: EJB Tier, J2EE Application Clients, Web Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Add the vendor specific deployment descriptors required to deploy Daytrader on Sun Java System Application Server Platform Edition 9. Since these do not impact the based J2EE deployment descriptors in any way, they can coexist in the project without impacting Geronimo, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-37) UpdateProfile button on Account page does not work
UpdateProfile button on Account page does not work -- Key: DAYTRADER-37 URL: https://issues.apache.org/jira/browse/DAYTRADER-37 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor The UpdateProfile button does not submit account profile changes to the server. After looking at the JSP, form tags are missing and need to be added. Already have a patch and will be committing shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-37) UpdateProfile button on Account page does not work
[ https://issues.apache.org/jira/browse/DAYTRADER-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-37. - Resolution: Fixed Fix Version/s: 2.0 1.2 Committed fix to both branches/1.2 and trunk (excluded branches/old2_0Trunk) UpdateProfile button on Account page does not work -- Key: DAYTRADER-37 URL: https://issues.apache.org/jira/browse/DAYTRADER-37 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 The UpdateProfile button does not submit account profile changes to the server. After looking at the JSP, form tags are missing and need to be added. Already have a patch and will be committing shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DAYTRADER-35) Change createDB script for the Geronimo 2.0
[ https://issues.apache.org/jira/browse/DAYTRADER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476209 ] Christopher James Blythe commented on DAYTRADER-35: --- A feature was added into Daytrader 1.2 and 2.0 to manage the table/index creation within the war file. The ddls are stored in a dbscripts sub-directory of the war file and a link was added to the configuration page to trigger the creation of the database tables and indexes. The prerequisite derby database is created by the datasource definition in the deployment plan files. This feature makes the database creation scripts obsolete. Nevertheless, there is still value in keeping a basic db creation script around for convenience. Based on discussion in the dev list, the database creation script should be moved from the modules sub-directory and placed in the bin directory. These changes along with the derby version update apply to both branches/1.2 and trunk. Change createDB script for the Geronimo 2.0 --- Key: DAYTRADER-35 URL: https://issues.apache.org/jira/browse/DAYTRADER-35 Project: DayTrader Issue Type: Improvement Components: buildsystem Reporter: Lasantha Ranaweera Attachments: DAYTRADER-35.patch.patch G 2.0 uses new version of Derby. Existing createDB.sh file has to modify according to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-36) Clean/update scripts in bin directory and remove images directory
Clean/update scripts in bin directory and remove images directory - Key: DAYTRADER-36 URL: https://issues.apache.org/jira/browse/DAYTRADER-36 Project: DayTrader Issue Type: Improvement Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Priority: Trivial Per discussion on the dev list, most of the scripts remaining in the bin directory either do not work or are no longer needed. Furthermore, the UI mock ups in the images directory are not necessary. Consequently, the following has been proposed... - Remove all existing scripts from bin except for a deploy and undeploy script and update these scripts to work with Daytrader 1.2/2.0 on Geronimo 1.2/2.0. - Delete the images directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DAYTRADER-36) Clean/update scripts in bin directory and remove images directory
[ https://issues.apache.org/jira/browse/DAYTRADER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-36: - Assignee: Christopher James Blythe Clean/update scripts in bin directory and remove images directory - Key: DAYTRADER-36 URL: https://issues.apache.org/jira/browse/DAYTRADER-36 Project: DayTrader Issue Type: Improvement Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Trivial Per discussion on the dev list, most of the scripts remaining in the bin directory either do not work or are no longer needed. Furthermore, the UI mock ups in the images directory are not necessary. Consequently, the following has been proposed... - Remove all existing scripts from bin except for a deploy and undeploy script and update these scripts to work with Daytrader 1.2/2.0 on Geronimo 1.2/2.0. - Delete the images directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DAYTRADER-35) Change createDB script for the Geronimo 2.0
[ https://issues.apache.org/jira/browse/DAYTRADER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-35: - Assignee: Christopher James Blythe Change createDB script for the Geronimo 2.0 --- Key: DAYTRADER-35 URL: https://issues.apache.org/jira/browse/DAYTRADER-35 Project: DayTrader Issue Type: Improvement Components: buildsystem Reporter: Lasantha Ranaweera Assigned To: Christopher James Blythe Attachments: DAYTRADER-35.patch.patch G 2.0 uses new version of Derby. Existing createDB.sh file has to modify according to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-36) Clean/update scripts in bin directory and remove images directory
[ https://issues.apache.org/jira/browse/DAYTRADER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-36. - Resolution: Fixed Fix Version/s: 2.0 1.2 Completed updates to 1.2 and 2.0... - removed images directory - removed old scripts in bin dir - added basic deploy and undeploy script to bin Clean/update scripts in bin directory and remove images directory - Key: DAYTRADER-36 URL: https://issues.apache.org/jira/browse/DAYTRADER-36 Project: DayTrader Issue Type: Improvement Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Trivial Fix For: 1.2, 2.0 Per discussion on the dev list, most of the scripts remaining in the bin directory either do not work or are no longer needed. Furthermore, the UI mock ups in the images directory are not necessary. Consequently, the following has been proposed... - Remove all existing scripts from bin except for a deploy and undeploy script and update these scripts to work with Daytrader 1.2/2.0 on Geronimo 1.2/2.0. - Delete the images directory -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-35) Change createDB script for the Geronimo 2.0
[ https://issues.apache.org/jira/browse/DAYTRADER-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-35. - Resolution: Fixed Fix Version/s: 2.0 1.2 Completed updates to 1.2 and 2.0... - moved db creation scripts from modules to bin - updated scripts to work with derby version packaged with Geronimo 1.2 and 2.0 Change createDB script for the Geronimo 2.0 --- Key: DAYTRADER-35 URL: https://issues.apache.org/jira/browse/DAYTRADER-35 Project: DayTrader Issue Type: Improvement Components: buildsystem Reporter: Lasantha Ranaweera Assigned To: Christopher James Blythe Fix For: 1.2, 2.0 Attachments: DAYTRADER-35.patch.patch G 2.0 uses new version of Derby. Existing createDB.sh file has to modify according to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DAYTRADER-24) Clean up plan files in 1.2 branch
[ https://issues.apache.org/jira/browse/DAYTRADER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-24: - Assignee: Christopher James Blythe (was: Matt Hogstrom) Clean up plan files in 1.2 branch - Key: DAYTRADER-24 URL: https://issues.apache.org/jira/browse/DAYTRADER-24 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 Attachments: daytrader-24.1120.patch, daytrader-24.patch The plan files in the 1.2 branch are are based on Geronimo 1.0 and need to be updated (similar to what is in the Daytrader 1.1 branch). It would also be nice if we could add plan files for Oracle and DB2 data sources. However, it looks like we do not include the necessary Tranql rars in Geronimo to support this out of the box. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ https://issues.apache.org/jira/browse/DAYTRADER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-25. - Resolution: Fixed Fix Version/s: 2.0 1.2 Applied code and schema patches to branches/1.2 and trunk. Update decimal precision and indexes in ddl --- Key: DAYTRADER-25 URL: https://issues.apache.org/jira/browse/DAYTRADER-25 Project: DayTrader Issue Type: Improvement Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 Attachments: daytrader-25.code.patch, daytrader-25.schema.patch 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-33) TradeDirect queueOrder fails to close JMS connection
[ https://issues.apache.org/jira/browse/DAYTRADER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-33. - Resolution: Fixed Fix Version/s: 2.0 1.2 Applied patch to branches\1.2 and trunk. TradeDirect queueOrder fails to close JMS connection Key: DAYTRADER-33 URL: https://issues.apache.org/jira/browse/DAYTRADER-33 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Fix For: 1.2, 2.0 Attachments: daytrader-33.patch The queueOrder method in TradeDirect closes the session, but does not close the JMS connection and return it to the pool. Consequently, if asynch 2-phase mode is enabled, the JMS connection pool will eventually throw an exception indicating that no connections are available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-29) Async 1-Phase mode should be removed
[ https://issues.apache.org/jira/browse/DAYTRADER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-29. - Resolution: Fixed Fix Version/s: 2.0 1.2 Applied patches to branches\1.2 and trunk. Trunk also required changes to TradeJPA.java. Async 1-Phase mode should be removed Key: DAYTRADER-29 URL: https://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Fix For: 1.2, 2.0 Attachments: daytrader-29.patch Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ https://issues.apache.org/jira/browse/DAYTRADER-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-25: - Assignee: Christopher James Blythe Update decimal precision and indexes in ddl --- Key: DAYTRADER-25 URL: https://issues.apache.org/jira/browse/DAYTRADER-25 Project: DayTrader Issue Type: Improvement Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Attachments: daytrader-25.code.patch, daytrader-25.schema.patch 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. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DAYTRADER-29) Async 1-Phase mode should be removed
[ https://issues.apache.org/jira/browse/DAYTRADER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-29: - Assignee: Christopher James Blythe Async 1-Phase mode should be removed Key: DAYTRADER-29 URL: https://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Attachments: daytrader-29.patch Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DAYTRADER-33) TradeDirect queueOrder fails to close JMS connection
[ https://issues.apache.org/jira/browse/DAYTRADER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe reassigned DAYTRADER-33: - Assignee: Christopher James Blythe TradeDirect queueOrder fails to close JMS connection Key: DAYTRADER-33 URL: https://issues.apache.org/jira/browse/DAYTRADER-33 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Attachments: daytrader-33.patch The queueOrder method in TradeDirect closes the session, but does not close the JMS connection and return it to the pool. Consequently, if asynch 2-phase mode is enabled, the JMS connection pool will eventually throw an exception indicating that no connections are available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-34) Fix dependency in pom.xml files for dojo-ui and json-proxy modules in trunk
Fix dependency in pom.xml files for dojo-ui and json-proxy modules in trunk --- Key: DAYTRADER-34 URL: https://issues.apache.org/jira/browse/DAYTRADER-34 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Critical The pom.xml files for the dojo-ui and json-proxy modules that were added to trunk (DAYTRADER-17) contained dependencies on daytrader:1.2-SNAPSHOT. This needs to be updated to 2.0-SNAPSHOT in order to build successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-34) Fix dependency in pom.xml files for dojo-ui and json-proxy modules in trunk
[ https://issues.apache.org/jira/browse/DAYTRADER-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-34. - Resolution: Fixed Fix Version/s: 2.0 Already fixed by Matt Hogstrom Fix dependency in pom.xml files for dojo-ui and json-proxy modules in trunk --- Key: DAYTRADER-34 URL: https://issues.apache.org/jira/browse/DAYTRADER-34 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Critical Fix For: 2.0 The pom.xml files for the dojo-ui and json-proxy modules that were added to trunk (DAYTRADER-17) contained dependencies on daytrader:1.2-SNAPSHOT. This needs to be updated to 2.0-SNAPSHOT in order to build successfully. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ https://issues.apache.org/jira/browse/DAYTRADER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-22: -- Fix Version/s: 2.0 Affects Version/s: 2.0 Applied changes to trunk... Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: https://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Piyush Agarwal Assigned To: Christopher James Blythe Fix For: 1.2, 2.0 Attachments: Daytrader-22.patch, Daytrader-22.patch.11152006 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-22) Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs
[ https://issues.apache.org/jira/browse/DAYTRADER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-22. - Resolution: Fixed Set publichQuotePriceChange to true in ejb-jar.xml so that MDBs get accessed during Daytrader scenario runs --- Key: DAYTRADER-22 URL: https://issues.apache.org/jira/browse/DAYTRADER-22 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Piyush Agarwal Assigned To: Christopher James Blythe Fix For: 1.2, 2.0 Attachments: Daytrader-22.patch, Daytrader-22.patch.11152006 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DAYTRADER-28) Un-needed methods in TradeJDBC Remote Interface should be removed
[ https://issues.apache.org/jira/browse/DAYTRADER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-28. - Resolution: Fixed Fix Version/s: 2.0 1.2 Assignee: Christopher James Blythe Un-needed methods in TradeJDBC Remote Interface should be removed - Key: DAYTRADER-28 URL: https://issues.apache.org/jira/browse/DAYTRADER-28 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Assigned To: Christopher James Blythe Priority: Minor Fix For: 1.2, 2.0 Attachments: daytrader-28.patch While developing the SLSB to JDBC mode, the interfaces for the original TradeBean SLSB where used as a template. The methods that are defined in the remote interface for TradeJDBC.java file should be removed since they are not used or implemented in the TradeJDBCBean class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-29) Async 1-Phase mode should be removed
[ https://issues.apache.org/jira/browse/DAYTRADER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-29: -- Attachment: daytrader-29.patch This patch simply removes the async 1-phase mode option. If additional changes are mode to the mode names, etc. a new JIRA will be opened. Async 1-Phase mode should be removed Key: DAYTRADER-29 URL: https://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Attachments: daytrader-29.patch Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-33) TradeDirect queueOrder fails to close JMS connection
TradeDirect queueOrder fails to close JMS connection Key: DAYTRADER-33 URL: https://issues.apache.org/jira/browse/DAYTRADER-33 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe The queueOrder method in TradeDirect closes the session, but does not close the JMS connection and return it to the pool. Consequently, if asynch 2-phase mode is enabled, the JMS connection pool will eventually throw an exception indicating that no connections are available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-33) TradeDirect queueOrder fails to close JMS connection
[ https://issues.apache.org/jira/browse/DAYTRADER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-33: -- Attachment: daytrader-33.patch Here is a patch... NOTE: This patch is dependent upon the patch for DAYTRADER-29. TradeDirect queueOrder fails to close JMS connection Key: DAYTRADER-33 URL: https://issues.apache.org/jira/browse/DAYTRADER-33 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Attachments: daytrader-33.patch The queueOrder method in TradeDirect closes the session, but does not close the JMS connection and return it to the pool. Consequently, if asynch 2-phase mode is enabled, the JMS connection pool will eventually throw an exception indicating that no connections are available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-17) Dojo-based interface for Daytrader
[ https://issues.apache.org/jira/browse/DAYTRADER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-17: -- Attachment: daytrader-17-01092007.zip Dojo-based interface for Daytrader -- Key: DAYTRADER-17 URL: https://issues.apache.org/jira/browse/DAYTRADER-17 Project: DayTrader Issue Type: New Feature Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-17-01092007.zip, daytrader-17.zip Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DAYTRADER-17) Dojo-based interface for Daytrader
[ https://issues.apache.org/jira/browse/DAYTRADER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe updated DAYTRADER-17: -- Attachment: (was: daytrader-17.zip) Dojo-based interface for Daytrader -- Key: DAYTRADER-17 URL: https://issues.apache.org/jira/browse/DAYTRADER-17 Project: DayTrader Issue Type: New Feature Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-17-01092007.zip, daytrader-17.zip Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DAYTRADER-20) Daytrader ear includes lots of kitchen sinks
[ https://issues.apache.org/jira/browse/DAYTRADER-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463572 ] Christopher James Blythe commented on DAYTRADER-20: --- Hmmm. I haven't noted this at all when building from the 1.2 branch. The only jar/war files that are packaged inside the ear are the ones that should be there... Did you make any changes to the 1.2 branch to fix this? Can this issue be closed? Archive: daytrader-ear-1.2-SNAPSHOT.ear testing: META-INF/OK testing: META-INF/MANIFEST.MF OK testing: dt-ejb.jar OK testing: streamer.jar OK testing: wsappclient.jar OK testing: web.war OK testing: META-INF/LICENSE.txt OK testing: META-INF/application.xml OK testing: META-INF/NOTICE.txt OK testing: META-INF/maven/ OK testing: META-INF/maven/org.apache.geronimo.daytrader/ OK testing: META-INF/maven/org.apache.geronimo.daytrader/daytrader-ear/ OK testing: META-INF/maven/org.apache.geronimo.daytrader/daytrader-ear/pom.xml OK testing: META-INF/maven/org.apache.geronimo.daytrader/daytrader-ear/pom.properties OK Daytrader ear includes lots of kitchen sinks Key: DAYTRADER-20 URL: https://issues.apache.org/jira/browse/DAYTRADER-20 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Currently the ear includes about 10-15 dependent jars it shouldn't. The m2 dependency scopes need to be adjusted to fix this. I'll fix this in trunk (2.0), also an issue in 1.2 branch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DAYTRADER-17) Dojo-based interface for Daytrader
[ https://issues.apache.org/jira/browse/DAYTRADER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463565 ] Christopher James Blythe commented on DAYTRADER-17: --- I just uploaded a new patch (daytrader-17-01092007.zip ) which... - Assumes the dojo src is available at /dojo/dojo.js (src is no longer included in the patch) - Supports Dojo 0.4.1 Once installed, the new ui can be accessed at the following url: /dojotrader/trader.html Note: The only existing file updated in the patch is the top-level pom.xml file. Otherwise, the zip file creates three new sub-directories under the modules directory (dojo-ui-ear, dojo-ui-web, json-proxy). Dojo-based interface for Daytrader -- Key: DAYTRADER-17 URL: https://issues.apache.org/jira/browse/DAYTRADER-17 Project: DayTrader Issue Type: New Feature Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-17-01092007.zip, daytrader-17.zip Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2708) ConcurrentModificationException in ConnectionTracking with Daytrader 1.2 under load
ConcurrentModificationException in ConnectionTracking with Daytrader 1.2 under load --- Key: GERONIMO-2708 URL: https://issues.apache.org/jira/browse/GERONIMO-2708 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 1.2 Environment: Geronimo 1.2 from geronimo/sever/branches/1.2 (01/04/2007) RHEL 4 SUN 1.5.0_10 JDK Reporter: Christopher James Blythe Looks like are some concurrency issues with Connection Tracking in Geronimo 1.2. - Built Geronimo from geronimo/sever/branches/1.2 (01/04/2007) - Deployed Daytrader (built from geronimo/daytrader/branches/1.2) - Stressed EJB and Session to JDBC mode with multiple clients using load driver Both tests resulted in the following exception when more than 1 client was driven. NOTE: I went back and double checked on Geronimo 1.1.1 and this does not occur. java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:860) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit(ConnectionTrackingCoordinator.java:92) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$8f3374f8.exit (generated) at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke(NoConnectionEnlistingInterceptor.java:70) at org.apache.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java :35) at org.apache.openejb.security.DefaultSubjectInterceptor.invoke(DefaultSubjectInterceptor.java:49) at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke(DefaultStatelessEjbContainer.java :178) at org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.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:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$34d791e3.invoke(generated) at org.apache.openejb.AbstractEjbDeployment.invoke(AbstractEjbDeployment.java :195) at org.apache.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:145) at org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$3eb3ed90.getQuote(generated) at org.apache.geronimo.samples.daytrader.TradeAction.getQuote(TradeAction.java:331) at org.apache.jsp.displayQuote_jsp._jspService(org.apache.jsp.displayQuote_jsp:71) at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java :672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at
[jira] Commented: (DAYTRADER-17) Dojo-based interface for Daytrader
[ http://issues.apache.org/jira/browse/DAYTRADER-17?page=comments#action_12456442 ] Christopher James Blythe commented on DAYTRADER-17: --- Had a short discussion with Matt the other day... The current patch contains a full-blown 0.4.0 version of the dojo source tree. That adds a lot of files to the Daytrader src tree if checked in as is. Obviously, we could rely on the shared version of Dojo provided by the Geronimo server as Paul has already mentioned. However, this fails to address other application servers that do not provie a Dojo implmentation. Matt and I came up with the following solution... - package up the 0.4.0 dojo src in an independent war file - have the Daytrader dojo UI reference this package - checkin the pre-packaged dojo war as a single file If you would like to switch to the dojo impl provided with Geronimo, simply change the request path in the Daytrader code. Thoughts, comments, suggestions? Dojo-based interface for Daytrader -- Key: DAYTRADER-17 URL: http://issues.apache.org/jira/browse/DAYTRADER-17 Project: DayTrader Issue Type: New Feature Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-17.zip, daytrader-17.zip Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- 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: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ http://issues.apache.org/jira/browse/DAYTRADER-25?page=all ] Christopher James Blythe updated DAYTRADER-25: -- Attachment: daytrader-25.schema.patch Here is a patch to fix the schema files associated with DT-14 (built against the 1.2 branch). This updates the indexes and the decimal precision. 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 Attachments: daytrader-25.schema.patch 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] Updated: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ http://issues.apache.org/jira/browse/DAYTRADER-25?page=all ] Christopher James Blythe updated DAYTRADER-25: -- Attachment: daytrader-25.code.patch This patch updates the quote price change algorithm to that described in my previous comments. The change factor varies between +/- 20% and if stock prices reach a value greater than $400, the price is cut in half. 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 Attachments: daytrader-25.code.patch, daytrader-25.schema.patch 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] Updated: (DAYTRADER-28) Un-needed methods in TradeJDBC Remote Interface should be removed
[ http://issues.apache.org/jira/browse/DAYTRADER-28?page=all ] Christopher James Blythe updated DAYTRADER-28: -- Attachment: daytrader-28.patch Here is a patch to remove all of the methods from the TradeJDBC.java file. Un-needed methods in TradeJDBC Remote Interface should be removed - Key: DAYTRADER-28 URL: http://issues.apache.org/jira/browse/DAYTRADER-28 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Priority: Minor Attachments: daytrader-28.patch While developing the SLSB to JDBC mode, the interfaces for the original TradeBean SLSB where used as a template. The methods that are defined in the remote interface for TradeJDBC.java file should be removed since they are not used or implemented in the TradeJDBCBean class. -- 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-29) Asyc 1-Phase mode should be removed
Asyc 1-Phase mode should be removed --- Key: DAYTRADER-29 URL: http://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- 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: (DAYTRADER-29) Async 1-Phase mode should be removed
[ http://issues.apache.org/jira/browse/DAYTRADER-29?page=all ] Christopher James Blythe updated DAYTRADER-29: -- Summary: Async 1-Phase mode should be removed (was: Asyc 1-Phase mode should be removed) Async 1-Phase mode should be removed Key: DAYTRADER-29 URL: http://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- 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-20) Daytrader ear includes lots of kitchen sinks
[ http://issues.apache.org/jira/browse/DAYTRADER-20?page=comments#action_12454734 ] Christopher James Blythe commented on DAYTRADER-20: --- David... Are you referring to all of the spec dependencies that are riddled throughout the pom.xml files or the actual code dependencies between the Daytrader modules/jars? Chris Daytrader ear includes lots of kitchen sinks Key: DAYTRADER-20 URL: http://issues.apache.org/jira/browse/DAYTRADER-20 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Currently the ear includes about 10-15 dependent jars it shouldn't. The m2 dependency scopes need to be adjusted to fix this. I'll fix this in trunk (2.0), also an issue in 1.2 branch -- 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-23) Decouple backend impls in order to support additional backend implmentations (ie. JPA, EE5, etc)
[ http://issues.apache.org/jira/browse/DAYTRADER-23?page=comments#action_12451386 ] Christopher James Blythe commented on DAYTRADER-23: --- David... I completely understand the reluctence... and you are right, this does add an additional degree of complexity. Nevertheless, I think we need to come up with something to address the following... - Better modularity and package organization - Ability to easily plugin additional backend implementations - Support EE4 technologies (and others) for comparisons Regardless of what we decide, I think #1 is an absolute must. I really hate how the ejb jar contains both EJB and JDBC impls and they are actually dependent upon one another in certain scenarios. Furthermore, I have always wished we could deploy Trade on Tomcat by itself without the EJB impl. As for #2 and #3, the real value in Daytrader and Trade has always been as a means of comparing performance, either for release to release measurement or for comparing technologies. Consequently, it would be nice to have an easily pluggable framework for managing different persistence impls (JDBC, EJB 2.1, JPA, EJB 3.0, Hibernate, Spring, etc.) . From a customers perspective, I would want to be able to use something like Daytrader to measure the performance of the stand JDBC mode and compare it to JPA and see where things shake out to determine what technology I use in the development of an application. In order to do this, I see two options... a) either build a pluggable framework or b) create multiple versions of DayTrader. Lets just say b scares me a lot more than a. I guess before going any further and talking about the details, I should ask if anyone agrees/disagrees with the 3 basic goals I defined above? Chris Decouple backend impls in order to support additional backend implmentations (ie. JPA, EE5, etc) Key: DAYTRADER-23 URL: http://issues.apache.org/jira/browse/DAYTRADER-23 Project: DayTrader Issue Type: New Feature Components: Web Tier, EJB Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Currently, all of the backend impl modes (Direct, EJB and the new SLSB to JDBC) are packaged together inside the ejb.jar. To provide greater flexibility and the ability to support additional back impls, I think we need to re-org the code within Daytrader. I've been brainstorming and have come up with the following... Create interfaces for the DaytraderServices and each of the access beans (ie. QuoteDataBean, OrderDataBean, etc.) util.jar (contains the following...) - Interfaces for access beans - defines interfaces with getters and setters - DaytraderServices (interface) - defines the high level transactions similar to TradeServices - Operation return types are based on access bean interfaces (not impls) - Any other commonly used routines For the EE4 component impls... jdbc-impl.jar (depends on util.jar) - Contains DaytraderJdbcServices class that implements DaytraderServices interface - Also contains impls for access beans that will be used for all EE4 components ejb2.1-impl.jar (depends on util.jar and jdbc-impl.jar) - Contains 2 impls for EJB modes (Session2Jdbc and Session2Entity) - DaytraderSession2JdbcServices class provides SLSB that wrappers DaytraderJdbcServices - DaytraderSession2EntityServices class provides SLSB to Enity bean impl - Both impls depend on access beans defined in jdbc-impl.jar For the EE5/JPA components - Define new access beans for EE5 impls based on interfaces - Also create new impls for DaytraderServices interface Provide DaytraderServicesFactory class which can... - Detect which impls a present during initialization using Class.forName() - Create instances of the desired services given a string parameter (assuming the service available) - Can either be packaged in the war or another utility jar - CANNOT go in util.jar to avoid circular dependency Key points: - New backend impls are isolated to their own jars - Backend impl jars can be removed for AppServers lacking support - Operation return types are based on interfaces (consequently EE4 and EE5 impls could co-exist) - war servlets and JSPs only know about access bean interfaces Any thoughts or comments? -- 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: (DAYTRADER-26) Cannot switch between EJB mode and Session Direct mode
[ http://issues.apache.org/jira/browse/DAYTRADER-26?page=all ] Christopher James Blythe updated DAYTRADER-26: -- Attachment: daytrader-26.patch Cannot switch between EJB mode and Session Direct mode -- Key: DAYTRADER-26 URL: http://issues.apache.org/jira/browse/DAYTRADER-26 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-26.patch Found a small typo that went in with the changes for Stateless Session to JDBC mode that causes an exception when switching between EJB and SessionDirect mode. Will attach the 1-line patch shortly. -- 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-26) Cannot switch between EJB mode and Session Direct mode
Cannot switch between EJB mode and Session Direct mode -- Key: DAYTRADER-26 URL: http://issues.apache.org/jira/browse/DAYTRADER-26 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: Christopher James Blythe Found a small typo that went in with the changes for Stateless Session to JDBC mode that causes an exception when switching between EJB and SessionDirect mode. Will attach the 1-line patch shortly. -- 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: (DAYTRADER-24) Clean up plan files in 1.2 branch
[ http://issues.apache.org/jira/browse/DAYTRADER-24?page=all ] Christopher James Blythe updated DAYTRADER-24: -- Attachment: daytrader-24.1120.patch Needed to add the TradeJDBC session bean definition to the plan files. Although it deploys just fine without the definiiton in there. I also noticed that we have a dependency on the system database. Is that really necessary? Clean up plan files in 1.2 branch - Key: DAYTRADER-24 URL: http://issues.apache.org/jira/browse/DAYTRADER-24 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Minor Attachments: daytrader-24.1120.patch, daytrader-24.patch The plan files in the 1.2 branch are are based on Geronimo 1.0 and need to be updated (similar to what is in the Daytrader 1.1 branch). It would also be nice if we could add plan files for Oracle and DB2 data sources. However, it looks like we do not include the necessary Tranql rars in Geronimo to support this out of the box. -- 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_12450223 ] Christopher James Blythe commented on DAYTRADER-25: --- Matt... You mean it isn't possible for someone to become trillionare in DayTrader? What a crock!!! ;-) Good point... found the code... the creep is due to the quote price updates that occur on every buy and sell. After load, the highest quote price is around $200 and we randomly multiple this by a number form 0.5 to 1.5. Some of the quotes end up as penny stocks while others can balloon to upwards of $1000. If the stock price gets down to $0.01 we automatically bump it up to $6. For the time being, I suggest impossing some kind of ceiling on the maximum stock price and also making it an additive algorithm with less variance. Something like... changeFactor = random() * 0.2 if (random() 0.5) changeFactor *= -1 if (price 400) newPrice = 200; else if (price 0.10) newPrice = 6 else newPrice += price + (changeFactor * price) For Daytrader 2.0, I actually think we could beef up the logic by adding the concerpt of stock splits. When ever we reach the ceiling, we split the stock and double the shares for users holding that stock in their portfolio. 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-25) Update decimal precision and indexes in ddl
[ http://issues.apache.org/jira/browse/DAYTRADER-25?page=comments#action_12450225 ] Christopher James Blythe commented on DAYTRADER-25: --- Opps minor typo... newPrice = price + (changeFactor * price) 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] Updated: (DAYTRADER-24) Clean up plan files in 1.2 branch
[ http://issues.apache.org/jira/browse/DAYTRADER-24?page=all ] Christopher James Blythe updated DAYTRADER-24: -- Attachment: daytrader-24.patch I removed the existing files from the plans directory, moved over the jetty and tomcat plans from the 1.1 branch, and made the following modificatoins: - Updated the password field to passwd in the AccountProfileEJB definition - Removed the dependency on the pre-built derby database - Set the create db flag on the Derby data source to true - Increased the data source max pool size to 30 - Removed the GBean to copy the pre-built derby database If any of these changes are not warrented, let me know... The associated patch file is attached. As a side note, I applied the patch to another workig copy of the repository and noticed that the patch program did not remove the old files. Instead, it merely made them 0 byte files. Is that expected? Chris Clean up plan files in 1.2 branch - Key: DAYTRADER-24 URL: http://issues.apache.org/jira/browse/DAYTRADER-24 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Minor Attachments: daytrader-24.patch The plan files in the 1.2 branch are are based on Geronimo 1.0 and need to be updated (similar to what is in the Daytrader 1.1 branch). It would also be nice if we could add plan files for Oracle and DB2 data sources. However, it looks like we do not include the necessary Tranql rars in Geronimo to support this out of the box. -- 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_12449715 ] Christopher James Blythe commented on DAYTRADER-22: --- All... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I think Andrew Spyker was partly responsible for adding this... so, let me see if I can track him down to get more details. Regardless, I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. Removing this option (and associated dependency) would also make it easier to decouple the app as suggested in Daytrader-23. I like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? 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-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_12449738 ] Christopher James Blythe commented on DAYTRADER-14: --- Piyush... I really like what you have here... It's clean, simple, and makes working with the default derby database so much easier. We no long have to run and external sql script or provide a pre-built derby database. Actually, I went ahead and changed the deployment plans in Daytrader-24 to create the derby db by default. Just a few more comments... - I like how feedback is written to the page while created the db. How do you feel about writing out the status for each sql command that is executed instead of waiting for all of them to complete. If for some reason, one were to fail it would be nice to see it in the browser screen. That way we don't have to dig through the logs to see what happened. - Looks like there might be a type of two in your trace/error statements... In TradeDirect.java - thrown on executing the [foll] sql command: - We need to sync up the ddl files - specifically, the indexes. I will create another JIRA to address this. Chris 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, daytrader-14.patch.1019 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] Created: (DAYTRADER-25) Update decimal precision and indexes in ddl
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-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_12449785 ] Christopher James Blythe commented on DAYTRADER-14: --- To quote the Guinness commercials... Brilliant! 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, daytrader-14.patch.1019 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] Created: (DAYTRADER-23) Decouple backend impls in order to support additional backend implmentations (ie. JPA, EE5, etc)
Decouple backend impls in order to support additional backend implmentations (ie. JPA, EE5, etc) Key: DAYTRADER-23 URL: http://issues.apache.org/jira/browse/DAYTRADER-23 Project: DayTrader Issue Type: New Feature Components: EJB Tier, Web Tier Affects Versions: 2.0 Reporter: Christopher James Blythe Currently, all of the backend impl modes (Direct, EJB and the new SLSB to JDBC) are packaged together inside the ejb.jar. To provide greater flexibility and the ability to support additional back impls, I think we need to re-org the code within Daytrader. I've been brainstorming and have come up with the following... Create interfaces for the DaytraderServices and each of the access beans (ie. QuoteDataBean, OrderDataBean, etc.) util.jar (contains the following...) - Interfaces for access beans - defines interfaces with getters and setters - DaytraderServices (interface) - defines the high level transactions similar to TradeServices - Operation return types are based on access bean interfaces (not impls) - Any other commonly used routines For the EE4 component impls... jdbc-impl.jar (depends on util.jar) - Contains DaytraderJdbcServices class that implements DaytraderServices interface - Also contains impls for access beans that will be used for all EE4 components ejb2.1-impl.jar (depends on util.jar and jdbc-impl.jar) - Contains 2 impls for EJB modes (Session2Jdbc and Session2Entity) - DaytraderSession2JdbcServices class provides SLSB that wrappers DaytraderJdbcServices - DaytraderSession2EntityServices class provides SLSB to Enity bean impl - Both impls depend on access beans defined in jdbc-impl.jar For the EE5/JPA components - Define new access beans for EE5 impls based on interfaces - Also create new impls for DaytraderServices interface Provide DaytraderServicesFactory class which can... - Detect which impls a present during initialization using Class.forName() - Create instances of the desired services given a string parameter (assuming the service available) - Can either be packaged in the war or another utility jar - CANNOT go in util.jar to avoid circular dependency Key points: - New backend impls are isolated to their own jars - Backend impl jars can be removed for AppServers lacking support - Operation return types are based on interfaces (consequently EE4 and EE5 impls could co-exist) - war servlets and JSPs only know about access bean interfaces Any thoughts or comments? -- 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-24) Clean up plan files in 1.2 branch
Clean up plan files in 1.2 branch - Key: DAYTRADER-24 URL: http://issues.apache.org/jira/browse/DAYTRADER-24 Project: DayTrader Issue Type: Bug Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Minor The plan files in the 1.2 branch are are based on Geronimo 1.0 and need to be updated (similar to what is in the Daytrader 1.1 branch). It would also be nice if we could add plan files for Oracle and DB2 data sources. However, it looks like we do not include the necessary Tranql rars in Geronimo to support this out of the box. -- 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-19) Fix various HTML syntax issues and remove un-needed import statements
Fix various HTML syntax issues and remove un-needed import statements - Key: DAYTRADER-19 URL: http://issues.apache.org/jira/browse/DAYTRADER-19 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Trivial Just a few minor changes to the html and jsp files to fix any HTML syntax issues that are raised during eclipse validation. I have also removed a few un-needed import statement from some of the jsps. -- 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: (DAYTRADER-19) Fix various HTML syntax issues and remove un-needed import statements
[ http://issues.apache.org/jira/browse/DAYTRADER-19?page=all ] Christopher James Blythe updated DAYTRADER-19: -- Attachment: daytrader-19.patch Here is the associated patch file built off of the 1.2 branch. Fix various HTML syntax issues and remove un-needed import statements - Key: DAYTRADER-19 URL: http://issues.apache.org/jira/browse/DAYTRADER-19 Project: DayTrader Issue Type: Bug Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Priority: Trivial Attachments: daytrader-19.patch Just a few minor changes to the html and jsp files to fix any HTML syntax issues that are raised during eclipse validation. I have also removed a few un-needed import statement from some of the jsps. -- 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-21) Indicate that MDB primitives are not intended for performance 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 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] Updated: (DAYTRADER-21) Indicate that MDB primitives are not intended for performance testing
[ http://issues.apache.org/jira/browse/DAYTRADER-21?page=all ] Christopher James Blythe updated DAYTRADER-21: -- Attachment: daytrader-21.patch This patch adds statements to the primitive list and individual primitives to indicate that they are not intended for performance 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 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] Updated: (DAYTRADER-21) Indicate that MDB primitives are not intended for performance testing
[ http://issues.apache.org/jira/browse/DAYTRADER-21?page=all ] Christopher James Blythe updated DAYTRADER-21: -- Priority: Minor (was: Major) 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 Priority: Minor 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-17) Dojo-based interface for Daytrader
Dojo-based interface for Daytrader -- Key: DAYTRADER-17 URL: http://issues.apache.org/jira/browse/DAYTRADER-17 Project: DayTrader Issue Type: New Feature Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- 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: (DAYTRADER-17) Dojo-based interface for Daytrader
[ http://issues.apache.org/jira/browse/DAYTRADER-17?page=all ] Christopher James Blythe updated DAYTRADER-17: -- Attachment: daytrader-17.zip Attached is the latest revision of my code which includes the 0.4.0 version of the Dojo toolkit (released late last week). Simply unzip this over an existing daytrader svn repository and build with maven. This package adds three new modules and a plan file for installing the target ear. - dojo-ui-ear - dojo-ui-web (contains the dojo 0.4.0 build and daytrader ui) - json-proxy (contains the web services proxy for interacting with daytrader services) Once installed, the interface can be accessed at... /dojo_trader/daytrader.html As I have already mentioned in posts to the dev list, it seems to be working without any major issues on Firefox and IE; however, it does require the Flash plugin (may do some additional work to remove this dependency if possible). The only qwerk I am seeing right now is that you have to resize the screen after performing the initial page load within Firefox in order for it to complete the layout correctly. Dojo-based interface for Daytrader -- Key: DAYTRADER-17 URL: http://issues.apache.org/jira/browse/DAYTRADER-17 Project: DayTrader Issue Type: New Feature Components: Web Tier Affects Versions: 1.2 Reporter: Christopher James Blythe Attachments: daytrader-17.zip Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- 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_12437908 ] Christopher James Blythe commented on DAYTRADER-14: --- David... this sounds great for use on Geronimo. However, we will still need a method for creating the database tables and indexes on other app servers like JBoss, WebLogic, WebSphere, etc. As a side note, the commands needed to create the tables and indexes are SQL statements themselves and could be executed within the application as JDBC statements. Just brain storming here... we could hook into the buildDB servlet action which populates the database or we could provide another link on the config page to execute the code to create the tables. Once the database is created and we have sufficeint access rights, we should be good to go. The only obsticle I can think of would be if there are any specifics that we need to account for in the schemas for various database vendors (ie. Derby, Oracle, DB2, etc.). Thoughts??? 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-1) [Daytrader] ejb module should not depend on wsappclient module
[ http://issues.apache.org/jira/browse/DAYTRADER-1?page=comments#action_12437912 ] Christopher James Blythe commented on DAYTRADER-1: -- Just out of curiousity, is anyone using the web services app client? Was wondering if we could simply remove it along with the TradeWebSoapProxy? These two are actually independent. The web services app client was created to test web service invocations of the Daytrader web services from a standalone J2EE client. The TradeWebSoapProxy, was added as a means of testing web services and driving the transactions via a browser and the basic servlets/JSPs. Consequently, a request to the action servlet would coordinate with the WebSoapProxy to invoke the target web service. Given the interest in AJAX, I think the AJAX-based interface that is currently in POC would remove the need for these items. [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] Created: (DAYTRADER-11) AccountProfile field password conflicts with DB2 v9.1 keyword
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 Environment: DB2 v9.1 Reporter: Christopher James Blythe Priority: Minor 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] Updated: (DAYTRADER-8) Small difference in sync order processing between Direct and EJB mode
[ http://issues.apache.org/jira/browse/DAYTRADER-8?page=all ]
Christopher James Blythe updated DAYTRADER-8:
-
Attachment: orderPatch.diff
Sorry for the delay in posting this... I wanted to make sure I used the proper
procedure for creating the patch before posting (thanks to Jason for his
input). Also, tested this under load and there seemed to be no ill effects.
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
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] Created: (DAYTRADER-8) Small difference in sync order processing between Direct and EJB mode
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
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...
271002 open2006-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...
272002 closed 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
