memcached-session-manager Factory class for use with the tomcat-maven-plugin standalone war functionality

This factory can be called from the tomcat standalone bootstrap code to use memcached-session-manager within your standalone project. I only implemented it for TC7 because the standalone war support is only for that version of tomcat. When using this factory, you configure msm with system properties. I could imagine this being improved with models.

Using this patch, in conjunction with a matching tomcat-maven-plugin patch, you can start your standalone project like this:

java -Dmsm.memcachedNodes="n1:localhost:21211" -jar standalone.jar \
   -sessionManagerFactory de.javakaffee.web.msm.MemcachedBackupSessionManagerFactory

The tomcat-maven-plugin pull request can be found here:

https://github.com/apache/tomcat-maven-plugin/pull/5

Dec 11 '13 05:12 jbcpollak

Sounds great to be able to use msm with tomcat-maven-plugin, so thanx a lot for the PR already!

The changes basically look good, I've already added comments to the commit. Two more things:

The selection of supported properties seems to be arbitrary (most "common" ones?), what about adding all properties?
I'm wondering if it makes sense to let MemcachedBackupSessionManager itself support system properties. This would have these advantages:
- No duplication of props
- msm would support configuration via system properties also in "normal" mode (running in tomcat)
I see this disadvantage: it would add lines to MemcachedBackupSessionManager (perhaps it's possible to keep this stuff in an extra class)

What do you think?

Dec 11 '13 08:12 magro

@magro I'm glad you like the idea, I was afraid you might not.

The properties I selected came from TomcatBuilder.java in the core project. In fact, with a bit of abstraction and interfacing, I guess you could change TomcatBuilder to use this factory class.

I don't know what other properties there are, I just used TomcatBuilder as a template. It definitely would make sense to add more, and to centralize their use.

Regarding using system properties more directly in MSM, I think that is a question for you. One of the problems I have with the current way MSM is configured (from <context>), is that with tomcat standalone, I would need to know the parameters at compile time (I think, and if I'm wrong, config would still be complicated).

Putting them in system properties makes it easier to configure at launch time. If you think that utility would be useful to 'regular' users, I guess it should be moved to core. I could see configuring msm as properties from setenv.sh for example, which is where a lot of other configuration gets added.

I'll try and find the logger code and use that in MSMF

Dec 11 '13 17:12 jbcpollak

The properties I selected came from TomcatBuilder.java in the core project. In fact, with a bit of abstraction and interfacing, I guess you could change TomcatBuilder to use this factory class.

Ok, TomcatBuilder was just built to support test setup, that's why it's not complete.

I don't know what other properties there are, I just used TomcatBuilder as a template. It definitely would make sense to add more, and to centralize their use.

All properties are documented on SetupAndConfiguration.

Regarding using system properties more directly in MSM, I think that is a question for you.

Yes, if we could get this as a "side product" somehow it would be great :-) I think the main point is keeping configuration options at one place (e.g. introduce a dedicated Configuration class), so that adding another config option needs only a modification at one place. Otherwise things will get lost/forgotten. Right now all configuration attributes are implemented as setters on MSM, they could be replaced by a single public boolean setProperty(String name, String value) which should be used by tomcat (digester) if a setter is not found.

One of the problems I have with the current way MSM is configured (from ), is that with tomcat standalone, I would need to know the parameters at compile time (I think, and if I'm wrong, config would still be complicated).

Not exactly sure what you mean. But perhaps using convention + reflection is a solution :-)

Putting them in system properties makes it easier to configure at launch time. If you think that utility would be useful to 'regular' users, I guess it should be moved to core. I could see configuring msm as properties from setenv.sh for example, which is where a lot of other configuration gets added.

Sounds good. And a central Configuration class that holds all config attributes :-)

Dec 18 '13 23:12 magro

The properties I selected came from TomcatBuilder.java in the core project. In fact, with a bit of abstraction and interfacing, I guess you could change TomcatBuilder to use this factory class. Ok, TomcatBuilder was just built to support test setup, that's why it's not complete.

I don't know what other properties there are, I just used TomcatBuilder as a template. It definitely would make sense to add more, and to centralize their use. All properties are documented on SetupAndConfiguration.

Ok, thanks!

Regarding using system properties more directly in MSM, I think that is a question for you. Yes, if we could get this as a "side product" somehow it would be great :-) I think the main point is keeping configuration options at one place (e.g. introduce a dedicated Configuration class), so that adding another config option needs only a modification at one place. Otherwise things will get lost/forgotten. Right now all configuration attributes are implemented as setters on MSM, they could be replaced by a single public boolean setProperty(String name, String value) which should be used by tomcat (digester) if a setter is not found.

I'm not sure what you mean by digester, but I do agree centralizing the configuration properties would be a great idea. I don't know if Apache Commons-Configuration would solve this problem, but it might be worth looking in to:

http://commons.apache.org/proper/commons-configuration/

