Hi Asankha, thanks for your reply! Were can I find more information about the WAR distribution model? What are the advantages/disadvantages of using a WAR versus standalone? What do you recommand for which purpose? We could also deploy a WAR-file inside a JBossAS, but I'm not sure about the advantages. Does this change anything regarding JMX-usage or clustering support? You probably still use or own implementations or am I wrong? I understand the reasoning of your change, but modifying a properties file inside of a JAR file is not a optimal solution. Do you expect your users to repackage the JAR? Sorry, if I get something wrong here. And yes, I had to modify the wrapper.conf. I had to add entries like that for the cluster management stuff wrapper.java.additional.13=-Dcom.sun.management.jmxremote.port=14121 wrapper.java.additional.14=-Dcom.sun.management.jmxremote.authenticate=false wrapper.java.additional.15=-Dcom.sun.management.jmxremote.ssl=false wrapper.java.additional.16=-Dorg.tanukisoftware.wrapper.WrapperManager.mbean=true I have to check how the graceful cluster restart will work. Maybe I don't need access to JMX of the wrapper and JMX to each instance is sufficient. We still need some way to update the configuration of the ESB-cluster while the system is running. You already implemented the gracful shutdown, which is the basis for that. We also had to increase the default values for initmemory and maxmemory in that file. I'm not sure about the GUI-driven installer. This surely would make things easier for first time users playing around with the ESB, but would not be that helpful to configure production environements where everything is most likely shell and script based. Regards, Eric
________________________________ Von: [EMAIL PROTECTED] im Auftrag von Asankha C. Perera Gesendet: Sa 10.05.2008 21:40 An: [email protected] Betreff: Re: [esb-java-dev] ESB configuration Hi Eric from a users perspective the current configuration approach is somehow confusing. The configuration is scattered in different configuration files. This is party due to the fact that we want to support a WAR distribution model along with the standalone.. Since in the standalone model, we start an embedded Tomcat instance (using the shell scripts, bat files, and wrapper etc), we want to initialize the ESB the same way for both distributions - i.e. using the startup servlet. This would guarantee that we do not break the WAR model as well. During the startup of Tomcat, we do not want anything related to Synapse or ESB in the classpath, but everything has to be loaded from the WAR class loader. Thus the reason to move the Tomcat startup into a separate JAR. Since we cannot move the logic that earlier parsed the server.xml into this, I had to introduce the tomcat.properties webapp\WEB-INF\classes\conf\axis2.xml HttpCoreNIOListener Port HttpCoreNIOSSLListener Port If we think about the axis2.xml, thats where all transports will be configured.. I think the solution to this is to give better documentation, and educate the users on how things can be changed - like a how-to guide maybe? webapp\WEB-INF\classes\conf\server.xml RMI-JMX-Port HTTPPort --> since a few weeks also redundantly here (see above) HTTPSPort --> since a few weeks also redundantly here (see above) DerbyPort --> rundundantly within the same file (also in the JDBC-URL) We will review the redundant declarations, and see if we can improve these.. AdminConsolePort --> since Asanhkas commit on Friday moved to: tomcat\lib\wso2-esb-startup-SNAPSHOT.jar\tomcat.properties which from a configuration point of view makes things even worse. How can we now change the admin port? We need to be able to change the port! This is via "ConsolePort=9443" on the tomcat.properties webapp\WEB-INF\classes\conf\wrapper.conf RMI-JMX-Port of wrapper I do not think you need to edit anything on the wrapper.conf.. did you have to? Ports are only one example. The user needs to know a bunch of configuration files and options. Can we somehow change this, that at least the most common options can be configured in a single file? Configuring the same options in different files rundundantly, like the http/https listener ports, has to be avoided. What if the values don't match? This can happen quite easily. A solution to this maybe something like a GUI driven installer..? Which asks a few questions, and configures the instance accordingly.. will this work? asankha
<<winmail.dat>>
_______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
