Michiel Meeuwissen wrote:
Nico Klasens wrote:
Download the war from http://cmsc.finalist.com and put your taglib jar
So, I took the opportunity to try it out...
Which gives me a list of remarks about CMSC first. Perhaps they're
interesting, because I'm a naive user:
The remarks are very relevant. What we try to reach is a point where we
can drop a war into a configured installation without changing anything
in the war. Every installation will tell the war what is expected from
it. All remarks are on my wishlist, but don't have a high priority.
The war you downloaded is the one which is running on cmsc.finalist.com
and is not yet a drop-in war or even a demo war.
- it took me quite some time to get it working. The installation notes
are in the other download.
I tried to get it working on hsql/jdbc.xml but did not succeed, but
perhaps the problem was in something I later solved.
The cmsc uses a datasource configured in tomcat. This datasource is
installed the first time the war is deplayed in tomcat. The war contains
a file META-INF/context.xml which is copied the first time to
$TOMCAT_HOME/conf/Catalina/localhost/cmc-webapp.xml
The default is currently for mysql with cmsc as db/user/password. tomcat
also requires the libs for the conection pool in commn/lib
- logging is configured so that configuration errors in the data-source
appear in the SQL log. Which was not the file I was tailing, so I was
flabbergasted for quite some time..
logging is overly specified anyway, because it is a hard job to set
logging back to service. Also it may be better to leave logging on
stdout in such a general download. "../logs" did not exist for me.
Logging is one of the things I want to move out of the war. The location
and requirements of logging are always different on every system and
environment. Developers like it on stdout and sysadmins in a daily
rolling file in thier logs dir.
- It depends on xerces. It was running tomcat 5.5 on java 1.5, with no
xerces. This gave very very, huge, errors from AJAX in the editors,
essentially saying that org.apache.xml.serialize.OutputFormat was
missing.. Very irritating. I needed to place xercesImp.jar and
xml-apis.jar in common/endorsed to get rid of it. I'd suggest to
remove the dependency, which would make installation a bit easier.
One of the things which are inherited from sources of old projects. I
haven't found a solution yet to do it in a java standard way which
supports all options. I haven't been looking very long.
- If something goes wrong during start up, it remains in an eternal loop
which is supposedly 'waiting for mmbase' (according to a
thread-dump). On the front-end no 503 are reported, during this
waiting, but requests are simply stalled. Also e..g the
tomcat-manager is unreacheable during this (eternal) time.
This is also a point which should be addressed, but there is not a nice
solution present which can be used easily.
- After a restart I needed to login again. I think that is not necessary
any more, because the cloud object in the session is serializable.
The tomcat context file defines a PersistentManager which turns of the
session save feature. No good reason for doing it other than that the
server starts in a clean state.
Anyhow, finally I saw your problem with the locale. A replacement
taglib-jar which is just checking the request property does not cause
it, so I will add that, because it would make me happy too (I only want
to set the locale in the outer-most JSP, perhaps even with <mm:content
language="client").
So, I suppose the cause is somehow related with the checking for the
parent ContextReferrers, because that is the only difference now. I
think you added that at june 7, but I never quite got why.
No, the issue is that it should not set the locale in the CloudTag to
the mmbase locale when nothing is found in surrounding tags. It should
leave the locale untouched.
Okay, I know now how to refactor it nicely. I have to extract another
method which only checks that the locale is set by something in the
current request. The getLocale method will then call getDefaultLocale
when the locale is not found by the new method. CloudTag.checkLocale
will then only call the new method.
Calling ContextReferrers is necessary to find the closest tag which can
provide a locale. A CloudReferrer can then return the locale from the
cloud. In this way you could use the cloud to keep track of which
language the user has selected. It is just one of my attempt to figure
out how to do localization with mmbase.
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
