the parody of mocks in JSF
by Dan Allen
It's hard to believe that for as long as JSF has been around, the only
decent repository of mocks for the JSF API comes not from the
implementation, but rather from all but dead and irrelevant project at
Apache (Shale). Of course, Seam 2 forged it's own path and has a healthy set
of mocks, although still somewhat incomplete and vagrant. In the Seam 3
spirit of modularity, I would like to migrate the Seam 2 mocks into a mock
module in Seam 3 that provides mock/stub object for various Java EE APIs. I
plan to categorize them by spec under the org.jboss.seam.mock folder
JSF - org.jboss.seam.mock.faces
Servlet - org.jboss.seam.mock.servlet
etc
This module should not depend on any other module so that it is easy to
reuse, perhaps even outside of the Seam framework. Perhaps seam-mock can end
up replacing Shale test. Who knows. We'll just let it play out. Please
contribute your ideas/use cases!
http://anonsvn.jboss.org/repos/seam/modules/trunk/mock/
As for the functionality, my feeling is that the mocks should be functional
as long as each class behaves like a bean. That means it shouldn't parse XML
documents or make similar assumptions. But they should be easy enough to
extend that perhaps you can add that functionality in your test case or we
can think about providing an additional subclass or helper if the need is
common (perhaps parsing an web.xml document).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but 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, 6 months
moving forward 2.1.2.CR2
by Norman Richards
We need to get 2.1.2 wrapped up. I've moved doc issues to the final
release. Can everyone take a quick at the remaining CR2 tasks and
either resolve them or move them to 2.1.2 (if they are small bug
fixes) or 2.2 if they are too big. If there's anything that needs in
2.1.2 and you don't have time to finish it, please let me know.
Thanks.
15 years, 6 months
Seam 3 porting issues
by Shane Bryzak
To get the ball rolling, I've hand picked a couple of the more important
issues from my list. We can discuss these in more depth during the conf
call, however I would like people to start thinking about them now.
1. Obtaining instances to a Web Beans component from outside of the
component framework. There are a number of places that we need to do
this. I got around it in SeamLoginModule by extending the
CallbackHandler to support callbacks for Identity, Authenticator, etc.
We unfortunately don't have such an easy workaround in other places -
here's just a few examples:
* DroolsHandler (which is a jBPM handler) needs to access the
Expressions and WorkingMemory components.
* SeamGlobalResolver (which resolves Drools global variables) needs to
get an instance of Manager to perform lookups.
* EntitySecurityListener and HibernateSecurityInterceptor both require
access to security components.
* DateConverter needs to access the TimeZone and Locale components
One possible solution to this issue is to have a thread local Manager
available for the lifecycle of a single request, which can be accessed
by non-component classes.
2. Module granularity / dependencies. I'm going to use security as an
example for this issue, however there are other modules which are
similarly affected. Within the security module, there are certain
features (such as the action components, RememberMe, etc) that depend on
the faces module. My preference is to not have any dependencies on
faces and that the security module remains view-layer independent.
One possible way to solve this issue is to introduce a bridging module,
in this example it would be seam-faces-security which contains the
functionality that you would require if you were using Seam Security in
a JSF environment. The only downside to this is that it may lead to jar
bloat (which may not really be an issue). The upside is that it keeps
everything nice and modular, and helps to simplify the dependency tree.
Shane
15 years, 6 months
laying the tracks for Seam 3
by Dan Allen
I'd like to start a new thread to discuss the Seam 3 foundation (since this
is no longer about the Seam 2.1 branch).
So far, we have four main SVN divisions:
examples
modules
docs
sandbox
I raised the question whether we should divide up modules into official,
sandbox, and thirdparty. Shane said that likely we don't need that
fine-grained of a division. However, I'm still concerned that sandbox is too
vague (the name reminds me of Tomahawk sandbox which is just a mess, IMO).
Plus, examples might need a sandbox. So perhaps we can have
modules
modules-sandbox
examples
examples-sandbox
Moving on, we are going to use a Maven structure for everything and which
closely resembles Web Beans. In fact, they should remain very close in
appearance for consistency.
Here's the inheritance for each Seam module:
webbeans/version-matrix (Pete, is this right?)
modules/version-matrix
modules/parent
modules/%modulename%
That would simply be expressed as:
<parent>
<artifactId>seam-parent</artifactId>
<groupId>org.jboss.seam</groupId>
<version>3.0.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>org.jboss.seam</groupId>
<artifactId>seam-%modulename%</artifactId>
<packaging>jar</packaging>
<version>3.0.0-SNAPSHOT</version>
<name>Seam %modulename%</name>
Of course, a module could be a parent to other modules, such as document
perhaps.
Examples have a different inheritance hierarchy
webbeans/version-matrix (correct?)
modules/version-matrix
examples/parent
examples/%examplename%
The first example (booking) will be using JSF 2.0. I'm going to express this
as a dependency per example right now because I'm thinking we still want
Seam 3 to work with JSF 1.2 (or should we?). I'll also assume that the app
server has JSF 2.0. We might want a build somewhere that can install JSF 2
into JBoss AS just like Web Beans has. Of course, we are waiting on a
deployer from my understanding.
I'll also use the Web Beans logging extension in the examples. I'll
coordinate closely with Shane to get the Seam security module running in the
booking. Shane, feel free to make changes/additions in booking. I'll keep
SVN up to date.
Discussing modules, we definitely need a few more than are currently listed.
Here are several I think we need:
faces (which would have page actions, faces messages, and perhaps engulf the
current ui too)
pageflow (I think this should not be considered an extension of bpm anymore
since it is really standalone)
That's all I've got at the moment. Feel free to correct me anywhere. These
are brainstorms.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but 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, 6 months
