Page fragment cache with JBoss Treecache, ehcache and a FileSystemCache
by Sebastian Hennebrueder
Hello,
I was working on the http://jira.jboss.com/jira/browse/JBSEAM-1891
and created three caching alternatives which can now be plugged in.
As this is the first thing I write, I would appreciate a feedback, if
the provided solution is what Christian was actually looking for and if
I should continue this or made something completely useless.
I attached the files and testng tests. If this is considered useful, I
can provide a SVN patch as well. All files are new anyway.
Cache Provider:
JBoss TreeCache 1.4
API changes a lot from 1.4 to 2, so we must be careful once the
I did not use the PojoCache as we have only simple Strings and no
complex beans. In that case PojoCache provides only overhead. (info
taken from pojocache wiki).
Eh-Cache
I did not enforce any Transaction guaranties (like READ_COMMITED) as we
have in Hibernate for example.
FileSystemCache
Manually written, idea: a large site cannot be hold in a cache being
present in memory. This cache has a small in memory area holding very
frequent files (size can be configured) and fetches files from disk.
Though the operation system caches access to disk, this is still a lot
slower than memory access but probably faster than having complex
queries to the database (see Seam Wiki queries)
The Cache can already be used in a web application using a custom
renderer kit.
example for components.xml
<component class="org.jboss.seam.cache.PageFragmentCache">
<property name="provider">#{filecache}</property>
</component>
<component class="org.jboss.seam.cache.FileSystemCacheProvider"
name="filecache">
<property name="boostBufferSize">50</property>
<property name="enableStatistics">true</property>
</component>
<component class="org.jboss.seam.statistics.StatisticsManager" />
Another idea:
I introduces a StatisticsManger component which might be used by any
components providing statistic information. This would provide one place
to access statistics of the application or to print a report. If you
like the idea, I would add a MBean wrapping this StatisticsManager else
I'll just remove it from the cache providers.
Some questions:
I did not find a way to access the name of the application (web context)
to use it as prefix for the JBoss TreeCache in case we use multiple
applications on the same system.
Is there a common way to load resources like configuration files? I saw
different approaches in the core code.
Best Regards
Sebastian Hennebrueder
laliluna.de
15 years, 10 months
Seam and RESTEasy integration
by Christian Bauer
On Jul 13, 2008, at 15:04 , Ryan J. McDonough wrote:
> Cool! I'm very interested as to how this is being implemented. Also,
> is this integration going to be part of Seam, RESTEasy, or as a sub-
> module of RESTEasy?
It's going to be part of Seam, planned is a seam-resteasy.jar that you
simply drop into your libs (in addition to any resteasy JARs). That's
how other frameworks and libs are integrated with Seam today. So I
guess we need a RESTEasy dependency in the Seam POMs to compile it
(Pete?).
Same for configuration: Any @Provider and @Path classes are
automatically discovered during Seam application startup when the
RESTEasy libs are in the classpath. If you want to customize settings,
you override a built-in Seam component in a Seam configuration file
(many deployment options here, this is just one of them):
<component name="resteasyApplicationConfig" precedence="20"
class="org.jboss.seam.resteasy.ResteasyApplicationConfig">
<property name="scanForResources">
<value>false</value>
</property>
<property name="resourceClassNames">
<value>my.CatalogResource</value>
<value>my.ItemResource</value>
</property>
... and so on ...
</component>
This Seam component supports all the other settings you'd have in
web.xml with plain RESTEasy. You do not have to touch web.xml at all
with this approach. This Seam component is an extension of the JAX-RS
ApplicationConfig. (By the way, this should be an interface, not an
abstract class... tell the "experts".)
So that allows you to run your existing @Path and @Provider classes in
a Seam app without any additional configuration or changes. Drop the
classes into the classpath and Seam will serve HTTP requests through
its existing resource-loading architecture (the SeamResourceServlet is
enabled in all Seam applications). You can even hook into that request
processing and customize the dispatcher, wrap the request, and so on.
This is regular Seam stuff.
Of course people want that integration not only for integrated
bootstrap and request processing but for the Seam programming model
when writing resources and providers:
1. You can put an @Name onto your @Path root resource class. This
enables Seam lifecycle management for the resource object. If it is
ScopeType.EVENT you basically get the JAX-RS default (POJO per
request) lifecycle. If it is ScopeType.APPLICATION, you get Singleton
lifecycle - you can also put @Synchronized on it. And so on for
ScopeType.SESSION and ScopeType.CONVERSATION. Once your resource
classes and providers are Seam components, you get full Seam
interception for @In(jection), and so on. E.g. you can use @In ItemDAO
on a field in your resource implementation.
2. You can put @Name on your @Provider class. It has to be
ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS
providers I need an extension to RESTEasy. I need to tell RESTEasy how
it should look up an instance of a Provider from Seam at runtime.
Right now you guys only support setProvider(clazz) and
setProviderInstance(o) at bootstrap. I need
setProviderLookup(anImplementationOfALookupInterface) or something
similar.
3. We'll probably have a mechanism for transporting conversation
identifiers in HTTP headers. However, I'm thinking that the way this
should be implemented is with explicit automatically created resources
that identify a particular conversation "workspace". See Bill's blog
about JMS integration and how you'd model a transaction resource
RESTfully. This is the same approach just for Seam conversations.
4. In a second stage we might want to integrate the Seam Application
Framework. This is a basic CRUD framework, today used for quick
development of JSF apps. We can use this as a foundation to expose
entity lists and instances for CRUD/search directly from the database
as HTTP resources. Similar to what Rails does out of the box, just
nicer :)
5. I'm thinking about a special provider that can marshal an object
graph into an XHTML (not just XML) response body and back from an
XHTML request body to an object graph. This is about the
"connectedness" of resources, see the O'Reilly REST book. As a
developer I should write a Facelets XHTML template that defines the
transformation. Imagine that you write it the same way you write a JSF
template today, with bidirectional binding using EL expressions, from
object getter/setter pair to XML attribute or element value. We can
even have built-in Facelets "widgets" that render certain
microformats. Seam has some machinery for this already but we might
need an extra interceptor on resource methods to trigger the
transformation. Or we use Seams pages.xml navigation rules ("when this
resource method finishes, render this template"). Bill, I'm not sure
we even need anything in RESTEasy for that, Seam intercepts these
things anyway if there is a @Name on the class.
Bootstrap, request servicing, and objectives 1 and 2 I already
implemented locally. Let's get the provider lookup for 2 done and I
can commit something into Seam trunk. We'll talk about 3, 4, and 5
later.
15 years, 10 months
Seam Guice integration
by Dan Allen
Given that we have Spring integration in the IoC module, it makes
sense that we would have Guice in there as well. Paul, would you be
interested in seeing the Guice module become part of the Seam project?
Seam devs, would this be something we want to see in Seam? I think it
should.
Granted, I know that there is the whole Web Beans coming down the
pike, but given that this integration is already implemented, why not
make it available in Seam 2.1?
-Dan
--
Dan Allen
Software consultant | Author of Seam in Action
http://www.mojavelinux.com
http://manning.com/dallen
NOTE: While I make a strong effort to keep up with my email on a daily
basis, life and work come first and, at times, keep me away from my mail
for a while. If you contact me, then don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.
15 years, 10 months
