While I'm far from an expert on the java gadget server, i have read
almost all code line by line, so while I'm far from an expert and i
might be completely wrong, this is the impression i got so far:
The java server is meant as a base for your own implementation, it
implements a simple in memory cache for instance for the gadget and
message bundle cache, which works of course in small scale
situations, but for large deployments you probably would want to use a
different caching backe-nd (memcached for instance).
The same for the gadget blacklisting, it uses a simple txt file with
regex expressions for blacklisting, which is fine in its self, but you
probably want something more scalable and maintainable then a text
file :-)
Now while there's not a lot of documentation available, it is apparent
in the source that the whole setup is made for expendability, you can
make your own blacklist and caching classes implementing the same
basic interfaces, and configure the server to use those. (The same
kind of extensibility can also be found in the feature support, you
can add your own javascript features, and feature classes in java and
extend your functionality that way)
However it seems the intention that the server doesn't have any
external dependencies (such as a specific sql server or caching back-
end), which is why they choose to make 'basic' versions of everything,
and leaving it to the deploying party to customize this to their own
environment.
-- Chris
On Feb 20, 2008, at 3:04 PM, Martin Webb wrote:
Leaving aside the gadget container, what needs to be done to make
the gadget
server fit for production?
I'd like to see a list of all the gotchas, todos, hacks, workarounds
and
other dubious items that lurk with the codebase. Does such a list
exist?
Would it make sense to create a JIRA specifically for this issue?
For example, I saw a comment that gadget caching is not production
ready?
Regards
Martin
--
Internet Related Technologies - http://www.irt.org