One of the problems I have with the current way MSM is configured (from ), is that with tomcat standalone, I would need to know the parameters at compile time (I think, and if I'm wrong, config would still be complicated). Not exactly sure what you mean. But perhaps using convention + reflection is a solution :-)

Sorry, this was a problem with markdown. I was commenting on the fact that MSM is configured through <context>, and that with standalone tomcat the <context> is defined at compile-time, which makes it tough to do deploy-time configuration.

Putting them in system properties makes it easier to configure at launch time. If you think that utility would be useful to 'regular' users, I guess it should be moved to core. I could see configuring msm as properties from setenv.sh for example, which is where a lot of other configuration gets added. Sounds good. And a central Configuration class that holds all config attributes :-)

I think a centralized Configuration class is a great idea, but it does seem a bit out of scope for this task. Would you consider it a requirement for merging the PR? Would the other code that uses configuration parameters (such as TomcatBuilder) need to be refactored as well?

I would be willing to look into the configuration issue, but I'm hesitant to make any significant changes without your approval of the general direction.

Dec 18 '13 23:12 jbcpollak

I'm not sure what you mean by digester, but I do agree centralizing the configuration properties would be a great idea.

With digester I'm referring to http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/util/digester/package-summary.html#package_description.

But that's not important, the thing to remember is that msm (MemcachedBackupSessionManager) can handle arbitrary configuration properties via setProperty(String name, String value) and pass this to our configuration object.

I don't know if Apache Commons-Configuration would solve this problem, but it might be worth looking in to:

http://commons.apache.org/proper/commons-configuration/

I don't think we need to pull in another lib, our task is very simple and setProperty + our own Configuration class is all we need IMO.

Sorry, this was a problem with markdown. I was commenting on the fact that MSM is configured through ||, and that with standalone tomcat the || is defined at compile-time, which makes it tough to do deploy-time configuration.

Still not sure what you mean. Do you have some code to show what you mean with configuration at compile time, and maybe provide some pseudo code that shows what you'd like to do but you think you're unable to do?

FWIW, with a central Configuration class this one could initialize itself from environment variables on construction, so I think it could easily provide the dynamic/runtime stuff you're looking for.

I think a centralized Configuration class is a great idea, but it does seem a bit out of scope for this task. Would you consider it a requirement for merging the PR?

After thinking about it, Yes. The Factory thing does not add that much value compared to the maintenance costs, so it's not a real improvement from my point of view. Because the PR basically wants to get configuration via system properties IMO the improvement would not be to add another layer that needs maintenance but to simplify / consolidate the current configuration approach. Also I don't think that the central configuration thing is that hard to realize. If you need some rough start / pseudo code of what I have in mind let me know.

Dec 19 '13 09:12 magro

Sorry, this was a problem with markdown. I was commenting on the fact that MSM is configured through ||, and that with standalone tomcat the || is defined at compile-time, which makes it tough to do deploy-time configuration. Still not sure what you mean. Do you have some code to show what you mean with configuration at compile time, and maybe provide some pseudo code that shows what you'd like to do but you think you're unable to do?

Just to touch on this quickly, I'll respond more deeply to your other comments when I have some time to think about them carefully. With the Tomcat-Standalone, the context.xml and server.xml are configured in the pom.xml file at compile-time and embedded in your war file.

In the case of MSM, the hostnames and IP addresses of your memcache servers are configured in the context. There is no (simple) provision in Tomcat Standalone to load configs (like server.xml or context.xml) at runtime, so you can't configure MSM's memcache servers at runtime without supporting loading configuration from alternate sources, like system properties.

I hope that makes sense.

Dec 19 '13 16:12 jbcpollak

Ok, that makes it clear.

Dec 21 '13 00:12 magro

You can configure and alternate server.xml path at tomcat standalone with java -jar yourstandalone.jar -serverXmlPath myserver.xml xxx.

But...

I build my standalones with following server.xml an use system properties

<Server ...

...

Then you can configure memcache server setup with system.properties. Why is that a problem?

Dec 21 '13 09:12 rossbachp

Sorry...!

<Host ..>
<Context docBase="myapps.war"
                         path="/myapps"
                         >
    <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="${mc.nodes}"
failoverNodes="${mc.failovernodes}" 
requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
enableStatistics="true" />
</Context>
</Host>
</Server>

Dec 21 '13 09:12 rossbachp

Thanks for this hint @rossbachp! Is this a possible solution for you, @jbcpollak?

Jan 01 '14 23:01 magro

Hi, sorry for the delay and thanks for the comments @rossbachp . I didn't know you could use system properties in server.xml, so that is very informative, and would certainly go a long way to helping. I had trouble using custom server.xml files with the standalone jar, it simply wasn't working.

Let me give it a shot (it might be a few weeks till I can get back to this), and I'll report back.

Jan 03 '14 04:01 jbcpollak

@rossbachp - We are starting to look into your solution now. Is there a standard file in Java to specify properties in? (You mentioned system.properties) or do you use -DpropertyName= for all of the properties you want to set?

Jun 16 '14 18:06 jbcpollak