Details
-
Type:
Task
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: None
-
Component/s: Configuration, Configuration Management, Development
-
Security Level: Public (Public: Anyone can view)
-
Labels:
-
Similar issues:
KULRICE-2816Deploy Rice standalone server with Recipe sample app to test environments KULRICE-2932rice-config.xml for deployment of standalone server KULRICE-2764Deploy Rice standalone server to our test environments KULRICE-3061Finish getting Rice test environments in place KULRICE-1475Deploy a test Rice Standalone application to a test environment KULRICE-6749Configure rice sample app as a client app running against a standalone server KULRICE-11774Create performance test environment: Standalone Server Oracle, Rice Sample App Client Oracle, KRAD Client Oracle KULRICE-11775Create performance test environment: Standalone Server MySQL, KRAD Client MySQL, Rice Sample App Client MySQL KULRICE-2695Create a rice-sample-applications repository in SVN and update sample embedded and thin client examples from 0.9.2/0.9.3 and put them in there KULRICE-14260Continuous Deployment: CI PoC for the testing and auto merging -
KAI Review Status:Not Required
-
KTI Review Status:Not Required
Description
In order to properly testing various remoting features (not to mention the suggested enterprise deployment model for Rice), we need to do some work to allow us to separate the sample application of Rice and deploy it as a separate application integrated with a standalone rice server. We also need to:
1) Make it easy for a developer to start up in this mode, either with one or two tomcats depending on what is easier.
2) Put an automated process into place that will deploy the sample app and the standalone server into separate application servers with different databases, but integrated with each other.
This is critical in order for us to test various configurations of rice as well as for proper load and performance testing and things of that nature.
Activity
Resolved per conversation with Eric W and Jeremy. Opening a separate jira for development environment config
http://evn4.rice.kuali.org talks to http://env5.rice.kuali.org now.
After adding a parameter to env5, it can be searched for and located by env4.
Planned process we're going with:
- Rice Sampleapp on ENV4.
- URL is http://env4.rice.kuali.org/
- Has its own database schema via RDS
- Setup to run standalone with Rice URLs pointing to proxying apache server
- Built as overlay to original Rice Application
- Rice Main Application on ENV5
- URL is http://env5.rice.kuali.org/
- Even though sample application (ENV4) is an overlay and essentially has all the pieces of rice it needs, it will be communicating to the ESB and rice components on ENV5.
- Has its own database schema via RDS
- Apache Web Server proxying env4 and env5 to the url http://sampleapp.rice.kuali.org/ (or something)
- We require this because of domain restrictions for communication between env4 and env5. The simplest thing to do is to run both of these applications under the same domain. Even thought these will have separate servers, they will not be known from the application perspective.
Wouldn't easy for developer mean seamless as far a development process goes? That way developers can switch between modes without much configuration or complicated workflow. I'm guessing this would need to be seamless between IntelliJ IDEA and Eclipse, so probably the tomcat/jetty maven plugins. The xml configuration is maybe the most complicated part. Seamlessly switching between standalone and embedded applications means being able to seamlessly swap out those configs. Right now the sampleapp uses the rice-config.xml. Maybe it should become its own application completely. Then, you could have two sample applications. One is sampleapp-embedded and sampleapp-standalone. That would make it very easy to switch between or even run separately at the same time (not that you would want to ever do that). You would just start one application or another.
According to Jeff, CM Team (Leo) can work on second part, but the first one needs clarification on what "easy for a developer" means.
Changing to blocker because this is critical for beta testers. Without it verified and working, some beta testers may not be able to test.
Closing since these items are now in the release notes.